locked
Relation between TERMINATE shape and CORRELATION SET in an Orchestration RRS feed

  • Question

  • Hello,

    My Requirement: Initialize a correlation set based on a generated Guid. Use that Guid inside the wcf request message. Call that wcf service(request-response) from an orchestration to an external system. Upon SOAPFault or an exception(i have two specific catch blocks for these), Suspend the workflow in the catch blocks so admins can later resume that orchestration instance. After the scope that contains the two exception blocks, I have a receive shape that follows the above initialized correlation to investigate the Asynchronous response from the external system. When I build the project, Surprisingly I get the error: "error X2279: uninitialized correlation XXX.Correlation_CID" where Correlation_CID is my correlation set name. 

    When I REPLACE my Suspend shapes with Terminate shapes, the error is gone and the project compiles !!! 

    I tried moving the correlation initialization to the top most level(without any scopes) and also various parts of the orchestration in the orchestration, Still the same error.

    I am wondering what kind of behavior is this. Is there a relation between Terminate shape and correlation set in an Orchestration. Or Am I doing anything wrong? Please help as I am staring at my monitor from 2 days, trying to figure out!!

    Thank you.

    Monday, August 15, 2016 10:54 PM

Answers

  • What you're asking for exactly is described here:

    http://social.technet.microsoft.com/wiki/contents/articles/31665.biztalk-server-suspend-and-resume-an-orchestration-on-two-way-port-error.aspx

    However, you have hit a Catch-22 in the Orchestration Designer.  You cannot Initialize a Correlation Set in a Loop Shape nor can you pass a Correlation Set as a Ref our Out Parameter to a Called Orchestration.

    So, what you have to do is this:

    1. Implement the retry as described in the above article.

    2. After that is successful, use a second Send Shape to Initialize the Correlation Set.  To consume the message sent by this shape, you can use an Orchestration with just one Receive Shape or a null Send Port.

    The key point is that it doesn't matter where you Initialize the Correlation Set, it doesn't have to be on the Two-Way Send.

    • Proposed as answer by Angie Xu Wednesday, August 24, 2016 6:50 AM
    • Marked as answer by Angie Xu Wednesday, August 24, 2016 6:51 AM
    Wednesday, August 17, 2016 2:12 PM
    Moderator

All replies

  • Hi,

    Believe you are getting this error because you are trying to follow the correlation set in exception block, try initializing and follow the correlation in the same scope and recompile.

    or

    try to define your correlation set in a non long running scope contained within your long running scope.

    I don't think there is any relation between terminate and correlation, terminate shape does ends the instance subscription of your orchestration indicating the correlation properties which would have got promoted when you initialized the correlation will cease to exist, if there are error at build time you might still bump into issues at run time.

    Also if you use the terminate shape within your catch exception block instead of suspend shape your orchestration will not be resumable.


    Regards Pushpendra K Singh

    Monday, August 15, 2016 11:24 PM
  • Hi,

    There is no relationship between those.

    It's purely designed time build error, because of missing configuration / logical flow.

    You need to properly initialize / follow the correlation logically.

    Thanks, SMSVikasK

    Tuesday, August 16, 2016 7:28 AM
    Answerer
  • Hi BizTalk Guy,

    error X2279: uninitialized correlation XXX.Correlation_CID" where Correlation_CID is my correlation set name.

    this error occurs when the correlation set has not initialized and some other shape is made to follow the same correaltion set.

    Please find the belowscreen shot.

     As you observe there are two correlation sets as seen in the screen shot. If you initialize the correaltion set inside the scope (here scope_1), that correlation set will stay initialized for the scope onlty. So if you are trying to make the receive after yoyu exception bloack follow the correaltion set, what you need to do is initialize the correclation set at the begining of the orchestration i.e at global level highlighted by an arrow in above screen shot.. than only you will be able to make the receive after the exception blocks follow the correlation set.

    Also if you use the suspend shape inside the orchestration, then the particular instance of the orchestration gets suspended with all the messages with their context property intact.

    In case of terminate shape the Orchestration instance is terminated and all its records are removed from the messagebox database.

    I agree with Pushpendra,

    there is no rel,ation between the correlation set and the suspend shape.

    Regards,


    Mandar Dharmadhikari

    Tuesday, August 16, 2016 8:11 AM
    Moderator
  • It's because the compiler detects that an error can occur before the Send Shape which initializes the Correlation Set, so when flow jumps to the Catch Block, the Correlation Set is not Initialized.

    Now, it may be 100% totally for sure that no error will ever occur, but the compiler does not know this.

    Without seeing the entire Orchestration, it works with the Suspend Shape probable because a Resume would restart the current scope before the Send Shape so it might work that time.

    There is no specific relationship between the Terminate/Suspend Shapes and Correlation Sets.

    Tuesday, August 16, 2016 1:53 PM
    Moderator
  • Thank you all, delighted to see many replies.

    This is my requirement:

    Initialize a correlation on a send shape.

    Call the service.

    Put a loop around the call to service and also a suspend shape to facilitate retrying\resuming of the orchestration instance in case of timeout\error. I am going to set retryCount to 0 on physical send port.

    Once the resuming is successful and the service is called successfully (for a handshake), Have the orchestration listen asynchronously on the same correlation that was initialized earlier.

    Please let me know if  this is possible, if so what are the steps?

    Tuesday, August 16, 2016 6:52 PM
  • Hi,

    You can have the resume option from the service send port since there will be a suspended send port msg in event of any error or timeout. Is there any specific need for which you need the orchestration to be resumed? If it is an orchestration with simple logic I would say you are better off resuming from port.

    Also you need a simple retry pattern in case you still need to stick to resuming logic within orchestration. I am not able to understand how using a correlation property will help your resume.

    Check this article for the resume pattern.

    https://psrathoud.wordpress.com/2014/02/01/understanding-resume-pattern-in-biztalk/


    Regards Pushpendra K Singh


    Tuesday, August 16, 2016 7:02 PM
  • This Wiki Article describes what you're looking for:

    http://social.technet.microsoft.com/wiki/contents/articles/31665.biztalk-server-suspend-and-resume-an-orchestration-on-two-way-port-error.aspx

    If it's a Two-Way Port, you do not need a Correlation Set at all.

    Tuesday, August 16, 2016 7:07 PM
    Moderator
  • hi biztalk guy,

    can you explain the business requirement??? its hard to understand why u want to do it???


    Mandar Dharmadhikari

    Tuesday, August 16, 2016 7:08 PM
    Moderator
  • Sure. I need to send some info to an external System that does Async processing of the info I sent. So, first the external system's service will give a handshake response. Then after an hour or so whenever it is done processing, It will call a different one-way service exposed by me to push the Async response to my workflow. Following the arrival of Async response, My workflow needs to resume and investigate the Async response and log the response and email it and so on... I surely want my orchestration to do the retry, not the physical send port because i can resume my workflow where i left off when the send shape failed. Remember by using a send port retry, if the retry is succeeded, my remaining part of the orchestration that listens for the Async response will still remain suspended and becomes useless. I know Correlation is no way related to retry. They are separate requirements within the same workflow. Hope it clarifies now?
    Tuesday, August 16, 2016 8:07 PM
  • Hi,

    ok the scenario appears like your orchestration will be in dehydrated state instead of in the suspended state hence it will not hit the exception block in valid business scenario and when it does you can always resume it, so you need not need to follow  the correlation property within your catch exception. Just thinking aloud here :-)

    Anyways if you still decide to stick to your approach : try to define your correlation set in a non long running scope contained within your long running scope, nested scope and see if that works for you.


    Regards Pushpendra K Singh

    Tuesday, August 16, 2016 8:27 PM
  • Hold on, don't over thinking this.

    Follow the instructions in the article to retry/suspend the 'handshake' operation since this is a Two-Way Port.  Now, very important, this has nothing to do with the Correlated Receive.

    You still Initialize the Correlation Set on the Send Shape.  The trick is, you will have to use a Called Orchestration because you cannot Initialize a Correlation Set in a Loop.  This is really nothing special, just set the Request/Response Messages as In/Out Params.

    The Correlated Receive Shape is after all this, meaning after the handshake response is received.  You would not put it in any Catch Block or anything since it's not an error condition.

    Tuesday, August 16, 2016 8:40 PM
    Moderator
  • I am NOT following correlation in my catch block. Two separate requirements: One: In catch block, suspend the orchestration. It should be resumable to call the service again. Two: once the resume is successful on subsequent retries, I should execute the correlation on receive shape when ever the Async response comes back.
    Tuesday, August 16, 2016 8:41 PM
  • Hi,

    this should be a simple design:

    After you rcv acknowledgement shape from service use a listen shape and put your asynchronous  receive shape under - note: since your 2nd response from service is going to be asynchronous the service layer has to ensure that they return some business id relevant to request which you can correlate on.

    Please note if this is high volume scenario better not to use an orchestration since you dont want too many instances dehydrated. In that case you can design an another asynchronous sub orchestration listening to response on the Service 


    Regards Pushpendra K Singh

    Tuesday, August 16, 2016 10:31 PM
  • Thanks. I am using the traditional boolean flag and looping mechanism so that In case of an error while calling the service, when I resume my orchestration from the suspend shape in the catch block, the work flow again calls the service. Can someone tell how to do this? it is not working currently.
    Tuesday, August 16, 2016 11:07 PM
  • Hi, Will you be able to share the orchestration code? 


    Regards Pushpendra K Singh

    Wednesday, August 17, 2016 1:12 AM
  • What you're asking for exactly is described here:

    http://social.technet.microsoft.com/wiki/contents/articles/31665.biztalk-server-suspend-and-resume-an-orchestration-on-two-way-port-error.aspx

    However, you have hit a Catch-22 in the Orchestration Designer.  You cannot Initialize a Correlation Set in a Loop Shape nor can you pass a Correlation Set as a Ref our Out Parameter to a Called Orchestration.

    So, what you have to do is this:

    1. Implement the retry as described in the above article.

    2. After that is successful, use a second Send Shape to Initialize the Correlation Set.  To consume the message sent by this shape, you can use an Orchestration with just one Receive Shape or a null Send Port.

    The key point is that it doesn't matter where you Initialize the Correlation Set, it doesn't have to be on the Two-Way Send.

    • Proposed as answer by Angie Xu Wednesday, August 24, 2016 6:50 AM
    • Marked as answer by Angie Xu Wednesday, August 24, 2016 6:51 AM
    Wednesday, August 17, 2016 2:12 PM
    Moderator
  • Pushpendra, I will share the workflow soon.

    Thanks Johns-305. I have included my loop inside a scope shape that way i can initialize my correlation, since correlation gets initialized only once per scope. Now when I ask the admins to retry in case of a service call failure, I have to ask them not to resume the physical send port instance and terminate them, correct? Because I have suspend, resume and retry logic everything built in my orchestration itself.

    One question about your point No.2.  When I use null adapter for second send shape, still Is the message going to be dropped in the message box? in which case my following receive shape will consume that message. Unless i use a whole separate dummy schema for my message that is used on the second send shape. Can you advise?

    Wednesday, August 17, 2016 5:24 PM
  • So, you have to follow all the instructions in the Article.  No shortcuts.  The physical Send Port is also taken care of, no need for the Administrators to touch that at all since it should complete normally.  The admins should only Resume the Orchestration, nothing else.

    Without seeing your Orchestration, I think you will still get a runtime error because of the Loop.

    On #2, no, because that Send will only Initialize the Correlation Set.  So long as it is consumed by something, you're good.  Unless the Send and Receive Messages are the same Type, it would not loop back to the Correlated Receive.

    • Proposed as answer by Angie Xu Wednesday, August 24, 2016 6:50 AM
    Wednesday, August 17, 2016 5:39 PM
    Moderator