9.6.10 Supporting Restartable Activities
If an instance of your Activity Processor ends with an exception return code and if you have defined the Activity with the attribute, then the Processing Sequence run may be eligible to be restarted from the point of failure.
Refer to Activity Details for information about setting the attribute in an Activity definition.
Refer to Restart a Processing Sequence Run for information on conditions that affect the eligibility of a Processing Sequence run to be restarted.
Your decision whether to allow your Activity to be will be influenced by a number of factors including:
- The risks of an exception being returned by your Activity Processor that might require a restart
- The need for your business process integration solution to be able to handle the restart in a largely automated manner, given the risks.
- The nature of the logical unit of work that the Activity performs
- The nature of the processing steps necessary to perform that work
- How you choose to implement those steps and whether sufficient information can and will be available through variable data in the variable pool or by any other means to enable your implementation to accurately and reliably restart processing at any given point of failure.
Before making your decision, you should understand that, in general, writing an Activity Processor to be requires greater skill, greater understanding of LANSA Composer processing and is more prone to error.
Remember, too:
- LANSA Composer's ability to restart a Processing Sequence depends on an error status having previously been returned by the activity. (Processing Sequences that end in error due to an abnormal program termination are not restartable.) Therefore, if your Activity Processor does not have any condition that causes it to set an error status in the Activity return code (and it is not an Iterator Activity), there is little point in implementing the restart support.
- Many of the common transport and other Activities supplied with LANSA Composer are supplied as restartable. If you were to consider the risks of failure in your business process integration solutions, it may be that you would conclude that the risk of failure in the course of normal operation was greater in those areas than in the functions encapsulated by your own Activity Processors. In that case, the costs of implementing this support in your own Activity Processors might not be justified by the benefits.
- The risks of an exception being raised in the course of executing an Activity are multiplied somewhat by the likely or typical number of iterations and the number and nature of items that may be executed by the Processing Sequence controller for each iteration. Because the risks are often greater (and perhaps less certain) for an Iterator Activity, you might more strongly favour implementing restartable support for such an Activity.
If you choose to implement restartable support in your Activity Processor:
- You must implement your solution such that your Activity Processor will have sufficient information available to it from the values of variables in the variable pool or by whatever other means you choose to enable your implementation to accurately and reliably restart processing at any given point of failure.
- You must implement your solution to be capable of reconstructing its state (as far as is necessary) such that it can validly resume processing at the appropriate point.
- If it is an iterator activity, then it must be capable of restarting its processing at the iteration in which the failure occurred.
- The DXACTBAS1 ancestor class has several properties that your Activity Processor can reference to help determine whether restart processing is required and at what point. Some of these are listed below. Use feature help in the Visual LANSA IDE for more information about the individual properties.
- CurrentIteration
- Restartable
- RestartingChild
- RestartingThis