There are additional guidelines for designing customizations that will be used by multiple customers. Following these guidelines will make your customization work for more customers and make it easier for a customer to use customizations from multiple sources.

Creo Elements/Direct Model Manager's architecture supports customization at three layers. At the lowest layer are the Creo Elements/Direct Manager Server objects. The middle layer is the CAD application layer, which provides the CAD data management objects, such as Model, Part, and Drawing. The objects for the Design Data Management and Desktop implementations are at the top layer.

The Design Data Management and Desktop objects are tightly coupled to those applications' schemas - DM and DT, respectively. The default schema for new Creo Elements/Direct Model Manager customers is DM. Many existing customers still use the DT schema; others have their own custom schema.

Customizations made at the CAD application layer should work for most Creo Elements/Direct Model Manager customers while still benefiting from the CAD capabilities of objects found at that level. However you will still need to account for behaviors that were in the DT or DM layers. For example, the DM and DT schemas handle data attributes differently so your code will need to determine which schema is being used and then initialize the data attributes. See the source code for the DT and DM objects to find the behaviors you will need to address. Using business objects for attributes, as described in the next section, provides even more schema independence.

The CAD application layer is implemented by objects found in the com.osm.datamgmt.biz package. See the Creo Elements/Direct Model Manager internal architecture for more information.

Consider the following two scenarios. Two companies, Partner A and Partner B, have developed customizations. Customer C wants to use both the Partner A and Partner B customizations. There are no functionality overlaps in the two customizations.

In the first scenario, both Partner A and Partner B extended MODEL_3D. You can tell that a customization extends a class by code that looks something like the following in the XML file:

In the second scenario, both Partner A and Partner B defined new attributes (or pseudo attributes) for MODEL_3D and then created business objects for the new attributes. Since the functionality does not overlap it is unlikely that the two customizations used the same attribute names. You can tell that a customization created business objects for attributes by code that looks something like the following in the XML file:

In the first scenario, a Java developer will need to merge the Java code for the two customizations so Customer C can use both of them. For example, the developer would need to modify Partner A's code to inherit from Partner B's class, or visa versa, and then resolve any problems.

In the second scenario, the Customer C can use both customizations by merging the attribute definitions in the XML file. No Java code needs to be changed.

Using business objects for attributes, rather than extending classes, solves most customization integration issues and provides the most general customization. Using listeners, as described in the Extension guidelines, also provides a good level of schema independence.