The Aptify Object Repository contains all objects, interfaces, components, reports and other files that are used within the system. These components are stored in packages. As with database objects, the Aptify Object Repository contains core objects and interfaces that should not be modified because they may be included in an upgrade and possibly overwritten. If a client requires additional functionality in an Aptify object, a new version of that object (with a unique name) should be created. The new object should then be stored in a client-specific Object Package.

Benefits of Using Complied Objects

Incorporating certain functionalities into compiled objects in the Aptify Object Repository instead of incorporating them in other areas such as stored procedures or triggers is a recommended Aptify methodology for configuration work for several reasons.

• It is easier to maintain because it is in a centralized location (the Object Repository).
• For GUI objects, the results from the logic display as soon as the record is saved. By building the logic into the business object, the functions may be called from the GUI whenever needed to provide immediate feedback to the user. Otherwise the record on a form would have to be refreshed to see the results. This enables the logic to be centralized, simplified and easier to maintain.

Naming Conventions

When an object in the Object Repository is created, following a specified naming convention helps organize the objects as well as clarify the functionality of the object. While organizations may define naming conventions that suit their business practices, the naming conventions used in Aptify are explained in the sections below.

Packages

The recommended naming convention for client-specific packages is a three- or four-letter abbreviation for the organization. Storing objects in a client-specified package limits the possibility of a client-specific object getting overwritten during an upgrade.

Please note that client objects with different names than the standard Aptify object names will not be overwritten during an upgrade either, even if they are located in a standard Aptify package.

Interfaces

The recommended naming convention for an interface is I followed by the client name abbreviation, followed by the service to which the interface applies or the business requirement, followed by Module.

For example: IABCPersonModule or IABCLineShipStatusModule

Generic Entity Objects

The naming convention for a Generic Entity assembly is the client name abbreviation, followed by the entity name (without spaces) and the word entity. When compiled, the assembly uses a .dll extension.
For example: ABCOrdersEntity.dll

Forms

The naming convention for an entity viewer form is the client name abbreviation, followed by the service or business requirement, followed by a Viewer suffix and then followed by a .dll extension.
For example, ABCSaveSubscriptionsViewer.dll

Reports

When a new report is created, it should be given a unique name and stored in the client-specific package in the Object Repository. Storing the report in the client-specific package eliminates the possibility of the report getting overwritten during an upgrade.

Wizards

The naming convention for a wizard includes the client name abbreviation, followed by a description of the wizard's purpose, followed by Wizard.dll.
For example, ABCDuesOrderEntryWizard.dll