Browse Prior Art Database

Extensible Rule Based Business Integration Artifact Naming Disclosure Number: IPCOM000131037D
Original Publication Date: 2005-Nov-05
Included in the Prior Art Database: 2005-Nov-05
Document File: 7 page(s) / 46K

Publishing Venue



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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 1 of 7

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 -->

<rule name="bo-extension-ref-field">

<get name="bo-type-name"/>

<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="$$"/>

<set name="case" value="first-to-lower"/>

<get name="applied-case" ref="bo-name"/>


<rule name="template" ref="field">

<set name="template" value="$$Data"/>

<get name="formatted"/>


</rule> </rules>

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 = Address = address

field.formatted = addressData

Result in field-name = addressData


Page 2 of 7

XML rule definition language, referred to as BeRule hereafter Rule Manipulation API Rule extension plugins Rule engine
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...