After the first part, I “propose” to replace the RequestResponse of the 2nd orchestration by 2 one-way port. Why? You can imagine that your orchestration could be called by a client who want a response or by an automatic process which doesn’t attempt any response.
So we want to replace this :
by this :
Due to the explanation of the 1st part, we know that we have to use the Property BTS.CorrelationToken.
So we just have to :
- Get the value of the BTS.CorrelationToken of the Request Message
- Set this value in the Response Message ( msgResponse(BTS.CorrelationToken ) = msgRequest(BTS.CorrelationToken ) // This expression write the value in the context )
- Initialize a correlation on the property BTS.CorrelationToken (this action promote the property in the context to enable routing)
In the first orchestration (the caller ), we’ve nothing to change.
Using these two one way port we can decide if we want to send a response or not according to a value in the context or if the BTS.CorrelationToken is present in the request message
NB : This pattern work only if the caller is an orchestration , you will see in the next part what problems occurs when we try to do this directly with a Request-Response physical port.