Issue with Replies from Consecutive Web Service Calls

[Don Martin]

I have a set of 3 web service calls that I need to chain together, using the response from one call to generate the request for the next call. I’ve used the java/ws-rawclient protocol for these threads to allow for using JSON.  In the web service (ws) threads, I wait for a reply, then use a static route to process the reply and send it on to the next ws thread. This works well for the first two calls – the reply from the first ws call is sent as a reply message to the second ws call. However, the second ws reply is sent as a data message rather than a reply message to the third ws thread. So it looks like cloverleaf is flipping the message type on each reply – the first ws thread takes a data message and returns a reply message; the second ws thread takes a reply message and returns a data message.  As a result, the reply route in the second ws thread isn’t getting used, and cloverleaf gives me an error stating the there is no route for the trxid. I’ve used SMAT to confirm the message types are getting set as described above, have written the following tcl proc that I put in the reply route for the first ws call.

set msgIn [msgget $mh]
set mh2 [msgcreate -recover -type data $msgIn]
msgmetaset $mh2 DESTCONN [msgmetaget $mh DESTCONN]
lappend dispList “KILL $mh”
lappend dispList “CONTINUE $mh2”
return $dispList

This solves the problem, but seems like a hack, and also gives me the following warning:
[msi :msi :WARN/0:redcap_getRecordIDs_xlate:04/27/2020 22:37:10] msiXlateMsgDone: Invalid MSI index -1
[msi :msi :WARN/0:redcap_getRecordIDs_xlate:04/27/2020 22:37:10] msiAddPostXlate: Invalid MSI index -1
[msi :msi :WARN/0:redcap_getRecordIDs_xlate:04/27/2020 22:37:10] msiRemovePostXlate: Invalid MSI index -1

So, is this warning something I should pay attention to, and is there a better way to accomplish what I’m trying to achieve, like using OVER or some other disposition in the reply route? Maybe relaying the message through another thread? Alternating reply routes with data routes (not a fan of this one)? Anything???

Thanks,

Don Martin

 

Topic

[Charlie Bursell]

Try using a SEND command.  Set SKIPXLT to 1 so it dows not hang.

Shouldn’t the message type be REPLY?

[Don Martin]

@Charlie – SEND gives me the same results as a CONTINUE, but thanks for the suggestion.  You’re right, ideally the message type would be a REPLY, but I need to keep flipping the message type to DATA as I forward it on to the next ws call, otherwise Cloverleaf will send a reply message outbound through the ws protocol and return a DATA message (that really should have just been another reply in my mind).

[Jim Kosloskey]

When I had a situation similar to but not exactly like this I used OVER to get the message on the IB side of an OB thread allowing me to route the reply to a different thread than the one which sent the original message. This was on 6.0 and at that time you could not route replies to a different thread.

I think I also had to change the message type of the copied message from reply to data.

That was 2009 so I have forgotten all of the particulars.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Don Martin]

Thanks Jim,

I think it was a previous post from you that gave me the idea to copy the message and change the type to DATA.  What you propose seems like it would probably work, but I may just leave things as they are and hope that the invalid MSI index warnings don’t cause any problems.  Appreciate the response.

[Jim Kosloskey]

Just curious, what release of Cloverleaf?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Don Martin]

We’re on release 6.2

I should have mentioned that earlier.

[Jim Kosloskey]

I am not sure if this is applicable but did you try route replies and it did not work?

I thought Route Replies was supposed to be corrected in 6.2 so that you could send replies to threads other than the originating thread.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Don Martin]

Yes, I’m using Route Replies and it allows you to route replies to a different thread.  This works, but if that REPLY message is routed to a different thread (thread 2), and thread 2 makes a ws call, the reply from thread 2’s ws call will come back as a DATA message, hence the issue.  So, if you have two different threads sending to thread 2, and one sends in a DATA message and the other thread sends in a REPLY message, you can’t handle the ws reply for those two messages in the same way.  Ideally I’d want to handle the replies the same regardless of how many hops a message made before it hit thread 2.

[Jim Kosloskey]

OK I think I get it so the first thread is not a WS connection and the second thread is?

 

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Don Martin]

The second thread is a WS connection, and it doesn’t really matter what the first thread is using from what I can tell.  The issue is really that if a REPLY is sent to a WS thread (let’s call it thread B),  the reply from thread B’s WS call will come back as a DATA message.  If a DATA message is sent to thread B, the reply from thread B’s WS call will come back as a REPLY message.  Ideally I would want (and expect) all replies coming back from thread B’s WS call to be REPLY messages.

Does that help clarify things?

[Rob Abbott]

I know you have already built this but you might consider using DTC the next time you need to do something complex; it was built to help tackle scenarios like this.

 

There is a webinar recording posted if you would like more detail about the feature.

Rob Abbott
Cloverleaf Emeritus

[Author]

Replies