Starting a service
One or more transaction codes are assigned to each program unit, either during application generation or using dynamic configuration.
The transaction code of the first program unit of a service has a special function because it is used to start this service. This transaction code is also called the service transaction code or service TAC for short. openUTM sets up a specific context (storage area, etc.) for each service started.
You can enter the service TAC in a large number of ways, e.g. by entering it at the terminal, selecting a menu item in an alphanumerical format, mouse clicking on a GUI client or using a Web browser.
Together with the transaction code you may transfer a message to openUTM containing necessary data for the required processing.
Dialog step and processing step
In the simplest case, a service consists of a single processing step, i.e. no interactions are required to process the service request: the result is output following the input of the service TAC, e.g. "All finished".
However, in many cases this structure is inadequate: you may have to request additional data, display intermediate results, or take account of individual selection options and branches in the service sequence. A service therefore often consists of multiple dialog steps.
A dialog step starts with a dialog message which one communication partner sends to the UTM application, and terminates with a dialog message which the service sends to the same communication partner as a response. Between these two points in time, the data is processed and there is no communication with this communication partner.
In distributed processing, a service does not only communicate with the user who started the service, but also with one or more partner services. A service started by a user may therefore not send the next message to the user but to another service application. In this case, since the message is not a response, it is called a processing step rather than a dialog step: A processing step starts when a dialog message is received and ends when the next dialog message is sent. This can be a response to the same partner (in which case the processing step corresponds to a dialog step) or a message to a third party.
A service may therefore be divided into multiple dialog steps, and a dialog step – in distributed processing – into multiple processing steps.
Figure: Dialog steps and processing steps
Switching between inputs and responses
openUTM requires a "strict dialog" to structure dialog services, i.e. each message must be followed by an answer. After sending a message to a service, you must receive a response before you can send another message to this partner.
This sequence - together with the modular service structure for processing steps - enables openUTM to maximize process utilization (see following two sections).
Modular processing steps in service structure
If a service consists of multiple dialog or processing steps, the service does not usually consist of only one service routine. Instead, it consists of a sequence of separate service routines called program units. Normally a program unit is equivalent to a processing step, i.e. a program unit reads a message and issues a message when it terminates. Subsequently the process is automatically released and is available for other jobs. The next program unit does not start until the next message is received from the communication partner.
For example, the service does not occupy a process while a user reads the output and prepares the next input at a terminal. As soon as the terminal user has finished the input, another process may, under certain circumstances, continue the dialog without notifying the user or the program unit.
Hence openUTM optimizes process utilization and this has a positive effect on system performance. openUTM uses this dialog concept (also called "pseudo-conversational") for dialogs with terminal users as well as for program-program communication.
In addition, the basic design for the use of modular processing steps simplifies the design of applications and results in clearly structured programs. However, it is flexible enough not to limit the programmer and makes a number of variations available to openUTM.
For examples of multi-step services and more information about connections between program units refer to section "Structuring services".
Asynchronous services
Using openUTM you can define services which run in the dialog with the user as well as services which can be started even when disconnected from the user. The message queuing functionality integrated in openUTM enables you, for example, to disconnect particularly large and non-time critical jobs - such as long statistical calculations or sorting tasks - from online dialogs without discontinuing transaction logging. You can use the message queuing functionality not just to perform processing jobs; it also lets you output messages, e.g. for print jobs, messages to a terminal or messages to service-controlled queues ("Messages to service-controlled queues").
The message queuing concept and its scope of application are introduced in the openUTM manual “Concepts and Functions”, for further information see section "Message Queuing (asynchronous processing)" of the present manual.