Author |
Message
|
abooddy |
Posted: Fri Nov 27, 2020 11:58 pm Post subject: TCPIPClientReceive Node response confusion\mixup |
|
|
 Novice
Joined: 28 May 2019 Posts: 20 Location: Baghdad, Iraq
|
Greetings,
We've a standard TCPIP client synchronous integration using TCPIPClientOutput node followed by TCPIPClientReceive node. When there is a timeout in receiving a response for a message, the following not timed-out messages gets the response of the timed-out message and every subsequent message gets the response of the current message - 1.
For example:
MsgReq1 > MsgResp1
MsgReq2 > MsgResp2
MsgReq3 > TIMEOUT
MsgReq4 > MsgResp3
MsgReq5 > MsgResp4
And so on...
This implementation is interacting with a financial application in which such mixups are not allowed.
The timeout error is: no data on connection.
Setup:
Both nodes are attached to a configurable service with the following settings:
Both nodes "Timeout sending\waiting data record" is equal to 25 seconds.
TCPIPClientOutput Advanced:
TCPIPClientReceive Advanced:
TCPIPClientReceive Request:
We will appreciate your assistance on the issue.
Thanks. |
|
Back to top |
|
 |
timber |
Posted: Sat Nov 28, 2020 12:49 pm Post subject: |
|
|
 Grand Master
Joined: 25 Aug 2015 Posts: 1292
|
|
Back to top |
|
 |
abooddy |
Posted: Mon Nov 30, 2020 9:58 am Post subject: |
|
|
 Novice
Joined: 28 May 2019 Posts: 20 Location: Baghdad, Iraq
|
Hi Timber,
It is not, I'm able to successfully parse each response returned and the timeout in my case is due to known network issues.
What's your thoughts on this issue? Did you encounter it before? |
|
Back to top |
|
 |
timber |
Posted: Tue Dec 01, 2020 12:59 am Post subject: |
|
|
 Grand Master
Joined: 25 Aug 2015 Posts: 1292
|
Quote: |
the response of the timed-out message and every subsequent message gets the response of the current message - 1...This implementation is interacting with a financial application in which such mixups are not allowed. |
It sounds as if your only method of correlating replies against requests is to depend on the sequence of replies. But that (as you have found) assumes perfectly-behaved responders.
You need a much more robust mechanism for doing the correlation - is there not some kind of unique id in the response that you can use? |
|
Back to top |
|
 |
abooddy |
Posted: Tue Dec 01, 2020 10:50 am Post subject: |
|
|
 Novice
Joined: 28 May 2019 Posts: 20 Location: Baghdad, Iraq
|
When a TCPIPClientOutput node writes on a stream, it assigns an ID at $LocalEnvironment/WrittenDestination/TCPIP/Output/ConnectionDetails[1]/Id which will be used by TCPIPClientReceive node to read the response for that specific request based on the assigned ID. This is the implementation in the IBM docs here:
https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ac67470_.html
I don't believe there is a better method of doing it than a built-in ID created by IIB. |
|
Back to top |
|
 |
timber |
Posted: Tue Dec 01, 2020 2:22 pm Post subject: |
|
|
 Grand Master
Joined: 25 Aug 2015 Posts: 1292
|
I think I see where the confusion is coming from.
This is what the Knowledge Center says about the TCPIPClientOutput node:
Quote: |
You can dynamically choose the connection details (host name and port number), and the connection used (ID), by using this property. You can also set the Reply ID on the connection. The Reply ID enables a string to be stored in the connection and to be seen in the local environment. You can use this connection to store Reply IDs from other TCPIP nodes or from other transports, such as WebSphere MQ |
My understanding (which may not be 100% accurate) is as follows: the value in ConnectionDetails[1]/Id will ensure that the TCPIPClientReceive node uses the same connection as the TCPIPClientOutput node. It will not do anything to ensure the proper correlation of responses.
I suspect that you will need to use the ReplyID in your flow, but I'm a bit hazy on the details. |
|
Back to top |
|
 |
|