Using the store and release sample application
Test messages
This sample application comes with three payment messages, in SWIFT MT103 format, to test the application.
In order for these payment messages to functionally demonstrate the purpose of the sample application, the value date of the payment messages needs to be modified to reflect the following:
| Payment message | Value date |
|---|---|
| HoldFurtherPaymentRequest.103 | Tomorrow's date |
| HoldPaymentRequest.103 | Today's date |
| SendPaymentRequest.103 | Yesterday's date |
The value date in MT103 payment messages is in the format of YYMMDD. The location of the value date within the delimited text of the payment message is highlighted by the red rectangle in the following figure.
Scheduling the change of business day and release of payment messages
After starting the WMB execution group containing the BAR files of the sample application, open the FTM OAC in a web browser and log in. After logging in, navigate to the Scheduler Task tab under the Configuration Data section in the panel on the left hand side, as shown in the following figure.
Click the scheduler task named Payment Release Service to open its scheduler task details page.
On the scheduler task details page, click the Resolve button, which is highlighted in the following figure.
From the Allowable Actions page, which is shown in the figure below, choose the ResetPaymentReleaseService action from the allowable actions list. Additionally, enter a time, in the format HH:MM, in the comment box. Finally, click the Submit button, which is highlighted in the red rectangle in the following figure.
Following this, the schedule entry to change a business day is set for the time entered in the comment box, and the schedule entry to release payment is set to five minutes after the time entered in the comment box. This can be verified by navigating to the scheduler task details page of the payment release service and displaying its calendar group.
From the Calendar Group Details page, click the Schedule tab, shown in the following figure. The schedule tab displays the updated schedule times. As seen in the figure, the change of business day is scheduled for the time entered in the comment box and the releasing of payments is set for five minutes after this time.
Based on the change of business time entered, the processing date for the service participant is also updated. This can be seen by navigating to the Service Participants page under the Configuration Data section, as highlighted in the following figure.
The processing date for the service participant, which is in the red rectangle in the following figure, is set to yesterday's date if the current time is less than the change of business day time, or to today's date if the current time is greater than or equal to the change of business day time.
Submitting the payment messages
In order for the sample application to ingest and process the payment messages, they need to be placed on the MQ queue, named FXH.SAR.PAYMENT_ORGINATION. This can be achieved by using the RFHUtil tool. The following figure shows this process.
Sample demonstration
After modifying the test MT103 payment messages and configuring the scheduler task, use RFHUtil, submit a number of each test message to the FXH.SAR.PAYMENT_ORIGINATION queue. The following example shows the processing of the three test messages. Shown below is the Payment Transaction page, which shows the situation where three of each test message is submitted. At this time, the processing date is set to yesterday's date (Apr 3, 2014), as the change of business day has not occurred for today's date (Apr 4, 2014).
Initial state
The following two figures show the OAC displaying the state of the scheduler task and service participant before the business day is changed for today. The scheduler task that is highlighted in the following figure indicates that the next schedule entry that will occur is to change the business day.
As the business day was not changed for today (Apr 4, 2014), the processing date for the service participant is still set to yesterday's date (Apr 3, 2014), which is highlighted in the following figure. In business terms, the payments gateway is still only processing payments that are dated for yesterday.
Submitting test messages
In the figure above, it can be seen that
- The inbound transactions with yesterday's value date (Apr 3, 2014), which are highlighted in the red rectangle, are processed by FTM immediately. These transactions are augmented with a green marker to indicate that FTM has completed processing them and that, in terms of their FSM, the final state has been reached. Below these transactions, unhighlighted, are the corresponding outbound transactions that were sent to the payments gateway.
- Those inbound transactions with a value date of either today's (Apr 4, 2014) or tomorrow's (Apr 5, 2014) date are put in a holding state. These transactions are highlighted in the blue rectangle. Also, note that they have no corresponding outbound transactions, indicating that they are still within FTM and have not been forwarded to the payments gateway. For further clarity, these transactions have been augmented with an amber icon to indicate their state.
Change business day occurs
The next two figures show the OAC displaying the state of the service participant and the scheduler after the change of business day has been processed by the scheduler task. The following figure shows the service participants and, in the highlighted area, that the processing date was updated from yesterday's date (Apr 3, 2014) to today's date (Apr 4, 2014). In business terms, the payment gateway is now processing payments dated for today or before.
The scheduler task is also updated to reflect the next schedule entry that is to occur now that the business day has been changed. The highlighted area in the following figure shows that the next schedule entry to occur is to release held payments.
Releasing payments occurs
The following figure shows the payment transactions page after the release payments schedule entry occurs. The inbound transactions that are highlighted in the red rectangle have been released from FTM, with their corresponding outbound transactions to the payment gateway highlighted in the blue rectangle. These payments have been released because, after the business day was changed, the payment gateway is now processing messages that are dated either on or before Apr 4, 2014.
However, not all of the payments are released. The payments highlighted in red in the following figure have value dates set to tomorrow's date (Apr 5, 2014) and are not eligible to be processed by the payment gateway at this time. They remain in a holding state within FTM.
After releasing the payments that are eligible to be released, the scheduler task updates to reflect the next schedule entry, which is to change the business day to tomorrow. The next schedule entry is highlighted in the red rectangle in the following figure.
Manually releasing a transaction
In this sample application, a held payment message can be released manually through the OAC. To release a transaction, click an inbound transaction on the Payment Transactions page. On the Payment Transaction Details page, click the Resolve button, which is highlighted in red in the following figure.
By using the Resolve button, an operator can choose to either cancel the transaction or release it.
To release a held transaction, choose the Release option from the allowable actions list, insert a reason into the comment box, and click the Submit button in the bottom right corner of the page.
The following figure shows the state of the Payment Transactions page after the command to release a transaction has been submitted and processed by FTM. The processing of the held inbound transaction is complete and augmented by a green icon, which can be seen in the red rectangle. The blue rectangle highlights the outbound transaction to the payment gateway that corresponds to the held inbound transaction.
If the operator chooses to instead cancel the transaction, they select Cancel from the allowable actions list and click the Submit button, as shown in the following figure.
In the cancellation scenario, the inbound transaction is put into a failed final state, which is augmented with a red icon as shown in the figure below. Additionally, this transaction has no corresponding outbound transaction, which indicates that no corresponding payment message was sent to the payments gateway.
