Online shopping can be broken down into two major phases, the purchase process and the fulfillment process. The purchase process is everything that is done before checking out, while the fulfillment process begins after the checkout.

The transition from the purchase process to the fulfillment process occurs when the SubmitOrder message is sent out after a successful checkout. The successful delivery of this message signals the transfer of control and the beginning of the fulfillment process.

The SubmitOrder message is a JMS ObjectMessage that contains the serialized order object. The order is serialized so that fulfillment can be serviced by an entirely independent system.

Building the fulfillment system on top of JMS provides the flexibility of a distributed fulfillment system. For example, a site could contain products from various vendors that can be purchased through the same account. A large site might sell bikes from one vendor and books from another publisher. These orders would require different fulfillers because they would not be fulfilled from the same warehouse. The Purchase Process allows for multiple shipping groups and multiple payment methods. The Fulfillment Process then determines which shipping groups will be fulfilled by which fulfiller and forwards the requests to the relevant fulfillers.

The default implementation assumes that the Purchase Process and all the configured fulfillment systems share the same order repository (or database containing the order information). The architecture is designed to provide the flexibility to accommodate systems with various back-end requirements and fulfillment houses. JMS messages allow this flexibility during the communication between the different subsystems because it serves as an API between the different disparate components. JMS provides the flexibility of integrating with Oracle ATG Web Commerce’s fulfillment framework regardless of how and where your existing fulfillment system resides. If the design of your fulfillment system follows the basic pattern defined by Commerce, then extending the basic functionality to support your existing fulfillment system should be straightforward.

Flow of control defines which components have privileges to edit different parts of the order. The basic premise is that once a component has control over a part of the order, only this component should edit this part of the order. Commerce does not verify that a component has the privileges to edit a specific part of an order. Commerce does not perform this verification because if the system is distributed, orders might be modified with a different system.

Commerce also assumes that all changes to the order will be tracked using Modification objects that capture the type of change that occurred. For example, if an item was added to a shipping group, then a ModifyOrderNotification message is sent with its array of Modifications including a GenericAdd modification. See the Modification Class section for more details on modifications.

Commerce assumes that all the components in the system share the same repository. If not all components share the same repository, then ModifyOrder and ModifyOrderNotification messages can be sent into the vendor’s system.

Vendors are responsible for listening for modifications in their subsystems. These modifications might be different from the modifications that Commerce is listening for by default. Vendors might have to implement the various ModifyOrder requests needed to synchronize the local order repository with the vendor’s back-end systems. Vendors should follow the guidelines for modifying objects and sending out modifications that indicate the types of changes that have occurred. If these guidelines are followed, then it is possible to extend the various modification handlers to maintain accurate copies of the data in the databases.

The following list describes the control flow during the Order Fulfillment process. A diagram following this list illustrates the flow of JMS messages during this process.

  1. OrderFulfiller receives a SubmitOrder message containing a serialized copy of the order. The owner of the order object is the component that receives this message. By default, the OrderFulfiller receives this message.

  2. The OrderFulfiller passes control of the different components to the configured fulfillers using FulfillOrderFragments. In this example there is only one fulfiller, the HardgoodFulfiller.

    Note: The various fragments contain the shipping groups associated with the items in the fragment. All the shipping groups listed in the fragment are now controlled by the component receiving this message. In this example, the HardgoodFulfiller now controls the shipping groups.

  3. While the HardgoodFulfiller controls the shipping groups, all modifications to the shipping groups take place through the HardgoodFulfiller. It is important that no other component modifies these shipping groups while the HardgoodFulfiller controls the shipping groups. The HardgoodFulfiller could be running on a back-end system in a different environment. If other components need to make changes to the shipping groups, the ModifyOrder requests are forwarded to the HardgoodFulfiller. The HardgoodFulfiller is responsible for making the requested changes to the shipping groups while they are under its control.

    Note: All modifications are performed by fulfillers by calling pipeline chains. For more information, see the Processor Chains and the Pipeline Manager chapter.

  4. When the shipping groups are shipped, a ModifyOrderNotification message is sent. When this message is sent, the HardgoodFulfiller gives up control of the shipping groups within the order. Control is transferred back to the OrderFulfiller automatically if no one else has control until the complete fulfillment of the order. This follows the assumption in the pattern that the OrderFulfiller retains control until the order is complete.

  5. The OrderFulfiller receives the ModifyOrderNotification message. If the business rules allow payment to settle on first shipment, then the payment groups are charged with the cost of the items, shipment and taxes. Business rules can also specify that payment be settled upon the shipment of the last shipping group.

  6. After the order is settled, the OrderFulfiller changes its state to NO_PENDING_ACTION and no longer controls the order.

The following diagram provides an overview of the flow of the JMS messages during the Order Fulfillment process.

Note: By default, the system is set up with one HardGoodFullfiller. In this example, the system uses two HardGoodFullfillers.

This diagram described in preceding text

Note: The OrderFulfiller is the only class that has control over the payment groups and the only class that can modify the highest-level Order object.

The fulfillment system is designed to be a flexible implementation that is easily extensible. This flexibility allows for the different ways businesses handle their fulfillment. If the Commerce order fulfillment system is not appropriate for a site, it is easy to remove the Commerce order fulfillment framework. Remove the Commerce order fulfillment framework by not running a fulfillment server and having another component listen for the SubmitOrder message. The SubmitOrder should contain all the information necessary for the vendor to start the fulfillment process. See SubmitOrder Class for more information.

Note: Commerce supports scenarios where the fulfillment of certain shipping groups has no access to the database.

Copyright © 1997, 2013 Oracle and/or its affiliates. All rights reserved. Legal Notices