Technical White Paper (page 3)

Integration with Legacy Databases

The Designer can map existing legacy entities and elements to a new project - indeed most projects nowadays include access to a corporation's legacy entities. The generated system can access records (for example name and address on the customer master, or the catalogue of products) and it can update records (orders received or acknowledgements). How it does that is dependent on the implementation:

The legacy entity may be on a separate database and be defined on the data access path.
The legacy entity may be in a locked database, such as SAP, and be accessed through an API.
The legacy entities may be on many databases (a catalogue of products with inventory availability at many warehouses) in which case the data may be accessed through an EAI system or a P2P system.
The legacy entity may be on an old or non-relational database that is not easily accessed in which case a Data Access Bean can be defined once off and used within the Designer as a "callable function".

Integration with Legacy Databases diagram

In summary it does not matter where the data resides - changing the Data Access Bean for the specific implementation can retrieve it.

Elements

The elements are defined for each entity. This effectively gives us the physical file layouts.

In the Designer the element name is unique. An element can be one of four types -

Element Type	Characteristics	Example
Information	Over 80% of a commercial database is informational.	name, address, voucher number, journal reference, invoice code, price
Derived	This is the result of a calculation.	inventory on hand, customer balance, statistical elements
Base	This triggers the calculation that updates the Derived element.	inventory receipt quantity, deposit value, order quantity
Transient	This element is not on the database. The value is calculated and output to a screen or report.	inventory value (price multiplied by unit cost), local value (foreign value divided by exchange rate)

The type then determines which rules are allowed on the elements and thus how the element will behave in programs. Here are some examples:

Parent Elements

An important feature of the element is that it can take its attributes from a single definition through a Parent Element. The Parent Element can:

Define attributes (size, type, source etc.)
Have associated objects (date, phone, mobile SMS, web link, carrier, postal code etc.)
Have customer-specific logic (digitized drawing, postal code completion, link to AI questionnaire etc.)

Rules, help text, and table values are all defined at the element level. They are defined once only and at the lowest level of detail. Therefore, there is no redundancy in the design.

Global Variables

Global Variables are populated immediately when a user logs on to the system - typically with default data about the user such as language, currency, customer code, or supplier code. The Global Variable is then used to restrict searches, for example so that a supplier can only see the supplier's products.

Constants

Elements can be defined as constants and presented on screens to break up input/output element groups. The constants are then available for translation.

1 2 [3] 4 5 6 7 8 9 10

Downloading This White Paper

Download Technical White Paper

All white papers are saved in the Adobe Acrobat format (pdf) for maximum portability. You may download the Adobe Reader at no charge from the Adobe website.

To save the file to your hard drive for later use, click the "download" link to open the document, and then click File and select the Save option. Enter a file name and location, and click the OK button.