Before you can deploy to the OSM run-time environment, you must determine which entities, libraries, and resources to include in the cartridge. Design Studio enables you to model multiple order types within a single project and deploy those order types to an OSM run-time environment within the context of a single project. For example, if you have defined a project with data to support the DSL services Add, Delete, and Modify for orders that come from 2 different sources (Siebel and Portal, for example), you can deploy the entire configuration to a run-time environment in one deployment cycle.
When packaging OSM cartridge projects, see the following topics:
When you combine multiple orders into a single project and deploy the cartridge to an OSM run-time environment, the OSM server combines the order data from each order into single master order template. Consequently, when packaging cartridges that contain multiple order types, the system automatically detects order data inconsistencies across order types and creates problem markers to identify the conflict. You must resolve all problem marker errors before you can deploy the cartridge.
For example, consider that two orders packaged in the same project both contain the ID data element. In Order 1, the ID data element is defined as a string (intended to be populated by a customer name and set of digits). In Order 2, the ID data element is defined as an integer (intended to be populated by a unique set of digits). In the run time environment, the OSM server has no ability to discern whether to treat the ID data element as a string data type or as an int data type. In this example, Design Studio would create a problem marker which you must resolve before deploying the cartridge.
Additionally, it is possible to introduce data inconsistencies when you have included the same data element in multiple orders, each defined with conflicting behaviors. For example, it is possible to model in Order 1 a Read Only behavior for the ID data element that evaluates to true when the field value equals 10001, while in Order 2, model a Read Only behavior for the ID data element that evaluates to true when the field value does not equal 10001. Because the OSM server is not able to resolve these types of conflicts, Design Studio detects them and forces you to resolve them prior to deployment.