Online Journal Edit and Budget Checking in 9.2
If you are upgrading to 9.2 you should be aware of a change to how Journal Edit and Budget Checking is run when kicked off online. Previously when you brought up a Journal online and initiated a Journal Edit, an App Engine would be kicked off on the Process Scheduler. Starting in 9.2, this Application Engine is now running on the App Server.
With this approach there is the potential for the AE to timeout depending on your app server settings - often this is set to 5 minutes. If this timeout occurs, then you will be logged out of your session and the Journal will be left stuck somewhere in the middle of the process. At that point you would need to come up with some SQL to reset flags and other data in order to process again.
In general, this process should finish rather quickly so you shouldn't have to worry. But there are two scenarios in which you may find yourself butting up against the timeout limit:
With this approach there is the potential for the AE to timeout depending on your app server settings - often this is set to 5 minutes. If this timeout occurs, then you will be logged out of your session and the Journal will be left stuck somewhere in the middle of the process. At that point you would need to come up with some SQL to reset flags and other data in order to process again.
In general, this process should finish rather quickly so you shouldn't have to worry. But there are two scenarios in which you may find yourself butting up against the timeout limit:
- Processing a Journal with a vary large number of lines, especially lines that have complicated coding.
- Many users all processing Journal Edits concurrently, must likely at month end.
A major factor in the performance of these App Engines is the configuration and usage of temp tables. If you run into issues, review these temp tables with your DBA. The tables may need data cleanup and stats reviewed. It appears the online instances of these temp tables will need some hand holding until we see a few more images released. There are some MOS documents out there referencing some bugs and explaining how to perform cleanup on these tables until they have some issues worked out.
If you are still seeing timeout issues, you may need to add more temp table instances. This can be helpful if you have many concurrent users running the App Engine. This change should be reviewed carefully, since it can have a large impact on your database. The amount of temp tables instances available for use by an Online App Engine is determined by a PeopleTools configuration, which is a system wide setting. If this setting was 3, which is the default, then PS_TEMP1, PS_TEMP2 and PS_TEMP3 would all be dedicated to online instances. For App Engines run on the process scheduler, the amount of instances is taken from the App Engine setting in App Designer. If this setting is also 3, then tables PS_TEMP4, PS_TEMP5 and PS_TEMP6 could be used. So the total amount of temp table instances will be the online instance count plus the count set on each App Engine that uses the table.
If you are still seeing timeout issues, you may need to add more temp table instances. This can be helpful if you have many concurrent users running the App Engine. This change should be reviewed carefully, since it can have a large impact on your database. The amount of temp tables instances available for use by an Online App Engine is determined by a PeopleTools configuration, which is a system wide setting. If this setting was 3, which is the default, then PS_TEMP1, PS_TEMP2 and PS_TEMP3 would all be dedicated to online instances. For App Engines run on the process scheduler, the amount of instances is taken from the App Engine setting in App Designer. If this setting is also 3, then tables PS_TEMP4, PS_TEMP5 and PS_TEMP6 could be used. So the total amount of temp table instances will be the online instance count plus the count set on each App Engine that uses the table.
Comments
Post a Comment