none
Access Context In Map On Send Side

    Question

  • Hello, this could be a very basic question, but hopefully someone will be able to answer it.

    I am receiving messages (HL7) using a custom receive pipeline. Inside my custom pipeline, I am promoting properties into the context. I have set up a map where I need to access these properties. However, I would like to access these properties on the send side. The reason why it needs to be on the send side is because I am attaching my map to the send port, so I assume that the message will have already hit the MessageBox and will be mapped on the send side. Hopefully that makes sense...

    I know that there are a few 3rd party tools I can use, but I was hoping that there's a simple functoid, or some code I can enter in a scripting functoid that will access the context for me.

    Would someone be able to point me in the right direction with this?


    Ankit
    Monday, February 7, 2011 4:49 PM

Answers

  • Hi Ankit,

    The above blog says that...you have to create a custom receive pipeline having ContextAccessorProvider Pipeline component.This pipeline component is also available for download.
    So basically when you download you will get two artifacts 1. ContextAccessor Functiod and 2.ContextAccessorProvider Pipeline component.

    Now what you need to do is...Create a custom receive pipeline and have the ContextAccessorProvider Pipeline component in the resolve party stage.
    After that..create a map and use the ContextAccessor Functoid.

    So here you dont have to call a map in the receive pipeline.

    We are using this in one of my project and working very fine.

    Rgds,
    Abhijit


    Abhijit Mahato - MCTS BizTalk Server blog: http://abhijitmahato.wordpress.com/ Please "Mark as Answer" if Post has Answered the Question
    Monday, February 14, 2011 7:37 PM

All replies

  • Hi,

    I have not seen a way to access message context from a map.

    One way you might be able to solve this is through property demotion in the send port. Most ppl know about property promotion in receive ports, but not many about demotion.

    Demotion is the reverse of promotion, values from the message context are set in the message body during the assembly stage of a pipeline component. For demotion to work you need to:

    1) Promote the fields in the outbound schema to the relevant properties in the property schema.

    2) Ensure the XML elemet or attribute is empty (<element></element>), if it is not present, or contains data then demotion will fail.

    THere is some documentation here: http://msdn.microsoft.com/en-us/library/aa547894(BTS.70).aspx

    And an old blog post here: http://geekswithblogs.net/sthomas/archive/2004/10/07/12285.aspx

    Regards,

    Alan


    http://www.CloudCasts.net - Community Webcasts Powered by Azure
    Monday, February 7, 2011 5:14 PM
    Moderator
  • Hi Ankit,

    Did you consider using the 'ContextAccessor' functiod available in CodePlex/

    http://contextaccessor.codeplex.com/

    we are using this in our project and its working fine..

    Regards,

    Abhijit


    Abhijit Mahato - MCTS BizTalk Server blog: http://abhijitmahato.wordpress.com/ Please "Mark as Answer" if Post has Answered the Question
    Monday, February 7, 2011 6:41 PM
  • Hi Abhijit

    Is the context accessor functoid only available when you call it using the recieve location? Here's a quote from the following post:

    This functoid only works in a map that is called in a receive port and only if the receive location uses a pipeline that uses the ContextAccessorProvider pipeline component that is included in he same DLL as the functoids.

    http://blog.eliasen.dk/2009/04/15/TheContextAccessorFunctoidPartII.aspx

    Is there anything that can be used without calling a map in the recieve pipeline?


    Ankit
    Monday, February 7, 2011 8:08 PM
  • Hi Ankit,

    The above blog says that...you have to create a custom receive pipeline having ContextAccessorProvider Pipeline component.This pipeline component is also available for download.
    So basically when you download you will get two artifacts 1. ContextAccessor Functiod and 2.ContextAccessorProvider Pipeline component.

    Now what you need to do is...Create a custom receive pipeline and have the ContextAccessorProvider Pipeline component in the resolve party stage.
    After that..create a map and use the ContextAccessor Functoid.

    So here you dont have to call a map in the receive pipeline.

    We are using this in one of my project and working very fine.

    Rgds,
    Abhijit


    Abhijit Mahato - MCTS BizTalk Server blog: http://abhijitmahato.wordpress.com/ Please "Mark as Answer" if Post has Answered the Question
    Monday, February 14, 2011 7:37 PM
  • Abhijit,

    Is that really true, what you are saying. I'm fiddeling around with those components at the moment and this is what the readme says:

    How?

    The main problem of accessing the context information from within a map (functoid) is the constraint you are executed within the context of the Xslt render engine. There is no access to the Pipeline, Message or Context instances.
    To bypass this problem, a custom pipeline component is introduced. This component will hold on the the context interface when it is pushed through the pipeline. It will do so in thread local storage.
    The functoid itself relies on that variable to gain access to the context.

    What this quote actually is saying is pretty much explained later in that same document:

    Constaints
    This construct has NOT been tested in larger environments. There is no documentation available about the inner workings of processing of a receive port.

    • This functionality relies on the assumption that a receive port with NEVER have a thread switch between the completion of a pipeline and the start of the maps processing!
    • This functionality relies on the assumption the ContextProxyComponent has been invoked before the functoid will (i.o.w. this functoid can NOT be used in send ports)!

    So I differ in my conclusion regarding this subject.

    Another interesting question on this note is what will happen if an error occurs between pipeline completion and map completion. When we retry that messge, will we be able to fetch those values in the threads local store? Probably not, since this will be handled by another thread as far as I can see. I would love to be proven wrong here since I need some of this functionality.

     //Niklas

     

    Wednesday, March 9, 2011 2:24 PM
  • Hi Abhijit,

    I have implemented the same ,used the custom pipeline available in the context accessor n placed it in resolve party and using the functoid to fetch ReceivedFileName but I am not getting the output.

    Can you please help me out

    Sunday, May 7, 2017 10:39 AM