In order to improve timeout /error-handling functionality of our systems, I would like to use a multi-step / conversational RPC transaction from IS to a back-end Natural program. It would be comprised of opening the conversation, calling the program and closing the connection. The hope being that if the server is unresponsive at a given moment, the timeout / lag would be encountered during the conversation opening and reduce timeout / lag issues occuring during the actual program call.
Essentially, we’re currently using a synchronous RPC connection to call the program… which occasionally times out. In the case of a timeout where the transaction request was actually received, upon timeout we are resubmitting the transaction - which causes duplicate record scenarios we would like to avoid.
I believe a Reliable RPC Connection would be ideal for the handling, but we require some extended record/transaction information contained in the response message (my understanding is that the only referenceable results when using Reliable RPC are the success or error code, no response message / details as per se).
there is no separate “open conversation” call to the server, this happens implicitly with the first call. Thus it will not improve your situation. Even worse you have to pay the additional overhead for both transaction handling in IS and conversation handling in EntireX.
You talk about a couple of different timeout/error situations: which errors do you get exactly?
You can realize such a request-reply scenario with Reliable RPC by using two different “queues” (services).
So the Adapter Service sends an asynchronous request to e.g. RPC/REQUEST/CALLNAT. Once the Natural RPC Server processes this request it can send back a reply to e.g. RPC/REPLY/CALLNAT. You probably need something like a “correlation id” which is used in both the request and reply messages.
In the Adapter you have to setup a Reliable Listener for RPC/REPLY/CALLNAT.
So, if I understand you correctly, the IS connection pool management is opening an RPC conversation and leaving it open for it’s duration?
The most pressing scenario is an application level timeout (IS retry interval) which ends up sending a second identical request causing duplicate record handling problems (not a system error as per se). I believe this is simply a delay on the Natural side of the equation when considerable load from other sources/sessions is present.
The Reliable RPC (asynchronous) will only provide either the success code (0000000) or an error code if I am not mistaken (and this upon polling for the status), which may fall short of our requirements (however, it may be enough and will be evaluated). As I have not used the Entirex adapter Reliable RPC processing before, any information / steps outline to keep in mind would be appreciated.
Correct me if I’m wrong, but further to a Reliable connection I can only see having full 2-way asynchronous communication with the addition of a listener accompanied by updates to the Natural codebase, etc… a bigger scenario / ball of wax.
No, the lifetime of a conversation is determined by the transaction in the IS flow. There is no stand-alone “open conversation” call to the RPC Server. But there is a separate “end conversation” call to the RPC Server triggered by the transaction end in the IS flow.
Not really. Once the EntireX Broker receives the request it sends back an success code to the Adapter (or an error code e.g. in case of a unknown service name). This is completely decoupled from the processing of the RPC Server. The RPC Server can pick up the call much later. E.g. the Adapter sends reliable requests over the weekend (and gets an okay from Broker immediately), but the RPC Server starts processing the accumulated calls Monday morning.
Yes, you need a listener (and services which are called by the listener) as well as changes to your server logic.