You cannot deploy modified versions of existing deployed cartridges with the same name and version - Design Studio always increments the version number by default. However, if you have small changes to make that do not include changes to the order template or data dictionary, you can override the existing cartridge.
For larger changes to a cartridge, including introducing new tasks, changing data types, or adding new orders, you should deploy a new version of the cartridge. Otherwise, you might encounter errors such as missing or extra nodes when running orders.
If orders are originating in an upstream system, they won't automatically be routed to the new cartridge. Upstream systems must be modified so that new orders specifically target the new version of the cartridge.
OSM performance can be impacted if you have many versions of a cartridge deployed at the same time. For example, you might experience slower Worklist response time. Factors which contribute to possible performance issues when you have multiple cartridge versions include the number of versions, the design complexity of your cartridges including the number of tasks in your orders, the number of OSM users, your hardware and so on.
In-progress orders for an existing cartridge are not impacted by the deployment of a new version of that cartridge, nor are they automatically migrated to the new version of the cartridge. For new orders to be created by default against the new version of the cartridge, the Default option (in the Project editor Properties tab) for the cartridge should be selected before it is deployed. Orders can be targeted to previous versions of a cartridge by specifying the version numbers in the order. See the discussion of the Project editor Properties Tab in the OSM Modeling Processes Online help for more details.
It is possible to send a revision order from a newer version of a cartridge against an in-flight order from an older version of the cartridge. The order will process only data that was contained in the original cartridge metadata.
XMLIE provides scripts to migrate orders from one cartridge version to another. For details, see the discussion on migrating orders in OSM System Administrator's Guide.
When an older cartridge version is no longer needed, consider removing it from OSM. You may wish to back up completed orders associated with the cartridge before undeploying it because the completed orders may be purged from the system.
To avoid purging orders from an old cartridge, you can create a different cartridge version for modeling changes, then create and process new orders with the new cartridge namespace and version. The old orders are processed with the old cartridge version. You can also disable the creation tasks of the old cartridge to ensure that no new orders are created with the old cartridge version.
If the OSM software is upgraded to a new version, all cartridges in use must be rebuilt using the updated SDK and redeployed. See the discussion on Upgrading OSM in OSM Installation Guide for details on upgrading cartridges when you upgrade to a new version of OSM.