Hello , 

  as far as I know I can initialize a correlation set on a send or receive shape. However , I have this scenario (picture attached) where a have a branch and , on each branch I initialized different correlation sets . What I want is to remove this decision branch and to move the logic in an assignment shape (initializing programmatically the correlation sets ) , so I can have only one send shape (and to remove the decide branch).

Thanks 

If I understand what you're trying to do correctly then IMHO you DO NOT NEED TO CREATE these properties as Correlation Sets. These are available as promoted properties in the BTS namespace and if set on the message will help you achieve the same objective.

So remove the correlation sets, set these properties in different message construct shapes but have them join before the send. You actually need ONLY ONE SEND.

Regards.

Hello Shankycheil , 

  sorry , I might not understood what you said. What I want is to use a protocol agnostic approach , that will forward the response back to the proper adapter - considering the protocol that triggered the request : (if it's a request-response : send the response to the response port of request-response , if it is a One way send port (HTTP) , send the response to a HTTP one way port.  

   If it is a request-response adapter , the request will have this properties promoted (BTS.RouteDirectToTP,BTS.CorrelationToken,BTS.ReqRespTransmitPipelineID,BTS.IsRequestResponse,BTS.EpmRRCorrelationToken) .I need to update them in the response (I can copy them with something like Message_Send(*) = Message_Receive(*)) . They will be in the message context but not promoted . To promote them I need to initialize the correlation set (with all the above corelation).They need to be promoted for rooting purposes , so the response can go to the proper protocol adapter.For HTTP , however , I need to promote only BTSInboundTransportType correlation (and none of the request-response correlation I mention above).This is why I have the branch , not only to initialize the properties taken from the request but mostly to promote them (with the correlation set).

Bottom of line , I want to get rid of this branch somehow , to have only one send port ...

• Edited by CezarBotezatu 14 hours 16 minutes ago

So, can I ask why you're trying do to this?

There's nothing wrong with a Decide Shape.

I want to do that because receiving a request and sending a response back to the proper protocol adapter should be transparent for an orchestration (one send and one receive logical ports ) .For the orchestration should be totally transparent that a Request-Response adapter or One way adapter triggered the orchestration , the response , when is pushed back to the Message Box , should be rooted to the proper adapter .

For Request-response , Biztalk is forcing you to use a logical request-response port (and it's handling all the correlations that I'm trying to promote in my example ( I'm doing BizTalk's job because I want to have only 2 unified logical ports : a request logical port and a response logical port - no matter of the type of the adapter)) . 

Don't know if it makes too much sense what I said , though : -) 

• Edited by CezarBotezatu 13 hours 40 minutes ago

Yes, I think I see what you getting at.  I also think you're trying too hard to outsmart the engine. :)

I posted a Wiki Article about using Orchestrations with one or two way ports:

http://social.technet.microsoft.com/wiki/contents/articles/24389.biztalk-server-using-an-orchestration-sync-or-async.aspx

I recommend you follow this pattern instead.

• Edited by Johns-305 [boatseller]MVP, Moderator 13 hours 10 minutes ago

Hello Shankycheil , 

  sorry , I might not understood what you said. What I want is to use a protocol agnostic approach , that will forward the response back to the proper adapter - considering the protocol that triggered the request : (if it's a request-response : send the response to the response port of request-response , if it is a One way send port (HTTP) , send the response to a HTTP one way port.  

   If it is a request-response adapter , the request will have this properties promoted (BTS.RouteDirectToTP,BTS.CorrelationToken,BTS.ReqRespTransmitPipelineID,BTS.IsRequestResponse,BTS.EpmRRCorrelationToken) .I need to update them in the response (I can copy them with something like Message_Send(*) = Message_Receive(*)) . They will be in the message context but not promoted . To promote them I need to initialize the correlation set (with all the above corelation).They need to be promoted for rooting purposes , so the response can go to the proper protocol adapter.For HTTP , however , I need to promote only BTSInboundTransportType correlation (and none of the request-response correlation I mention above).This is why I have the branch , not only to initialize the properties taken from the request but mostly to promote them (with the correlation set).

Bottom of line , I want to get rid of this branch somehow , to have only one send port ...

• Edited by CezarBotezatu Tuesday, September 01, 2015 4:48 PM

Hello Shankycheil , 

  sorry , I might not understood what you said. What I want is to use a protocol agnostic approach , that will forward the response back to the proper adapter - considering the protocol that triggered the request : (if it's a request-response : send the response to the response port of request-response , if it is a One way send port (HTTP) , send the response to a HTTP one way port.  

   If it is a request-response adapter , the request will have this properties promoted (BTS.RouteDirectToTP,BTS.CorrelationToken,BTS.ReqRespTransmitPipelineID,BTS.IsRequestResponse,BTS.EpmRRCorrelationToken) .I need to update them in the response (I can copy them with something like Message_Send(*) = Message_Receive(*)) . They will be in the message context but not promoted . To promote them I need to initialize the correlation set (with all the above corelation).They need to be promoted for rooting purposes , so the response can go to the proper protocol adapter.For HTTP , however , I need to promote only BTSInboundTransportType correlation (and none of the request-response correlation I mention above).This is why I have the branch , not only to initialize the properties taken from the request but mostly to promote them (with the correlation set).

Bottom of line , I want to get rid of this branch somehow , to have only one send port ...

• Edited by CezarBotezatu Tuesday, September 01, 2015 4:48 PM

I want to do that because receiving a request and sending a response back to the proper protocol adapter should be transparent for an orchestration (one send and one receive logical ports ) .For the orchestration should be totally transparent that a Request-Response adapter or One way adapter triggered the orchestration , the response , when is pushed back to the Message Box , should be rooted to the proper adapter .

For Request-response , Biztalk is forcing you to use a logical request-response port (and it's handling all the correlations that I'm trying to promote in my example ( I'm doing BizTalk's job because I want to have only 2 unified logical ports : a request logical port and a response logical port - no matter of the type of the adapter)) . 

Don't know if it makes too much sense what I said , though : -) 

• Edited by CezarBotezatu Tuesday, September 01, 2015 5:25 PM

I want to do that because receiving a request and sending a response back to the proper protocol adapter should be transparent for an orchestration (one send and one receive logical ports ) .For the orchestration should be totally transparent that a Request-Response adapter or One way adapter triggered the orchestration , the response , when is pushed back to the Message Box , should be rooted to the proper adapter .

For Request-response , Biztalk is forcing you to use a logical request-response port (and it's handling all the correlations that I'm trying to promote in my example ( I'm doing BizTalk's job because I want to have only 2 unified logical ports : a request logical port and a response logical port - no matter of the type of the adapter)) . 

Don't know if it makes too much sense what I said , though : -) 

• Edited by CezarBotezatu Tuesday, September 01, 2015 5:25 PM

Yes, I think I see what you getting at.  I also think you're trying too hard to outsmart the engine. :)

I posted a Wiki Article about using Orchestrations with one or two way ports:

http://social.technet.microsoft.com/wiki/contents/articles/24389.biztalk-server-using-an-orchestration-sync-or-async.aspx

I recommend you follow this pattern instead.

• Edited by Johns-305 [boatseller]MVP, Moderator Tuesday, September 01, 2015 5:54 PM

Yes, I think I see what you getting at.  I also think you're trying too hard to outsmart the engine. :)

I posted a Wiki Article about using Orchestrations with one or two way ports:

http://social.technet.microsoft.com/wiki/contents/articles/24389.biztalk-server-using-an-orchestration-sync-or-async.aspx

I recommend you follow this pattern instead.

• Edited by Johns-305 [boatseller]MVP, Moderator Tuesday, September 01, 2015 5:54 PM

I understood what you're trying to do. Unfortunately BizTalk DOES NOT SUPPORT an 'If' construct in the Message Construct. It is for this reason that you will have to have a DECIDE shape, specific Message constructs BUT you can still use the SAME (or ONE) send shape.

Instead of the correlation sets I have used ResponseMessage(*) = RequestMessage(*) to ensure that the values get populated, while specifically setting "BTS.IsRequestResponse" and "BTS.RouteDirectToTP" to true in case and only "BTS.IsSolicitResponse" to true in the other. Having done this in the Message Construct and using the same message in both the branches you can pull the send shape out of the decide shape.

Normally I create a single decide with THREE branches, one to check for IsRequestResponse, second to check for IsSolicitResponse and the else clause. This helps me bind the same orchestration to both ONE Way, Two Way Ports and also address the "call orchestration" scenarios"

Regards.

I understand , Shankycheil , updating the properties is not a a big problem . Problem occurs when you need to promote them in the message context (using the Initializing correlation set). For each protocol (and branch , in my case), the set of the correlation initialized is different . I initialize different correlation on each send shape. Having just one send shape means that I should initialize all the correlations (for all possible protocols) and to invalidate the values of the correlations not related to the current protocol ? (Ex  : if HTTP -> BTS.IsRequestResponse = 'False' and BTS.RouteDirectToTP = 'False' but still promote all of them  : BTS.RouteDirectToTP,BTS.CorrelationToken,BTS.ReqRespTransmitPipelineID,

BTS.IsRequestResponse,BTS.EpmRRCorrelationToken , BTSInboundTransportType (<- for HTTP))

That was actually the question from the beginning , can I initialize different correlation shapes on ONE send shape (or other way to promote those properties ) using a runtime "If" condition (one send shape , no branches)

I apologize. You will need TWO SEND shapes with different correlation sets.

Regards.