One of our developers asked me to find out… if we have an asynchronous service call (with Reliable RPC and no XML payload in response), and that service is unavailable, is there a way to guarantee that the service call is made once the service is back up, and/or is there some way to respond to the application that the service was unavailable?
In my understanding, I believe the application must not be listening for a response to be able to tell it that the service was down.
Please advise what options I have to help improve the error recovery capabilities.
If I am using USR6304N with reliable auto-commit, is USR6305N applicable? Currently USR6304N has a response code:
OUTPUT
RC (N04) return code
0 ok
1 invalid function code
2 invalid reliable state
3 reliable state can't be changed
commit/rollback pending
4 invalid ACI version
9999 Broker error (see MESSAGE)
MESSAGE (A80) message text
and there is no bad return code if the message was posted to the Broker but the service was unavailable.
USR6305N has as a response:
OUTPUT
RC (N04) return value
0 ok
1 invalid function code
9999 Broker error (see MESSAGE)
MESSAGE (A80) message text
If I changed USR6304N to do a client commit instead of auto-commit, then called USR6305N, could I expect USR6305N to tell me anything differently thant USR6304N does now?
No, with auto-commit USR6305N does not apply, when you call it there will be no pending UOW to commit
For USR6304N you will receive errors in relation to the state change only,
for USR6305N you will see the messages related to the actual commit / rollback.
We have done some testing today using the status returned by USR6306N. The developer asked the SOA developers to retire the service to see what comes back in the UOW status field.
I checked the logs and the response we get back from the service call is:
<?xml version='1.0' encoding='utf-8'?>env:Serveroracle.fabric.common.FabricException: The composite "default/PublishSalesOrderEntirexReqABCSImpl!1.0*soa_35a770a4-79f0-4eef-be48-dd90f282cf86" is retired. New instances cannot be initiated.
My question is: is the “delivered” message because EntireX realizes that for calling a service that has been retired, it not only isn’t there but likely is never coming back; hence it is done?
DELIVERED is the status while the RPC Server is processing the request.
I assume that you call the user exit directly after the RPC call, right? You should save the UOWID so you can check the status later. In the already mentioned diagram you can see that the status will move to PROCESSED once the RPC Server commits the UOW, or CANCELLED once it cancels the UOW (in case an error occured).
As long as the server didn’t pick it up it will stay in ACCEPTED. It changes to DELIVERED when the server does a receive. If the server aborts or for whatever reason decides not to do a commit or cancel the status will revert to ACCEPTED when either the server issues a backout or an implicit backout occurs. A logoff or deregister as well the occurrence of a server non-activity timeout will result in an implicit backout.