Introduction

IBM Sterling Selling and Fulfillment Suite (SSFS) is a state-of-the-art product for order and inventory management. SSFS allows you to control complex supply chain process, including source, aggregate, manage, and monitor orders across all channels; manage inventory, operations, and labor resources at customer warehouse facilities; and maintain complete visibility of process and inventory.

WebSphere Commerce is an industry leader in the e-commerce solution space. E-Commerce is no longer simply about presenting and selling products online. It is about delivering a smarter shopping experience that is seamless and integrated across all customer touch points. It is about providing a rich, relevant, personalized experience across multiple channels of your business. But ultimately, it is about doing more to leverage the power of your brand and present its value consistently to your customers.

Integrating WebSphere Commerce and SSFS side-by-side enables you to leverage the powerful capabilities of both products.

Using the principles of service-oriented architecture (SOA), side-by-side integration is implemented by using Enterprise Service Bus (ESB) technology. IBM provides three ESB implementation approaches: WebSphere ESB, WebSphere Message Broker (hereafter called Message Broker), and WebSphere DataPower SOA appliances. The choice of a particular ESB technology is determined by your specific needs, overall IT environment, and available skills.

Side-by-side integration of WebSphere Commerce and SSFS using WebSphere ESB is extensively documented in the WebSphere Commerce Information Center .

This article presents a sample side-by-side integration solution using Message Broker as the ESB technology.

Back to top

Sample application file

This article provides a Project Interchange archive file that you can download, WCToSSFSMediationModule.zip. It contains a fully-configured integration flows and messages sample, ready for you to deploy and run. You can import it into your workspace, explore the application, and then deploy and run it from the WebSphere Message Broker Toolkit.

Back to top

Overview

The important aspects of any ESB integration solution include the following tasks:

• Identify the service interfaces that you must connect to.
• Define or choose the correct transport mechanisms,
• Establish proper transformation flows between corresponding service interfaces.

The scenario described in this article connects order and inventory service interfaces of WebSphere Commerce with corresponding order and inventory service interfaces from SSFS. WebSphere Commerce service interfaces are defined using the Open Applications Group (OAGIS) message structure. SSFS uses a custom XML schema to represent data for SSFS services. Therefore, as part of the message flow in Message Broker, you must transform WebSphere Commerce data representation to SSFS data representation. The ESB layer establishes proper mapping between related concepts in WebSphere Commerce and SSFS.

This article assumes SOAP over HTTP connections on the WebSphere Commerce side and JMS connection on the SSFS side.

Back to top

Order submission

From the perspective of order and inventory management, the order submission scenario can be summarized as shown in Figure 1.

As shown in Figure 1, you must perform the following steps as part of this business scenario:

1. Add an item to the cart.
2. Check the inventory availability in the inventory tracking system.
3. Prepare the items in the cart for order submission.
4. Reserve the inventory in the inventory system.
5. Submit the order for the cart.
6. Kick off the order processing in the order management system.

As you can see, Steps 2, 4, and 6 require a message exchange between WebSphere Commerce and SSFS. This article will describe how the message flows for these operations are implemented in the Message Broker logic.

Conceptually, inventory-related and order-related message flows are separated. This is done to modularize the solution. From a business scenario perspective, messages from each flow can participate in the same or different business scenarios.

Inventory check availability flow

As discussed previously, for the purposes of this article, we assume that communication between WebSphere Commerce and Message Broker is accomplished though SOAP over HTTP protocol. Therefore, the request from WebSphere Commerce enters the message flow through the SOAPInput node.

In the beginning of the flow, you must determine which operation is specified in the message that Message Broker is receiving. This is done in the InventoryServices subflow and is based on detecting the operation name in the incoming message. Based on the operation name, the message is routed to the corresponding node for further processing. In the example, you only detect the inventory availability request and route corresponding messages to the FindInventory_SetFunctionName node. This is the JMS header node, where you must specify the corresponding operational function that is invoked on the SSFS side to process the inventory availability request (TargetFunctionName in the ApplicationProperties message field).

At this point, JMS header is added to the message, but it still has to transform the content of the message into the data structure that SSFS will understand. Before doing that, you need to store the WebSphere Commerce specific XPath expression, which you can later reuse in the message flow. This is done in the SetExpressionToLocalEnviornment node, where you temporarily store the XPath expression value in the local environment. The expression is in the form of an extended XPath notation, which is being used in the transformation process as a query language to retrieve parts of the incoming message tree based on certain selection criteria, such as the ItemID number.

Now you are ready to perform message data transformation. This is done in the GetInventoryAvailabilityToFindInventoryInput_Transformation node. The purpose of this node is to transform the WebSphere Commerce representation of the inventory availability request data into SSFS representation. Since both WebSphere Commerce and SSFS representations of this information use XML, you can achieve data transformation using XSL code.

In addition to transformation of the message payload, you also have to set the correlation JMS ID to make sure that you can match the request to SSFS with the corresponding response. To do that, use the SetSOAPReplyIdToJMSCorrelId node to set the JMS correlation ID to the SOAP ID of the original SOAP request from WebSphere Commerce. This approach ties the original SOAP request ID to the corresponding JMS message ID.

At this point, you are almost ready to send the request to SSFS, but you need to store the value of the XPath expression (which you already stored in the local environment) in a more persistent location, such as the WebSphere MQ queue. This is done in nodes JMS MQ Transform, SetMQProperties, and MQ Output. The JMS MQ Transform node adds MQMD headers to the message tree, which is then used by SetMQProperties to populate the MQMD Message ID property. The expression is also created in the XMLNSC domain in the message tree from the local environment. Once the Message ID and XMLNSC domain have been set, the MQ Output sends the message to the SSFSMediation_LocalStorage_D local queue.

When SSFS processes the request from WebSphere Commerce, it replies through the FindInventory JMS Input node (Figure 3). At this point, you have to perform three tasks:

1. Retrieve the value of the XPath expression needed by WebSphere Commerce (stored this value on a queue when the message was traveling from WebSphere Commerce to SSFS).
2. Transform the reply from SSFS XML format into an XML format that WebSphere Commerce understands.
3. Make sure that you properly match the SSFS response to the original request from WebSphere Commerce.

The first task is accomplished by retrieving the value of the expression from the local WebSphere MQ queue. Information related to the expression was stored under the key corresponding to the original SOAP Reply ID, which in our case, also corresponds to the JMS Correlation ID. The retrieval task is performed through the following nodes:

• SetJMSMsgIdToJMSCorrelId: This is needed to populate JMS message ID with the same value as the JMS correlation ID).
• JMS MQ Transform1: This casts the message from JMS to the MQ format.
• GetExpressionFromQueue: This is needed to actually retrieve the value from the queue.

The second task is achieved by using XSL transformation to transform the data representation from SSFS into WebSphere Commerce. This task is encapsulated in the XSL transformation node FindInventoryToShowInventoryAvailability_Transform.

For the third task, all you have to do is to set the SOAP ID of the SOAP reply message to the same value as the JMS ID. This is done in the PutSOAPReplyId node. After which, the reply is sent to WebSphere Commerce.

Inventory reservation flow

As you can see from Figure 4, the inventory reservation flow is similar to the inventory availability flow described above. A notable difference is the presence of the ActionCodeFilter node, which is used to differentiate between two actions: reserve inventory and cancel inventory reservation.

The actual transformation logic captured in the XSLT transformation node ProcessInventoryRequirementToReserveAvailableInventoryInput_Transformation is different, since you are transforming the message data required for different business functions.

The final difference between the inventory reservation flow and the inventory availability flow is that you do not need to store (and retrieve) the value of the expression, since the corresponding expression is not required to enable the proper data transformation between WebSphere Commerce and SSFS. All the other operations in this flow are essentially the same as the inventory availability flow.

Order processing flow

As mentioned above, order services are represented as a separate message flow. This is primarily done for logical separation and flexibility of deployment. Similar to inventory messages, order-related messages enter the Message Broker runtime using the SOAP Input node as shown in Figure 5.

You use the OrderServices subflow to segregate handling of different order-related functions. For the purposes of this sample, we only support the "process order" function. The message corresponding to this function is routed to the CreateOrder_SetFunctionName node, where the equivalent target function name required to invoke the proper operation at SSFS, is set (TargetFunctionName in the ApplicationProperties message field).

Similar to the inventory message flow, you use the SetSOAPReplyIdToJMSCorrelId node to ensure that the JMS Correlation ID is set to the same value as the original SOAP request ID from WebSphere Commerce.

Next, ensure that the action set in the message is "TransferOrder" and performs a corresponding XSL transformation in the ProcessOrderToCreateOrder_Transformation node to transform the data representation from WebSphere into the SSFS. Once the transformation is complete, the message is ready to be sent to SSFS through the JMS Output node.

As shown in Figure 6, the reply from SSFS has to be converted to order the acknowledgement message from the WebSphere Commerce side. This is done through the corresponding XSL logic in the CreateOrderToAcknowledgeOrder_Transformation node. Once the transformation is performed, ensure that the proper SOAP reply ID is set on the message. This is accomplished using the same approach as described in the Inventory reservation flow section.

Back to top

Importing and setting up the sample

To implement and run message flows described in this article, a certain configuration is required on WebSphere Commerce, SSFS, and Message Broker. The following sections will explore each of the individual configurations with respect to each of the product offerings. You must have the following installations in place before proceeding with the configuration steps:

• IBM WebSphere Message Broker Toolkit Version 7.0
• IBM DB2® Universal Database Version 9.7
• IBM WebSphere Application Server Version 7.0
• IBM WebSphere Commerce Version 7.0 with Feature Pack 3
• IBM Sterling Selling and Fulfillment Suite Version 9.1

Back to top

Configuring WebSphere Commerce for WebSphere Message Broker

The steps required to configure WebSphere Commerce are similar to the ones for WebSphere ESB-based integration. There is an exception in that instead of pointing to the WebSphere ESB mediation module, the message URL values are as follows:

External Inventory System:

http://<full_hostname>:<port_number>/webapp/wcs/component/inventory/
 services/InventoryServices

External Order System:

http://<full_hostname>:<port_number>/webapp/wcs/component/order/
 services/OrderServices

<full_hostname> is the full hostname (including domain), or the IP address of the system for which the WebSphere Message Broker flows are deployed. <port_number> is the HTTP port for which the queue manager's service listener is running. You can retrieve the port number using the following command on the Message Broker command console:

mqsireportproperties <broker_name> -e <execution_group> -o HTTPConnector 
 -n port

<broker_name> and <execution_group> are the names of the broker and execution groups for which the flows are deployed.

Back to top

Configuring SSFS for Message Broker

Similar to WebSphere Commerce, the configuration steps for SSFS in relation to Message Broker are also similar to WebSphere ESB-based integration, which is documented in the WebSphere Commerce Information Center. However, there are several things to consider when proceeding with the instructions:

1. Within the context of WebSphere ESB, given its web-service based connectivity capability and service-oriented integration built on top of WebSphere Application Server (hereafter called Application Server), it inherits much of the name spaces from Application Server, which can be used for looking up the name service using the bootstrap port number.
   
   In contrast to WebSphere ESB, Message Broker is not a web-service provider and does not have any running servers; rather, it uses message queues for communication. For external connection to be established, you need to create administered objects in the Java™ Naming and Directory Interface (JNDI) namespace such that the external JMS applications and SSFS can look up the administered objects to connect to WebSphere MQ and access MQ destinations to send or receive messages. For all inbound API calls over JMS defined in SSFS, the lines going from the first Generic JMS node to the API node, the value of some parameters need to be adjusted for Message Broker (as well as the environment that you have). In particular, you must update the Provider URL and Initial Context Factory to match the location of the binding files as well as the type of the context factory for which SSFS is configured. See the example in Table 1.

2. For all outbound API calls over JMS defined in SSFS (all the lines going from the API node to the Generic JMS node), a mechanism is used for SSFS to notify WebSphere Commerce of data changes in SSFS. You must adjust both the Provider URL and Initial Context Factory parameters within the Message Broker context. See the example in Table 2.

3. The Sterling Commerce Real-Time Availability Monitor (RTAM) is used to generate both the inventory availability dataload CSV files for batch updates, and SyncInventoryAvailability service requests for inventory adjustments. The same steps used to configure RTAM for WebSphere ESB is used for Message Broker. Before loading the rules for organization, you must set up the MadisonRoot organization to be an Inventory Organization to maintain its own inventory as follows:
   1. Go to Application Platform > Participant Modeling > Participant Setup.
   2. Search and go to the details of the MadisonRoot.
   3. In the organization details, go to Roles&Participation tab > Advanced Attributes tab > Inventory tab.
   4. Select Inventory Information Available and This Organization Is a inventory organization and click Save.

If you created the inventory items under the Default organization, you must reset all inventory details after performing the previous steps.

Back to top

Configuring WebSphere Message Broker

Message Broker is a lightweight, yet advanced integration broker under the IBM WebSphere product portfolio that is capable of integrating business data from a wide range of disparate applications across multiple environments regardless of platforms, protocols, or data formats. In other words, it enables application connectivity and business data transformation among heterogeneous systems with its advanced ESB capabilities.

The mandatory configuration steps needed for the Message Broker runtime to function properly as an ESB between WebSphere Commerce and SSFS are detailed in the following steps:

1. Create the WebSphere Message Broker Queue Manager.
2. Create the Broker and Execution Group.
3. Create the queues.
4. Set up and configure the JMS administered objects.

For more information about Message Broker, see the IBM Education Assistant for WebSphere Message Queue V7 or IBM Redbook: WebSphere Message Broker Basics.

Creating the WebSphere Message Broker Queue Manager

1. Launch the IBM WebSphere MQ Explorer.
2. Right-click on the Queue Managers folder and select New > Queue Manager.
3. In the Create Queue Manager wizard:
   1. Enter MB7QMGR as Queue Manager Name and click Next.
   2. In the next panel, proceed with the default settings by clicking Next.
   3. On the "Queue Manager Enter configuration options" panel, select the Create server-connection channel option as shown in Figure 7 and click Next. With the assumption that both WebSphere Commerce and SSFS are on separate machines, you must select this option to enable remote administration of the queue manager over TCP/IP.
      
      Figure 7. Creating the server-connection channel option
      
      
      
   4. On the Queue Manager Enter listener options panel, select the Create listener configured for TCP/IP option as shown in Figure 8 and enter the port number you want to use as the listener port. The default value is 1414. Click Next.
      
      Figure 8. Creating a listener
      
      
      
   5. Once the Message Broker queue manager MB7QMGR has been successfully created, select its Listeners as shown in Figure 9. Upon the successful creation of the queue manager MB7QMGR, go to MB7QMGR > Advanced > Listeners.
      
      Figure 9. Selecting listeners
      
      
      
   6. In the Listeners window to the right, right-click on the listener LISTENER.TCP and select Properties. Under the General properties to the left, modify the IP address field with the full hostname for which the listener is running on (Figure 10). It is name of the machine where Message Broker is installed and running.
      
      Figure 10. Properties for LISTENER.TCP
      
      
      
   7. Click Apply and then OK.

Creating the Broker and Execution Group

1. Launch the IBM WebSphere MQ Explorer.
2. Right-click on the Broker folder and select New > Local Broker.
3. In the Create Broker Wizard panel:
   1. Enter the value MB7BROKER as the New Broker Name as shown in Figure 11 and click Next.
      
      Figure 11. Entering the new Broker name
      
      
      
   2. In the next panel as shown in Figure 12, enter the name of the queue manager for which you created earlier (MB7QMGR). Leave everything else as default and click Finish. Note that on Windows®, you must have administrator access rights to create brokers by using the WebSphere Message Broker Toolkit or WebSphere Message Broker Explorer. When creating a new broker, you might be prompted to agree to the user of administrator rights, or be prompted to enter an administrator user ID and password.
      
      Figure 12. Creating a new broker
      
      
      

Creating the queues

1. Launch the IBM WebSphere MQ Explorer.
2. Right-click the Queues folder and select the option New > Local Queue as shown in Figure 13. For more information about the other queues, see WebSphere MQ queues.
   
   Figure 13. Launching the local queue creation wizard
   
   
   
3. On the Create a Local Queue panel, enter the name of the queue as shown in Figure 14. All other fields use the default settings. Click Finish. A total of four queues are created, each with a unique name. See Step 4 below for the queue names.
   
   Figure 14. Creating queues
   
   
   
4. Repeat Steps 1 to 3 above for each of the following queues:
   1. SSFSAPIsImport_SEND_D: Storage for request messages that are coming from WebSphere Commerce to SSFS.
   2. SSFSAPIsImport_RECEIVE_D: Storage for response messages that are coming from SSFS to WebSphere Commerce. Think of response messages as replies to those request messages stored in SSFSAPIsImport_SEND_D.
   3. SSFSAPIsImport_SEND_D: Storage for synchronization messages that are being initiated from SSFS to WebSphere Commerce. For example, a change in the inventory on the SSFS side must be synchronized with WebSphere Commerce.
   4. SSFSMediation_LocalStorage_D: A local storage queue used by Message Broker only for relaying message properties. For example, using the SOAPRelyId from the request flow to the reply flow.

Setting up and configuring JMS administered objects

Before any application can retrieve administered objects from a Java Naming and Directory Interface (JNDI), you must first create those administered objects with the corresponding configurations.

1. Launch the IBM WebSphere MQ Explorer.
2. In the WebSphere MQ Explorer Navigator panel to the left, right-click on JMS Administered Objects and select Add Initial Context as shown in Figure 15 to initiate the configuration process for the objects.
   
   Figure 15. Initiating the configuration process
   
   
   
3. In the Add Initial Context panel, set the following properties:
   1. Select the File system option as the JNDI namespace location.
   2. The "JNDI Service Provider Factory class" is set to the default value of com.sun.jndi.fscontext.RefFSContextFactory.
   3. Browse to the directory where you want to store the JNDI Namespace Location binding files as shown in Figure 16. For example, C:\Program Files (x86)\ibm\WebSphere MQ\MB_FileBindings. You specify the file system as the JNDI namespace location because the binding files are to be stored on the local file system.
      
      Figure 16. Connection details
      
      
      
   4. Click Next.
   5. Select the option Connect immediately on finish and click Finish.
   6. Upon completion, you see two directories, Connection Factories and Destinations, created under the JMS Administered Objects for each JNDI namespace location (see Figure 17).
      
      Figure 17. Two types of JMS administered objects in WebSphere MQ JMS
      
      
      
4. Right-click Connection Factories and select New > Connection Factory. Follow the GUI panels and set the following properties:
   1. On the "Enter the details of the connection factory" panel, set the Name field to SSFSAPIsImport_QCF with Messaging Provider set to the default of WebSphere MQ, as shown in Figure 18, and click Next.
      
      Figure 18. Creating a Connection Factory
      
      
      
   2. On the "Select the type of connection factory" panel, set the Type field to Queue Connection Factory as shown in Figure 19 and click Next.
      
      Figure 19. Specifying the type for the connection factory
      
      
      
   3. Set the Transport field to MQ Client as shown in Figure 20 and click Next.

      The option of Bindings does not work here because the transport can only be used if the JMS application (SSFS) that uses the connection factory is on the same computer as the queue manager. Given that the JMS application being used here is on a remote machine, MQ Client is the more suitable option.

      
      
      Figure 20. Setting the Transport field
      
      
      
   4. Use the default information provided in the "Enter the details of the object you want to create" panel and click Next.
   5. Under the General tab (Figure 21), double-check the properties you have set.
      
      Figure 21. Verifying all the values for each corresponding field
      
      
      
   6. Under the Connection tab, select the Base queue manager as shown in Figure 22. This is your default queue manager of MB7QMGR. Given the JMS application (SSFS) that uses the connection factory is on a remote machine, you must configure the default localhost value in the Connection list field to the actual hostname with its port number in parentheses in order for the JMS application to establish a connection. Leave the "Connect options" field as the default of Standard and click Finish.
      
      Figure 22. Establishing a connection
      
      
      
5. Right-click Destinations and select New > Destination. Follow the GUI panels and set the following properties for each of the queues you just created under the Create the Queues section (with the exception of the SSFSMediation_LocalStorage_D queue):
   1. Enter the queue name in the Name field as shown in Figure 23 and click Next.
      
      Figure 23. Creating the destination
      
      
      
   2. Use the default values in this panel and click Next.
   3. Under the General tab, select your default queue manager of MB7QMGR and enter the name of the queue in the Queue field as shown in Figure 24. Leave everything else as the default and click Finish.
      
      Figure 24. Specifying the name of the queue manager and the queue name in the General properties tab
      
      
      
   4. Repeat the above for Steps A to C for each of the following queues:
      • SSFSAPIsExport_RECEIVE_D
      • SSFSAPIsImport_RECEIVE_D
      • SSFSAPIsImport_SEND_D

      Note that the SSFSMediation_LocalStorage_D queue is missing from the above list because the remote JMS application does not use it. Its sole purpose is only for local storage.

For information about creating and deploying the BAR file, see the WebSphere Message Broker V7 Information Center.

Back to top

Conclusion

In this article, you learned that side-by-side integration of WebSphere Commerce and Sterling Selling and Fulfillment Suite resulted in a "one plus one equals five" effect, allowing you to leverage value from two state-of-the-art products. WebSphere Message Broker provided a reliable and highly scalable mechanism to enable this integration.

Back to top

Download

Information about download methods

Resources

Learn

• Distributed Order Management with Sterling Selling and Fulfillment Suite
  
  
• Installing, configuring and deploying: WebSphere Commerce
  
  
• Installing, configuring and deploying: Distributed Order Management with SSFS
  
  
• Installing, configuring and deploying: SSFS with RTAM
  
  
• Deploying a message flow application in WebSphere Message Broker Toolkit
  
  
• WebSphere MQ queues
  
  
• IBM Redbook: WebSphere Message Broker Basics
  
  
• developerWorks WebSphere Commerce zone
  
  

Discuss

• WebSphere Commerce discussion forum
  
  

About the authors

Cong Ren is a Software Developer working for IBM Software Group at the IBM Canada Lab in Toronto. He joined Sterling Integration development in 2011 and is involved with the overall integration effort between Sterling Commerce and WebSphere Commerce using various service integration technologies. In previous roles, he worked in WebSphere Application Server install, development, and test. He holds a Bachelor of Science degree in Computer Science from the University of Toronto.

James Tang has experience in many roles related to software development and the project life cycle. His responsibilities include gathering requirements and designing and implementing solutions. He is currently the Integration Development Manager for Sterling Commerce at the IBM Canada Lab in Toronto. The team's mission is to integrate IBM's Smarter Commerce portfolio to create the best of breed commerce solutions for our customers through incubation and prototypes.

Leho Nigul is a highly experienced Software Developer and Solution Architect at IBM Canada Lab. He has held multiple technical leadership and architecture roles while working on such products as WebSphere Commerce, WebSphere Application Server, WebSphere Portal, and Rational Application Developer. Leho holds a Bachelor of Computer Engineering degree from McGill University in Montreal, and a Master of Business Administration degree from Schulich School of Business in Toronto.

Barbara Wong is a Software Developer working at the IBM Canada Lab in Toronto. She joined Sterling Integration development in 2011 and is involved with the overall integration effort between Sterling and WebSphere Commerce using WebSphere Message Broker and WebSphere Enterprise Service Bus. In previous roles, she also worked in WebSphere Application Server Installation Factory development, WebSphere Commerce development, DB2 development, and System Verification Test and development. She holds a Bachelor of Mathematics degree from the University of Waterloo.

James Chung is a Software Developer working with the WebSphere Commerce and Sterling Integration development team at the IBM Canada Lab in Toronto.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Sample application file
• Overview
• Order submission
• Importing and setting up the sample
• Configuring WebSphere Commerce for WebSphere Message Broker
• Configuring SSFS for Message Broker
• Configuring WebSphere Message Broker
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Message Broker

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers