1) We had a main cartridge that included among other things the one and only order along with the recognition rule, tasks, subprocesses, etc
2) At some point, we introduced two new order types that extended the main order. We also introduced two new recognition rules for the new orders, which would have a higher precedence than the main order's recognition rule. The new orders used the same creation task, query tasks, processes etc as the main order.
3) Several orders were submitted, and they were correctly "classified" to the new order types, as expected.
4) At some point, we decided that those changes should be reverted. So we removed the entities from the cartridge, we also purged from the database the orders that belonged to the new order types, and built and redeployed the cartridge.
5) After that, we could not submit any orders sucessfully. We kept getting an exception stating that no creation task could be found for the order.
6) In order to overcome this situation, we had to undeploy the cartridge (i.e. all our orders got purged), and redeploy it. This restored things back to normal.
Does anyone know if this behaviour is normal?
This happened to our DEV environment, so losing our orders was not a big deal. If, however, we have to remove entities from a cartridge deployed to production where losing orders is not an option, how would we be able to achieve it without compromising our functionality?
Any suggestions would be greatly appreciated.
Hi Pantelis it sounds like a bug to me.
In fact there is a real creation task in the deployed metadata which is different from the one that is presented by the design studio (which basically just defines the former task's data).
And its links to some other entities were probably damaged by the steps you applied.
I cannot say more without having access to your environment.
However as a general rule, I would suggest to avoid removing entities from a ctg or perhaps to deploy cartridges as a new version when you have removed entities.