locked
XML Diassembler component is not doing property promotion RRS feed

  • Question

  • Hello Everyone,

    I have a schema with three fields A, B and C. I have made them promoted properties.

    I have also created pipeline component which reads the value from                     

    //Fetching values of A
     objA = inmsg.Context.Read("A", "https://TestProj.PropertySchema");

    I have also created a Receive Pipeline where I am using XMLDiassembler in disassemble stage and kept this pipeline component in Validate stage.

    So, as per my understanding once XMLDiassembler is executed all the properties should be promoted but I am getting null while reading element A(objA).

    Please guide.

    


    However when i am using XML Receive Pipeline values are getting promoted.

    Thanks,
    Prashant


    Thursday, March 19, 2015 10:05 AM

Answers

  • Basically, the XmlDisassembler does not read through the incoming message immediately.  It waits until some later component or the MessageBox reads it.  This is done for various performance reasons, memory consumption, etc.

    So, since your custom component is next in line, when it gets the Message, the data has not yet been read by the XmlDisassembler, even though it passed that Stage in the Pipeline, so it hasn't had a chance to read and Promote any Context Properties.  This is by design, and what you are seeing is a known side-effect.

    This is accomplished by wrapping the data in a custom Stream class.  That is why it only gets read and processed when some other component Reads it.  Like this:

    [SomeLaterComponent].Read

      --> xmlDasm.Read

        -->  XmlStream.Read  (I don't recall exactly which one)

          -->  Property Evaluation

            -->  Property Promotion

    The easiest thing would be to just do you work with the Properties in an Orchestration.  If you absolutely have to use a Pipeline Component, then you have to somehow force a Read by the XmlDisassembler.

    Unfortunately, this can get a little tricky due to differences in possible underlying streams.

    MemoryStream ms = new MemorySteam();
    YourIncomingDataPartStream.CopyTo(ms);
    ms.Position = 0;
    YourIncomingMessage.BodyPart.Data = ms;
    
    Code like this will force the message to be processed by the XmlDisassembler and cause the Properties to appear.  Note, this is a very basic non-optimized example.  You may have to/should modify to better suit your case.

    Thursday, March 19, 2015 1:04 PM
    Moderator
  • Ahh, if the custom pipeline (which is next to XML-disassembler) is where you access the promoted field, then you can’t access the custom properties in same receive pipeline.  Inside a receive pipeline, you can promote items to the message context only if you need them for Orchestrations, Send Ports. For accessing you may need a custom code which handles the streaming.

    This is due to the restriction as John described. When the message is received, the whole message is not loaded for performance reason. BizTalk pullsas stream, the stream of data through the pipeline and adapter. So when the stream reaches the disassemble stage XML-disassembler handles the stream,  also at the same time stream flows through to the next component  (in your case your custom component) as this stage (when a section of stream is received by your custom component) some section of the stream is still handled by the XML-disassembler. So when your code tries to access the context property, the custom files are not promoted to the context of the message yet for you to access.

    If you use the same code to access the promoted property after the pipeline, may be in Orchestration or in send port where you will get hold of the promoted property in the context of the message.

    Think the flow of stream in pipeline as water flowing through a pipe (the analogue used by my faviourte BizTalk book, BizTalk profession 2006). When your custom component in validate stage tried to access the part of the water for context property, the XML-Dissembler which still has the some part of the water has not added the custom properties to the water :)

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.


    Thursday, March 19, 2015 1:10 PM

All replies

  • XML-Receive pipeline uses the same XML-Dissasembler component. So either using XML-Receive pipeline or your custom pipeline with XML-Dissasembler component in the disassembling stage doesn’t make any difference.

    So for your problem, it could be due to other pipeline component you use (I can see some “PromoteCustomC…” component in the validate stage, may be this or some other component) or it could be due to data. Check it.

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, March 19, 2015 11:35 AM
  • What you are seeing is the expected, as in not a bug, but not obvious behavior.

    It is because the XmlDisassembler does not process the entire message before returning it for the next component.  Instead, it wraps the incoming stream in a custom stream class so the message only gets processed by the XmlDisassembler when it is Read at some later point.

    The reason the Promoted fields do not appear in your next component is because they actually have not been promoted yet because the incoming data has not pulled through the XmlDisassembler yet.

    Unfortunately, there is no way out of the box to force the XmlDisassembler to process the message.

    For exactly this situation, I have a Pipeline Component that just copies the data stream to a VirtualStream in order force processing by the XmlDisassembler.

    You can accomplish the same by simple reading a large chunk, enough to move the pointer past the Promoted fields, then reset the Position to 0.

    Thursday, March 19, 2015 11:37 AM
    Moderator
  • Hi Ashwin,

    I have created a custom pipeline component- PromoteCustomC... In this component I am only fetching the value using below code-

    //Fetching values of A
     objA = inmsg.Context.Read("A", "https://TestProj.PropertySchema");

    Also, I am using the same file for testing through XMLReceive pipeline and my custom pipeline with XMLDisassembler and then the PromoteCustomCo..


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Thursday, March 19, 2015 11:56 AM
  • Hi John,

    Thanks a lot for your reply, I knew that it could be a known issue but was wondering about the explanation.

    However, the explanation you provided is a bit tough to understand :)

    Will it be possible to rephrase it in a bit simpler words?

    Thanks a lot for your understanding and help :)


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Thursday, March 19, 2015 11:59 AM
  • Basically, the XmlDisassembler does not read through the incoming message immediately.  It waits until some later component or the MessageBox reads it.  This is done for various performance reasons, memory consumption, etc.

    So, since your custom component is next in line, when it gets the Message, the data has not yet been read by the XmlDisassembler, even though it passed that Stage in the Pipeline, so it hasn't had a chance to read and Promote any Context Properties.  This is by design, and what you are seeing is a known side-effect.

    This is accomplished by wrapping the data in a custom Stream class.  That is why it only gets read and processed when some other component Reads it.  Like this:

    [SomeLaterComponent].Read

      --> xmlDasm.Read

        -->  XmlStream.Read  (I don't recall exactly which one)

          -->  Property Evaluation

            -->  Property Promotion

    The easiest thing would be to just do you work with the Properties in an Orchestration.  If you absolutely have to use a Pipeline Component, then you have to somehow force a Read by the XmlDisassembler.

    Unfortunately, this can get a little tricky due to differences in possible underlying streams.

    MemoryStream ms = new MemorySteam();
    YourIncomingDataPartStream.CopyTo(ms);
    ms.Position = 0;
    YourIncomingMessage.BodyPart.Data = ms;
    
    Code like this will force the message to be processed by the XmlDisassembler and cause the Properties to appear.  Note, this is a very basic non-optimized example.  You may have to/should modify to better suit your case.

    Thursday, March 19, 2015 1:04 PM
    Moderator
  • Ahh, if the custom pipeline (which is next to XML-disassembler) is where you access the promoted field, then you can’t access the custom properties in same receive pipeline.  Inside a receive pipeline, you can promote items to the message context only if you need them for Orchestrations, Send Ports. For accessing you may need a custom code which handles the streaming.

    This is due to the restriction as John described. When the message is received, the whole message is not loaded for performance reason. BizTalk pullsas stream, the stream of data through the pipeline and adapter. So when the stream reaches the disassemble stage XML-disassembler handles the stream,  also at the same time stream flows through to the next component  (in your case your custom component) as this stage (when a section of stream is received by your custom component) some section of the stream is still handled by the XML-disassembler. So when your code tries to access the context property, the custom files are not promoted to the context of the message yet for you to access.

    If you use the same code to access the promoted property after the pipeline, may be in Orchestration or in send port where you will get hold of the promoted property in the context of the message.

    Think the flow of stream in pipeline as water flowing through a pipe (the analogue used by my faviourte BizTalk book, BizTalk profession 2006). When your custom component in validate stage tried to access the part of the water for context property, the XML-Dissembler which still has the some part of the water has not added the custom properties to the water :)

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.


    Thursday, March 19, 2015 1:10 PM
  • Thanks a lot for your explanation John and Ashwin, have a good day ahead :)

    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Thursday, March 19, 2015 2:45 PM
  • Hi John & Ashwin,

    I know this question is already answered but I was documenting this behavior and wanted to know if there is any link or reference which talks about this behavior of XML Disassembler?

    Thanks in advance.


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    • Proposed as answer by Juhi Gupta Thursday, November 26, 2015 10:47 AM
    • Unproposed as answer by Juhi Gupta Thursday, November 26, 2015 10:47 AM
    Tuesday, March 31, 2015 5:42 AM
  • Like at MSDN, no.
    Tuesday, March 31, 2015 11:33 AM
    Moderator
  • Thanks John.

    Hello Everyone,

    I have documented this behavior in my blog with sample code and screenshots, please have a look if interested.

    VERY STRANGE BEHAVIOR OF XML DISASSEMBLER- PROPERTY PROMOTION NOT HAPPENING PROPERLY


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Wednesday, April 1, 2015 8:30 AM