Automation and optimization are high on the list for all organizations. A key part of this in SCD is the Transaction STP feature which enables you to automate the way transactions are processed and only deal with exceptions. In this piece, we will take a look at some of the tools that can be used to help users handle the process.
Start by looking at the Message Queue window where the STP queues are defined (Message queue type = STP queue). In this window, we want to point to the field Maximum Age. As with other message queues, this defines the number of days after which a ‘Finished’ message will be deleted (provided this has not been disabled in the Service Options window). For an STP queue, this means the number of days after a transaction has reached the highest status possible, which at many client installations is ‘Final GL’. However, the transaction is of course not deleted, rather the message status is changed from ‘Queued’ to ‘Removed’ and it is no longer part of the STP. For this reason, if you use the STP workflow, you should always make sure that transactions reach the highest status at the end of the workflow lifecycle, and that it is not left in a lower status; furthermore having the maximum age set to a high number makes little sense: once a transaction is in the highest status that should be it, and any subsequent processing can (or rather should) only happen if the transaction is modified and thereby lowered in status and automatically re-queue anyways. Note if you leave the maximum age field blank it works as if you had entered 0 days.
The service processing the STP is defined in the STP Service Configuration window. In order not to overload the database with constant queries to the queues, it is recommended by SimCorp to set the Polling higher than or equal to 1 minute. This means it can take up to 1 minute before the transaction is handled in the STP process, or even longer if a large batch of transactions needs attention. It is in this window under the tab Jobs you also define the Fin Calc Server and the Transaction Status Server. The Fin Calc Server will only raise transactions from Free Deal to Fin Calc whereas the Transaction Status Server will raise transactions on the remaining status levels. The reason is that when transactions are saved in Fin Calc status the p/l numbers are re-calculated and finalized, requiring more computing power. Often these 2 service types are running on the same STP Service Configuration, and if system performance is an issue, it is worth considering splitting these out into separate ones. Adding more services is also a good idea, as these scale almost linearly.
The STP Queue Monitor is a great place to get an overview of the STP process. This gives an overview of transactions in the queue by transaction code, transaction status, message status, and server. Before working with this window make sure you add a few more fields (Right click on the header, select View properties, and then Select fields). We recommend adding Business Trans Code, No of Jobs, Reschedule reason, STP status mode, and Status. First, you will notice transactions with a message status of Queued and the STP status mode in Maximum status reached; these will be removed from the list once the maximum age described above has passed. Unfortunately, you can only filter on the message status (we suggest selecting everything except ‘Queued’), but if you right-click on the header and select View properties – Sort and Totals at least you can sort by for example STP status mode for an easier overview.
To investigate transactions with an issue, for example in status ERROR, you right-click select STP Transaction Status Queue and you are taken to this window with the transactions from the monitor loaded. In this window, STP Transaction Status Queue, you can see more details of each transaction and from the functions menu, you can open the transaction window, put the transaction on hold, or remove it from the queue altogether. Note, auxiliary jobs (which we covered in Tip #5) might be set up to prevent a transaction from being raised in status; these will be shown as queued with a checkmark in the Aux status job failed or pending fields.
Let’s turn our attention to the STP Transaction Monitor. This lets you manage transactions in the queue in a similar way as the two windows described above if only a little more user-friendly. We will take a closer look at some of the options you have with the function’s menu:
Assign Message Queue. Normally a transaction will get an STP message queue assigned during import in a DFS when created in the Create… windows in batch or even when entered manually using a default. But if there for some reason are transactions without a message queue, they can be assigned using this option.
Show Auxiliary Status. This is the same sub-window on Auxiliary jobs you find on the single transaction window. You can keep the window open and click through the transaction on the main window and it will update accordingly.
Hold/Release Transaction. Easy way to toggle multiple transactions on the STP queues. In some rare cases, a transaction can get stuck in the queue, and here it can sometimes help to hold transactions and then release them immediately afterward.
This was a quick discussion about the tools of the STP transaction process workflow. If you have any comments or questions, be sure to let us know via the usual channels. And don’t forget to like our post.