Origin objects, custom objects, and overlays

About origin objects

An origin object is an object created in Base Development mode of Developer Studio. All out-of-the-box AR System application and server objects are origin objects.

By default, Developer Studio is in Best Practice Customization mode. In this mode, you cannot create, directly modify, or delete origin objects.

To work with origin objects, switch to Base Development mode. See Setting-the-development-mode-for-object-customization.

About custom objects

Objects that are newly created in Developer Studio in its default Best Practice Customization mode are custom objects; they are not in an original BMC application. Custom objects are not modified or deleted during an AR System server or application upgrade.

When you create new objects, such as forms or fields, in Best Practice Customization mode, Developer Studio appends the __c string to the default name of the object. For example:

• Default Administrator View__c
• Character Field__c

The __c string is not used for the out-of-the-box objects, which provides an assurance that the custom objects' names do not conflict with out-of-the-box objects for future releases. If you remove __c from the custom object name or rename the object, this might result in a name conflict in the future

Using custom objects has the following advantages:

• The application and server installation programs do not modify or delete custom objects during application and server upgrades.
• Custom objects make it easy to identify all the user-created (versus out-of-the-box) objects in your applications.

About overlays

An overlay is a copy of a AR System server structure or workflow object that is used in place of the origin object. An origin object for which an overlay has been created is an overlaid object. Until you modify the overlay, its appearance and functionality are identical to that of the overlaid object. (BMC Helix CMDB does not support overlay functionality.)

The following figure shows how unmodified objects, overlays, and custom objects are used in place of the original objects for a customized application.

Difference between a base application and a customized application

Overlays are separated into granular components, which allow you to add to or overwrite some aspects of an object and inherit other aspects. When aspects are inherited, changes made to the origin object are also inherited in the overlay. For example, when you upgrade, any inherited aspects that are updated in the new version of the product are also updated in your overlay.

Where aspects are added (such as forms added to a filter, or permissions added to a form), the changes made to the origin object are also inherited in the overlay.

Granular-overlays help to minimize reconciliation of overlays after you apply patches or upgrades.

When you create an overlay, the AR System server creates a copy of the object. For objects that store data such as forms and fields, AR System copies the definition of the object but does not create a copy of database tables or columns that are used to store the data. The same data is available through the origin object or the overlay.

At run time, the AR System server and clients (such as the mid tier) use overlay objects in place of the origin objects. For example, if a filter is to be used during an operation and AR System server detects that the filter has an overlay, the server executes the overlay filter instead of the origin filter. Or if a client is required to fetch an object from the server and the object has been overlaid, the client fetches the object's overlay instead.

During upgrades, a AR System installation program ignores overlays—it does not undo their modifications, overwrite them, or delete them. The installer is unaware that they exist. Only the objects that were installed with the application or server are modified. After the upgrade, the application or server continues to use the overlays instead of the origin objects for runtime operations.