Creating JMS Web Services : ATG Webservice

In addition to Web services that call Nucleus methods, the ATG platform enables you to create Web services that send JMS messages through Patch Bay. Many events in the ATG platform are triggered by JMS messages, so by calling a Web service that sends a JMS message, a client can start execution of various services and processes. In particular, scenario actions are triggered by JMS messages, so you can use Web service calls to invoke scenario actions remotely. For example, suppose a new user registers in some application, which invokes a Web service that sends the registration information to the ATG platform. The client application could then call a Web service that sends a JMS message of type atg.dps.Register into Patch Bay, thereby triggering a scenario action that (for instance) sends an e-mail message to the new user.

This chapter discusses how to create Web services that send JMS messages, and how to configure components to listen for these messages. For more information about JMS and Patch Bay

Using the JMS Message Web Service Wizard

To create a Web service that sends a JMS message, you use the Web Service Creation Wizard, just as you do for Web services that invoke Nucleus methods. On the first screen of the wizard, however, you click the JMS Message Web Service link (rather than the Component Method Web Service link). In this version of the wizard, you do not select a Nucleus component and method; instead, the key selections are the message type and the Patch Bay port name to use. The message type is the JMSType value for the message. This is a String, stored in the message’s header, that identifies the kind of message it is. For example, a message of JMSTypeatg.dps.PageVisit is sent when a site visitor displays a page.

For the port name, the wizard gives you two options, IndividualEvents and GlobalEvents. These are the standard ports where the Scenario Manager listens for scenario events.

The names of the classes generated by the wizard are based on the JMS message type of the message. For example, if you create a Web service that sends a message whose JMSType is atg.dps.PageVisit, the service implementation interface is named SendPageVisitSEI, and the service implementation class is named SendPageVisitSEIImpl.

Structure of a JMS Web Service

JMS Web services generated by the wizard are similar to Web services that call Nucleus methods. JMS services expose a Nucleus method, but it is always the receiveObjectMessage() method of the component /atg/dynamo/messaging/MessageImporter. This method receives the message object and forwards it into Patch Bay.

The receiveObjectMessage() method takes three parameters:

the message object

a String indicating the JMSType of the message

a String indicating the Patch Bay port name to use

The Web service call itself takes only a single argument, the message object. The JMSType and port name are hard-coded when you generate the Web service, and the service implementation class passes them (along with the message object supplied by the client) to the receiveObjectMessage() method. This simplifies the client’s task, because it does not need to be aware of either the JMSType or the port name.

For example, a Web service that sends a JMS message when a user views a page would be called like this:

public void sendPageVisit(atg.userprofiling.dms.PageVisitMessage a);

The service implementation class then calls the receiveObjectMessage() method like this:

messageImporter.receiveObjectMessage(a, "atg.dps.PageVisit",
 "IndividualEvents");

For information about calling Web services that send JMS messages from Java clients, see the Accessing ATG Web Services from Java Clients chapter. (Note that you cannot use the dynamic process described in that chapter for calling these Web services.) For information about calling Web services that send JMS messages from .NET clients,

Patch Bay Configuration

The /atg/dynamo/messaging/MessageImporter component, whose receiveObjectMessage() method is invoked by JMS Web services, is a Patch Bay message source. When a Web service invokes the method, the message passed to that method is sent either to the destination patchbay:/sqldms/MessageImporter/IndividualEvents or to patchbay:/sqldms/MessageImporter/CollectiveEvents, depending on the message type.

The standard Patch Bay configuration file, /atg/dynamo/messaging/dynamoMessagingSystem.xml, includes the necessary declarations for the message source and destinations:

<message-source>
 <nucleus-name>
 /atg/dynamo/messaging/MessageImporter
 </nucleus-name>

 <output-port>
 <port-name>
 IndividualEvents
 </port-name>
 <output-destination>
 <destination-name>
 patchbay:/sqldms/MessageImporter/IndividualEvents
 </destination-name>
 <destination-type>
 Topic
 </destination-type>
 </output-destination>
 </output-port>
 <output-port>
 <port-name>
 GlobalEvents
 </port-name>
 <output-destination>
 <destination-name>
 patchbay:/sqldms/MessageImporter/CollectiveEvents
 </destination-name>
 <destination-type>
 Queue
 </destination-type>
 </output-destination>
 </output-port>
</message-source>

The Scenario Manager is a message sink configured to receive messages from these destinations. This configuration occurs in two places:

In the standard Patch Bay configuration file, the Scenario Manager is configured to receive individual scenario events from the destination patchbay:/sqldms/MessageImporter/IndividualEvents.

In the /atg/dynamo/messaging/dynamoMessagingSystemDSSGlobal.xml file, the Scenario Manager is configured to receive global scenario events from the destination patchbay:/sqldms/MessageImporter/CollectiveEvents.

You can configure other message sinks to receive messages from the patchbay:/sqldms/MessageImporter/IndividualEvents destination by declaring them in the dynamoMessagingSystem.xml file. Note, however, that you cannot configure other sinks to receive messages from patchbay:/sqldms/MessageImporter/CollectiveEvents. This destination is a queue, used by global Scenario Managers only; adding sinks to this destination may interfere with the global Scenario Managers receiving messages. If you want another message sink to receive these messages, configure an additional destination for MessageImporter to send global scenario events to, and configure your sink to listen to that destination instead.

ATG Commerce and Session Backup

ATG Commerce adds several property values to the list of values that are written to the session backup server after every request. The property values that are added preserve the following for the user:

1.current and saved orders

2.active promotions

3.products currently being compared

4.event name for the current gift list

The properties that store this information are specified by layering on the following configuration file for the central configuration component, /atg/dynamo/Configuration.

# Add orders, promotions, and product comparisons to the list of
# items that are restored on session failover.

sessionBackupServerPropertyList+=\
     /atg/commerce/ShoppingCart.restorableOrders,\
     /atg/userprofiling/ProfileFailService.activePromotions,\
     /atg/commerce/catalog/comparison/ProductList.items,\
     /atg/commerce/gifts/GiftlistFormHandler.eventName

The configuration file is located at /<ATG9dir>/DCS/config/.

Adding Items to Shopping Carts :ATG

Adding One Item at a Time

The simplest way to add items to the current shopping cart is to add them one at a time. The following JSP code example serves as an illustration.

In the example, the user can select which SKU of the current product to add to the cart from a drop-down list. A ForEach servlet bean is used to iterate over the SKUs of the product and populate the drop-down list, which is associated with the catalogRefIds property of the CartModifierFormHandler. Additionally, the user can specify in a textbox a quantity of the selected SKU to add to the cart, which is associated with the quantity property of the CartModifierFormHandler.

When the user clicks the Add To Cart submit button, the form is processed, the properties of CartModifierFormHandler are set, and the handleAddItemToOrder method of CartModifierFormHandler is invoked. The handleAddItemToOrder method adds the quantity (specified in CartModifierFormHandler.quantity) of the selected SKU (specified in CartModifierFormHandler.catalogRefIds and identified by repository ID) to the current Order and then reprices the Order.

<dsp:importbean
bean="/atg/commerce/order/purchase/CartModifierFormHandler"/>
<dsp:importbean bean="/atg/dynamo/droplet/ForEach"/>

<%--Create a form for user to select a SKU and add it to his/her cart:--%>
<dsp:getvalueof id="form10" bean="/OriginatingRequest.requestURI"
idtype="java.lang.String">
<dsp:form action="<%=form10%>" method="post">

<%--Store this product's ID in the Form Handler: --%>
<dsp:input bean="CartModifierFormHandler.ProductId"
paramvalue="Product.repositoryId" type="hidden"/>

<%--set id param so that the Navigator won't get messed up in case of an
error that makes us return to this page.--%>
<input value='<dsp:valueof param="Product.repositoryId"/>' type="hidden"
name="id">

 <table cellpadding=0  cellspacing=0 border=0>
   <tr><td class=box-top-store>Add to Cart</td></tr>
   <tr><td class=box>

<%--Display any errors that have been generated during Cart
        operations:--%>
       <dsp:include
page="../../common/DisplayCartModifierFormHandlerErrors.jsp"
flush="true"></dsp:include>

       Add

<%--Textbox with QTY the user wants to order: --%>
       <dsp:input bean="CartModifierFormHandler.quantity" size="4"
value="1" type="text"/>

<%--Create a dropdown list with all SKUs in the Product.
        Store the selected SKU's id in the form handler: --%>
       <dsp:select bean="CartModifierFormHandler.catalogRefIds">

<%--For each of the SKUs in this Product, add the SKU to the
        dropdown list:--%>
         <dsp:droplet name="ForEach">
           <dsp:param param="Product.childSKUs" name="array"/>
           <dsp:param value="Sku" name="elementName"/>
           <dsp:param value="skuIndex" name="indexName"/>
           <dsp:oparam name="output">

<%--This is the ID to store if this SKU is selected in
            dropdown:--%>
             <dsp:getvalueof id="option73" param="Sku.repositoryID"
idtype="java.lang.String">
<dsp:option value="<%=option73%>"/>
</dsp:getvalueof>

<%--Display the SKU's display name in the dropdown
            list:--%>
             <dsp:valueof param="Sku.displayName"/>
           </dsp:oparam>
         </dsp:droplet>
<%--ForEach SKU droplet--%>
       </dsp:select>
       <br>


<%-- ADD TO CART BUTTON: Adds this SKU to the Order--%>
       <dsp:input bean="CartModifierFormHandler.addItemToOrder"
value="Add to Cart" type="submit"/>

<%-- Go to this URL if NO errors are found during the ADD TO
CART button processing:--%>
       <dsp:input bean="CartModifierFormHandler.addItemToOrderSuccessURL"
value="/checkout/cart.jsp" type="hidden"/>
     </td>
   </tr>
 </table>
</dsp:form></dsp:getvalueof>



Note : if you’ve installed ATG Business Commerce, you can also refer to AddToCart.jsp in the Motorprise reference application for a similar JSP code example. AddToCart.jsp is embedded into product.jsp to enable the user to add a quantity of the displayed SKU to the user’s shopping cart. You can access both AddToCart.jsp and product.jsp at <ATG2007.3dir>\MotorpriseJSP\j2ee-apps\motorprise\web-app\en\catalog\. You can also open these pages in the ACC’s Document Editor via the Pages and Components>J2EE Pages task area.

Adding Multiple Items at Once

You can create pages that allow users to add multiple items to the current shopping cart in a single form submission. The items can refer to different products, different SKUs, and have different quantities. The CartModifierFormHandler contains an items property that allows you to set per-item property values.

The following JSP code example illustrates adding multiple items for more than one SKU for a single product. In the example, the user can specify in a textbox a different quantity for each SKU to add to the cart. There are hidden input fields for the product ID and SKUs. Each product ID, SKU, and quantity textbox is associated with a subproperty of one element in the CartModifierFormHandler.items array.

When the user clicks the Add To Cart submit button, the form is processed, the properties of CartModifierFormHandler are set, and the handleAddItemToOrder method of CartModifierFormHandler is invoked. The handleAddItemToOrder method iterates through the CartModifierFormHandler.items elements and adds an item for each element with a non-zero quantity, using that element’s productId and catalogRefId for the new item.

<dsp:importbean
bean="/atg/commerce/order/purchase/CartModifierFormHandler"/>
<dsp:importbean bean="/atg/dynamo/droplet/ForEach"/>
<dsp:form action="display_product.jsp" method="post">
<input name="id" type="hidden" value='<dsp:valueof
param="product.repositoryId"/>'>
<dsp:input bean="CartModifierFormHandler.addItemToOrderSuccessURL"
type="hidden" value="shoppingcart.jsp"/>
<table border=1>
<tr>
<td>SKU</td>
<td>Quantity</td>
</tr>
<dsp:droplet name="ForEach">
  <dsp:param name="array" param="product.childSKUs"/>
  <dsp:param name="elementName" value="sku"/>
  <dsp:param name="indexName" value="skuIndex"/>
  <dsp:oparam name="outputStart">
    <dsp:input bean="CartModifierFormHandler.addItemCount"
paramvalue="size" type="hidden"/>
  </dsp:oparam>
  <dsp:oparam name="output">
    <tr>
    <td><dsp:valueof param="sku.displayName"/></td>
    <td>
      <dsp:input
bean="CartModifierFormHandler.items[param:skuIndex].quantity" size="4"
type="text" value="0"/>
      <dsp:input
bean="CartModifierFormHandler.items[param:skuIndex].catalogRefId"
paramvalue="sku.repositoryId" type="hidden"/>
      <dsp:input
bean="CartModifierFormHandler.items[param:skuIndex].productId"
paramvalue="product.repositoryId" type="hidden"/>
    </td>
    </tr>
  </dsp:oparam>

</dsp:droplet>
</table>
<BR>
<dsp:input bean="CartModifierFormHandler.addItemToOrder" type="submit"
value="Add To Cart"/>
</dsp:form>


The CartModifierFormHandler must be told how many elements to allocate for the items array. This is done by setting the CartModifierFormHandler.addItemCount property. In the preceding example, addItemCount is set to the number of SKUs defined for the product in a hidden input field . This technique works in the example because all of the CartModifierFormHandler.items input fields have explicit value or paramvalue attributes.

The next code fragment illustrates a more complex technique for setting CartModifierFormHandler.addItemCount. This technique is appropriate if you want to preserve a user’s input when a page is redisplayed because of a form submission error. The dsp:setvalue tag is not executed if the page is redisplayed.

<dsp:droplet name="/atg/dynamo/droplet/Switch">
  <dsp:param name="value" bean="CartModifierFormHandler.addItemCount"/>
  <dsp:oparam name="0">
    <dsp:setvalue bean="CartModifierFormHandler.addItemCount" value="5"/>
  </dsp:oparam>
</dsp:droplet>
<dsp:input bean="CartModifierFormHandler.addItemCount" value="5"
type="hidden"/>

Overriding the Default Commerce Item Type

By default, ATG Commerce supports three types of commerce items. One corresponds to regular SKUs. The other two correspond to configurable SKUs and their subproperties in the ATG Commerce Catalog Your site may support additional custom commerce item types
The commerceItemType property of CartModifierFormHandler determines what type of commerce item is created by addItemToOrder. Normally, commerceItemType is set to “default.” You can specify a different commerce item type in the CartModifierFormHandler configuration file or in a form input field. If you add multiple items in a single form submission, you can override the CartModifierFormHandler.commerceItemType setting for an individual item by including a hidden input field to set CartModifierFormHandler.items[n].commerceItemType.

Values for commerceItemType must match keys in /atg/commerce/order/OrderTools.commerceItemTypeClassMap.

Handling Custom Commerce Item Properties

The CartModifierFormHandler.addItemToOrder method has built-in support for some types of commerce item extensions. If your site has extended commerce items with primitive data type properties, you can supply values for those properties by associating form fields with the CartModifierFormHandler.value Dictionary.

For example, suppose your site has extended commerce items to support monograms, and the custom properties are named monogram and style. The following JSP code example illustrates how to handle user input for monograms without making any CartModifierFormHandler changes.

<b>Monogram Options</b><br>
Initials / Text: <dsp:input bean="CartModifierFormHandler.value.monogram"
size="20" type="text"/><br>
Style: <dsp:select bean="CartModifierFormHandler.value.style">
    <dsp:option value="Block"/>Block
    <dsp:option value="Diamond"/>Diamond
    <dsp:option value="Panel"/>Panel
    <dsp:option value="Stagger"/>Stagger
    <dsp:option value="Script"/>Script
 </dsp:select><br>

If you add multiple items in a single form submission, you can supply different custom property values for each item via the value Dictionary in each CartModifierFormHandler.items array element. Continuing with the preceding example, you could specify a single item’s monogram text as:

Initials / Text: <dsp:input
bean="CartModifierFormHandler.items[0].value.monogram" size="20"
type="text"/><br>

If you add multiple items in a single form submission and you want to supply the same custom property values for all or most of the items, you can use CartModifierFormHandler.value for the common values and CartModifierFormHandler.items[n].value for special cases. If a property name appears in both the common Dictionary and an individual item’s Dictionary, addItemToOrder uses the individual item’s value.

Note that the value Dictionary cannot be used for standard commerce item properties, such as quantity and catalogRefId.

Creating and Retrieving Shopping Carts : ATG

As previously mentioned in this chapter, the ShoppingCart component stores a user’s current and saved shopping carts. You can use the ShoppingCart component’s properties and handle methods to create a new shopping cart or retrieve one of the user’s saved shopping carts and make it the user’s current shopping cart.


The following JSP example illustrates how to create and retrieve shopping carts. In the example, the ShoppingCart.savedEmpty property is checked to determine whether the current user has any saved shopping carts. If the user doesn’t have any saved shopping carts, the user is given the option to create one. If the user has saved shopping carts, the user is given the option to select one of the saved shopping carts to either delete or make the current shopping cart, to delete all of the saved shopping carts, or to create a new shopping cart.


<dsp:importbean bean="/atg/commerce/ShoppingCart"/>

<dsp:form action="shoppingcart.jsp" method="post">

 <dsp:droplet name="/atg/dynamo/droplet/Switch">
   <dsp:param bean="ShoppingCart.savedEmpty" name="value"/>

   <dsp:oparam name="true">
     <!-- since there are no saved carts, we cannot switch to another so
          we only give them the option to create a new cart -->
     <dsp:input bean="ShoppingCart.create" value="Create" type="submit"/>
another shopping cart
   </dsp:oparam>

   <dsp:oparam name="false">
     <!-- We have other shopping carts, so let them do everything -->
     Shopping Cart <dsp:select bean="ShoppingCart.handlerOrderId">
     <dsp:droplet name="ForEach">
       <dsp:param bean="ShoppingCart.saved" name="array"/>
       <dsp:param value="savedcart" name="elementName"/>
       <dsp:oparam name="output">
         <dsp:getvalueof id="option26" param="savedcart.id"
idtype="java.lang.String">
<dsp:option value="<%=option26%>"/>
</dsp:getvalueof><dsp:valueof param="savedcart.id"/>
       </dsp:oparam>
     </dsp:droplet>
     </dsp:select>:
  <dsp:input bean="ShoppingCart.switch" value="Switch" type="submit"/> to,
  <dsp:input bean="ShoppingCart.delete" value="Delete" type="submit"/> or
  <dsp:input bean="ShoppingCart.create" value="Create" type="submit"/>
       another shopping cart.<BR>
     <dsp:input bean="ShoppingCart.deleteAll"
value="Delete All Shopping Carts" type="submit"/>
   </dsp:oparam>

 </dsp:droplet>

</dsp:form>

Purchase Process Services : ATG

ATG Commerce enables you to build sites that support simple or complex purchasing processes. A simple
purchase process might provide customers with a single shopping cart, and enable customers to
purchase products using a single payment method and to ship those products to a single location. In
contrast, a more complex purchase process might include multiple shopping carts, payment methods,
and shipping locations. You can use ATG Commerce to customize a purchase process that fills all the
requirements of your sites.

This post includes information on the following purchase process services:

Loading Orders
Describes the process involved in loading an Order from the Order Repository.
Includes information on how the purchase process manages refreshing Orders.

Modifying Orders
Describes how to modify an Order using the catalogRefId of a CommerceItem or
the ID of a ShippingGroupCommerceItemRelationship. Includes information on
adding items to an Order, removing items from an Order, and modifying item
quantities in an Order.

Repricing Orders
Describes how to reprice and update an Order using the RepriceOrderDroplet
servlet bean.

Saving Orders
Describes the process involved in saving an Order to the Order Repository.

Canceling Orders
Describes the process involved in deleting an Order from the user’s shopping cart.

Checking Out Orders
Describes the process involved in preparing a simple or complex Order for checkout,
submitting the Order for checkout, and actually checking out the Order.

Processing Payment of Orders
Describes how payment of Orders is processed. Also describes how to extend the
system to support new payment operations and payment methods.

Scheduling Recurring Orders
Describes how to create recurring Orders that automatically submit themselves on a
schedule.

Setting Restrictions on Orders
Describes how to set restrictions on placing Orders.

Tracking the Shopping Process
Describes how to track stages an Order goes through in the purchase process.

Troubleshooting Order Problems
Provides important information if you have modified the OrderManager and are now
experiencing problems with orders.

Handling Returned Items
Describes how the purchase process handles returned items.

Extending the ATG Commerce Form Handlers

Describes how the ATG Commerce form handlers manage transactions. Also provides
information to assist you when extending them.

Base Commerce Classes and Interfaces : ATG

The base commerce classes and interfaces are the core objects that are used throughout ATG Commerce. These objects store the data that represent shopping carts, items to be purchased, shipping information, pricing information, and payment information. All the individual parts of ATG Commerce use these classes.

The ATG Commerce class hierarchy is divided into classes and interfaces. The interfaces provide access to the data in the objects in a way that frees it from the underlying implementation. The interfaces are described below. For information on how all the classes and interfaces are related, refer to the Purchase Process Class Diagrams section.

Interface:

Order:

The Order interface represents the delivery and payment information for a collection of items. An Order contains CommerceItems, ShippingGroups, PaymentGroups, and Relationships.

CommerceItem:

The CommerceItem interface represents information about a product to be purchased. A CommerceItem contains the SKU (also called the catalogRefId) and the quantity of the item purchased.

ShippingGroup:

The ShippingGroup interface contains information about the delivery of a collection of CommerceItem objects. A ShippingGroup could contain a physical delivery address.


PaymentGroup

The PaymentGroup interface contains payment information, shipping costs, and tax information for each item or the entire Order. This includes information such as a credit card number, an expiration date, and the amount to be charged.

Relationship   

The Relationship interface represents an association between two or more of the commerce objects listed above, such as the relationship between a CommerceItem and a ShippingGroup.

It is important to understand the concept of relationships, although they are usually hidden from the ATG Commerce user. The commerce-specific interfaces that extend Relationship are CommerceItemRelationship, ShippingGroupRelationship, PaymentGroupRelationship, and OrderRelationship. For more information, see the Using Relationship Objects section

HandlingInstruction:

The HandlingInstruction interface describes special handling for a CommerceItem within a given ShippingGroup. Gift wrapping is an example of HandlingInstruction.


The following types of classes implement the interfaces described above:

    Order Classes

    Item Classes

    Shipping Classes

    Payment Classes

    Relationship Classes

    Handling Classes


Order Classes:

OrderImpl:

This class implements Order. It contains data structures for managing collections of other commerce objects. It manages collections of CommerceItem, ShippingGroup, PaymentGroup, and Relationship objects.

Note1: Order equality is determined by comparing the orderId, the lastModified time, and transient properties.

Note2: If you write any new code that modifies the Order object, make sure the code synchronizes on the Order object before it is modified.


Item Classes:

CommerceItemImpl:

This class implements CommerceItem. It stores the data about a specific item in an Order.


Shipping Classes

ShippingGroupImpl:

This class implements ShippingGroup. It stores the data describing where and how to ship CommerceItems, as well as the Relationships to items in the shipping group. This class provides no functionality itself; it is used through the HardgoodShippingGroup and ElectronicShippingGroup subclasses (described below).


HardgoodShippingGroup:

This class implements ShippingGroup and extends ShippingGroupImpl. In addition to storing inherited data, it stores information about how the CommerceItems are to be shipped to a physical street address, such as the carrier and postal address.


ElectronicShippingGroup


This class implements ShippingGroup and extends ShippingGroupImpl. In addition to storing inherited data, it stores information about how CommerceItems are to be delivered electronically, such as an e-mail address.


Payment Classes:


PaymentGroupImpl:


This class implements PaymentGroup. It stores the payment information for CommerceItems, shipping costs, and tax. It also can contain Relationships to those items, shipping costs, or tax costs in the PaymentGroup. This class provides no functionality itself, but is used through the CreditCard and GiftCertificate subclasses (described below in this table).


CreditCard:

This class implements PaymentGroup and extends PaymentGroupImpl. In addition to storing inherited data, it stores information about how CommerceItems, shipping costs, and tax costs are paid for using a credit card.


GiftCertificate:   

This class implements PaymentGroup and extends PaymentGroupImpl. In addition to storing inherited data, it stores information about how CommerceItems, shipping costs, and tax costs are paid for using a gift certificate.


StoreCredit:

This class implements PaymentGroup and extends PaymentGroupImpl. In addition to storing inherited data, it stores information about how CommerceItems, shipping costs, and tax costs are paid for using a store credit.


Relationship Classes:


ShippingGroupCommerceItemRelationship:

When this Relationship is added to a ShippingGroup and CommerceItem, the CommerceItem is shipped using the information in the ShippingGroup. This Relationship object itself contains data such as the quantity to be shipped.

PaymentGroupCommerceItemRelationship:

When this Relationship is added to a PaymentGroup and CommerceItem, the CommerceItem is paid for using the information in the PaymentGroup. This Relationship object itself contains data such as the quantity of the item to be paid for using the PaymentGroup

PaymentGroupShippingGroupRelationship:


When this Relationship is added to a PaymentGroup and ShippingGroup, the shipping cost is paid for using the information in the PaymentGroup. This Relationship object itself contains data such as the amount of the shipping cost to be paid for using the PaymentGroup.


PaymentGroupOrderRelationship

When this Relationship is added to a PaymentGroup and Order, the tax cost or order cost is paid for using the information in the PaymentGroup. This Relationship object itself contains data such as the amount of the tax cost to be paid for using the PaymentGroup.



Handling Classes:


HandlingInstructionImpl   

This class implements HandlingInstruction. It contains a ShippingGroup ID, CommerceItem ID, and quantity, as well as data about what quantity of CommerceItems in which ShippingGroups need special handling. This class provides no functionality itself, but should be used through a subclass.


GiftlistHandlingInstruction

This class implements HandlingInstruction and extends HandlingInstructionImpl. In addition to storing all the basic data that it inherits, it also stores data about which CommerceItems in the Order were added from a gift list.