Compensation - Xyna-Factory/xyna GitHub Wiki

Figure 1: Compensation Area of ''SFTP Upload'' Service call containing a single Process Step. Compensation is the process of executing the Process Steps defined in Compensation areas in Workflows. Compensation areas can be modeled for all Service invocations and may contain arbitrary Modeling Blocks. The Compensation process is initiated whenever a Workflow fails. All Process Steps that executed successfully previously to the failed Step(s) are then compensated in opposite order of their previous execution. That means the order in which the Compensation areas are executed is exactly opposite to the order of normal execution. The Process Steps inside of each Compensation area are executed in normal order.

Table of Contents

Modeling

  • Open the block via the corresponding Compensation symbol . Prior to modeling the required Compensation, the block has to be activated by clicking the Override internal Compensation or Enable Compensation field, respectively.
  • Model the Compensation in the activated block as usual.
Please note: To delete a Compensation, click the respective field Override internal Compensation or Enable Compensation again. Thereby the modeled block is also removed completely. Thus, it is not possible to only temporarily deactivate a Compensation. After each new activation, the properties have to be remodeled as well. If you accidentally deleted a Compensation, you have still the option to undo your changes (Ctrl+Z, cf. Undo and Redo).

Compensation of Subworkflows

When a Subworkflow call is compensated, the whole Subworkflow will be compensated per default, i.e. all steps inside the Subworkflow are getting compensated. This default behavior can be changed by activating the Compensation area.

If the whole Subworkflow gets compensated, the corresponding Xyna Order will get scheduled again (in Compensation mode), using the same Capacities and Vetoes as during its original runtime.

Example Use Cases

Compensations are often used to make sure that allocated resources are freed when not needed any more. One example are open connections. Let a Workflow have three steps:

  1. Open HTTP connection
  2. Send Message over HTTP
  3. Close HTTP connection
It is now prudent to add Close HTTP connection as Compensation to the call of Open HTTP connection. Whenever the third step Close HTTP connection is not called because of an exception in the second step, the connection is then closed by the Compensation.

Because only successfully executed steps are compensated, the connection is only closed when it has been opened successfully before.

Please note: If the Workflow above has a fourth step that fails, the Compensation of the first step is called even though the connection has already been closed successfully in the third step. In some cases it makes sense to open the connection in the Compensation of the Close HTTP connection step 3, and even send some compensating message over HTTP as well in the Compensation of step 2. In other cases one would just ignore connections that are already closed in the implementation of Close HTTP connection.

Compensation in Audits

In Audits, Compensation steps are shown in their respective compensation area.

Exceptions During Compensation

If an exception occurs during Compensation and is not handled inside the Compensation area, the whole Compensation process will be interrupted and aborted immediately. No further steps will be compensated.

Please note: If a Subworkflow is called during Compensation it will be executed normally, including the possibility of compensating itself if it fails.

See Also

⚠️ **GitHub.com Fallback** ⚠️