This article originally published in the Architects Corner section of our LANSA Review customer magazine Issue 39, 2010.
Information is the life blood of business. Making decisions based on out-of-date or incorrect information may result in lost revenue, upset customers or compliance violations and may threaten the viability of the company.
Managing the data is easier when the data definitions and business rules are centrally defined outside the program code. If any of the definitions or rules need to be changed, you only have to make that change in one place! Secondly, you will want to make sure that any program or utility that accesses the data uses the most recent definitions and business rules. In other words, to protect your data, you want the definitions and rules centrally deployed, without exception.
Considering that many companies use a variety of programming languages and utilities that may access the same set of data, that's easier said than done.
LANSA provides tools, collectively called the LANSA Repository, that describe, store and deploy data definitions and their related business rules.
This Repository facility has always been available to programs developed in LANSA and programs that use LANSA Open for .Net to access data. LANSA Enforcement Triggers can provide the same level of protection to any program or utility that accesses data that has been described in the LANSA Repository, even Data File Utility (DFU).
Describing the data and rules
The Repository allows you to describe data items ("fields" in IBM i terminology) and their business rules, plus tables ("files" in IBM i terminology) and their business rules.
Data item definitions may include:
- Name – a variable programs can refer to
- Labels – for the user interfaces
- Data type – strings, numbers
- Formats – such as dates in various representations
- Validation rules – for example the data item must not be blank
- Actions – actions that need to happen under certain conditions
- Help text – for a better understanding
A table definition may include:
- A list of the data items in the table. Data items can be physical or derived. The latter meaning that their value is based on the value of other data items from the same table or from other tables.
- Validation rules specific to the table context, for example a validation for a customer table could be that you are not allowed to delete a customer if invoices or orders exist for that customer.
- Actions specific to the table context, for example, if a customer record is updated in this table, update customer information in other tables as well (a typical CRM scenario).
- Indexes and relationships with other tables.
escribing what the objects (data, tables and rules) are like, rather than the code to create them. LANSA stores the descriptions in database tables in the Repository.
The Repository typically contains thousands of definitions and rules, depending on the size of the application. That's really where the logic is or should be defined, so the applications that use the data don't have to repeat the same definitions and rules.
Deploying the definitions
From the data, table and business rule descriptions stored in the Repository, LANSA generates an executable program to manage access to the data. This could be a compiled C#, C or RPG program, depending on the platform. This executable is a component of LANSA's Data Management Services (DMS).
The DMS provides independence for the data from the applications that use it and provides independence from the database management systems in which the data resides. This means that when you want to move your application to another platform, you simply move and deploy the Repository definitions to the other platform. This is a feature that our solution partners specifically like, because it provides complete cross platform capabilities for their solution.
Enforcing the rules to all
The LANSA Data Management Services have always been available to programs developed with LANSA and programs that use LANSA Open for .Net to access data.
But how can you enforce the LANSA DMS routines that deploy the definitions and business rules (potentially thousands) to other applications and utilities? This is where LANSA's Enforcement Triggers come in. Deployed as triggers at the database level, LANSA Enforcement Triggers can provide the same level of protection to any program or utility that accesses data that has been described in the LANSA Repository.
A few Enforcement Triggers may activate hundreds of LANSA DMS defined rules and validations.
How about existing datasets?
You can import the definitions of any existing dataset into the LANSA Repository and then optionally further enhance the definitions using the LANSA Repository tools. This process of making a file known to LANSA does not affect the file itself, nor does it involve any duplication of data.
Many companies use the Repository on top of a packaged solution, such as JD Edwards or Insure/90. It allows them, for example, to define more user friendly field names, add formula/derived fields and define additional rules and actions, without affecting the packaged solution itself. It is like putting a mask on top of a dataset or viewing the dataset through a different pair of glasses.
The benefits of the DMS
With the LANSA DMS you have one resource to manage the data, acting as a guard to ensure that programs cannot perform inappropriate actions to the data.
You have one place to maintain when change occurs. You do not need to find every program that has access to the database and then modify, compile and test each program – and risk that you may overlook a program.
The LANSA DMS protects your data from any application that wants to access the data, including COBOL programs, C# programs, Java programs, RPG programs and utilities like DFU. The protection applies even when you implement access to your data via Web services or Microsoft Excel.
LANSA Data Management Services provide:
Single point of protection for your data but universal coverage – Whether by mistake or intentionally, no program or utility can corrupt your data or cause referential integrity problems. Not even using DFU.
Reduced maintenance costs – With LANSA you change the definition once, rebuild the Data Management Service and deploy it – no need to change a class and repair the repercussions, no need to change a /COPY (copybook) and recompile every program that uses the copied code.
Consistency – The business rules associated with a dataset reside in one place and when the rules change you only need to maintain it in the one place. All programs that access the dataset through the LANSA DMS instantly use the same changed rule.
Business level definitions – When the rules are described at a business level, rather than being coded in a particular programming language, maintenance is easier. The LANSA tools use data abstraction to remove details specific to program language, database and platform deployment.
Cross platform capabilities – It's easy to generate the Data Management Services for another platform from the same Repository definitions.
LANSA's Data Management Services protect your data once and for all.