Refactoring Orchestration into Two Pieces

Home Page Forums BizTalk 2004 – BizTalk 2010 Refactoring Orchestration into Two Pieces

Viewing 1 reply thread
  • Author
    Posts
    • #13707

      I have had mixed success with passing correlations. I have heard that passing initialized correlation sets is “not supported”. Although, it doesn’t say that in the docs.

      Not sure how else to solve this.

    • #13708

      What properties are involved in the correlation.
      Can you initialize the correlation set on the initial receive. Using a custom pipeline to promoted the correlated properties if they are not promoted directly from the message.
      Ensure these properties are in the message context of the message sent to the sub-orchestration. The sub-orchestration will have a correlation set of the same type as the main orchestration and will copy these properties into the response message and intialize its correlation set on send.

      The receive in the \”gather\” loop will follow the correlation set intialised by the main receive.

      One potential issue is when is the gather loop going to set its subscription for the return messages. If it is after completion of the scatter loop. What happens if the sub-orchestration completes before the scatter loop has completed. Are you going to get routing failures.
      You could try putting the scatter and gather loops in a parallel shape?

      • #13709

        A correlation is basically a dynamic filter. i.e. property values you are filtering on are only known at runtime.
        When you initialize the correlation the orchestration creates a subscription on the messagebox using the correlation set properties and their values as a filter.
        In order to gather all the responses from the scatter loop you need a single identifier from the original message that ties all the responses back to the orchestration instance.
        Create a property called CorrelationId. In the initial receive pipeline use a custom pipeline component to promote the MessageId into your CorrelationId property.
        In your orchestration have a Direct receive port, on the activate receive set your filter and add BTS.ReceivePortName = <portname>. You cannot bind a direct port so you will need to have a subscription filter to do this.
        Create a correlation set using the CorrelationId property and initialize this correlation set on the activate receive.
        Enter your Scatter loop, in a message assignment shape:
        outputmessage(YourNamespace.CorrelationID) = inputmessage(YourNamespace.CorrelationID)

        Send the messages on a direct port to your sub-orchestration.

        In the sub-orchestration create correlation set based on the CorrelationId property. You are not using this correlation set for correlation, but purely as a mechanism to promote the CorrelationId on the return message.
        In the messageassignment shape where your create the return message:
        responsemessage(YourNamespace.CorrelationID) = requestmessage(YourNamespace.CorrelationID)
        Send the response to a direct send port and initialize the correlation set on the send – This will promote the CorrelationId property.

        Back in your original message add an operation to the original direct receive port and link this to the receive shape in your gather loop. On this receive shape set Following Correlation to the correlation set initialized on the activate receive.

        • #13710

          Neal, can you want to email me your sample.

          • #13711

            I have an unruly orchestration that folows a \”scatter/gather\” model, i.e. it a loop with a send, then a loop with a receive. Due to not being able to init correlation in a loop, the orch has a lot of repetitive shapes before the loop (first time send) and the same logic in the loop.

            I am going to call a sub-orch from the \”scatter\” loop, but the question is will I have correlation problems in the \”gather\” loop. I was thinking about passing the correlationset from the original orch to the new one, but the parameter direction is \”in\” and grayed out so I cannot make it a \”ref\”.

            So in other words, can I the correlation be initialized in sub-orch, and yet do a receive with a following correlation in the main-orch?

            Any ideas appreciated.

            • #13712

              We are using SOAP Headers and do have a receive pipeline that promotes the SOAP Headers. One of the elements in the SOAP header is simply called CorrelationID, and we set it to a GUID.

              I’m still really confused what \”Initialize Correlation\” means in Biztalk and why it can only be done once. If I have a scatter/gather, I reset my CorrelationId on each Send, yet there is only one \”initialized correlation set\”.

              [quote:8f99fd7efb]Can you initialize the correlation set on the initial receive.[/quote:8f99fd7efb]
              I guess that is a round-about possibility that I can investigate further.

              In one of our orchestrations, we had send a dummy message to initialize correlation, because later we had a loop, and in the loop, only sometimes would we actually need to create and send the exception message (i.e. only when there were exceptions). Someone told me there is an adapter that eats the output (i.e. we are writing to message to a dummy flat file directory, but there is no need to really write there, this was just a get-around to set the correlation.

              I did try playing with passing a correlation set to a sub-orchestration.
              The parameter direction is limited to \”in\”. So I guess you have a receive with a \”following\” correlation in a sub-orch, but it seems to be impossible to have a send an initialize a correlation.

              • #13713

                [quote:f272f9ddcb]Can you initialize the correlation set on the initial receive.[/quote:f272f9ddcb]

                I just tried this, here is the scenario. I created a dummy project to test these concepts. I have a WeatherRequest and WeatherResponse schema (and an orchestrationA that I call with direct binding that receives the request and returns a dummy response).

                I have another orchestration that tests the scatter/gather model.
                I have only one correlation type and set in the orchestration, and it is on zip-code. When I receive the message with one zip code, I loop three times and increase the zip code by one each time.

                I changed the initial receive of the WeatherReq to \”Init. Correlation\”.
                I then have the scatter loop which has a Send WeatherReq2 (I basically just change the zip code and set an action that signals the orchestrationA – see above – to receive the message. The send shape at the bottom of the scatter loop sets the \”following correlation\”.

                I then have the gather loop, and also set the \”following correlation\” of the receive shape there.

                I’m now getting this compile error:
                error X2259: in a sequential convoy receive the ports must be identical

                According to the sequential convoy doc: \”Sequential correlated receives are receives that are correlated to previous receives.\”.

                There are no parallel shapes in my orch. The recap, the first receive receives a Weather Req and the second receive receives a WeatherResponse. The first receive is tied to a flat file port (and has a filter on the action). The second Receive is tied to a direct binding port.

                Thanks for any more ideas!

                • #13714

                  Thanks Greg.

                  I’m trying to do a proof of concept and a training example using a simple message without SOAP Headers – using ZipCode to correlate on. When I’m happy with the results, I will do surgery on the real live orchestrration. I’m also doing a custom in-house class next month, so I need to show them a simple example. I’ve got all the filtering set up as per your example.

                  I didn’t think about linking both receives to the same receive port.
                  This avoids the \”Convoy\” error I reported last message?

                  However, two questions:

                  1) Do I really need to add a second operation – or only if the messages are different schemas?
                  2) How do you add a second operation to a receive port?

                  I could upload my example somewhere if you are willing to take a look.
                  Yesterday, I went with the idea of sending a Dummy message to init the corrleation befoer the loop. We’ve done this before, and it should work, but for some reason I’ve probably got a dumb bug. I have trace statements through-out bouth orchestrations, and I see three messages being sent (scattered) to second orch. But for some reason,

                  [code:1:c09a36d7ea]
                  This is message that kicks off first orchestration via filter on the Action=\"SCATTER\":

                  00000000 0.00000000 [9292] Debug4Sub:A Started Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000001 0.00000000 [9292] <Zipcode>12345</Zipcode>
                  00000002 0.00000000 [9292] <Action>SCATTER</Action>
                  00000003 0.00000000 [9292] </ns0:WeatherRequest>

                  I THEN LOOP, BUMPING UP ZIPCODE AFTER EACH LOOP, AND SENDING MESSAGE TO DIRECT PORT. NOTE THE ACTION=\"WEATHER\", WHICH IS THE FILTER USED BY THE SECOND ORCH. SO HERE YOU SEE THREE SENDS WITH THREE ZIP CODES: 12345, 12346, 12347.

                  00000004 0.00003604 [9292] Debug4Sub:B Loop WeatherRequest=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000005 0.00003604 [9292] <Zipcode>12345</Zipcode>
                  00000006 0.00003604 [9292] <Action>WEATHER</Action>
                  00000007 0.00003604 [9292] </ns0:WeatherRequest>
                  00000008 0.31321803 [9292] Debug4Sub:C Send Completed

                  00000009 0.31637681 [9292] Debug4Sub:B Loop WeatherRequest=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000010 0.31637681 [9292] <Zipcode>12346</Zipcode>
                  00000011 0.31637681 [9292] <Action>WEATHER</Action>
                  00000012 0.31637681 [9292] </ns0:WeatherRequest>
                  00000013 0.34250945 [9292] Debug4Sub:C Send Completed

                  00000014 0.34277430 [9292] Debug4Sub:B Loop WeatherRequest=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000015 0.34277430 [9292] <Zipcode>12347</Zipcode>
                  00000016 0.34277430 [9292] <Action>WEATHER</Action>
                  00000017 0.34277430 [9292] </ns0:WeatherRequest>
                  00000018 0.40174520 [9292] Debug4Sub:C Send Completed ============ END OF LOOP MESSAGE ============
                  00000019 0.40338674 [9292] Debug4Sub:D Scatter Loop Completed
                  ============ END OF LOOP MESSAGE ============

                  EACH MESSAGE BELOW IS RECEIPT OF MESSAGE BY ORCH2.
                  MY CURRENT BUG IS THAT IT IS RECEIVING 5 MESSAGES, NOT 3.

                  00000020 0.86219531 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000021 0.86219531 [9292] <Zipcode>12345</Zipcode>
                  00000022 0.86219531 [9292] <Action>WEATHER</Action>
                  00000023 0.86219531 [9292] </ns0:WeatherRequest>

                  00000024 0.89273047 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000025 0.89273047 [9292] <Zipcode>12346</Zipcode>
                  00000026 0.89273047 [9292] <Action>WEATHER</Action>
                  00000027 0.89273047 [9292] </ns0:WeatherRequest>

                  00000028 1.65971065 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000029 1.65971065 [9292] <Zipcode>12347</Zipcode>
                  00000030 1.65971065 [9292] <Action>WEATHER</Action>
                  00000031 1.65971065 [9292] </ns0:WeatherRequest>

                  ——– THIS SHOWS THE FIRST RESPONSE BACK IN ORCH 1.

                  00000032 2.30413175 [9292] Debug4Sub:E Received Response=<ns0:WeatherResponse xmlns:ns0=\"http://CorrelationTests.WeatherResponse\"><Temperature>90</Temperature><Pressure>30</Pressure><Description>Partly cloudy</Description><City>Dallas</City><State>TX</State><Zipcode>12345</Zipcode></ns0:WeatherResponse>

                  ——– THIS SHOWS THE SECOND RESPONSE BACK IN ORCH 1.

                  00000033 2.44385099 [9292] Debug4Sub:E Received Response=<ns0:WeatherResponse xmlns:ns0=\"http://CorrelationTests.WeatherResponse\"><Temperature>90</Temperature><Pressure>30</Pressure><Description>Partly cloudy</Description><City>Dallas</City><State>TX</State><Zipcode>12345</Zipcode></ns0:WeatherResponse>

                  —- NOW ORCH 2 RECEIVES MORE MESSAGES…

                  00000034 2.70041561 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000035 2.70041561 [9292] <Zipcode>12347</Zipcode>
                  00000036 2.70041561 [9292] <Action>WEATHER</Action>
                  00000037 2.70041561 [9292] </ns0:WeatherRequest>
                  00000038 2.93957758 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                  00000039 2.93957758 [9292] <Zipcode>12346</Zipcode>
                  00000040 2.93957758 [9292] <Action>WEATHER</Action>
                  00000041 2.93957758 [9292] </ns0:WeatherRequest> [/code:1:c09a36d7ea]

                  The two extra messages result in two suspended instances of Orch2 with message Microsoft.XLANGs.Core.PersistenceException. Orch 1 remains dehyrdated.

                  I have done some work trying to see when items appear in BTSSubscriptionViewer. So for instance, if you receive a message and set \”initializing correlation\” – does that immediately create a subscription – or does it wait until the first Send. This is what confuses me – what does \”Initialize Correlation\” mean vs creating a subscription.
                  Each send in the scatter loop must create a subscription because the \”key\”, i.e. the promoted field that we are correlating on is different.

                  • #13715

                    The whole trace didn’t get pasted in last message:

                    [code:1:6e6c86dc09]00000025 0.89273047 [9292] <Zipcode>12346</Zipcode>
                    00000026 0.89273047 [9292] <Action>WEATHER</Action>
                    00000027 0.89273047 [9292] </ns0:WeatherRequest>
                    00000028 1.65971065 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                    00000029 1.65971065 [9292] <Zipcode>12347</Zipcode>
                    00000030 1.65971065 [9292] <Action>WEATHER</Action>
                    00000031 1.65971065 [9292] </ns0:WeatherRequest>
                    00000032 2.30413175 [9292] Debug4Sub:E Received Response=<ns0:WeatherResponse xmlns:ns0=\"http://CorrelationTests.WeatherResponse\"><Temperature>90</Temperature><Pressure>30</Pressure><Description>Partly cloudy</Description><City>Dallas</City><State>TX</State><Zipcode>12345</Zipcode></ns0:WeatherResponse>
                    00000033 2.44385099 [9292] Debug4Sub:E Received Response=<ns0:WeatherResponse xmlns:ns0=\"http://CorrelationTests.WeatherResponse\"><Temperature>90</Temperature><Pressure>30</Pressure><Description>Partly cloudy</Description><City>Dallas</City><State>TX</State><Zipcode>12345</Zipcode></ns0:WeatherResponse>
                    00000034 2.70041561 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                    00000035 2.70041561 [9292] <Zipcode>12347</Zipcode>
                    00000036 2.70041561 [9292] <Action>WEATHER</Action>
                    00000037 2.70041561 [9292] </ns0:WeatherRequest>
                    00000038 2.93957758 [9292] Debug2A: Request=<ns0:WeatherRequest xmlns:ns0=\"http://CorrelationTests.WeatherRequest\">
                    00000039 2.93957758 [9292] <Zipcode>12346</Zipcode>
                    00000040 2.93957758 [9292] <Action>WEATHER</Action>
                    00000041 2.93957758 [9292] </ns0:WeatherRequest>[/code:1:6e6c86dc09]

Viewing 1 reply thread
  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.