An asynchronous PI message cannot have a reply message. Thus the RPC program which creates the asynchronous PI message (Sender Adapter) or receives an asynchronous PI message (Receiver Adapter) must have INPUT parameters only. Parameters of direction OUT or INOUT are not allowed.
If you want to perform Exactly Once Processing, we recommend using the message protocol "EntireX Reliable RPC".
The remainder of this section describes the necessary steps to use Exactly Once Processing with the message protocol "EntireX RPC". It does not apply to Reliable RPC.
Since the standard RPC functionality uses (on a technical level) a synchronous request reply model, an RPC request always has a reply. In case of an asynchronous PI message, the reply generated by the RPC Server (Receiver scenario) or PI Adapter (Sender scenario) is "empty", which means that it basically contains a return code only.
If an RPC Client application sends a message to the Sender Adapter the following steps are taken:
The RPC Client sends an RPC Call to the PI Adapter (INPUT parameters only).
The Adapter processes the RPC Call (conversion to XML), creates a PI message with Quality of Service Exactly Once and passes the message to the Adapter Engine
The Adapter sends back a reply (without payload data) to the RPC Client. This step happens in parallel to the further processing of the message in PI.
The following scenarios are possible on the client side:
The RPC Client receives a positive answer from the Adapter: the message has been delivered successfully.
The RPC Client receives a return code, which is neither a timeout nor a communication error: the message could not be delivered. The RPC Client should resend the message (in case of a configuration problem: first correct the configuration issue).
The RPC Client receives a return code, which is a timeout or a communication error: it is unclear if the message has been delivered. The RPC Client should resend the message. However, in this case the message might be delivered more than once.
So far, delivery of the message is guaranteed, but duplicates are possible.
If duplicate messages cannot be handled by the PI scenario and should not occur the following additional feature can be used:
Optionally the RPC Client application creates a unique Message ID (UUID/GUID) as part of the message payload
This is always the first parameter of the RPC call, format has to be A36
Uniqueness is guaranteed by the Adapter within the scope Adapter/Broker/Serveraddress/Programname
If the RPC Client sends a new message it must use a new Message ID
If the RPC Client resends a message it must use the same Message ID
Once the Adapter has successfully delivered the message to PI, it persists the Message ID
If the Adapter receives a message with an already persisted Message ID the message will not be delivered again to PI
Exactly Once is now guaranteed, no duplicate messages will be created.
If the Receiver Adapter sends a message to the RPC Server application the following steps are taken:
The Adapter Engine passes a PI message with QoS Exactly Once to the PI Adapter.
The Adapter processes the PI message (conversion from XML), creates an RPC Call (only INPUT parameters) and calls the RPC Server.
The Adapter waits for a reply from the RPC Server (without payload data). Depending on the answer the Adapter either returns a Delivery Acknowledgement of type "deliveryAck" (if the RPC call was successful) or (in case of error) of type "deliveryErrorAck" back to the Integration Server.
The following scenarios are possible on the Sender Adapter side:
RPC Server returns no error to the Adapter: message has been processed successfully.
Adapter receives a return code, which is neither a timeout nor a communication error: message has not been processed. PI will resend the message to the Adapter, Adapter will call the RPC Server.
Adapter receives a return code, which is a timeout or a communication error: unclear if the message has been processed. Adapter logs this unknown status, PI will resend the message to the Adapter.
So far, delivery of the message is guaranteed, but duplicates are possible.
If duplicate messages cannot be handled by the RPC Server application and should not occur the following additional feature can be used:
Optionally the Adapter sends the unique Message ID of the PI message to the RPC Server application as part of the message payload
This is always the first parameter of the RPC call, format has to be A36
The RPC Server application should use this Message ID for duplicate message detection
Exactly Once is now guaranteed, no duplicates will be processed in the Server application.