Timeouts are seen when transferring messages via SWIFT. This issue mostly occurs when messages are sent to one particular client. The client also experiences timeouts around the same time when sending messages back to the sender.
There are additional (custom) steps in the corresponding business process (BP) where it invokes another asynchronous business process before responding to SWIFT.
Diagnosing the problem
SWIFTNet Server FAEvent BP appears to be a custom version of the SWIFTNet 6 BP version where the invoke mode is hardcoded to be SYNC by default. Upto 20 second delays were observed during peak time in this BP during the synchronous invokes. In the SWIFTNet 7 version, the hardcoded value is removed and the invoke mode follow the SWIFTNet Routing Rule configuration. This ensures response back to SWIFT as early as possible.
Resolving the problem
1. Re-evaluate the BP to be based on the SWIFTNet 7 version instead of SWIFTNet 6 version. This issue is mainly with the hardcoded SYNC mode but in 5241 Fix Pack release IBM included a fix to this BP - handleSWIFTNet7FileActEvent (the out of the box BP). It is best to migrate the BP on top of the SWIFTNet7 version of the 5241 Fix Pack release.
2. Configure the SWIFTNet Routing Rule to invoke the sub-process asynchronously.
3. Move the asynchronous invoke BP step farther down in the SWIFTNet Server FAEvent BP to a point after the Swift response so that the Swift response is not dependent on the invocation of the
4. It is also worth considering the use Release Service and to use only specific subset of Process Data when invoking the sub-process BP.