Uniqueness of conversation IDs(?)

Question

In WebLogic81sp5/WLI8.5 I use a service control to call a conversational Web service from a JPD process. The service control exposes two methods, clientRequest (conversation state: start) and a callback method, clientResponse (conversation state: finish).
When I call the clientRequest method (in a Control send node), the service control generates a unique conversation id of the form:
[<processInstanceID>]myserviceControl:<AUniquePart>
Now, the web service may not reply, so I put a Timeout path on my Control send/Control receive structure, configured to retry once. In case the response does not arrive within, say, 1 minute, the request is resent, generating a new conversation ID for the service control:
[<processInstanceID>]myserviceControl:<AnotherUniquePart>
So far, so good. But now the fun starts: Assume that the first response was only delayed, not lost. After 1.5 minutes it arrives, bearing the original conversation ID in a <CallbackHeader> element in the SOAP header. Because the service control is now tied to the new conversation ID, I would expect the Workshop framework to ignore the incoming (delayed) response and just return a SOAPFault saying that the conversation ID is unknown.
However, the process happily accepts the old message, even if the conversation ID is outdated?
In fact, when the second response arrives, IT triggers a SOAPFault stating that the conversation is unknown.
Workshops seems to discard the unique part of the service control conversation ID, given that the error message reads: "An attempt was made to send a request to conversation id <processInstanceID>. This is not a valid conversation id." So for conversation control, Workshop only uses the process instance ID?
I tested this theory by having the web service return with a modified conversation ID in the header, like:
[<processInstanceID>]myserviceControl:BLAHBLAHBLAH
Indeed, the process happily accepts this response and continues?!
Is this how the Workshop framework is supposed to work, or is there some switch that I am not aware of? In other words, how can I make sure that Workshop does not loose the uniqueness of a service control ID and just accepts any incoming message to the process instance in question?
(This becomes a serious issue if the control is used more than once in a process. Assume requestA will generate responseA ('SUCCESS'), and requestB will generate responseB ('FAILURE'). If the Control receive node waiting for responseA times out, it causes requestA to be resent. Now, if the first responseA is received, it will appear to the process as belonging to the second requestA. This is not critical; however, when the process now sends off requestB, it receives (and accepts) the second responseA as belonging to requestB! Since responseA and responseB differ (SUCCESS/FAILURE), the process now thinks that requestB went fine even though it actually failed.)
If you are still with me so far, I thank you for reading and apologize for the lengthy post...
/ Anders

Answer 1

Hi Anders
Hi
I tested your scenario and it seems to work as designed.
It is true that the process Instance Id is what JPD considers and not the whole of conversationId.
So which ever response "comes first" will be consumed and other will get dropped.This is what we see now.
Here are the convId and the results for 2 concurrent requests.
JPD ---> Service control ---> JWS
Req 1:
<conversationID>[1152668451563]ws:192.168.1.100-1be3a66.10c6056ed9d.-7f8d</conversationID>
Retry1:
<conversationID>[1152668451563]ws:192.168.1.100-1be3a66.10c6056ed9d.-7f87</conversationID>
Response1:
Actual response with convId [1152668451563]ws:192.168.1.100-1be3a66.10c6056ed9d.-7f8d
Retry1 Response:
Failure with conv Id [1152668451563]ws:192.168.1.100-1be3a66.10c6056ed9d.-7f87
com.bea.wlw.runtime.core.bean.ConversationNotFoundException: An attempt was made to send a request to conversation id 1152668451563. This is not a valid conversation id. The most common cause of this exception is an attempt to send a request to a conversation that has already been
Request2:
<conversationID>[1152668454958]ws:192.168.1.100-1be3a66.10c6056ed9d.-7f8a</conversationID>
Retry of request2:
<conversationID>[1152667953547]ws:192.168.1.100-1be3a66.10c6056ed9d.-7fa5</conversationID>
Response1:
Actual response with convId [1152668454958]ws:192.168.1.100-1be3a66.10c6056ed9d.-7f8a
Retry1 Response:
Failure with conv Id [1152667953547]ws:192.168.1.100-1be3a66.10c6056ed9d.-7fa5
com.bea.wlw.runtime.core.bean.ConversationNotFoundException: An attempt was made to send a request to conversation id 1152668451563. This is not a valid conversation id. The most common cause of this exception is an attempt to send a request to a conversation that has already been
MULTIPLE CONTROL INSTANCES:
In this case I believe we can use control factory to create multiple control instances and so they get unique control instance id also and so the responses are consumed correctly not across the requests as you mentioned here.
You can define a factory like
* @common:control
private test.WsControlFactory wsFac;
and then create the instances by
public void wsSayHello1() throws Exception
WsControl ws1 = wsFac.create();
WsControl ws2 = wsFac.create();
ws1.sayHello(timeout);
ws2.sayHello(timeout);
I have tested this scenario also.
the conv id looks like
control instance1 (ws1)
<conversationID>[1152668886228]wsFac:0:192.168.1.100-1be3a66.10c6056ed9d.-7f79</conversationID>
control instance2 (ws2)
<conversationID>[1152668886228]wsFac:1:192.168.1.100-1be3a66.10c6056ed9d.-7f77</conversationID>
control instance1 retry
<conversationID>[1152668886228]wsFac:2:192.168.1.100-1be3a66.10c6056ed9d.-7f6f</conversationID>
control instance2 retry
<conversationID>[1152668886228]wsFac:3:192.168.1.100-1be3a66.10c6056ed9d.-7f6d</conversationID>
Please let me know if you have any questions or you see a different behavior.
Thanks
Vimala