In this piece, we are going to take a closer look at a part of transactions that are used by every SimCorp client at least to some extent: auxiliary jobs. It can be a difficult, time-consuming task to set up a definition without a template, so we are going to focus on some general setups.
Let us start with the Auxiliary Job Definition window. This is the core window that defines the process applied to the transaction workflow. The first challenge is to define the lines in the grid window. Generally speaking, you need 3 lines to make a simple setup. This can consist of
The first line is where you define the initialization of the run of the job itself.
The second is typically where you send the job in case of an error.
And the last line is the flag the job as successfully executed.
The field Function is the key field to defining what the job should do. You only assign the function to one of the lines, the other 2 lines typically have ‘Dummy’ assigned. The field Execution time is important to consider if you want the job to run in batch, manually or on a server. If you have a server executing the job, remember to include the field Aux message type from the select list in the grid (hidden by default) and set the message type defined in the STP Service Configuration window.
Under the functions menu, you will find a Fields sub-window. This is especially useful to define when the auxiliary job sends a cancel and replacement message in the event of an amendment of the transaction. Rather than sending a new message for any corrections (for example free codes), you can use? field-level control if the auxiliary job should be triggered again.
The next window is the Auxiliary Job Triggers, essentially defining what the auxiliary job definition is triggered by based on segments. The only thing to point out here is to be mindful of the transaction status levels assigned; if you initiate this on position (both max and min), and your transaction is not saved on position, make sure you check the box Initiate if saved on a higher status. This is another field that is hidden by default.
In the Compulsory Status Level window, you can ensure a transaction is not raised in status until the auxiliary job has been completed successfully. To do this, enter the segment combination of the job and set the field Compulsory status level to the next status level up that the job was initiated on; for example, if it is initiated on Position, set this to Free deal, assuming your organization does not have any customized status levels. Next, go under the functions menu and select Dependencies. In the sub-window that opens, select the auxiliary job definition, and enter the highest status level from the job in the field Actual auxiliary job no; let us say the last line in the grid of the Auxiliary job definition was 30, then enter 30. And lastly in the field Auxiliary job completion code enter ‘Executed’.
When you are setting up auxiliary jobs you often find errors and need to correct the setup. This can only be done if there are no pending transactions using the auxiliary job. The easiest way to resolve this is by opening the window Terminate Auxiliary Jobs, select the job and a date, and then terminate it. This releases the hold SimCorp Dimension has on the auxiliary job setup and allows you to make changes. Obviously, this should not be done in production unless you are fully aware of the consequences.
The last observation we would like to share around auxiliary jobs is the maintenance of them. If you have used SimCorp Dimension for a while and are not sure if an auxiliary job assigned to a transaction is even used anymore, you can create a data extract on the transaction table Auxiliary Status to fetch the last time the job was executed.
We hope this has given some insight into how to better understand Auxiliary Jobs. If you have any suggestions or any further questions regarding this topic, please feel free to leave a comment or drop us a line.