The following section answers some commonly asked questions about the fulfillment framework.
Question: Why does Oracle ATG Web Commerce only use durable topics? Are not some messages sent to only one component that might be listening?
Answer: Topics are used because various subsystems might be interested in the message being sent. Examples of this include the
ModifyOrderNotification
message. It can be sent by any of the components in the system. TheOrderFulfiller
and theOrderChangeHandler
components both listen for this message but each does something different with it.OrderFulfiller
might determine that it now has control of the shipping group whose modifications are included in theModifyOrderNotification
message. TheOrderChangeHandler
might choose to send some other message as an event into another subsystem.Question: Where do we deal with Payment groups? When do we charge?
Answer: The
OrderFulfiller
module handles payment groups. The default implementation charges the whole order either at the time of the order’s first shipment or at the time of the order’s last shipment. This is configurable by changing the state of theSettleOnFirstShipment
property in theOrderFulfiller
to true or false as is needed by the business rules.Question: Why does Commerce use Java Messaging Service (JMS)?
Answer: JMS allows you to build a distributed system that enables disparate subsystems to handle fulfillment for various parts of the fulfillment process. JMS and messaging allows you to abstract out all the connections and gives you the flexibility to adapt your existing systems to the Commerce system. For example, the
OrderFulfiller
system might be located on the same set of machines in the site hosting facility. TheHardgoodFulfiller
might be based in some other set of headquarters. The actual warehouse that does the shipping might be in another location. If the warehouse receives an e-mail when a shipping group is submitted, then a service can listen on the JMS message indicating that the shipping group is to be shipped. An e-mail can be constructed from the contents of the message.Question: What are modification objects? What purpose do they serve?
Answer: The Modification object is an abstraction that tries to capture the various ways in which changes can occur to the order. There are several types of modifications: add, remove, or update. Modifications can be targeted and therefore can modify shipping groups, payment groups, orders or relationships. Modifications contain a status field indicating whether the modification was successful or a failure.
This abstraction allows the system the flexibility to interface with existing legacy or distributed systems. A disparate system can construct an array of Modifications that will capture the types of changes that it is requesting or the modifications it already performed.
Refer to the sections on ModifyOrder Class and ModifyOrderNotification Class for more information.
Question: How do scenarios find out about what is going on in the fulfillment system?
The scenario engine receives messages that are sent during the fulfillment process. Those messages are documented in the Inventory JMS Messages section.
The events contain the profile and the information needed for performing an action on those events. For example, the
ShippingGroupShipped
event contains the profile, the order and the shipping group that was shipped. This allows the scenario writer to create an action that sends an e-mail to the user (the profile) with the order information (from the order) and the details of the shipping group that was shipped (the shipping group). For more information, refer to the Order Fulfillment Events section.Question: How do I change the behavior of
ModifyOrder
messages?The
ModificationHandler
class deals with all theModifyOrder
messages. Both theOrderFulfiller
and theHardgoodFulfiller
have their own versions of those handler classes calledOrderFulfillerModificationHandler
and theHardgoodFulfillerModificationHandler
. The class contains two methodshandleModifyOrder
andhandleModifyOrderNotification
.To change the behavior of one of those two handling methods, override the method if you extended the existing
OrderFulfillerModificationHandler
orHardgoodFulfillerModificationHandler
classes. Otherwise, a new class implementing theModificationHandler
interface should be written and configured for theOrderFulfiller
orHardgoodFulfiller
.Question: How do I change the behavior of
ModifyOrderNotification
messages?Answer: See the answer for changing the handling of the
ModifyOrder
message in the previous question.Question: How do we deal with the Modification IDs? Who is generating them? How do we guarantee the uniqueness?
Answer: Modification IDs are generated using the ID generator. The combination of the message source and message ID need to be unique to allow external systems to track the various messages in the system.