Settlement Procedure as Workflow
We recommend that you use the predefined SAP workflow template when you develop your own workflows. The workflow templates contain examples on the tasks described below.
For each workflow task, you can activate schedule monitoring, define address data for messages, specify repetition counters for temporary errors (when profiles are blocked, for example), and so on.
Caution
If you want to execute a settlement run for multiple settlement steps, we recommend that you define the settlement procedure as a job.
However, if you still prefer to define the settlement procedure as a workflow, performance problems may occur with larger numbers of parallel settlement steps. In order to avoid performance-critical dynamic parallel processing, you can replace the settlement steps from each settlement unit with customer-specific steps that take all settlement units into account at one time.
Generate Settlement Run Instance
To start a settlement run as a workflow, you must first use the background task TS20500362
to generate an object reference. The reference is required in order to execute the settlement steps.
The data flow definition must contain the settlement document number and the run number. In the workflow container, these parameters must be defined as input parameters. The settlement workbench transfers the parameters at the start of the workflow.
If the settlement run was successfully instantiated, the ISUEDMSettlement
and SettlUnits
output parameters contain the instance reference and the table with all the settlement units that are taken into account in the settlement document.
Change Status of Settlement Run
Directly after an instance of the settlement run is generated, you must use the task TS20500364
to change the status of the task to Started
. This prevents additional runs for settlement documents with the same data basis (same settlement units) from being started. In the settlement workbench, the user can then follow the status of the settlement run.
Apart from the instance reference, the only parameter that is transferred is the internal status description. This can be:
01:
Started
02:
Finished with OK
03:
Terminated
The Finished with OK
status should be the last action in the workflow. The Terminated
status should be set before the workflow is terminated after a critical error. Otherwise, a new run for the settlement document cannot be created and the recalculation of the settlement steps cannot be recalculated.
Execute Settlement Step
The backgound task TS20500361
(IS-U-EDM execute settlement step
) is used to execute a settlement step. The data flow definition determines which settlement step is executed.
Generally all the settlement steps (with the exception of parallel steps; see Execute Parallel Settlement Step
) and all the parameters (profiles and values) are transferred to the background task and the results are added to the parameter container. This ensures that, apart from the names of the settlement steps, the data flow for each step is identical. The settlement step has an automatic filter to calculate the required input parameters. The name of the settlement step must be transferred (in capital letters) as the SettlStep
element.
The Return
element can be evaluated in order to determine whether the settlement step ended with a warning.
To ensure that the workflow runs without errors, the following outputs should be modeled:
Step executed
Processing of settlement unit &1 terminated with error &
The simplest way of handling an error is to set the status of the settlement run (see Change Status of Settlement Run
), thereby terminating the workflow.
Execute Parallel Settlement Step
Some settlement steps can only process one settlement unit only. In order to enhance system performance, these settlement steps are executed in parallel. The table of settlement units is used for parallel processing.
Unlike a global settlement step, only one settlement unit may be specified in the data flow definition. This unit is determined by the index access to the table of settlement units. If additional settlement steps cannot be called unit all the settlement units were processed, the task running in parallel must be encapsulated in a parallel section.
Parallel sections can also be used to distribute long-running independent calculations over different servers, thereby optimizing the total runtime.
Set Alert
An alert can be triggered from the workflow. This is necessary, for example, if a settlement step that is critical for processing is terminated due to an error. The background task used for this is TS20500368
.
The following elements must be entered in the data flow:
MSGTY: Message category
MSGID: Message class
MSGNO: Message number
The elements are entered in the same way as the system fields (SY-MSGNO
, SY-MSGID
, SY-MSGTY
, SY-MSGV1
, SY-MSGV2
, SY-MSGV3
, and SY-MSGV4
).
An alert must be confirmed manually in the settlement workbench. Special authorization is required to view or confirm alerts. An alert generates a BOR event simultaneously that can be used in an additional workflow to send a notification mail, for example.
Set or Read Parameter Value
The value parameters of settlement steps that work with values as input parameters are transferred to the container. These parameters are generally calculated by a pre-stored settlement step. A parameter value can also be set directly in the workflow by the task TS20500369
and then added to the workflow container.
The parameter name, value, and if necessary context (settlement unit, grid, reference profile) are defined in the data flow. The parameter name must be entered in capital letters. When you specify the value, ensure you use the technical display (as in ABAP coding) because the entries are not converted.
To read a given value from the workflow container (for example to evaluate the value in a branch condition), use task TS20500370
. The selection criteria are the parameter name (in capital letters), together with the optional criteria of settlement unit, grid, reference profile, or key in the data flow definition.