Recently I got some weird errors while compiling a BizTalk project containing orchestrations. Errors like ‘unexpected token’ and ‘unexpected keyword’, and ‘a part of a messagetype must be of class type’.
Blog Post by: AxonOlympus
Blog Post by: AxonOlympus
I had never come across the need to execute rules based on message metadata until a colleague of mine asked me the other day. Which is surprising as we often define routing rules based on the message context.
The basic principle is simple, – Rather than using schema based facts, we use facts based on .Net assemblies. In this case IBaseMessageContext (Microsoft.BizTalk.Message.Interop). This works well in cases where you’d like to call the rule from within a pipeline, as the context of the pipeline message (IBaseMessage) is implementing the IBaseMessageContext interface.
If, on the other hand, you want to execute the rule form an orchestration we can’t use an interface as a rule fact, as the CallRules Policy shape can’t work with interfaces. In those cases we’d need to use a custom class (the one the is used by BizTalk is internal).
Before we create the rule you need to have your facts ready. The input fact is going to be the context object mentioned above but you need to create the output schema where you’re going to store the result if the rule evaluates to true.
Open the Microsoft Business Rule Compose and create your policy and rule as you’d normally do. Then in the Fact Explorer select the .Net Classes tab, right-click the .Net Assemblies node and select Browse. The IBaseMessageContext interface is found in the Microsoft.BizTalk.Pipeline assembly. Select the assembly and expand the IBaseMessageContext in the tree view.
Drag the Read(String strName, String strNamespace) method to your rule condition:
If you haven’t developed a pipeline component before you can use a nuget package like Default Breeze BizTalk Pipeline Component. Simply create a class library project and install the nuget package. Follow the steps at the top of the pipeline component file before implementing the Execute method.
public IBaseMessage Execute(IPipelineContext pc, IBaseMessage inmsg) { //Create a policy object based on the name of the Policy Policy policy = new Policy("MessageContextSamplePolicy"); // Create the response document XmlDocument doc = new XmlDocument(); doc.LoadXml(@"<ns0:BreTest xmlns:ns0=""http://BreWithPromotedPropertiesSample.BreTest""><Field></Field></ns0:BreTest>"); var responseDoc = new TypedXmlDocument("BreWithPromotedPropertiesSample.BreTest", doc); //Execute the policy and pass the message context and the response docoument policy.Execute(new object[] { inmsg.Context, responseDoc }); var responseXml = responseDoc.Document.OuterXml; // TODO // Take action on the response XML... return inmsg; }
There are two problems to working with the context data together with orchestrations; Access the metadata and not being able to work with interfaces (CallRules Policy shape can’t work with interfaces).
Within the orchestration we don’t have the IBaseMessage from which we can easily access the context. Instead we got the XLANGMessage. The message context is not as easily accessible form the XLANGMessage as it is from the IBaseMessage. Thankfully Maxime Labelle provided insight of how this can be accomplished.
I solved these problems be creating my own class called XLANGMessageContext and from within the constructor I read through the metadata. The class also provide a Read method that will return the value for a specific property:
public class XLANGMessageContext { Hashtable _messageContext = null; public XLANGMessageContext(XLANGMessage message, string name, string ns) { try { foreach (Segment segment in Service.RootService._segments) { IDictionary fields = Context.FindFields(typeof(XLANGMessage), segment.ExceptionContext); foreach (DictionaryEntry field in fields) { XMessage msg = (field.Value as XMessage); if (msg == null) continue; if (String.Compare(msg.Name, message.Name) != 0) continue; var key = new XmlQName(name, ns); _messageContext= msg.GetContextProperties(); } } } catch (Exception /* e */) { // do not provoke failure // probably best to add some logging here } } public object Read(string strName, string strNamespace) { var key = new XmlQName(strName, strNamespace); var result = _messageContext[key]; return result; } }
Creating the rule is very similar to the messaging scenario, but instead of using the IBaseMessageContext object you’ll use the Read method from the XLANGMessageContext:
In your orchestration, create a BreHelperComponent.XLANGMessageContext valiable called xlangMessageContext, and construct it in an Expression shape:
xlangMessageContext = new BreHelperComponent.XLANGMessageContext(myMessage);
Lastly add a CallRules shape and provide the parameters:
You can download the sample here.
HTH
Mikael
Blog Post by: wmmihaa
I miss the old BizTalk Hotrod Magazine, of my knowledge, there isn’t no other type of magazine about BizTalk Server. And the only thing we have approximately to that is the Flipboard BizTalk Magazine that I have weekly published throughout these last months. You can find the BizTalkMagazine into Flipboard in in your favorite device […]
Blog Post by: Sandro Pereira
Colin Dijkgraaf and myself have released a version of the BizTalk Documenter for BizTalk 2013 and an update for the BizTalk Documenter for BizTalk 2010. These releases fix the following issues and have added some new functionality; Added a WIX installer to the project. Fixed several inner exceptions within the application. Suspend and Terminate orchestration […]
Blog Post by: mbrimble
Save the date for BizTalk Summit 2014, which will take place December 3-5 on the Microsoft Campus in Redmond, WA. There will be 300+ partners and customers, so bring your questions, knowledge, and business cards. Agenda Executive keynotes outlining Microsoft vision and roadmap Technical deep-dives with product group and industry experts Product announcements Real-world demonstrations […]
Blog Post by: mepemberton
In July, Microsoft ended all support for BizTalk Server 2004. This got us to thinking about the looming end of support for other versions of BizTalk Server: mainstream support for 2006 and 2009 has already ended, and extended support for 2006 (and R2) ends in July 2016: http://social.technet.microsoft.com/wiki/contents/articles/18709.biztalk-server-product-lifecycle.aspx According to Microsoft, extendedsupport differs quite a […]
Blog Post by: mepemberton
Classical but mandatory I’ll talk about social and big data in furtherarticles. The first will describe how retrieving live tweets and store them in HDFS. Pre-requisite We’ll use the flume to retrieve stream tweet/ A Flume event is defined as a unit of data flow having a byte payload and an optional set of string […]
Blog Post by: Jeremy Ronk
This is the fourth in a series of posts exploring What’s New in BizTalk Server 2013 R2. It is also the second in a series of three posts covering the enhancements to BizTalk Server’s support for RESTful services in the 2003 R2 release. In my last post, I wrote about the support for JSON Schemas […]
Blog Post by: Nick Hauenstein
In the last few weeks I have been doing BizTalk project migrations successfully from BizTalk Server 2006 and Visual Studio 2005 to recent version: BizTalk Server 2010/VS 2010 or BizTalk Server 2013/VS2012. In most of the scenario this is a simple task and regarding to Visual Studio we basically just need to open the “old” […]
Blog Post by: Sandro Pereira