The recent release of the Anypoint Connector for .NET opens up many opportunities for plugging into .NET based rules engines. Since the .NET Connector allows developers to call out to native .NET code, these rules engines can be easily integrated as a result.
Why do I want to do this?
Utilizing a rules engine promotes efficiency in system interfaces where some business logic needs to be executed and this logic can be frequently updated. You could wire all of this logic into your integration application via custom code or using several routers but these rules become difficult to maintain in code and may require several re-deployments as changes are introduced. Using a rules engine allows developers to decouple business logic from integration logic and as a result, rules can be easily maintained.
MuleSoft recognizes that organizations may have made significant investments in .NET based rules engines and these rules may need to be extended from their legacy platforms for a period of time. As a result of business transformation, there may be new requirements that are better suited for a modern integration platform to address in order to support API or SaaS integration use cases. MuleSoft’s Anypoint Platform is able to support these use cases by providing the agility and connectivity to enable these business scenarios while supporting an existing rules engine platform.
Connecting the BizTalk Rules Engine
To demonstrate this concept, we will take a recent customer scenario for connecting Anypoint Platform to the BizTalk Rules Engine. This MuleSoft customer has seen their IT landscape evolve and they now have requirements to support SaaS based endpoints and comprehensive API lifecycle management. Much like any organization, there were some timing constraints in making a complete transformation. As a result, they wanted to continue to leverage their legacy rules engine for a period of time while this transition was taking place.
High Level Architecture
In this simplified walk-through we are going to have a consuming application that would like to perform a credit check on a particular customer request. This scenario is well suited for using a business rules engine as there is different logic involved in performing this credit check that can change frequently. When the credit check logic does require modification, we do not have to redeploy a lot of different components; just a set of business rules. A rules engine provides a ‘separation of concerns’ that allows an ESB to focus on what ESBs are good at: connectivity and routing.
The flow of our solution follows:
- A Consuming Application will reach out to Mule ESB via an HTTP request.
- Mule ESB in turn will call a native .NET method via the .NET Connector. This connectivity is enabled via the .NET Connector that was released in July 2014. The .NET Connector allows developers to call .Net assemblies that have been written in any .NET language.
- The BizTalk Rules Engine does expose an API which can be consumed from any .NET assembly or application. We are able to take advantage of this API within our .NET method.
- We will pass a TypedXML document to the BizTalk Rules Engine which is the data format that the BizTalk Rules Engine is expecting.
- The BizTalk Rules Engine will evaluate the incoming message and then run it through a series of 5 different rules that evaluate the Customer Group that that the customer belongs to in SalesForce and the max credit threshold for that particular group.
- A boolean value will be returned that includes a flag indicating whether or not the credit check has been approved or not
Conclusion
In this blog post we discussed some real-world concepts and challenges that Connected Enterprises are encountering. We were able to provide a solution that allows organizations to be flexible while enabling innovation that allows organizations to meet their business objectives.
Biztalk vs Mule ESB »
Learn how to move to a modern integration solution »
