How to use context data with Business Rules

How to use context data with Business Rules

 

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).

Create the output fact schema

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.

Create the rule (Messaging scenario)

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:

 

 

Create the pipeline component (Messaging scenario)

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;
}

Create the rule (Orchestration scenario)

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:

Use the XLANGMessageContext (Orchestration scenario)

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

BizTalk Magazine – September 2014 Edition (proof of concept)

BizTalk Magazine – September 2014 Edition (proof of concept)

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

BizTalk Documenter 2013

BizTalk Documenter 2013

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

BizTalk Summit 2014 in December

BizTalk Summit 2014 in December

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

The Upcoming End of Extended Support for BizTalk Server 2006

The Upcoming End of Extended Support for BizTalk Server 2006

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

Visual Studio fail to imported project while migrating BizTalk Project: Unable to read the project file. The project file could not be loaded. Root element is missing

Visual Studio fail to imported project while migrating BizTalk Project: Unable to read the project file. The project file could not be loaded. Root element is missing

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