Extensible Rule Based Business Integration Artifact Naming
Original Publication Date: 2005-Nov-05
Included in the Prior Art Database: 2005-Nov-05
Porting BI (Business Integration) artifacts from a platform vendor to another vendor is not a one to one mapping between the respective artifacts. One BI broker might have artifacts that are not present on another broker. A target broker might need additional artifacts that are not present on a source BI broker. The number of artifacts to generate on the target platform can be enormous and manually naming them is tedious and leads to erroneous naming. Some BI brokers might have assisted naming of artifacts, but they are usually not versatile and commonly not accessible through a generic programming interface. This article describes an extensible configurable rule based naming engine. Naming rules can be plugged and be combined in a description language based on XML.
Extensible Rule Based Business Integration Artifact Naming Introduction
The rule based naming engine has the following characteristics:
XML definition to instantiate and combine rules Plug in mechanism to add new rules to the rule based naming engine in form of Java classes Common base set of rules mainly for string manipulation and access to artifacts are available
The example below shows how the rule based naming can be used:
<!-- Extension base BO reference field -->
<set name="field-name" value="$field.formatted$"/>
<rule name="prefix-strip" ref="bo-stripped">
<set name="string" value="$bo-type-name$"/>
<set name="additional" value="Generic"/>
<set name="separator" value="_"/>
<get name="stripped" ref="bo-name"/>
<rule name="modify-case" ref="stripped">
<set name="string" value="$bo-stripped.bo-name$"/>
<set name="case" value="first-to-lower"/>
<get name="applied-case" ref="bo-name"/>
<rule name="template" ref="field">
<set name="template" value="$stripped.bo-name$Data"/>
The rule system above declares the top level rule bo-extension-ref-field, which tells the rule naming engine how a business object extension reference field name has to be generated. In a target business integration broker, a business object (BO) extension reference field might mimic object inheritance in that it refers to its super class by reference. This reference is not needed in BI brokers that support direct inheritance and thus a new object and a new reference field have to be created in a non supporting broker. The other rules are predefined rules available to end users to manipulate strings in order to produce desired names.
The rule naming engine supports input and output parameters (indicated by set and get inside the rule instance) and they can be made dependable on each other.
Executing above rule produces the following values step by step (scope relative to bo-extension-ref-field):
Input from bo-type-name = Generic_Address
The core of the rule engine is composed of
bo-stripped.bo-name = Address
stripped.bo-name = address
field.formatted = addressData
Result in field-name = addressData
XML rule definition language, referred to as BeRule hereafter
Rule Manipulation API
Rule extension plugins
Optionally a graphical BeRule editing tool
BeRule assembles available rules and creates instances of it. Input parameters (set) are wired with output parameters (get). In a graphical editor, the former could be shown as incoming arrows in a flow graph; the latter as outgoing arrows.
The rule manipulation API is a shortcut to directly communicate with the rule engine without having to define a BeRule document and is used by programs that need to have compile-time dependent rules with a set of predefined parameters.
The rule engine evaluates a BeRule document. It analyzes the rul...