Dialogs consisting of multiple processing steps constitute a frequent type of transaction processing. This technique is designed to simplify the work of application users.They should be able to formulate jobs interactively step by step and thus be able to evaluate the interim results at each processing step.
The reservation of train tickets, for example, can be programmed as a service in two steps:
1st step: | Query whether seats are still available. |
2nd step: | Reserve the seat and confirm reservation. |
By chaining the programs that implement the individual processing steps, you ensure that the entire service is processed in the right order. You chain program units via entries in the PEND call. Here you select the RE operation modifier in the KCOM field if you also want to set a synchronization point at the end of the processing step and specify the transaction code of the follow-up program in the KCRN field. If you only want to terminate the processing step without setting a synchronization point, you have to select the KP operation modifier instead of RE in the PEND call. The follow-up program is started when openUTM receives the next input message.
Figure: Multi-step service
The service presented in the figure consists of two program units which perform one dialog step each. However, there is no limit to the number of program units that you can combine in a a service. For all program units of a service, openUTM provides service-specific storage areas which can be used by the program units to transfer information (see "KDCS storage areas in openUTM"). These storage areas are included in transaction logging.
The second program unit contains an FPUT call in addition to the MPUT call. This call does not create a dialog message. It creates an asynchronous message, in this case an output message to the printer.
Same processing step for differing actions
If two or more actions of the same type are performed in an application, it is advisable to handle processing steps that are identical for all actions in a single program unit. This is demonstrated using multiple step services in the example below:
The data of an insurance policy is to be displayed at the outset of different actions, so that one of the following steps can be performed:
modify data
delete data
calculate premium
report a claim
The first step is identical for all four actions, while the subsequent steps are all different (see diagram below).
First, all four actions are processed in the same program unit. Each action has its own transaction code, i.e. four different transaction codes are assigned to the first program unit. When the program unit is started, openUTM displays the transaction code used for the service start in the KCTACVG/ kccv_tac field of the KB header. Depending on the transaction code the program unit determines which program unit is started as follow-up program unit, i.e. which follow-up TAC is entered in the KCRN field when calling PEND.
Figure: Program unit to which multiple transaction codes are assigned