App-to-App Reply Interface

[Albert Tong]

We have an inbound thread with protocol “PROTOCOL:java/ws-server” which receives a message and sends to outbound thread with protocol “PROTOCOL:java/ws-rawclient”. We need the reply received from the outbound thread to be sent back to the inbound thread as the reply back to the application sending to the inbound thread.

Is there an example that can be provided for app-to-app reply so we can get this working? Attached is a diagram from the Cloverleaf docs showing what we are wanting to setup.

If you cannot provide examples, is there documentation that shows how this should be setup. If there is no documentation, can you let us know which parts are needed for this to work? For example, on the inbound thread, which tabs(s) need to be configured Inbound and/or Outbound and then within each which areas. Similar for the outbound thread.

Topic

[Jim Kosloskey]

Albert,

Is this a query/response integration?

If so can the source system do an ‘asynchronous’ message exchange where it sends a query message, gets a reply the message has been received, then accept the response from the responding system asynchronously on a different connection?

That would eliminate the delay waiting for the queried system.

If not then I don’t know what the issue is.

By definition the sending system wants to wait for the response from the responding system.

If your question is how do you setup Cloverleaf to do this ‘synchronous’ exchange then:

In the IB thread do not respond to the message.

In the OB thread Outbound Tab:

   Click on ‘Await replies’

   Set your timeout handling configuration as you normally would

   Leave ‘TPS Inbound Reply’ empty

   set the ‘Trx ID Determination Format’ appropriately

In the OB Thread Route Replies Tab add the appropriate route info for the TrxID determination set above. Route the reply to the IB Thread.

I think that should do it.

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

[Jerry Tilsley]

Jim,

With the Protocol:TCPIP that is pretty simple and straight forward.  But with the WS-Server it doesn’t seem to work that easily.  I have this exact scenario where I am doing the ITI.18 Query/Response.  I get the response from the OB thread and send it to the IB thread, but then the reply to the original source ends up blank of the vendor side.  These WS-Server/Client protocols don’t work as easily and the document is very thin to non-existent.

Albert,

I feel your pain.  If I get this figured out I’ll let you know.  If you get it working would you share as well?

Thanks,

Jerry

[Albert Tong]

I tried as you noted and I can see the outbound thread is sending the response message back, but the inbound thread seems to not know what to do with it.

I am seeing this error in the inbound thread. I appreciate any more guidance you may provide.

Call to “doReply” returned error string “BADDATA unknown driver control value ‘{_TRXID_ _HCI_static_route_-in_rims_ws_case}'”. Returning bad send to engine.

Engine idle — 08/24/2017 14:17:05

[Jim Kosloskey]

OK I am not that familiar with the WS protocols.

Albert,

With the Engine Output set appropriately what does the Metadata for the Reply message show when it arrives at the IB thread for Message Type?

Is it reply or data?

I am just wondering if that protocol needs the message to be a ‘data’ type and maybe it is still ‘reply’.

If that is the case, then a Tcl proc at the handle replies of the OB thread which changes the reply to data. (might need to make a copy because I don’t think that the Message Type metadata field cannot be changed). In that case then you would not do a route replies but rather a route data on the OB thread and the TrxID would be set as you normally do on an inbound thread.

What release level of Cloverleaf?

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

[Rob Abbott]

Albert please open a support case on Infor Xtreme and the support team can help you out.  Please provide the detail above including the error message you are getting.

Rob Abbott
Cloverleaf Emeritus

[Albert Tong]

Jim

Thanks for the assistance here I tried these but no luck.

I am getting the message back to the inbound thread but it does not know how to reply back. I keep getting this error. Any idea the options for the DRIVER variable?

[java:wrte:ERR /0:in_rims_ws_case_0:08/28/2017 14:49:32] Call to “doReply” returned error string “BADDATA unknown driver control value ‘SENDANDWAIT 0′”. Returning bad send to engine.

[Jim Kosloskey]

Contact me via email (Click on the email button) and I will try to assist off-line.

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

[Charlie Bursell]

What Cloverleaf version?

[Albert Tong]

We have version 6.2

[Charlie Bursell]

Albert:

This works for me on 6.2

I setup a test bed like:

  TESTIN

---

> TESTOUT

   INPUT  

---

> OUTPUT                  RECEIVER

TESTIN and TESTOUT were in their own process

All others in another process

I routed Fileset/local from TESTIN to TESTOUT.  TESTOUT sent to INPUT vis TCPIP and awaited replies

I raw routed from INPUT to OUTPUT  which then sent via TCPIP to RECEIVER

RECEIVER sent a reply back to OUTPUT

I set up a reply route from OUTPUT to INPUT.  When I receive the reply from RECEIVER I simply CONTINUE it.

In the INPUT thread I receive the reply in the TPS OUTBOUND and had to PROTO it for it to go.

I had echo statements throughout so I know the reply received at TESTOUT was all the way from RECEIVER

If this is too confusing, send me an e-mail and I will send you what I did.

cbursell@fastem.com

[Albert Tong]

I got this to work thanks for all the help. Setting the Copy Driver control protocol on the ws-raw-client side is what did it. Again thanks!

[Srinath Komakula]

Hi Albert,

Can you please share the thread configuration and any tcl procs that you have configured to get this working. I have similar configuration I need to make and looking for some guidance.

[Author]

Replies