{{getLoggedInUser() == undefined? getMsg('unknownUser') : getLoggedInUser()}}
The following chapters describe the various things to know when migrating from version 16.x of i-net Clear Reports to version 17.x. If you migrate from older versions of i-net Clear Reports, then you should also read the other migration information depending on the version that you migrate from.
Every Scheduler task since version 12 will be migrated to the Task Planner in the setup when updating a system that used the previous Scheduler.
Migrating tasks from the Scheduler to the Task Planner
When tasks are migrated from Scheduler to Task Planner, some minor issues may arise, since many things have been streamlined and simplified. See the following hints.
as file: was removed, which gave each generated report a different name. Now the name of the generated file(s) come from the title configured in the report template (*.rpt). However, the
File System Action has an option
File Name Format which allows you to construct a unique name.
Save (on servers file system) the settings
Attach date and
Attach time was combined into the option
File Name Format.
Send via Email, the CC and BCC options were removed, and values from CC are added as normal receivers. The options
Put reports in a zip file,
Attach date and
Attach time were removed.
Print (at server-known printer) the option
Count of Copies was removed, it always prints once. Other even older options like
orientation and
quality which were only available via Java API were also removed.
There are some rare combinations of settings which were possible with the old Scheduler but are no longer possible with the Task Planner. It is possible some of the more exotic settings will get a slightly different behavior in the Task Planner.
DayStepSize greater than 1, which means execute every
N days. In the scheduler this adds
N days from the start date for each next execution. After conversion to Task Planner this always starts at the 1st of month and then adds
N days for each next execution. If the
DayStepSize is 7 then it will convert to a weekly interval.
WeekStepSize greater than 1, which means every
N weeks. If it is 2 then a
Two Weeks interval will be used. Other values are not supported in the Task Planner and when converting this it will set the
WeekStepSize to 1.
MonthStepSize greater than 1, which means every
N months. In the scheduler this adds
N months to the start date for each next execution. This can only be represented with a Cron Trigger. The Cron starts at a given month and then adds
N months for the next execution. When converting such tasks it will determine the start-month automatically in order to match the correct interval. This only works if the
MonthStepSize is 2, 3, 4, 6 or 12. For other values it will be every
N months, but the execution month will likely be wrong.
YearStepSize greater than 1, which means every
N years. This is not supported in the Task Planner and when converting this it will set the
YearStepSize to 1.
N executions or after a given Date: this feature is not available in the Task Planner. When converting expired tasks they will be deactivated.
Old custom actions will not work after migrating to the Task Planner. Those actions must be replaced with custom Jobs and/or Actions. See the programming samples for how to implement your own Job or Action.
Old dynamic properties classes will not work after migration to Task Planner. If you loaded your dynamic values from a Database then you can probably replace your custom dynamic properties with a Database Series. For other cases it should be replaced with a custom Series implementation. See the programming samples for how to implement your own Series type.
In Task Planner, each task always must have an owner, so a task belongs to a user. Migrated tasks will have Scheduler as owner. Because certain triggers, jobs and result handlers require certain permissions the artificial user Scheduler gets some permissions automatically if you have System Permissions enabled. If you remove the permissions it can happen that tasks can no longer be executed.
If you want to move the tasks to another user then you must duplicate a task and then delete the old one. The new task will belong to the currently logged in user.
Due to the new user the reporting server is running with there may be permission problems when accessing the Repository browser. You should look up the path of your repository in the Configuration Manager and check the permissions of this path in a console program on the server.
It is important for the reporting server that its user has read+write permissions to every file and additional execute permissions for directories. The owner of each file and directory should be the user the reporting server is executed with.
You can find out the respective user using ps aux | grep java.
A server restart is required after these changes were made.
The following chapters describes the various things to know when migrating from version 15.x of i-net Clear Reports to version 16.x. If you migrate from older versions of i-net Clear Reports then you should also read the other migration information depending on the version that you migrate from.
The i-net Designer and the i-net Clear Reports server now requires Java 8 as minimum version of the Java virtual machine. The i-net Clear Reports viewer requires Java 7.
The report server use a 64bit Java VM. As the 32 bit and 64 bit preferences on Windows are stored on different locations it may be necessary to export the configuration using the older i-net Clear Reports version and import it using i-net Clear Reports version 16.
The following chapters describes the various things to know when migrating from version 14.x of i-net Clear Reports to version 15.x. If you migrate from older versions of i-net Clear Reports then you should also read the other migration information depending on the version that you migrate from.
The i-net Clear Reports web server was moved into a plug-in. Since plug-ins will be initialized automatically, the web server will start automatically, for example if the API was used. You need to remove the webserver plug-in if you embedd i-net Clear Reports instead of using it as report server.
The setup and report server on Windows use a 64bit Java VM to install and use i-net Clear Reports. As the 32 bit and 64 bit preferences on Windows are stored on different locations it may be necessary to export the configuration using the older i-net Clear Reports version and import it using version 15.
In the configuration manager dialog "Plugins" it is now possible to activate/deactivate plugins to extend or restrict the functionality of i-net Clear Reports. Some plugins are deactivated by default, e.g. Statistics and Scheduler.
The following chapters describes the various things to know when migrating from version 13.x of i-net Clear Reports to version 14.x. If you migrate from older versions of i-net Clear Reports then you should also read the migration information depending on the version that you migrate from.
With version 14 we are introduced the concept of plugins to i-net Clear Reports. This removes a large amount of libraries from the installation and adds a single zip file per feature. This makes it much easier to say which library is required for a specific feature, this also avoids ClassNotFoundExceptions which could occur when removing libraries for features you didn't need.
Every plugin is a single zip file. All plugins are located in a folder named "plugins". On server start this directory is scanned and a plugin dependency hierarchy is created. All plugins with unresolved dependencies will be disabled. Now the start classes of all valid plugins are instantiated and the extensions for the core or other plugins are registered. The last step is the initialization of all valid plugins. To check which plugins were successfully loaded, activate the logging of i-net Clear Reports and set the log level to at least INFO.
A plugin is a zip file. It contains at least the files "plugin.properties" and "server.jar". The plugin.properties defines the start class which implements the interface com.inet.plugin.ServerPlugin. Further properties of the plugin are defined by annotations of the start class. These annotations cover the id of the plugin, its dependencies and the plugin version. For further details refer to the Server Programming Guide.
If you are using a custom scheduler action and/or dynamic properties, it is necessary to write a plugin for this action and/or dynamic property class. Registering custom actions or dynamic properties to the scheduler does no longer work by adding a jar-file to the lib path. For more information please refer to the samples in the i-net Clear Reports installation directory.
The email settings in the configuration moved from the category "Scheduler" into the new category "Email Settings" because they are used by "Error Notifications" as well.
It is now possible to display a link with a support email address in the error dialog of HTML and Java report viewer. You can configure it in the configuration manager category "Email settings". The default value is "clearreports@inetsoftware.de".
It is now possible to send an email notification in case of an error. In the new plugin "Error Notifications" you can set an email address to which all error notifications will be send.
