ILOG Rules for .NET and Microsoft BizTalk Server
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
White Paper
ILOG Rules for .NET
and Microsoft
BizTalk Server
.
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
Page 5
Page 6
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.
Page 7
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.
Page 8
2.2. BizTalk Server architecture
The following schema describes the overall product architecture:
Orchestrations
Business Rules
Engine
Inbound Outbound
Receive Receive Send Send
Adapter Pipeline Pipeline Adapter
Incoming Outgoing
Message Subscriptions Message
MessageBox
Message Path
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.
Page 9
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.
Page 103. 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.
Functional enhancements
Platform upgrade
Software Development Lifecycle
Design Design
Construct Construct
Test Test
Deploy Deploy
Manage and Monitor
Deploy Deploy Deploy Deploy
Validate Validate Validate Validate
Author Author Author Author
Analyze Analyze Analyze Analyze
Rule Management Lifecycle
Policy Policy Policy
Change Request Change Request Change Request
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.
Page 113.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
Page 12ILOG 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.
Page 133.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.
Page 144. 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 Policy managers must be able to make rule Frequent
maintain their own business rules changes themselves and
Controls are necessary to ensure that policy increasing
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
Managing a large volume of The volume of rules managed require a complex Project-
business rules rules organization and hierarchy specific
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
Managing decision intensive Customers policies creates decision making Domain-
processes requiring sequencing of the rules expressed Specific
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
Managing rules as an enterprise Customers are already using ILOG Rule Increasing
asset Management System for business rule as a market
management trend
Customers’ business requires them to produce an
Page 15audit 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.
Page 165. 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 Instantiation ILOG
Expression Rule execution Rule Engine for .NET
Step 3
Web Service
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.
Page 17Figure #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.
Page 18RuleUtilities.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.additionalLiabilityIns
urance), 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
Page 19Biztalk Server Rule
Orchestration Web Service
Step 1
Component Rule
Component
Step 2 Rule execution ILOG
Web Service interface Rule Engine for .NET
Exposed thru
Web Services
Step 3
Web Service
Figure #5 – Calling a “rule web service” leveraging ILOG rule engine for .NET
from a BizTalk Server Orchestration
Sample technical implementation
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.
Page 20Figure #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.
Page 21Figure #10 – Calling the rule Web Service from a BizTalk Server orchestration
Applicability and benefits
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.
Page 22Functional
Component
Custom ILOG
Code Rule Engine for .NET
Biztalk
Rule Engine
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.
Sample technical implementation
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.
Page 23Figure #13 – Calling both rule engines in the same application
Applicability and benefits
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…
Page 246. 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.
Page 25You can also read
