A fundamental tenet of the LANSA Rules Engine architecture is to keep applications separated from the databases with which they work. This is vital for data integrity.
In every system, there exists a set of rules that control how an application's programs are allowed to create, read, update or delete data. These rules exist to maintain the quality and consistency of the data and also to protect data integrity in a multi-user, transactional environment. Failure to follow the rules can lead to anything from bad data to a total system crash. You ignore the data integrity process at your peril!
Not in the database and not in the application
Typically, rules are maintained at the database level, using stored procedures, field validation, triggers etc., or in the application programs. The obvious benefit of enforcing rules at the database level is that it eliminates duplication. The downside is that all database vendors have their own proprietary ways to implement triggers and stored procedures so that enforcing rules for data integrity at this level locks you into a specific database. You can avoid this kind of database lock-in by coding rules at the application layer, but then every program needs to incorporate the same set of rules, leading to duplication, inconsistencies and difficult to manage code.
A completely independent data services layer
LANSA has implemented its data services layer to provide a single access point for all data, serving to abstract formats, locations and conventions. Specific data service programs – called Object Access Modules – are generated from data held in the repository. These OAMs know about the structure of the database (relationships, fields and files) and contain the rules that govern all create, read, update and delete transactions. So whenever any program anywhere on the network wants to 'create_New_Employee' in the ‘comp_Employee’ table in the HR system, that request will be directed via the data services layer and the appropriate OAM. Future changes will only cause that specific OAM to be regenerated and will not impact other programs. Not only do OAMs protect your data by applying validation rules, they can include other intelligence such as activating database independent triggers and workflow actions or on-the-fly derived fields based on calculations and other formulas.
Importing existing data/schemas
When building new applications, developers define data, tables, and relationships using LANSA’s development tools; but many projects extend existing applications. Developers can take advantage of OAMs by importing data, schema, and stored procedure definitions from existing application into the LANSA Business Rules Engine.
The LANSA Data Services Layer is accessible from any program on any platform
OAMs can be used by any program regardless of the development language used e.g. Java, LANSA, C#, PHP, RPG, COBOL etc. The net result is that all of your applications – irrespective of their age or technology – use a common data services layer to access the underlying databases.