Thursday, April 2, 2009

Hi all

At there is a guy who is struggling to get the MessageID into a message inside a map.

I have been trying to help him and have come to a stand still, because I missed a very important point. The MessageID is “written” and not promoted to the context base. Therefore, it cannot be read using the functoid found at (The one used inside an orchestration).

So basically, you can use the functoid to get hold of all the properties that were promoted into the context, but the ones that were written, you need to get to some other way.

I have created a small sample that illustrates how to do this inside an orchestration.

It can be downloaded here.

Basically, I have a schema for the input:


It has two fields, and I have promoted the first field.

The output schema looks like this:


It has four fields.

What I want in the output is this:

  • Field1: The value from Field1 in the source schema. It isn’t to be mapped directly, though. I want to demonstrate that the functoid can be used to get values that were promoted from a schema.
  • Field2: The value from Field2 in the source schema. Mapped directly
  • MessageID: The Message ID of he input message. Since this isn’t accessible by the functoid, I will use a Message Assignment shape to do that
  • ReceivedFileName: Will contain the content of the BTS.ReceivedFileName poperty – by using the functoid.

The map looks like this:


I am using the ContextAccessor (for orchestations) to fill a value into Field1 and ReceivedFileName. I am mapping Field2 directly. The MessageID field I am not mapping, since I need a message assignment shape for that. The element “MessageID” must be present in the output, though. Otherwise i cannot fill in value. So, as you can see in the screenshot, I have set the “Value” property to “<empty>”. This will create an empty element. This feature is very handy for initializing elements that will later on get values from message assignment shapes but also for creating the needed empty fields for demotion.

Anyway, the parameters for the first functoid look like this:


The parameters are:

  1. The name of the message to get the value from.
  2. The name of the property
  3. The name space of the property schema that property exists in.

The second functoid looks like this:


Now, the final touch is the orchestration:


Quite simple… A receive, a construct and a send port for the output. The construct shape has two shapes inside it. The first is a transformation shape hat will execute the map. The second is a message assignment shape hat will insert the messageid into the destination schema.

The message assignment shape looks like this:


I made the MessageID field of he output a distinguished field and can therefore insert values into it. This is quite clever . the way you can do several things to a message as long as you are still inside the same Construct Message shape. After the map, where I let the MessageID field be empty, I can insert a value into this field using a distinguished field. I could also just as easily have used XPath to do that, but that is not as readable, so I didn’t do it.

So… This was the first post of two – next time I will look at the receive port version of the Context Accessor functoid.

And one last point: If the idea i just to get an Id into a message and it doesn’t have to be the message ID of a message, you can also just use the “New GUID” functoid found at


Thursday, April 2, 2009 12:54:15 AM (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 

Theme design by Jelle Druyts