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.
DayStepSizegreater than 1, which means execute every
Ndays. In the scheduler this adds
Ndays from the start date for each next execution. After conversion to Task Planner this always starts at the 1st of month and then adds
Ndays for each next execution. If the
DayStepSizeis 7 then it will convert to a weekly interval.
WeekStepSizegreater than 1, which means every
Nweeks. If it is 2 then a
Two Weeksinterval will be used. Other values are not supported in the Task Planner and when converting this it will set the
MonthStepSizegreater than 1, which means every
Nmonths. In the scheduler this adds
Nmonths 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
Nmonths 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
MonthStepSizeis 2, 3, 4, 6 or 12. For other values it will be every
Nmonths, but the execution month will likely be wrong.
YearStepSizegreater than 1, which means every
Nyears. This is not supported in the Task Planner and when converting this it will set the
Nexecutions 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.