Hello,

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.

Regds,

#Mainframe-Integration
#webMethods
#EntireX

What client and what server are involved here ?

#Mainframe-Integration
#webMethods
#EntireX

The client is a Natural program, and the server is an XML RPC Server exposing a web service.

#EntireX
#webMethods
#Mainframe-Integration

For reliable RPC USR6305N is used to “commit” the message, this may return a broker error code,
USR6306N can be used to query the status of a message.

#Mainframe-Integration
#EntireX
#webMethods

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?

#webMethods
#EntireX
#Mainframe-Integration

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.

#webMethods
#Mainframe-Integration
#EntireX

Brian, you can use USR6306N to check the status of an UnitOfWork which is implements an Reliable RPC call. You can also monitor the status in SMH.

For details see the documentation of Reliable RPC in the Natural documentation: http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat822mf/rpc/reliable_rpc.htm#reliable_rpc. USR6306N is described in the last part.

The UnitOfWork status is described here: http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_sp2/EntireX/8-2-SP2_EntireX/adminGeneral/persistUsing.htm#understandUowStatus

The 2 important ones are PROCESSED = message has been processed successfully by the Server, and CANCELLED = message processing by the Server failed.

#webMethods
#EntireX
#Mainframe-Integration

Thanks Rolf and Wolfgang,

I think this USR6306N may be what I needed. I will investigate and see how I might be able to use it.

#webMethods
#Mainframe-Integration
#EntireX

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.

UOWID UOW-STATUS USER-STATUS CREATE-TIME
100000000000000C DELIVERED Apr 26 11:28:23

UOWID UOW-STATUS USER-STATUS CREATE-TIME
100000000000000D DELIVERED Apr 26 11:31:11

UOWID UOW-STATUS USER-STATUS CREATE-TIME
100000000000000E DELIVERED Apr 26 11:32:01

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?

We then un-deployed it.

UOWID UOW-STATUS USER-STATUS CREATE-TIME
100000000000000F DELIVERED Apr 26 11:44:44

UOWID UOW-STATUS USER-STATUS CREATE-TIME
100000000000000G DELIVERED Apr 26 11:45:22

2012-04-26 11:45:46.977> Worker-1…( CP:HTTPTransport.invoke() I:Empty Response )
2012-04-26 11:45:46.977> Worker-1…( CP:HTTPTransport.invoke() I:Response: null )
2012-04-26 11:45:46.977> Worker-1…) Leave: TransportHandler.sendReceive()

Is there any service down condition where the status will be something other than “delivered”?

#webMethods
#EntireX
#Mainframe-Integration

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).

#webMethods
#Mainframe-Integration
#EntireX

And it’ll stay in DELIVERED status when the server is down as long as the message is on the PS, right ?

#EntireX
#webMethods
#Mainframe-Integration

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.

#Mainframe-Integration
#EntireX
#webMethods