Search code examples
mapsbiztalkbiztalk-2010biztalk-orchestrations

Promoted Property in Orchestration

I have reading about that we can promote property in the orchestration. Below are my steps -

  1. Create a new "StudentID" promoted property.
  2. Change value "MessageContextPropertyBase".
  3. Update value of the "StudentID" in the orchestration.
  4. Create a new correlation set of "StudentID".
  5. Initializing correlation set of Send shape.
  6. Create a send port in the BizTalk Administrator Console.
  7. Set a filter "POC.PromotedProINOx.Schema.PropertySchema.StudentID == "7" "

I am getting no error. But I want that if "StudentID" is 7 then it should be subscribe.

Issue - I think that it's not checking value of "StudentID" as message file always drop in the out folder.

Am I missing something?

Solution

  • There could be several things you are missing

    1. If message on the Receive Port has a message that has the same promoted property with the correct StudentID of 7, both the Orchestration and the Send Port will subscribe to it. So if you set the StudentID to something else in the Orchestration the message you are sending through the send port didn't actually go through the Orchestration but came directly from the Receive Port.
      Fix: have the value for the received message set to something else or not have the promoted property on the inbound message.

    2. You have specified the Logical Port in the Orchestration to Specify Later and then bound it too the Send Port. By default a Send Port always has a subscription of it's Unique ID. When an Orchestration publishes the message through a Logical Port bound to a send port it sets and promotes that ID when it publishes the message. Even adding a subscription rule just means it will treat it as BTS.SPID = {id} OR {your rule}. This means even if the StudentID does not match the subscription rule on the send port it will match the SPID and still pick it up.
      Fix: Change your logical port in the Orchestration to Direct Bound.

    3. The third possibility is that from the Orchestration the message that you are publishing does in fact have a StudentID of 7.
      Fix: Check you construct shapes (Map & Assignment) to make sure that you are actually setting it to another value. Make sure that the message specified in the Send Shape is actually the one constructed with the new value.

    The way to analyze the problem is to look at the context properties of the message that is going through the send Port, either by enabling tracking of Properties before the Pipeline, or by Stopping (but not Unenlisting) the Send Port and looking at the Context Properties of the Suspended message(s).

    If the message going through the Send Port has the StudentID = 7 then either you have done #3 or #1 see below.

    If the message has the details of the Receive Port as well as the StudentID, then it has come directly from the Receive Port as per #1. However I would expect to see a error from the Orchestration from when it attempted to publish a message with a different StudentID, unless either the Orchestration did not even run (look at tracked instances) or see below.

    If the message going through the Send Port has the promoted property of BTS.SPID then the Logical Port is bound to the Send Port as per #2.

    If you are getting two messages for each one you put in, you will have one of each of the above and have done both #1 & #2.

    In Summary, always check the context properties of a message whenever it does not route the way you expect it too.