Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

BizTalk Server 2009 : Use The Business Rule Engine (part 1)

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/24/2013 5:29:32 PM

1. What Is a Business Rule Engine?

An organization's most strategic assets are the products/services it provides to its customers as well as the business model and internal processes it uses to differentiate itself from its competition. An organization's IT department's most valuable assets are the data on products/services and customers of the organization as well as the workflows and business rules that drive the internal processes and business model. It is the IT department's main responsibility to ensure the agility of those assets.

Although data management and portability is being addressed by database management systems such as SQL Server and although workflow management and portability is usually addressed by business process management services such as the BizTalk orchestration engine, business rules are usually neglected. Most business rules today are implemented in procedural languages and code that is maintained by application developers and programmers. This ties up one of the most critical organizational assets and limits its agility. The cost and time required to update the business rules and underlying IT services within an organization that implements its business rules in procedural languages is too high for such an organization to react quickly to its business units' needs. Moreover, the business rules might be improperly translated from the design documents (written in a human language) to the procedural code, which contributes to problems and leads to inconsistency.

The BRE addresses these pains. It allows IT departments to properly isolate, consolidate, and manage their business rules and policies in a simple manner so that they can react to their organization's business process changes swiftly at low cost points. The Business Rule Engine allows business analysts to describe business policies and rules in a simple graphical or textual form without the need to use a typical procedural programming language. Those rules are then stored away from the rest of the enterprise applications in a separate business rule store managed by the Business Rule Engine. Isolating business rules from the invoking applications in such a manner allows business analysts and business rule authors to update the business rules dynamically to meet the changes required by their business units. Updating those business rules does not require any changes to enterprise applications or business orchestrations that invoke them, unless changes to those rules require new data input or alter the output in a way that requires updates to the calling application. Running applications will seamlessly fire the latest version of the updated business rules the next time they invoke them. Applications leveraging the BRE invoke business rules through the Business Rules Framework.


The Business Rules Framework is a Microsoft .NET-compliant class library. It provides an efficient inference engine that can link highly readable, declarative, semantically rich rules to any business objects (.NET components), XML documents, or database tables. Application developers can build business rules by constructing rules from small building blocks of business logic (small rule sets) that operate on information (facts) contained in .NET objects, database tables, and XML documents. This design pattern promotes code reuse, design simplicity, and modularity of business logic. In addition, the rule engine does not impose on the architecture or design of business applications. In fact, you can add rule technology to a business application by directly invoking the rule engine, or you can have external logic that invokes your business objects without modifying them. In short, the technology enables developers to create and maintain applications with minimal effort.

Rule engines optimize rule resolution performance. They can evaluate rules within the same policy in parallel and cache their results until the facts involved in their evaluation change. Business policies, or rule sets, are composed of multiple business rules. Figure 1 illustrates this composition. The order of the evaluation of the different rules within a policy may be controlled by setting priorities to these different rules. Rules are composed of a condition followed by a set of actions that are executed if the condition in question is evaluated to be true. Conditions are composed of operations—predicates—that can be performed on facts to result in a Boolean value. Facts may be part of an XML document, an entry in a relational database, a basic .NET type, or a .NET component. To retrieve the values of complex facts, fact retrievers, which are .NET components that implement a particular interface, may be used.

Figure 1. The composition of a business policy

The Business Rule Engine is composed of multiple components:

  • The Business Rule Composer allows business rule authors to identify the sources for the different facts used within their business rules as well as define and version their business policies and business rules.

  • The Business Rule Store holds the definition of those business policies and facts.

  • The in-memory cache holds the results of the evaluation of the different business rule conditions.

  • The Business Rules Framework is used by application developers or orchestration developers to call business policies and execute different business rules from within their applications or orchestrations.

  • The Business Rules Update Service monitors the Business Rule Store for published updates of policies and rules to deprecate older versions from the cache and reevaluate conditions as needed.

Studies show that 15% to 50% of annual IT budgets are spent on compiling, testing, and implementing rule changes in applications. Rule engines allow the separation of business rules from the applications that use them and enable the maintenance of business logic without having to resort to code changes and software modification. This reduces application development time and significantly reduces maintenance and enhancement cost by 15% to 50%. IT organizations leveraging rule engines can increase the flexibility of their applications and services and reduce their time to production. Rule engines promote visibility and understanding of business policies and procedures as well as consistent decision making, since a business rule update in a rule engine directly updates the behavior of all enterprise applications and services that call the common business rules managed by the rule engine. This enforces order to the rules and policies that govern business (eFORCE).

2. What Are Business Rules?

As explained in "Implementation Guide of BizTalk's Business Rules" (Xi, 2005),

Business rules (or business policies) define and control the structure, operation, and strategy of an organization. Business rules may be formally defined in procedure manuals, contracts, or agreements, or may exist as knowledge or expertise embodied in employees. Business rules are dynamic and subject to change over time, and can be found in all types of applications. Finance and insurance, e-business, transportation, telecommunications, Web-based services, and personalization are just a few of the many business domains that are governed by business rules. Each of these business domains shares the need to convey business strategies, policies, and regulations to information technology (IT) personnel for inclusion into software applications.

As mentioned previously, a rule consists of a condition and a set of actions. If the condition is evaluated to true by the BRE, the actions defined in the rule are executed.

Traditional procedural and object-oriented programming languages, such as C, C++, and Microsoft Visual Basic, are oriented toward programmers, thus limiting the ability of nonprogrammers to participate in the maintenance of automated business policies. Even advanced object-oriented languages, such as Java and C#, are still primarily programmers' languages. The Business Rule Engine and the Business Rules Framework address this problem by providing a development environment that enables rapid application creation without the lengthy cycle of traditional application programming. For example, business policies constructed by using this framework can be updated without recompiling and redeploying the associated orchestrations (Xi, 2005).

3. When to Use the BRE?

Traditionally, rule engines have been used for such things as credit scoring and underwriting in financial organizations because of the volume and complexity of business rules that these applications require. Using a procedural programming language to code such rules directly into an application makes application maintenance difficult and expensive, as these rules change often. The difficulty in maintaining these rules is encountered even in the initial release of the application, since such rules often change between the time the code is written and the time it's deployed. Hence, rule engines were devised to separate business rules from application logic (Moran).

Virtually every application includes some logic that needs to change often or needs to change in ways not anticipated in the original design. The real question then is not whether you need a rule engine, but how much time and money the rule engine will save you. Even if only a small subset of your rules is subject to change, your project can benefit greatly by separating these rules from the rest of the program logic. This is particularly true during user acceptance testing when missed requirements and incorrect assumptions become evident. A rule engine enables you to make dramatic changes in system behavior without dramatic changes in your code, and it enables you to make changes at runtime.

Although simple runtime rule customization can be implemented by using database tables or configuration files to store values for facts used in business rules, a rule engine offers much greater flexibility than simple database tables or configuration files. A rule engine allows you to isolate the condition as well as the action from the application flow. You can simply update a rule's condition, change values associated with facts, or change actions in a rule altogether without the need to recompile and redeploy the application.

So when do you use the BRE and when do you keep your rules outside the BRE? A rule engine is suitable when your application involves significant decision making; the rules are complex or change frequently; the rules need to be shared across multiple applications and organizations; or you are in a volatile industry sector where change is the norm or regulation is extensive and complex. Maintaining your rules in custom code that may be configured through database value lookups or configuration files is suitable when the rules are mostly static and computational, or are simple, even if numerous; speed and throughput are more important than flexibility and maintenance cost; or your business rules are never expected to change in the future (eFORCE).

Other -----------------
- Microsoft Dynamics CRM 4 : Scribe Integration - Scribe Insight Architecture
- Microsoft Dynamics CRM 4 : Scribe Integration - Integration Options
- Maintaining Dynamics GP : Safeguarding data by Backing Up everything
- Maintaining Dynamics GP : Improving stability by Managing Dictionaries
- Client Access to Exchange Server 2007 : Using Cached Exchange Mode for Offline Functionality
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 3) - Using Group Schedules
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 2) - Sharing Information with Users Outside the Company
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 1)
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 2) - Domain Time Hierarchy
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 1) - Time Services Role in Authentication
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server