Rules Processing

The rules-processing engine, found within most integration servers, allows the application integration architect and developer to create rules that control the processing and distribution of information. Rules processing is an application development environment supported by the integration server to address the special requirements of integrating applications. By using rules engines, integration servers can implement intelligent information routing and transformation. For example, at times a message will be required by a second target application. At other times, a piece of information will need to be routed to two or more applications. In both these cases, information must be routed to any number of target applications that extract and translate data from any number of source applications. A truly flexible solution requires a rules engine to make these formatting and routing decisions dynamically. Combining a rules engine with a message transformation layer allows such a solution to be realized.

Essentially, a rules engine is an application that resides between applications; one that does nothing more than provide the logic for sharing information. Each rules engine solves an intelligent routing and transformation problem differently. Most have the capability of testing a message to determine its fields and values. Most often, rules engines use traditional Boolean logic (IF, ELSE, and OR) and high-level languages to create rules and associate actions with each rule according to its algorithm.

The rules-processing capabilities of integration servers should not be confused with the capabilities of traditional application servers. Application servers provide a full spectrum of element environments and tools. Most rules-processing engines only provide features sufficient to move a message from any number of source systems to any number of target systems. However, as integration servers have matured, they have begun to provide rules-processing services that rival those of traditional application servers. Pushing the envelope in this direction, some vendors have gone so far as to integrate application servers with integration servers. This strategy combines the best of both worlds while also addressing service-oriented application integration.

Rules processing generally relies on scripting languages rather than on more complex programming languages (such as Java and C++) and on interpreters rather than on compilers. However, as in almost everything about integration servers, the way in which each integration server processes rules varies from vendor to vendor and from integration server to integration server.

Rules are created through either the rules editor (which functions like a program editor) or a wizard. The program editor creates rules by allowing commands to be entered into the integration server. These commands may be stored as a simple text file, or in more sophisticated integration servers, they may be stored within the repository. The rules wizard guides the user through the selection of each rule that is being applied to a particular message, group of information, or events. For example, the wizard may ask if the message should be processed as soon as it comes into the integration server or at a specific time of day. Options such as these are particularly useful for things like updating customer information in a database, when such updates might be better made during off-peak hours. The wizard may also inquire about the transformation of information between the source and target systems, including the logic that may be required. It may create the opportunity to take many variables into account at the same time, such as checking for states and events that other systems may provide. For example, it may not be advisable to update the SAP database if the last update to the database produced an error message or an unstable state. Or certain users might have to be logged on before proceeding with a certain type of message processing. Depending on the need, it may be beneficial to wait for a specific event before extracting information from a source system.

Because rules processing is truly programming, almost anything can be done. Information can be generated based on sales events over a million dollars. Other applications based on the monitoring of events for states can be invoked. Anything that can be programmed can be made part of the rules processing. With rules engines becoming more powerful and vendors providing easier mechanisms to create rules, there is no limit to what is attainable.