Michael Stephenson

keeping your feet on premise while your heads in the cloud
posts - 358 , comments - 425 , trackbacks - 11

My Links

News

View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn

Twitter












Archives

Post Categories

Image Galleries

BizTalk

Mates

Message Construction in an Orchestration

Probem

When you are in an orchestration there and you want to create a new instance of a message but not by mapping it from an existing message there are a number of ways this can be achieved.  Basically you use a message assignment shape inside of a message construction shape.  There is another post which is not bad which explains a number of different ways this can be done.  Although they all pretty much do the job I had some concerns about these and tried to come up with an alternative which I preferred.  the post to which i am referring is:

http://www.objectsharp.com/Blogs/matt/archive/2004/11/09/1009.aspx?Pending=true

The main reasons I didnt want to use the approaches here are:

1. Use a Map

This one isnt really applicable to this post as i have already said the situation was to create the message without using a map.

2. Assign one message to another

This isnt really applicable to my situation either as this is suitable when both message instances are of the same type.  If this is your case then you should use this technique

3.Create a message with the help of a System.XML.XMLDocument variable

My main concern here is that doing this "inline" in the shape has the major problem that if the schema changes then the the code is difficult to maintain and you are not going to catch bugs until you start pushing messages through the orchestration at which point I can imagine this will be quite difficult to troubleshoot.

4. Creating a more complex message using : System.XML.Document, System.XML.XMLNode,System.XML. XMLAttribute, Interim BizTalk Message 

See above.

5. Use a .Net helper class to create the message

Of all of the approaches I think this one is my preferred, but I plan to add a little more to the example just to make it a bit more complete in terms of how I have implemented my alternative solution to this problem.

Alternative Solution

The aim of my alternative solution is to provide an easy way to build messages which will also save time in troubleshooting because breaking changes to a schema will be caught as compile errors rather than waiting until testing my orchestration and finding that i forgot to update the string which is used to create my XmlDocument.

The following example describes how it works.

Example

The following picture shows the solution structire for this example.  We have two projects, one a BizTalk project with two schemas and an Orchestration.  The second project has a class called SimpleResponse which is generated by xsd.exe to represent the SimpleResponse schema.  The other class is the one we will use in our Orchestration and it will be explained later.

 

The below picture shows a simple orchestration which will receive a message based on a simple request schema (SimpleRequest.xsd) and send a response based on another schema (SimpleResponse.xsd).  In the picture you can also see the MessageConstruction shape and MessageAssignment shape which are used to construct the response message.

In the below picture you can see we have the two messages in the orchestration view and also in the variables we have a variable called simpleResponseAdapter.  This represents a class in the utilities project.

The picture below shows the code of the SimpleResponseAdapter. 

The aim here it to use the Adapter design pattern (see here for more info: http://www.dofactory.com/Patterns/PatternAdapter.aspx). 

This adapter inherits from the SimpleResponse class.  The simple response class is regenerated in the build process by using xsd.exe and pointing to the schema.  By using the SimpleResponseAdapter you can set all of the properties as required but you can also retrieve an XmlDocument representing the object.

The below picture shows the expression shape in the orchestration.  As you can see by using the SimpleMessageAdapter you can code against it like any normal .net type, and when you want to actually create the BizTalk message you just assign it to the return value of the adapters .ToXmlDocument() method.

This shows how to use the adapter to help you in the construction of BizTalk messages.  Some other benefits are:

  • Because the type is serializable you can create it in one place and use it elsewhere in your orchestration.  This is useful in scenarios where you want to have a message worked with in different parts of a scope (ie: before, in the scope and in an exception handler)

There are some things to be aware of also:

  • There will be a slight hit because of the serialization of the type then conversion to an Xml document, although i dont see this as being a major issue especially with smaller messages.  It is a trade off to get the benefits of this technique
  • Using it across the whole orchestration can result in the state being persisted to the database.

There are some troubleshooting things i came across when developing this technique:

  • If you forget to add the serializable attribute to the adapter you can not use it across the whole orchestration.  You can still use it within a single expression so long as the state doesnt need to be persisted
  • If you forget to set the XmlRoot attribute on the adapter class then you can get some errors about being unable to find the schema if you miss the namespace (when the message is pushed through the Xmlassembler for example) and also it might not serialize as expected if you dont specify the root node name in the attribute.

Conclusion

I hope this post demonstrates a useful technique which can be used as an alternative to the ones put forward in the original article I mentioned.  The key point is that all approaches are valid and you need to choose the best one for your situation.

Update

There is another way to do this, and in my opinion this is probably the best.  It has the benefits of the idea I discuss above about being able to catch changes and potential problems as compile errors by being strongly typed, but does not have the hassle of having to do the serialization yourself.  For more information see Darren Jeffords blog

http://blogs.msdn.com/darrenj/archive/2004/09/29/235719.aspx

Print | posted on Tuesday, September 26, 2006 7:54 PM | Filed Under [ BizTalk ]

Feedback

Gravatar

# re: Message Construction in an Orchestration

any chance of you postingthe source for this example?
10/26/2006 1:30 PM | Terry
Gravatar

# re: Message Construction in an Orchestration

This idea is just what I'm looking for but I just dont seem to be able to get it to work. Seeing the full solution might help.
10/26/2006 1:36 PM | Terry
Gravatar

# re: Message Construction in an Orchestration

Thanks for the quick response Mike.

I've downloaded the example files and in VS 2005 (.net 2.0) and BizTalk 2006 I can make a clean compile, so I'm sure I can get it working here. So I think the problem is in VS 2003 and BizTalk 2004.
I'm getting an error when I build the BT project.
"the dot operator cannot access non-static data fields on object references"
The error is cause from these two lines in the Message Assignment shape.
simpleResponseAdapter.RequestId = simpleRequest.RequestId;
simpleResponseAdapter.ResponseMessage = "This is a response message";
Where RequestID and ResponseMessage are both marked as errors.


I've generated a new SimpleResponse.cs with the older version of XSD.EXE and the generated code looks very different from the original version.
If I dont generate an new .cs then I get a compile error SimpleResponse.cs
Expected class, delegate, enum, interface, or struct
where the word partial is underlined.

Do you have any ideas as to what I need to do to get it working with BT 2004 ?
10/27/2006 12:47 PM | Terry
Gravatar

# re: Message Construction in an Orchestration

Thank you! Thank you! Thank you!
2/9/2007 4:59 PM | Sushant Anand
Gravatar

# re: Message Construction in an Orchestration

Hi,

When i run the application i get the following error in the event log. I have checked and seen that i do have the strong name file. I have removed and readded the assembly, rebuilt, redployed several times and am at a loss.

Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'Orchestrations.CampusOutfittersOrderProcess(5bbad109-3a88-7863-f0ff-d174a6dc9531)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: b3fe96a7-3ecc-4142-8408-06e1f7ae9acb
Shape name:
ShapeId:
Exception thrown from: segment -1, progress -1
Inner exception: Could not load file or assembly 'VG.CO.ApplicationServices.Utilities.Message, Version=1.0.0.1, Culture=neutral, PublicKeyToken=99ab8855e97fa9fc' or one of its dependencies. The system cannot find the file specified.

Exception type: FileNotFoundException
Source: VG.CO.Fulfillment.BizTalk.Orchestrations
Target Site: Microsoft.XLANGs.Core.StopConditions segment1(Microsoft.XLANGs.Core.StopConditions)
The following is a stack trace that identifies the location where the exception occured

at Orchestrations.CampusOutfittersOrderProcess.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)



For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
2/12/2007 6:43 PM | Sushant Anand
Gravatar

# re: Message Construction in an Orchestration

Let me know if this gives you no joy
11/1/2008 8:28 AM | kreditrechner
Gravatar

# re: Message Construction in an Orchestration

I found this article just a few days ago. I realize this is about three years old, but the differences between BT 2006 to 2009 aren't much in regard to my Message Assignment needs, so I found this use full.

Only, I'm running into the XLang Exception "Inner exception: Object reference not set to an instance of an object.

Exception type: NullReferenceException"

I followed your tutorial to the tee, generating a class and such from xsd.exe, the adpater class, set the variable, and did all the XLang code as you had up there. So I know I did the right steps.

The only thing I can *think* might be the problem is that I have a two way receive port, and the Message Assignment is being sent back to the initial receive port. But it seems it's from the .NET code it's self, and not the Orchestration.
8/7/2009 4:02 PM | John Nelson
Gravatar

# re: Message Construction in an Orchestration

The link to esnips seems to be broken and/or the file isn't there
5/4/2010 9:07 AM | SteveC
Gravatar

# re: Message Construction in an Orchestration

Hello,

Please explain what fields are in the SimpleRequest.xsd and SimpleResponse.xsd. I mean paste the screenshot of the two schemas here.
Please reply as soon as possible.

Thank you a lot.
2/17/2012 5:55 AM | Mohsen
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 
 

Powered by: