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:
CloneEditManager
This class provides some of the core configurations to the feature. It provides the API for executing the pipeline chains and performing call backs to the CloneEditHandlers
throughout the entire process.
Classes |
|
Subclass |
|
Component |
|
Configuration |
|
CloneEditHandler
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 CloneEditManager
and are executed at various points in the initialization and reconciliation processes.
Class |
|
Subclasses |
|
Components |
|
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 theCloneEditState
object. For example, this is where theCommerceItemHandler
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.
CloneEditState
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 |
|
Commerce Service Center stores this object in the window scoped CSROrderHolder
, which can be accessed using the getCloneEditState
API.
CSROrderHolder
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.
Classes |
|
Components |
|
CSRAgentTools
This class provides the more generic API used by the application. This includes the configuration for submitted order states and the API for determining if an order should used the cloning feature.
Classes |
|
Components |
|
CSRCommitOrderFormHandler
This form handler class provides the handlers for triggering the reconciliation process.
Classes |
|
Components |
|