Cloning Core Classes

The following describes a few of the core classes and components that implement the clone edit feature and are the likely places for applications to apply overrides and extensions.

Clone Edit Manager

The CloneEditManager class provides the API for executing the pipeline chains and performing call backs to the CloneEditHandlers throughout the entire process. First, the original order is cloned at the repository level and executed, and then the changes in the clone order are reconciled with the original order. Refer to the ATG Platform API Reference for detailed information. These handlers are accessed using the main DCS module.

Classes

atg.commerce.order.edit.CloneEditManager

Component

/atg/commerce/custsvc/returns

Configuration

cloneEditHandlers provide a list of CloneEditHandler components.intializeEditChains is a map of pipeline chains used in the initialization process. Keyed by order state.reconcileOrderChains is a map of pipeline chains used in the reconciliation process. Keyed by order state.

Clone Edit Handler

This abstract class is used for creating application classes that participate in the entire process through a callback interface. Components of this type are configured in the core Commerce CloneEditManager class and are executed at various points in the initialization and reconciliation processes. This handler is accessed through the DCS module.

CSR Clone Edit Handler

This class is used for extends the core Commerce CloneEditHandler class. Components of this type are configured in the CSRCloneEditManager and are executed at various points in the initialization and reconciliation processes. These handlers are accessed through the DCS-CSR module.

The CloneEditHandlers components are called during various points in the clone edit process:

Post-repository cloning.

The handlers are called just after the original order is cloned at the repository level. You can extend the cloneOrder method to customize cloning of data.

Verifying the clone.

The validateCloneOrder handlers are called after the clone order has been created and loaded.

Initializing the CloneEditState.

Once the clone order has been generated and verified, the initializeCloneEditState handlers are called to initialize any meta-data or objects that are needed for the CloneEditState object. For example, this is where the CommerceItemHandler maps the commerce items in the original order to those used in the clone order. These maps are used in the reconciliation process to identify those items that have been added, deleted or updated.

Reconciling the clone.

After all updates are completed on the clone order, the reconciliation process executes the handlers to perform reconciliation of the data between the clone and the original order. For example, the CommerceItemHandler determines which items were added, removed or updated and updates the original order accordingly.

Creating post-reconciliation process events.

After the reconciliation process is complete, the handlers are called to generate any fulfillment notification events for any changes they may have applied to the original order.

Clone Edit State

This class defines the state object used by the clone edit process. It provides access to the original and clone orders, as well as the API for adding and retrieving state information. It is created and returned by the initialization process and is required as input to the reconciliation process.

Classes

atg.commerce.order.edit.CloneEditState

Commerce Service Center stores this object in the window scoped CSROrderHolder, which can be accessed using the getCloneEditState API.

CSR Order Holder

This class defines the shopping cart used by an agent to modify customer orders. It provides an API for determining when the application is in clone edit mode, for storing the clone edit state object and for masking the current working order ID with the original order ID. The loadOrder(Order) API initiates the clone edit process for a given order and stores the clone edit state object.