Gateway 6.17.3 User Guide Save PDF Selected topic Selected topic and subtopics All content Axway Gateway: Managing Transfers Transfer states in Gateway Introduction Gateway offers the possibility to enable additional processing based on events that occur during its functioning. One such event, which is an important feature of Gateway, is routing. Routing is triggered by a change in state of a transfer. This section examines the meaning of each transfer state, the difference between apparently similar states and the state changes which trigger a routing event. Transfer states During its life cycle a transfer can have different processing phases, called states. There are three major phases that are common to all transfers: the beginning phase, the processing phase and the end of transfer phase. Depending on configuration options and on the protocol used, different states can correspond to each of these phases. Beginning phase Processing phase End of transfer phase To begin To restart Frozen Delayed Created To pack Packing To sign Processing Processing (responder) Suspended Interrupted Ended To ack Acknowledged Nack by user Nack by XFB Ended routing Cancelled routing Cancelled To unpack Unpacking Ended third party failed (*) Ended third party authorized (*) Acked third party failed (*) Acked third party authorized (*) (*) These states are specific to SWIFTNet transfers. Calculated states Some of these states are calculated by taking into account the state, route state and trade state. These states offer a global overview of what is actually happening with the transfer (trade decoding/encoding, routing). Examples: Cancelled routing means that the transfer will not be routed. Unpacking means that the transfer is ended and a trade processing is in progress. This table lists the calculated states: Calculated state State Route state Trade state To pack To begin To process Packing To begin Processing To Unpack Ended Ended to ack Acknowledged Nack by user Nack by XFB To process Unpacking Ended Ended to ack Acknowledged Nack by user Nack by XFB Processing Ended wait receipt Ended Ended to ack Acknowledged Nack by user Nack by XFB Trade wait receipt Ended third party failed Ended Ended to ack Trade third party failed Trade third party rejected Ended third party authorized Acknowledged Nack by user Nack by XFB Trade third party authorized Acked third party failed Ended Ended to ack Trade third party failed Trade third party rejected Acked third party authorized Acknowledged Nack by user Nack by XFB Trade third party authorized Ended routing Ended Nack by user Nack by XFB May route Cancelled routing Cancelled May route The calculated state field is used in internal processing for handling state transitions. For all other cases not listed in this table the State field is used as calculated state. Note that Ended routing means that the transfer is scheduled for routing and Cancelled routing means that the transfer will not be routed. State transitions During the life cycle of a transfer, each change of state represents a transition – an event which triggers notif (notification) processes within Gateway. These processes are responsible for: Routing Connection to other software products (such as Sentinel) Calendar event scheduling and so on State transitions for transfers in responder mode Created >>> Processing (responder) >>> Ended routing >>> Ended State transitions for transfers in initiator mode Frozen >>> To begin >>> Processing >>> Ended routing >>> Ended The states are listed in the Route transfer states configuration menu. When a transfer reaches a configured state, router processing is triggered, meaning that the Decision Rule selection is started. Each transition to one of these configured states leads to Rule Table evaluation and Decision Rule triggering. Example: By default the Ended routing state is selected. Each time a transfer ends, whether it was routed or not, Rule Table evaluation takes place. In this case, if you configure the Ended state to be notified to the routing process, you will see two Rule Table events triggered - one for each state. This happens due to the transition from Ended routing to Ended, because this whole notification mechanism is based on calculated transfer state changes. By default, to avoid double notifications and to cover the majority of use cases, only a few states are selected. This setting can be considered the safest and avoids any unexpected behavior. We therefore recommend that you leave this setting unchanged. Routing with SWIFTNet When using SWIFTNet, Gateway does not know immediately if a routed transfer has ended successfully or not. Protocol-specific acknowledgments may be received some time after a transfer ends. Initially Gateway assumes a positive ack and the transfer is considered ended (Ended to ack). It could happen that a negative answer is received from the partner and the transfer has to be cancelled. In the Route transfer states configuration menu, the Cancelled routing state is configured by default. However, the Nack by XFB state is not configured by default. This might not be enough to trigger Rule Table evaluation. Even if the state transition occurs (Ended to ack >>> Nack by XFB), as the final state is not configured, Rule Table evaluation is not triggered. Ensuring that routing is triggered with SWIFTNet We recommend that you enable the Nack by XFB state in the Route transfer states configuration menu. Route State Transitions The following table shows which results trigger which route state transitions: Route state Transitions to When XFER_TO_ROUTE XFER_ROUTED Successfully route transfer to XIB/another transfer XFER_EN_ROUTE Transfer switched to ended state XFER_ROUTED Not applicable XFER_ROUTE_FAILED XFER_NOT_ROUTED / XFER_NOT_TO_ROUTE XFER_ROUTED Routing is done on ACKED state, incoming transfer XFER_EN_ROUTE XFER_NOT_ROUTED Transfer passed into Ended-to-ACK and direction was incoming XFER_ROUTE_FAILED Not able to perform routing, calling of a script does not count XFER_MAY_ROUTE / XFER_EN_ROUTE XFER_ROUTE_FAILED Not able to perform routing, calling of a script does not count XFER_NOT_ROUTED Transfer is ended and direction is incoming and no routing was done XFER_NOT_TO_ROUTE Transfer is ended and direction is outgoing XFER_ACKED XFER_ACKED It is a final state so there are no transitions from it. The route_state becomes Acknowledged ("A") if the routed transfer is acknowledged Related topics Overview: File Transfers and Transfer Requests Overview: Routing SWIFTNet state transitions Managing Events on Gateway Links to documentation set for Axway Gateway 6.17.3: Installation -- User -- Unix Configuration -- Upgrade -- Interoperability -- Security, requires login -- Release Notes Related Links
Axway Gateway: Managing Transfers Transfer states in Gateway Introduction Gateway offers the possibility to enable additional processing based on events that occur during its functioning. One such event, which is an important feature of Gateway, is routing. Routing is triggered by a change in state of a transfer. This section examines the meaning of each transfer state, the difference between apparently similar states and the state changes which trigger a routing event. Transfer states During its life cycle a transfer can have different processing phases, called states. There are three major phases that are common to all transfers: the beginning phase, the processing phase and the end of transfer phase. Depending on configuration options and on the protocol used, different states can correspond to each of these phases. Beginning phase Processing phase End of transfer phase To begin To restart Frozen Delayed Created To pack Packing To sign Processing Processing (responder) Suspended Interrupted Ended To ack Acknowledged Nack by user Nack by XFB Ended routing Cancelled routing Cancelled To unpack Unpacking Ended third party failed (*) Ended third party authorized (*) Acked third party failed (*) Acked third party authorized (*) (*) These states are specific to SWIFTNet transfers. Calculated states Some of these states are calculated by taking into account the state, route state and trade state. These states offer a global overview of what is actually happening with the transfer (trade decoding/encoding, routing). Examples: Cancelled routing means that the transfer will not be routed. Unpacking means that the transfer is ended and a trade processing is in progress. This table lists the calculated states: Calculated state State Route state Trade state To pack To begin To process Packing To begin Processing To Unpack Ended Ended to ack Acknowledged Nack by user Nack by XFB To process Unpacking Ended Ended to ack Acknowledged Nack by user Nack by XFB Processing Ended wait receipt Ended Ended to ack Acknowledged Nack by user Nack by XFB Trade wait receipt Ended third party failed Ended Ended to ack Trade third party failed Trade third party rejected Ended third party authorized Acknowledged Nack by user Nack by XFB Trade third party authorized Acked third party failed Ended Ended to ack Trade third party failed Trade third party rejected Acked third party authorized Acknowledged Nack by user Nack by XFB Trade third party authorized Ended routing Ended Nack by user Nack by XFB May route Cancelled routing Cancelled May route The calculated state field is used in internal processing for handling state transitions. For all other cases not listed in this table the State field is used as calculated state. Note that Ended routing means that the transfer is scheduled for routing and Cancelled routing means that the transfer will not be routed. State transitions During the life cycle of a transfer, each change of state represents a transition – an event which triggers notif (notification) processes within Gateway. These processes are responsible for: Routing Connection to other software products (such as Sentinel) Calendar event scheduling and so on State transitions for transfers in responder mode Created >>> Processing (responder) >>> Ended routing >>> Ended State transitions for transfers in initiator mode Frozen >>> To begin >>> Processing >>> Ended routing >>> Ended The states are listed in the Route transfer states configuration menu. When a transfer reaches a configured state, router processing is triggered, meaning that the Decision Rule selection is started. Each transition to one of these configured states leads to Rule Table evaluation and Decision Rule triggering. Example: By default the Ended routing state is selected. Each time a transfer ends, whether it was routed or not, Rule Table evaluation takes place. In this case, if you configure the Ended state to be notified to the routing process, you will see two Rule Table events triggered - one for each state. This happens due to the transition from Ended routing to Ended, because this whole notification mechanism is based on calculated transfer state changes. By default, to avoid double notifications and to cover the majority of use cases, only a few states are selected. This setting can be considered the safest and avoids any unexpected behavior. We therefore recommend that you leave this setting unchanged. Routing with SWIFTNet When using SWIFTNet, Gateway does not know immediately if a routed transfer has ended successfully or not. Protocol-specific acknowledgments may be received some time after a transfer ends. Initially Gateway assumes a positive ack and the transfer is considered ended (Ended to ack). It could happen that a negative answer is received from the partner and the transfer has to be cancelled. In the Route transfer states configuration menu, the Cancelled routing state is configured by default. However, the Nack by XFB state is not configured by default. This might not be enough to trigger Rule Table evaluation. Even if the state transition occurs (Ended to ack >>> Nack by XFB), as the final state is not configured, Rule Table evaluation is not triggered. Ensuring that routing is triggered with SWIFTNet We recommend that you enable the Nack by XFB state in the Route transfer states configuration menu. Route State Transitions The following table shows which results trigger which route state transitions: Route state Transitions to When XFER_TO_ROUTE XFER_ROUTED Successfully route transfer to XIB/another transfer XFER_EN_ROUTE Transfer switched to ended state XFER_ROUTED Not applicable XFER_ROUTE_FAILED XFER_NOT_ROUTED / XFER_NOT_TO_ROUTE XFER_ROUTED Routing is done on ACKED state, incoming transfer XFER_EN_ROUTE XFER_NOT_ROUTED Transfer passed into Ended-to-ACK and direction was incoming XFER_ROUTE_FAILED Not able to perform routing, calling of a script does not count XFER_MAY_ROUTE / XFER_EN_ROUTE XFER_ROUTE_FAILED Not able to perform routing, calling of a script does not count XFER_NOT_ROUTED Transfer is ended and direction is incoming and no routing was done XFER_NOT_TO_ROUTE Transfer is ended and direction is outgoing XFER_ACKED XFER_ACKED It is a final state so there are no transitions from it. The route_state becomes Acknowledged ("A") if the routed transfer is acknowledged Related topics Overview: File Transfers and Transfer Requests Overview: Routing SWIFTNet state transitions Managing Events on Gateway Links to documentation set for Axway Gateway 6.17.3: Installation -- User -- Unix Configuration -- Upgrade -- Interoperability -- Security, requires login -- Release Notes