none
if shared data is updated in a parallel then all references in every task must be in a synchronized or atomic scope

    Question

  • Hello,
    I am getting the error in orchestration while building the project. Let me first explain about the orchestration.

    scenario1:FileDownload

    Source schema is "Codeco95B"
    destination schema is "Oracledbbinding"  [insert the mapping output into oracle table]

    Scnaroi2: File Generation [reverse operation of file download]

    Source: Read the data's from Oracle table [OracleDBBindingPOLLINGSTMT.xsd]
    destination schema is "COdeco95B"
    I did the separate projects for scenario1:FileDownload and Scnaroi2: File Generation. The two application is running fine but
    now intended to combine the two [scenario] into single project.

    please guide me to solve this problem. how to handle the exceptions in orchestration. And help me to improve/redesign the orchestration .


    Thanks, Archana

    Wednesday, July 17, 2013 6:23 AM

Answers

  • If the two scenarios are different they DO NOT COMBINE THEM into a single Orchestration. If these scenarios are related in ways such as shared schemas, port, helpers libraries and/or maps then put them into One Application and/or ONE BizTalk Solution but independent projects.

    In regards to when you should

    1. parallel actions - when for the completion of a specific task different activities can be done independed of one another then you use parallel shape. e.g.: For the preparation of a message you need to query different things from same/different systems then each of those queries can be put into a parallel shape. NOTE: the BizTalk Host instances will still execute this but maybe in different threads within the main thread.
    2. Scope - A scope is associated with a persistence point (which is when BizTalk writes data into the MessageBox). A Scope on the broader term implies if you want to club multiple actions/activities into a single cohesive action which should succeed or fail.
    3. Compensate - in case yor scope clubs actions across multiple/disparate systems then it may so happen that while the transaction has succeeded in System A, it failed a subsequent action in System B. In this case you actually need to write a reversal for System A. This is compensation as from a business standpoint either both or none defines the transaction (Scope).
    4. Exceptions - you catch exceptions and this may result in you having to compensate.

    Regards.

    Thursday, July 18, 2013 6:33 AM

All replies

  • This article here shows you how to setup a synchronised scope in each branch if you have a shared variable. I hope this helps. http://www.codeproject.com/Articles/13413/Parallel-Branching-and-Scoping-in-BizTalk-Orchestr
    Wednesday, July 17, 2013 6:56 AM
  • When two activities are executing in parallel, common data elements (used across both paths) need to be protected from simultaneous access. In code you typically use SyncLock or other such mechanisms to ensure data integrity. If you put the entire branch into one scope then this error would go away, but in this case it'd interfere with the request-response pattern, etc.

    As you mentioned, one branch consumes a file and loads data into DB while the other consumes data from a DB and generates a file... so why combine? They are two different tasks and if kept separate will execute in parallel if both the events occur so what are you trying to achieve by clubbing them as ONE orchestration?

    Regards.

    Wednesday, July 17, 2013 7:22 AM
  • I did the separate projects for scenario1:FileDownload and Scnaroi2: File Generation. The two application is running fine but

    now intended to combine the two [scenario] into single project.

    Can you clarify this a bit?  Do you mean separate Projects, as in BizTalk Projects in Visual Studio?

    If all you want is one single VS project, just copy/move the other .odx into the other project.

    Are these two processes even related?  What you've set up is a Parallel Convoy so the first two Request messages must be directly related through a Correlation Set.

    You description suggests Scenario 1 & 2 would operate serially, ie. 1 then 2.  That would be two separate Orchestrations.

    Wednesday, July 17, 2013 11:45 AM
  • Hello,
    I am getting the error in orchestration while building the project. Let me first explain about the orchestration.

    Archana,

    You didn't specify the error your are getting, can you tell what error you are getting?


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful.

    Wednesday, July 17, 2013 1:16 PM
  • It really looks like these should be two seperate orchestrations, unless there is a dependency in one branch on the other branch (in which case you'll probably run into trouble anyways due to non-determinism)...

    You said you wanted these to be part of the same project, but they could still be seperate orchestrations in the same project.  Is there a reason this needs to be in a the same orchestration in a parallel shape?

    Wednesday, July 17, 2013 10:15 PM
  • I agree with Shankycheil. Why do you aggregate two independent processes in one orchestration?

    Leonid Ganeline [BizTalk MVP] BizTalk: the Naming Conventions in Examples

    Thursday, July 18, 2013 2:55 AM
  • Hi all,

    @ SAAkhlaq,

    I am getting the error "if shared data is updated in a parallel then all references in every task must be in a synchronized or atomic scope".

    @Shakycheil,Boatseller,Johann & Leonid,

    yes.two scenario is totally different, I thought that by using the parallel actions I can able to combine two different orchestration into single orchestration.

    @All

    my intension is combine two orchestration into a single. parallelly I would like to run the two different scenario. is it possible to combine two different scenario in parallel shape? I am new to BizTalk. Please advice me on this

    when should I use

     1.parallel Actions

    2.Scope

    3.Compensate

    4.How can I handle the exceptions?

    please guide me.

    finally, I am maintaining two orchestration for two different scenario. i set filter on the send port based on the bts.receiveportname =receive port name.the application is running fine without any issue.I want to know the details about the parallel scope actions.


    Thanks, Archana

    Thursday, July 18, 2013 5:21 AM
  • If the two scenarios are different they DO NOT COMBINE THEM into a single Orchestration. If these scenarios are related in ways such as shared schemas, port, helpers libraries and/or maps then put them into One Application and/or ONE BizTalk Solution but independent projects.

    In regards to when you should

    1. parallel actions - when for the completion of a specific task different activities can be done independed of one another then you use parallel shape. e.g.: For the preparation of a message you need to query different things from same/different systems then each of those queries can be put into a parallel shape. NOTE: the BizTalk Host instances will still execute this but maybe in different threads within the main thread.
    2. Scope - A scope is associated with a persistence point (which is when BizTalk writes data into the MessageBox). A Scope on the broader term implies if you want to club multiple actions/activities into a single cohesive action which should succeed or fail.
    3. Compensate - in case yor scope clubs actions across multiple/disparate systems then it may so happen that while the transaction has succeeded in System A, it failed a subsequent action in System B. In this case you actually need to write a reversal for System A. This is compensation as from a business standpoint either both or none defines the transaction (Scope).
    4. Exceptions - you catch exceptions and this may result in you having to compensate.

    Regards.

    Thursday, July 18, 2013 6:33 AM
  • I do not use the parallel processing shape very much and will explain why later. I think that parallel processing shape can be used when you have two or more processes that might take a long time to process and you want to make sure that each process finishes before continuing. The last part of the sentence is important because if it is not important that each process finishes before proceeding then there is nothing to be gained from using the parallel processing shape. I think that if there is not a dependency for all processes to finish together then you should not use this shape. This shape is useful if one of the dependant processes might block for sometime and you do not want to wait before executing the other processes. Note that the parallel processing shape tries to execute each branch in sequence starting from the most left hand branch. If that branch blocks then the next one starts. It is a common misconception that all processes in a parallel shape execute at the same time. This is confusing to most novices. Thus I think the only advantage of the parallel processing is to group several processes together to make sure they all process before proceeding. If the shape did truly process all branches in parallel then I would use it more often. How to use scopes is a big question that I can't cover properly here. Use the codeplex article article i that gave in my first reply as a starting point to try to understand how to use scopes with the parallel processing shape. Once you have understood that example then you might need to ask some more questions. You will have to use scopes properly to use the parallel processing shape. Once again how to use compensation and exception handling is another big topic. I think you should ask a separate question in this forum about how to use compensation and exception handling after you have read these MSDN articles. http://msdn.microsoft.com/en-us/library/aa577575(v=bts.20).aspx and http://msdn.microsoft.com/en-us/library/aa578339(v=bts.20).aspx.
    Thursday, July 18, 2013 6:34 AM
  • "yes.two scenario is totally different,"

    Then no, should not combine them.

    To answer you question specifically, it is not possible at all to combine them using the Parallel Shape.

    Combining doesn't get you anything in terms of performance, all it would do is introduce extra complexity to the management and development experience.

    Thursday, July 18, 2013 2:08 PM