You can redefine two methods of the DXACTBAS1 ancestor class to perform one-off tasks when your Activity Processor is loaded and unloaded by the Processing Sequence controller. These methods are:

  • ActivityLoad
  • ActivityUnload

These methods may become particularly significant when your Activity is defined with the Keep Active attribute. In this case, for a Processing Sequence that executes the activity more than once, the sequence of method calls in the Activity Processor is like this:

  • ActivityLoad (the first time the Activity is executed)
    • ActivityInit … ActivityRun … ActivityTerm (for each time the Activity is executed)
    • ActivityInit … ActivityRun … ActivityTerm (for each time the Activity is executed)
    • Etc …
  • ActivityUnload (when the Processing Sequence ends)
Note: The Keep Active attribute does not guarantee that your Activity Processor will be loaded and unloaded only once. Under some circumstances, including specifically when the Activity return code indicates an exception, the Processing Sequence controller will unload the Activity Processor (and reload it again, if necessary, for subsequent instances of the Activity).

Defining your Activity with the Keep Active attribute (and implementing your Activity Processor to support it) can offer the potential of significant performance benefits for Activities:

  • That are likely to be used more than once in a Processing Sequence run.
  • That have a significant load and/or unload cost (in performance terms) that need not be repeated for every execution of the Activity.

For example, an Activity that exclusively uses a single LANSA Integrator (JSM) service could be written to load and initialize the service and then use the same connection handle for all subsequent executions in the same Processing Sequence. In this event, it might redefine the ActivityUnload method to unload the JSM service and close the JSM connection.

Note: The Activity Processor must be written to fully support this mode of execution. Simply setting the Keep Active attribute for an existing Activity without reviewing and revising the Activity Processor may introduce unanticipated bugs. For example, the Activity Processor might have been written with the assumption that all its variables were initialized for each execution of the Activity. When you set the Keep Active attribute, this assumption will no longer be valid.
  • No labels