ilog rules for .net and microsoft biztalk server · and microsoft biztalk server ... sometimes more...

ILOG Rules for .NETand Microsoft BizTalk Server

White Paper

ILOG Rules for .NET

and Microsoft BizTalk Server

White Paper

This paper was made possible through the direct participation of SoftFluent.http://www.softfluent.com/

© ILOG, September 2005 – Do not duplicate without permission.ILOG, CPLEX and their respective logotypes are registered trademarks.

All other company and product names are trademarks or registered trademarks of their respective holders.The material presented in this document is summary in nature, subject to change,

not contractual and intended for general information only and does not constitute a representation.

Content

1. Introduction...................................................................................................................................7

2. About BizTalk Server ...................................................................................................................8 2.1. Overview................................................................................................................................8 2.2. BizTalk Server architecture....................................................................................................9 2.3. Application integration ...........................................................................................................9 2.4. Business Process Management ..........................................................................................10 2.5. Additional pieces and features ............................................................................................10

3. About ILOG Rules for .NET........................................................................................................11 3.1. Overview..............................................................................................................................11 3.2. Rule Engine for .NET...........................................................................................................12 3.3. Rule Studio for .NET............................................................................................................12 3.4. Rule Team Server for Sharepoint........................................................................................14 3.5. Rule Solutions for Office ......................................................................................................14

4. Integration benefits ....................................................................................................................15

5. Integration scenarios .................................................................................................................17 5.1. Calling ILOG Rule Engine for .NET from a BizTalk Server orchestration ...........................17

Overview.......................................................................................................................................17 Sample technical implementation.................................................................................................17 Applicability and benefits ..............................................................................................................19

5.2. Exposing rules through a Web Service and calling it from BizTalk .....................................19 Overview.......................................................................................................................................19 Sample technical implementation.................................................................................................20 Applicability and benefits ..............................................................................................................22

5.3. Combining ILOG Rule Engine for .NET with BizTalk Server Rule Engine ..........................22 Overview.......................................................................................................................................22 Sample technical implementation.................................................................................................23 Applicability and benefits ..............................................................................................................24

6. Conclusion ..................................................................................................................................25

1. INTRODUCTION

As Charles Darwin said in his evolution theory, “It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change”.

And this is true also for businesses. Furthermore, enterprises, whatever business they are in, evolve in a fast-changing environment: economic conditions, technology, regulation, competition or customer demand. So adjusting to these changes is all the more critical for their future.

Enterprise assets are usually articulated around four axes: people and their knowledge, data and information available for optimal decisions, partners or ecosystem in general and processes that define its functioning.

But processes have often been defined in a way to do business efficiently considering the market conditions at the time of definition. Often parts or all of these processes are built in applications that can not adjust quickly to external changes, reducing the overall agility of the enterprise.

The ability to evolve these processes and the underlying Information Technology is a huge challenge. For companies who succeed in doing it, it can prove to be a key differentiator, sometimes more important than the size of the company or its established position in a specific market.

Most successful companies will be the ones able to continuously adjust processes and business rules in response to evolving business conditions.

To reach this goal Business Rules Management Systems (BRMS) improve the lifecycle management of the solution by:

Allowing combination of decision table, decision tree and if/then rules for all type of decision processes, Addressing projects ranging from thousands to millions of transactions, Making business policies accessible and manageable directly to business users.

Similarly, Business Process Management Systems (BPMS) provide this flexibility for the evolution of processes.

In both cases, the extraction of the business processes and the business policies from applications through BPMS & BRMS results in an improvement of:

Accessibility Flexibility Manageability

This is why these software categories are both growing in importance as technology is maturing.

Beyond this short introduction, the goal of this white paper is to explain how to integrate Microsoft® BizTalk® Server and ILOG® Rules for .NET® to provide a compelling solution to the agility challenge mentioned above. This integration is illustrated through simple samples that demonstrate the possible technical options, while emphasizing their applicability and specific value.

Some areas of the document are a bit technical but most of the whitepaper is suitable for a quite broad audience, from decision makers who are facing the challenge to key software architects who want to understand how these two software products can work together.

2. ABOUT BIZTALK SERVER 2.1. Overview

On its official product web site, Microsoft describes BizTalk Server 2004 as follows:

“BizTalk Server 2004 helps customers efficiently and effectively integrate systems, employees, and trading partners through manageable business processes enabling them to automate and orchestrate interactions in a highly flexible and highly automated manner.”

Several key words in this sentence capture the extensive nature of BizTalk Server.

Integrate is the first key word that reflects a major dimension of the product, the central one which has been there since its origin1. BizTalk plays a foundational role in helping loosely-coupled applications cooperate through inter-application messages. This gives BizTalk Server an Enterprise Application Integration dimension.

Business Processes are also key as the product has strongly evolved over recent versions to put more emphasis and features on the “business” dimension, moving beyond the underlying technical plumbing.

Orchestrate confirms the global role that BizTalk Server can play for an overall process beyond the simple flow matching and transformation. This gives BizTalk Server a Business Process Management (BPM) dimension.

Manageable is also meaningful, because there are numerous pieces in BizTalk Server that target this need. This word should be understood to span two dimension: technical operations management for data integration mechanisms, as well as activity monitoring for the execution of business processes.

I would also put some emphasis on the Flexible adjective, as there are various ways of leveraging BizTalk Server features to implement a solution with it. To some extent, BizTalk Server is a very powerful toolbox providing many components that may or may not be used depending on context. In fact, it is quite uncommon to find a project in which all components are used. Having so many possibilities ensures that there is no real limitation to what you can do with BizTalk Server.

The only downside of being so rich a product is that it requires the appropriate skills to be implemented in the optimal way.

Because BizTalk Server is a quite broad product, the goal here is not to give an exhaustive description of the product, but rather to provide you with the basic understanding of the features and positioning to be able to understand how BizTalk Server can cooperate with Rules for .NET to solve business problems.

If you want to know more about BizTalk Server, we highly recommend the reading of David Chappell’s whitepaper “Understanding BizTalk Server 2004”.

1 Historically, BizTalk Server derived from a software piece called “Commerce Interchange Pipeline”, which was packaged with Site Server Commerce Edition 3.0, a product released in 1998. This piece was focused on allowing B2B relationships between companies with emphasis on integration, especially data mapping and pipelines. It was later taken out of the E-Commerce context to broaden applicability, extended in terms of features and renamed BizTalk Server 2000.

2.2. BizTalk Server architecture The following schema describes the overall product architecture:

ReceiveAdapter

SendAdapter

MessageBox

Orchestrations

Inbound Outbound

SendPipeline

Message Path

Business RulesEngine

Incoming Message

<XML Message>

<XML Message>

<XML Message>

<XML Message>

Outgoing Message

Receive Pipeline

SubscriptionsSubscriptions

Figure #1 – BizTalk Server architecture (source David Chappell)

On the inbound side, the BizTalk Server engine processes messages received from other systems using adapters and receive pipelines.

In the middle, the BizTalk Server engine orchestrates business processes leveraging their description and ensuring the different steps are executed consistently. Note that at this stage, there is also a “specific” Business Rules component included in BizTalk Server that can be leveraged to provide basic business rules features.

On the outbound side, the engine accomplishes the symmetrical operations to process messages that are sent to other systems.

2.3. Application integration BizTalk Server application integration features are built around the concept of messages. Whatever the technical protocol or communication mechanism used by applications, every data flow is considered as a message.

It is worth to note that internally, BizTalk Server always manipulates XML messages. If a message received is not in XML format, BizTalk will convert it first. The same applies for messages sent.

To ensure the adaptation to different protocols, BizTalk Server uses Adapters that can adjust to the expected communication channel. Adapters delivered natively by BizTalk Server are mostly “technical adapters”, that provide transport level protocol implementation such as File System, HTTP, SMTP, MSMQ… There are also higher level adapters such as Web Service or SQL Server adapters. People can also find application level adapters such as the SAP Adapter that allows direct connection with an SAP system (or one for Siebel). One can also write Custom Adapters to better fit his specific needs. This approach is especially targeted to ISVs who want to provide a strong level of integration with BizTalk Server.

Inbound and outbound messages are processed through pipelines2. Pipelines are made of a pre-defined sequence of steps that are needed to accomplish their mission. For example, the “receive pipeline” is made of the following steps: Decode, Disassemble, Validate and Resolve Party. The “send pipeline” is made of the following steps: Pre-assemble, Assemble and Encode.

Last but not least, BizTalk Server handles the appropriate routing of inter-application messages. Incoming messages usually trigger an orchestration, either by creating an instance of a new process or completing another step of a process which is already under way. Messages can also be directly routed to a send pipeline if appropriate.

2.4. Business Process Management BizTalk Server business process management features cover different areas, all targeted towards automating business processes and making them flexible.

First of all, it is critical to understand the basic underlying idea, which is to avoid hard-coding the workflow inside the application. One can always write a program that will do the correct step succession and conditional branching. But describing processes graphically and externalizing the process logic from the application provide additional benefits in terms of flexibility & maintenance3. This is why BizTalk Server provides an Orchestration Designer to describe the flow of business processes.

As BizTalk Server always manipulates data in XML format, an orchestration processes XML business documents. So BizTalk Server also provides a Schema Editor to define the schema of the manipulated documents, relying on the XSD standard. This is all the more interesting since the product includes an element called the BizTalk Mapper, which allows transformation of data. This transformation tool is very powerful, including simple data manipulation as well as complex functoids that can achieve complex operations.

Then, as mentioned above, BizTalk Server includes the Business Rule Engine, as one part of the overall Business Process Management strategy. This engine allows extraction of business rules to make them accessible to business users through a vocabulary, and give them the flexibility to change them without modifying the orchestration.

Note: Business rules can also be implemented directly in orchestrations, but separating them can prove to be a better choice because then it will not be necessary to stop the application and redeploy as it would be otherwise.

2.5. Additional pieces and features We won’t give too much detail about the additional features of BizTalk Server but it is worth to note that this product also includes features for:

Management and operations Monitoring of applications and orchestration execution Single Sign-On services Business Activity Monitoring through pre-designed OLAP cubes to analyze activity Human Workflow services

2 Pipelines appeared even before the “Commerce Interchange Pipeline” that we mentioned in an earlier footnote. In fact, Commerce Server 2.0, a product released in 1997 by Microsoft, implemented an Order Processing Pipeline. This pipeline processed an online order following a structured sequence of key steps such as: Catalog checking, basket Filling, promotion implementation, shipping mode selection, tax calculation…

3 This idea is in fact very similar to the one that we will describe later for business rules so it is critical to clearly get this point, where most of the value of BPMS & BRMS tools resides.

3. ABOUT ILOG RULES FOR .NET 3.1. Overview

The immediate goals of a BRMS project are typically some combination of the following:

Enabling knowledgeable business experts to write business rules or policies directly using a familiar and comfortable language and statement structure. Supporting high variability in business rules across time, products, jurisdictions, customers or other domains.

This is done most efficiently by decoupling the business rule lifecycle from the software development lifecycle. Doing so enables rule authors (i.e. policy managers) to operate independently of the software development cycle, leading to parallel software development and rule lifecycles. This is illustrated in Figure 1.

In the top half of the figure – the Software Development Lifecycle – application releases are driven by major requirement changes and external (such as application server, or ERP) product release schedules. These releases are produced by architects, business analysts, and developers in following the traditional software development cycle of requirements specification, analysis, design, development, testing and deployment.

In most situations, business rules change on a finer timeline and are driven by business policy changes that represent variants or extensions on the established functional base for the project’s current release. This is shown as the “Rule Management Lifecycle” in the lower half of. Changes implemented here require smaller, more focused cycle of authoring and testing by the policy manager, and timely deployment to production. Depending on the needs of the application, this business rule cycle can take as long as a few months or as little as a couple of hours to complete.

DesignConstruct

Test

AnalyzeAuthorValidate

Manage and MonitorDeploy

Platform upgrade

PolicyChange Request

Deploy


Deploy



Deploy

Rule Management Lifecycle

DesignConstruct

Test

Deploy

Software Development Lifecycle



Deploy

Functional enhancements

Figure #2 – Rule and Software development cycles

If you want to know more about Rules for .NET, we highly recommend the reading of ILOG’s whitepaper “Enterprise Business Rule Management for .NET”. The summary we give hereafter is just a quick overview of the key pieces.

3.2. Rule Engine for .NET Business rule applications invoke rules by calling the rule engine. The ILOG Rule Engine for .NET is a flexible, high-performance execution platform suitable for a variety of .NET applications.

Key features of the engine include:

RETE Execution: ILOG Rule Engine for .NET supports traditional RETE (forward chained, or inference) rules execution as well as sequential processing. Multi-Programming Language Support: The rule engine is a native .NET assembly and features an API for embedding the rule engine into a .NET application using any programming language targeting the Microsoft .NET Framework. Tracing Interface: The rule engine exposes an API that can be used to trace rule execution and log engine events. Flexible Deployment: Architects can deploy the rule engine to any .NET application: client-side (WinForms and Office-based applications) and server-side (ASP.NET, Windows Services, and XML Web Services).

Most .NET rule applications are built using a layered component model architecture. From an application architect’s perspective, ILOG Rule Engine for .NET and the associated business rules fit into the Microsoft prescriptive application architecture.

Both client-side and server-side applications can take advantage of this logical architecture.

3.3. Rule Studio for .NET

Figure #3 – Rules for .NET architecture

ILOG Rule Studio for .NET is a set of extensions to Visual Studio .NET featuring a rich graphical user interface that can be used by developers for many aspects of business rule application development, including:

Business Object Model Creation: Developers use ILOG Rule Studio for.NET to create the BOM by adding a new Class Library project into their Visual Studio .NET solution. In most cases, the BOM creation process can be expedited by importing existing .NET classes using the Business Object Model Wizard. Once imported, the classes will appear in the Business Object Model View where they can be decorated with the domain specific verbalizations that make up the language in which policy managers write business rules. The decoration process is highly flexible, permitting developers not only to give natural language-like names to classes, attributes and methods, but also to specify in detail how those names are translated into invocations of actual executable methods.

Rule Authoring: With ILOG Rule Studio for .NET, developers can take full advantage of a point-and-click rule editor and set of integrated tools that greatly simplifies the task of writing and managing business rules. Developers edit the standard properties of a rule such as its name, package, priority, etc. using the Properties window. Additionally, they can extend the standard rule properties by adding their own custom properties. To make it easier to author syntactically correct rules, the Rule Editor features a dropdown prompt of rule language expressions that can be inserted into a rule. For complex business object model, developers may limit how policy managers see domain specific verbalizations of the BOM when editing rules. Source Code Control Integration: Developers usually work on copies of project artefacts and use a source code control system or a configuration management system to merge changes into a common project code repository. ILOG Rules for .NET facilitates this approach by representing business rules in the file system as source files similar to those used for storing C# or VB.NET source code. Ruleset Extraction and deployment: By default, when a rule-based Visual Studio .NET solution is compiled a ruleset is generated for each rule project. This ruleset contains all the business rules in the rule project. But developers can also specify a rule query that filters the extracted ruleset by rule properties. Rule Publishing to Team Server: Once the project has a stable business object model, developers can expose all or a subset of the initial business rules to policy managers who can then take over the function of rule authoring and management. Using the Publish Wizard in ILOG Rule Studio for .NET, business rules can be published to ILOG Team Server for SharePoint as rule documents.

3.4. Rule Team Server for Sharepoint Business rule applications must be designed to empower policy managers to maintain and manage business rules throughout their lifecycle. ILOG Rules for .NET facilitates this via the ILOG Rule Team Server for SharePoint – an industry-first, robust document-centric repository for business rules built on top of Microsoft Windows SharePoint Services. It features:

Web-based Rule Editor: Business rules can be edited remotely using a web-based rule editor that is composed of web parts. These web parts are configurable components in Windows SharePoint Services that can be used to provide a customized user interface for policy managers.

Document-Oriented Organization: Business rules are organized in the repository as document libraries, folders, and rule documents, or RuleDocs. RuleDocs are Microsoft Office documents containing business rules. This makes it easy for policy managers to find the rules they need to work on. Collaborative Environment: Large business rule application projects involving teams of policy managers will often need to collaborate with each other. Policy managers can work together on business rules more effectively by leveraging the collaboration support provided by Windows SharePoint Services such as: user presence, discussion boards, task list, issue tracking, and alerts. Permission Management: Access and permission to business rules stored the repository are managed using the built-in Windows SharePoint Services access control. The ability to add, delete or modify business rules depends on the role of the user attempting to change the rule, and metadata associated with the rule. A SharePoint administrator can define users and assign them a corresponding site group that will dictate their individual access and permission to the rule documents. Version Management: Using the file versioning capabilities of Windows SharePoint Services, policy managers can manage different versions of rule documents for auditing and rollback purposes. Concurrency Control: An important aspect of working collaboratively is the ability to lock rule documents (check-in and check-out). Leveraging the file locking support in Windows SharePoint Services, ILOG

Team Server for SharePoint supports simultaneous, multi-user rule authoring and management. ILOG Rule Team Server for SharePoint is a document-centric repository. In ILOG Rule Team Server for SharePoint, business rules are stored as XML documents that facilitate collaboration between teams of policy managers.

3.5. Rule Solutions for Office ILOG Rule Solutions for Office enables policy managers to edit business rules using familiar Microsoft Office productivity applications. Currently, it supports integration with Microsoft Office Word 2003. It provides policy managers the following capabilities:

Rule Authoring: Policy managers can author and manage business rules in RuleDocs using a rule editor hosted inside Microsoft Word and Microsoft Excel, while taking advantage of the collaboration features of Windows SharePoint Services through a Shared Workspace Pane. Off-line Rule Authoring: Using Microsoft Word and Microsoft Excel as the rule editor, policy managers have the ability to author business rules even when not connected to their corporate network.

4. INTEGRATION BENEFITS

There are several possible integration approaches that make BizTalk Server and Rules for .NET work together. But before detailing these approaches, let us explain first under what circumstances it becomes necessary to use Rules for .NET instead of BizTalk Server’s built-in rule engine.

As explained before, the BizTalk Server rule engine provides basic rule features. Using this engine can be enough for projects that do not have a strong need in the business rules area, in which case using BizTalk Server alone provides the advantage of simplicity and cost.

However, using Rules for .NET and BizTalk Server together becomes necessary to achieve any of the following goals:

Empower business users to maintain their own business rules Manage a large volume of business rules Manage decision intensive processes Manage rules as an enterprise asset

The following table provides a detailed perspective about each point and how we perceive it as being already expressed by customers:

Overall goal Detailed needs Customer reality

Empowering business users to maintain their own business rules

Policy managers must be able to make rule changes themselves Controls are necessary to ensure that policy managers safely edit rule artefacts Workflows are required that enable fast-tracking of rule changes made by non-technical authors that still safeguard the stability of the production environment Tool-level support for business rule collaboration among policy managers, business analysts and developers is required

Frequent and

increasing

Managing a large volume of business rules

The volume of rules managed require a complex rules organization and hierarchy Customer’s policies transcribe in thousands of active rules that need to be updated selectively and carefully managed The team of business analysts is large and authoring, versioning, and other management functions of the repository are a necessity The number and organization of rules require ensuring consistency across all the rules Customers need simulation and testing of the rules

Project-specific

Managing decision intensive processes

Customers policies creates decision making requiring sequencing of the rules expressed Customers require supporting policy-intensive business processes such as underwriting that involves many policies Customers express requirements for decision intensive policies based on multiple sources of information outside of BPM platform

Domain-Specific

Managing rules as an enterprise asset

Customers are already using ILOG Rule Management System for business rule management Customers’ business requires them to produce an

Increasing as a market

trend

audit trail of the decision made (for example in a compliance issue)

Customers look at sharing rules across different applications including non BPM Customers look for centralized rules management such as access controls, consistency checking Customers need best practices based on industry standards (e.g. ACORD for insurance) or type of decision making Customers require rule deployment to multiple platforms, including .NET and J2EE

Table #1 – Major needs leading to use Rules for .NET in conjunction with BizTalk Server

In the end, even on simpler projects, there is a good probability that as time goes by, the business rules need increases, making a product such as Rules for .NET relevant and complementary to BizTalk Server.

5. INTEGRATION SCENARIOS As mentioned in the previous section, there are several possible integration approaches that make BizTalk Server and Rules for .NET work together. These various approaches may be relevant in different scenarios. For each approach, we will explain the overall integration strategy, detail what it means in terms of technical implementation through a sample4 and discuss the applicability scenario and its benefits.

5.1. Calling ILOG Rule Engine for .NET from a BizTalk Server orchestration

Overview

The first and straightforward approach for combining ILOG Business Rules for .NET with BizTalk Server consists of directly calling ILOG rule engine from a BizTalk Server orchestration.

BizTalk Server Orchestration Designer allows the opportunity to define a particular step in the process as an Expression. This step is then made of .NET code that can be written directly in the Expression Editor of the Orchestration Designer.

As this is .NET code and as ILOG rule engine is a .NET component, it is easy to instantiate and call ILOG rule engine for rule set execution.

Biztalk Server Orchestration

Step 1 Component

Step 2 Expression

Step 3 Web Service

ILOG Rule Engine for .NET Rule execution

Instantiation

Figure #4 – Calling ILOG rule engine for .NET from a BizTalk Server Orchestration

Sample technical implementation

As mentioned before, the sample is based on the Business Rule for .NET version 2.0 tutorial. The scenario is a car rental application that checks eligibility of the customer. Eligibility policies based on age are captured in the following decision table:

4 The sample is based on Rules for .NET version 2.0 Tutorial, step #4. The functional scenario is a car rental application and an agreement eligibility rule based on a decision table.

Figure #5 –Business rule from ILOG tutorial used in samples

This “Age Check” decision table is simply called through specific code instantiating the RuleExecuter object and setting the relevant values and parameters to evaluate the eligibility of the customer depending on age.

Figure #6 – Calling ILOG rule engine directly from a BizTalk Server Orchestration

The code is written directly through the Expression Editor inside a BizTalk Server orchestration.

Here is the sample code that we used to implement the step #4 of the scenario.

RuleUtilities.RuleExecuter.CreateModel(); pickupBranch = new CarRental.Branch(ReservationRequest(CarRentalOrchestration.PropertySchema.pickupState), ReservationRequest(CarRentalOrchestration.PropertySchema.pickupCity)); scheduledReturnBranch = new CarRental.Branch(ReservationRequest(CarRentalOrchestration.PropertySchema.scheduledReturnState), ReservationRequest(CarRentalOrchestration.PropertySchema.scheduledReturnCity)); customer = new CarRental.Customer(ReservationRequest(CarRentalOrchestration.PropertySchema.firstName), ReservationRequest(CarRentalOrchestration.PropertySchema.lastName), ReservationRequest(CarRentalOrchestration.PropertySchema.age), ReservationRequest(CarRentalOrchestration.PropertySchema.loyalty)); requestedCarGroup = CarRental.CarGroup.GetCarGroup(ReservationRequest(CarRentalOrchestration.PropertySchema.name)); rentalAgreement = new CarRental.RentalAgreement(customer, pickupBranch, ReservationRequest(CarRentalOrchestration.PropertySchema.pickupDate), scheduledReturnBranch, ReservationRequest(CarRentalOrchestration.PropertySchema.scheduledReturnDate), requestedCarGroup, RuleUtilities.Model.GetCoverageNames(ReservationRequest(CarRentalOrchestration.PropertySchema.additionalLiabilityInsurance), ReservationRequest(CarRentalOrchestration.PropertySchema.lossDamageWaiver), ReservationRequest(CarRentalOrchestration.PropertySchema.personalAccidentInsurance), ReservationRequest(CarRentalOrchestration.PropertySchema.personalEffectsProtection))); executer = new RuleUtilities.RuleExecuter(model, outputWriter); model.AddRentalAgreement(rentalAgreement); executer.ExecuteReservationRules(rentalAgreement);

Note: There could also be alternative variants of this approach like encapsulating the rule engine call into a custom .NET component that would take care of linking to ILOG rule engine5. Doing so could be relevant to comply with some specific architecture patterns or to achieve additional tasks beyond the rule engine call inside the intermediate component.

Applicability and benefits

This solution is the most straightforward way for quickly leveraging ILOG business rules in conjunction with BizTalk Server process management capabilities.

Beyond the benefits mentioned in the previous paragraph, this is the option for minimal coding and easy implementation.

However, in terms of architecture, this might be a limiting scenario. The main constraint is that choosing this approach forces rule execution on the same server as the BizTalk Server.

It might be enough in certain contexts but for complex projects, having the flexibility of deploying orchestrations and rule execution on different servers can be useful. In that case, it might be necessary to evaluate another integration approach.

5.2. Exposing rules through a Web Service and calling it from BizTalk

Overview

A more sophisticated approach to leveraging ILOG business rules for .NET in conjunction with BizTalk Server is to encapsulate the rule execution in an XML Web Service that exposes relevant interface for executing the rule set.

5 One could also go as far as creating a BizTalk custom adapter

Rule Web Service

Rule Component

Biztalk Server Orchestration

Step 1 Component

Step 2 Web Service

Step 3 Web Service

ILOG Rule Engine for .NET

Rule execution interface

Exposed thru Web Services

Figure #5 – Calling a “rule web service” leveraging ILOG rule engine for .NET from a BizTalk Server Orchestration


For this approach, the first step is to encapsulate the rule execution into a component exposing a Web Service interface. Note that this is easily achieved in .NET by putting a [Webmethod] attribute before the declaration of the CheckEligibility method. The code is then similar as the one written before for calling the rule set from the BizTalk orchestration.

Figure #7 – Encapsulating the rule in a “rule web service”

Note that this approach is interesting far beyond the BizTalk Server integration question. This web service is now reusable across the enterprise and beyond, in fact whenever executing the business rule is needed.

To clarify the benefit, here is a description of the CheckEligibility web service interface. As shown through the test page provided by .NET, the interface is strongly “typed” and consistent with the input data required by the service.

Figure #8 – CheckEligibility Web Service test page

As it was explained above, the Web Service can be leveraged by any application (and in fact on any platform as Web Services allow cross-platform interoperability). The example on the figure #9 is an example of calling the web service from a .NET application.

Figure #9 – Calling the rule Web Service from any .NET application

As BizTalk Server is Web Service aware, we now directly introduce the Web Service as a step in our orchestration representing our business process, with no need to write code to call the rule execution.

Figure #10 – Calling the rule Web Service from a BizTalk Server orchestration


This solution is the most elegant way for integrating ILOG business Rules with BizTalk Server.

We now add to the benefits mentioned in the introduction paragraph:

Web Service implementation reusable beyond BizTalk Server integration context, Compliant with Service-Oriented Architecture principles allowing maximal level of interoperability, Flexibility in terms of deployment, Scalability of the architecture.

There is no real drawback of this approach as compared to the previous one, except that it requires a bit more work and the appropriate skills to implement XML web services. But this is a mandatory investment in the future.

5.3. Combining ILOG Rule Engine for .NET with BizTalk Server Rule Engine

Overview

In some cases, it might happen that a company finds itself in the situation of having rules implemented both in ILOG Rules for .NET and in BizTalk Server Rule Engine.

Though we would not recommend doing so on purpose, this could happen by the unsynchronized development of two projects within an organization, or after a merger or acquisition.

Still, from a technical point of view, there is no major issue in having both products living or working together. To demonstrate this, we imagined a scenario in which we combine the two rules engine in a single application. As both engines are exposed .NET components, we can instantiate them from the same functional component.

Functional Component

ILOG Rule Engine for .NET

Biztalk Rule Engine

Custom Code

Figure #11 – Technically, a .NET component can leverage both engines

We also want to emphasize here the opportunity to progressively migrate rules from a fully BizTalk-designed application towards ILOG Business Rules for .NET. This can be relevant when needing to make rules more sophisticated, for instance by implementing decision tables or rule flow.


To illustrate this scenario, let us imagine that the car rental company is now part of a larger “frequent renter” consortium. The consortium has implemented its own rules in BizTalk Rule Engine for giving rebates to frequent renters.

Figure #12 – Sample rule implemented in BizTalk Rule Engine

Because the application needs to check the eligibility of the customer but also adjust the price to his frequent renter status, we want to be able to invoke both rules managed by Rules for .NET and the ones implemented in BizTalk Rule Engine. We can easily achieve this as both engines are .NET components.

Figure #13 – Calling both rule engines in the same application


Combining both engines in a single application can be useful when inheriting code from different application development strategies. It is not a choice that we would favor in new application scenarios.

The benefits here are:

The good compatibility level between offerings, The possibility to evolve progressively rules in a BizTalk-centric application to Business Rules for .NET.

The “progressive” evolution is likely to be necessary when the conditions described earlier are met: need to give business users easy tools to update rules, rules becoming more complex with decision tables or rule flow, need for managing rule at enterprise level, etc…

6. CONCLUSION

Although at first glance, there is a clear overlap between BizTalk Server and ILOG Business Rules for .NET, because of the capability to define and execute business rules in both products, these products are highly combinable and complementary to provide the best value in business process and business rules management.

A joint solution between BizTalk Server and Rules for .NET is ideal for solutions in the following areas:

Business processes that include complex business policies such as pricing, welfare administration, claims processing, and eligibility Policy-intensive business processes including loan or insurance underwriting, loyalty management Business process management and business policy management across systems

Customers successfully implementing these products will gain a significant level of flexibility, accessibility and manageability of their custom and/or composite business applications.

ILOG Rules for .NET can provide overall cross-the-enterprise management of sophisticated rules & policies and make it accessible to business users while BizTalk Server is able to fulfill the mission of orchestrating processes with a loosely-coupled applications approach and asynchronous message-based communications.

Both can manage high volumes of data and handle the most complex projects in an efficient way.

Compatibility between the two offerings is excellent because of the strong .NET orientation of both products. It is quite easy to call ILOG’s Rule Engine for .NET from a BizTalk Server orchestration through the use of a few lines of code. It is also possible and recommended to take a fully SOA-compliant approach to define a web services oriented integration scheme.

One can also combine rules implemented with the two engines if necessary at a certain stage, which can be useful in evolution scenarios, especially when needing the sophistication of a full BRMS after having started with the simple rule engine included in BizTalk Server.

Beyond the specific value of these two offerings, it is also worth looking at this evolution in the light of overall software market trends. Thanks to enhanced levels of interoperability between software packages through the generalization of XML and Web Services, it is likely that “best-of-breed” approaches will continue to gain more popularity. This trend will make relevant software package combinations one of the keys to successful high-value business application development and maintenance.

Microsoft BizTalk Server & ILOG Rules for .NET is certainly one of these winning combinations.

ilog rules for .net and microsoft biztalk server · and microsoft biztalk server ... sometimes more...

Documents