The entire cloning process is facilitated by a pair of pipeline chains, which are defined in the /atg/commerce/commercepipeline.xml file:
The
initSubmittedOrderEditchain prepares the order for editing by creating the clone copy. The pipeline that will be executed is determined by the order’s state and theCloneEditManager.reconcileOrderChainspropertyThe
reconcileSubmittedOrderchain reconciles the changes with the original order when everything is committed by the agent. The pipeline that will be executed is determined by the order’s state and theCloneEditManager.property
reconcileOrderChain
These two chains are executed based on the state of the order. For example, different chains could be defined for handling orders in different states. Commerce Service Center provides one set of chains for handling all orders in a submitted state as defined by the submitted order states configured in CSRAgentTools. These two chains can be modified using standard configuration override techniques.
The CloneEditManager component contains the configuration for mapping order states to the chain names using the initializeEditChains and reconcileOrderChains properties. The following describes each link in the two chains.
Chain: initSubmittedOrderEdit – executed at the start of the edit process:
Link | Processor Component | Description |
|---|---|---|
|
| Performs the cloning of the order at the repository level and creates the Commerce objects from the newly created order item by calling |
|
| Validates the clone order after it has been created. |
|
| Initializes a state object based on the two orders, which is used to later reconcile the changes back to the original order. |
|
| Stores the original promotion counts in the clone edit state so that they can be compared to the promotion counts after applying updates. Changes in the promotion count are used to identify the promotions to consume. |
|
| Saves coupon tracking meta-data in the clone edit state so that it can be restored after applying updates in reconciliation. |
Chain: reconcileSubmittedOrder – execute to reconcile the changes with the original order:
Link | Processor Component | Description |
|---|---|---|
|
| Prepares the state object for reconciliation. |
|
| Copies the changes to the original order based on the contents of the clone order and information stored in the clone edit state object created in the initialization pipeline. |
|
| Executes the core commerce process that validates the original order for checkout. |
|
| Executes the core commerce process that removes empty shipping groups from the original order. |
|
| Executes the core commerce process that removes empty payment groups from the original order. |
|
| Executes the core commerce process that creates implied relationships between commerce objects in the original order. |
|
| Executes the core commerce process that sets the amount of the payment groups based on relationship in the original order. |
|
| Executes a process that adjusts for the authorized amounts of the payment groups in the original. For example, new payment groups are authorized and changed payment groups have their authorized amounts adjusted. |
|
| Restores the original coupon references on the pricing adjustments using the meta-data saved in the clone edit during initialization. |
|
| Updates the coupon references on the pricing adjustments for any new coupons that were claimed during the update. |
|
| Calls |
|
| Reconciles gift list quantities for changes made to the original order. |
|
| Consumes coupon promotions that may have been claimed and used during the edit process. |
|
| Sends the core commerce |
|
| Sends fulfillment JMS events for each change applied to the original order. |
|
| Sends agent audit events for each change made to the original order. |
Submitted Orders and Clone Editing
When an agent selects an order that is considered modifiable, Commerce Service Center makes a copy of that order when it is considered to be in a clone edit state.
Because the order is copied into a transient state for the edit process, the changes applied by initial pricing operations on the order are not immediately saved to the repository. They are only saved if the agent completes the post-submit checkout of the order.
