About the Generic Entity Architecture Features

This topic provides an overview of the features of the Aptify Generic Entity (GE) architecture. These features are discussed in the following sections:

Provides Easy Access To Data

The GE architecture uses an object model that is based on objects and collections. For example, to access all of the fields in a record, a programmer uses the fields collection of the generic entity. Programmers with database experience are accustomed to this kind of process, but the process is also easy to learn for people without database experience.

Provides Validation

The GE provides validation for all standard field-level validation needs. The following validation rules apply:

• Required fields may not be left blank
• For numeric fields, a valid numeric value is required
• For text fields, a valid text value is required (no use of the quoted identifier)
• For date fields, a valid date value is required

While these rules are indeed quite simple, they provide the field-level validation that most database systems do not consistently implement. In many cases, additional validation code is required when the logic goes beyond the field level. Each object derivation from the GE may implement any combination of validation logic. See Developing Field-Level Validation Scripts for a discussion on specifying additional validation logic for a particular field.

Provides Abstract Data Model

By providing a powerful, abstract data model, the GE architecture enables the creation of tools that dynamically configure themselves around the structure of an object. For example, it is quite easy to create generic viewers, export tools, and merging tools that take advantage of the generic entity's object model.

Supports Complex Data Types

In most database systems, relations between data are highly abundant. In many cases, one-to-many relations exist that typically consist of foreign key links between tables. Typically, it is difficult to write code that will easily manipulate master/detail data relationships. The GE supports modelling complex one-to-many and many-to-many data relationships via extended object attributes called Sub-Types.

Sub-Types allow you to model data with the objects with any level of depth. Additionally, it is possible to have any number of sub-type collections at any given level of the data model. It is also possible to dynamically examine the capabilities of the object via a standard GE interface.

See Creating Sub-Type Entities for information on creating sub-type entities within Aptify.

Permits Overriding Standard Functionality

Although problems exist in the traditional database development methodology, framework-based development has not been very successful for several reasons. One of the most pressing reasons not to use a framework to develop database applications is that most frameworks limits developer flexibility. Additionally, most frameworks are design-time frameworks, not run-time frameworks, which causes additional loss of value.

In Aptify's GE architecture, as with all Aptify technologies, it is possible to select the services your application requires. At any point, it is quite easy to augment, override, or use the capabilities of the GE. Because of this focus, it is always possible to go around the default functionality of the GE to accomplish a task. While the vast majority of requirements fall within what the GEcan accomplish by itself, the need does arise to go around or augment its basic functionality.

In Aptify, a developer can create a plug-in to modify the standard behavior of an entity, including validation, duplicate checking, and merging operations. See Developing Entity Plug-in Objects for information on entity plug-in objects. See Developing Duplicate Check Objects for information on duplicate checking objects.

Provides Security

The GE architecture provides a standard security layer. Using the Generic Entity architecture automatically enables the configurability of each entity with separate permission control lists for CRUD (Create, Read, Update, and Delete) permissions. It is easy to add more security capabilities to GE derived objects, or to override the basic security capabilities if necessary.

Enables Rapid Development

By abstracting complex data models with a standard object interface and providing the necessary tools to build such objects quickly, the GE architecture helps to decrease overall development time while improving reliability and the feature set. One of the greatest benefits for system development efforts is that this architecture establishes a well-defined interface between each layer of the application architecture. As a result, a developer can become very efficient at developing GUIs without prior knowledge of the inner workings of the data model. In fact, the design goal of this object architecture was to enable business analysts to take a system directly from prototype to production (GUI level) with no understanding of the data model in its raw relational form (only an understanding of object fields, sub-types, and so forth). This encapsulation of system logic effectively allows for the separate encapsulation of knowledge of the database and the GUI, simplifying the overall development cycle.

Provides Automatic Version Control for Data

Another problem with many database systems is tracking and controlling changes to the data. As database systems are used, the value of the information contained within them grows. Due to this natural effect, it is important for an organization to be able to control and review changes made to the data. In most systems, data changes are difficult to control and difficult to track. In any GE based system, it is easy to control access to data (see About the Generic Entity Architecture Features section above), and to track changes to the data. Version Control (referred to as Record History within Aptify) is built into the GE, and any object built using the GE automatically receives this feature. It is a configurable option that an administrator can turn on or off for each entity. Because mass storage is available at low cost, version control is typically left on for most entities.

In addition to tracking changes, it is possible for the GE to require the user making the change to document the reason for the change (by entering comments, who requested the change, and so forth).

As the system records data changes, a user-oriented change string is recorded along with a snapshot of the object. The Change String is a message that states which fields were changed in a user-oriented syntax. An example is shown below:

First Name changed from Bob to John

Last Name changed from Jones to Smith

Title changed from President to CEO

Company changed from ABM Corp. to SOL Corp.

The snapshot of the object is required in an XML style markup language. An example is shown below:

Version 2 of the record

<OBJECT TYPE=FULL_VERSION ENTITY=Person VERSION=2>
       <FIELD NAME=FirstName>John</FIELD>
       <FIELD NAME=LastName>Smith</FIELD>
       <FIELD NAME=Title>CEO</FIELD>
       <FIELD NAME=Company>SOL Corp.</FIELD>
</OBJECT>

Version 1 of the record

<OBJECT TYPE=FULL_VERSION ENTITY=Person VERSION=1>
       <FIELD NAME=FirstName>Bob</FIELD>
       <FIELD NAME=LastName>Jones</FIELD>
       <FIELD NAME=Title>President</FIELD>
       <FIELD NAME=Company>ABM Corp.</FIELD>
</OBJECT>

The syntax of this language is designed to accommodate nearly any type of data format. Due to its highly structured format, it is possible for the Generic Entity layer to restore prior versions automatically to perform difference analysis and to do merging.

Provides Duplication Check Object

The GE defines a hook in the system to allow each customer to define the logic for checking for duplication of data. For example, depending on the locale, the customer, and a number of other factors, customers may often have companies entered into the system that are really duplicates. The GE defines a standard interface that can be used to define a duplication object which determines whether a record about to be created would potentially (or absolutely) be a duplicate of any other record. The two levels are defined as follows:

1. Absolute duplicates: If the duplication check object finds what it considers to be an absolute match (for example, a company record that has ALL relevant fields matching: name, address, phone, city, state, and so forth), the GE does not allow the record to be created.
   
   
2. Potential duplicates: If the duplication object finds what it considers to be a potential match, but is not absolutely certain that it is indeed a match, the system prompts the user stating that it has found x potential duplicate(s) and allows the user to view them.

Each duplication object simply defines the logic and returns to the GE a listing of absolute and/or potential duplicates. The GE in turn provides the GUI and decision logic required for the end-user, thus standardizing the GUI and simplifying the programming to implement this feature. See Developing Duplicate Check Objects for information on duplicate checking objects.

Provides Customer-Extensible Logic System

The GE architecture provides a hook into the logic of the creating and updating of records in the database called a verify object. This object is an optional, customer-defined object that hooks into the Save process of the GE for a given object type. For example, a customer may want to add logic to send an e-mail to a specific user whenever a new order is placed. We could easily build an object to comply with the requirements for the Verify Object interface and perform its custom operations. By supporting this generic extensibility, systems can be developed quite simply to eliminate the need to modify the base objects. That way even the business systems developed on top of the GE can easily provide extensibility to their customer's implementation needs.

Builds in Transaction Processing

In many cases, a transaction, meaning a change to the database, has multiple steps. It is vital to the integrity of the data that the transaction occurs in its entirety or it does not occur at all. The way to accomplish this is to use transaction processing command blocks directed to the server. This ensures that an atomic transaction space wraps to the individual database commands and enables the commit or rollback of the entire transaction. The GE architecture automatically creates transactional wrappers around any changes made to the database. This makes it very easy to build a database system that automatically ensures data integrity. (Most existing systems were developed without transaction processing code because many developers are either unaware of the necessity of this part of the application, or are unfamiliar with implementation or lack time to implement it properly.)

Supports Distribution of Objects

The GE architecture automatically supports the distribution of object processing using the Aptify Object Repository.