Service Definition Framework

Synchronous calls from HCL Commerce to Sterling Order Management

For Synchronous calls from HCL Commerce to Sterling Order Management, HCL Commerce makes an outbound web service call to the SOAP servlet. This servlet contains an action.properties file that is used to map the Action name from theHCL Commerce request to the SDF service in Sterling Order Management. Sterling Order Management tries to identify the Action Name by looking at the node value of wsa:Action in the HCL Commerce request. If the value is null, then Sterling Order Management derives Action from the SOAPBOD Document Element name. After getting the Action Code, Sterling identifies the Sterling Order Management service to invoke for this action from the value defined in the action.properties file. This service converts the message from SOAP to XML API input.

The getCompleteOrderDetails call is the one exception to this rule. It is not a SOAP message – it is a direct API call to AuthOnlyServlet, passing input as expected by the Sterling API. For example, ProcessInventoryRequirement_ReserveInventory calls the SOAP servlet and invokes the service SCWC_SDF_reserveAvailableInventory, which is defined to call a sub-service. At a high level, this sub-service converts the message from HCL Commerce format to Sterling Order Management API format. The sub-service then replaces the values for key attributes defined in the ValueMaps file, calls the API, and runs conversion on the output of the API.

The following flow illustrates some of this process.

Asynchronous calls from HCL Commerce to Sterling Order Management

For asynchronous invocations from HCL Commerce to Sterling Order Management, HCL Commerce posts the message to a JMS queue. The transport WebSphere MQ must be activated in the HCL Commerce Administration Console. Set these WebSphere MQ parameter values as follows to identify which queues will send messages:

Table 1. WebSphere MQ Parameter Values

IBM MQ Parameter	Value
Error Queue	JMSErrorQueue
Factory	JMSQueueConnectionFactory
Inbound Queue	JMSSerialInboundQueue
Outbound Queue	JMSOutboundQueue

Sterling Order Management is an external order system, so the message type Message for external order system must be created. To send out a message by JMS queue, this message type must be assigned to the transport, WebSphere MQ. Configure this as follows:

After the messages are posted into a JMS queue, the integration server on the Sterling Order Management side picks up these messages up from the queue and calls the appropriate SDF service on the Sterling side.

For example, with Transfer Order, once the cart is submitted from HCL Commerce, a SOAP message is placed in a JMS queue. From there, the SCWC_SDF_createOrder integration server picks the message up from the JMS queue and calls SCWC_SDF_createOrderService, as shown in the next figure.

The SCWC_SDF_createOrderService shown next converts the message into Sterling Order Management createOrder API input XML format and invokes the API.

Asynchronous calls from Sterling Order Management to HCL Commerce

For asynchronous communication between Sterling Order Management and HCL Commerce, Sterling Order Management events are used to publish a message to a JMS queue. For example, the createOrder.OnSuccess event publishes a message to JMS Queue by calling the SCWC_SDF_createOrderOnSuccess service. This in turn calls the SCWC_SDF_createOrderOnSuccessService, as shown next:

The SCWC_SDF_createOrderOnSuccessService, converts the message to HCL Commerce expected input format:

Upon conversion, the message is placed in a JMS queue. Once the message is in the JMS queue, Sterling integration server is used to pick up the message and call the appropriate HCL Commerce service.

The server tab defines which integration server processes these messages:

The arguments tab on the API node configures the HCL Commerce service to invoke:

Synchronous calls from Sterling Order Management to HCL Commerce

Synchronous calls from Sterling Order Management to HCL Commerce are made using InvokeWebService component, which makes outbound web service calls using a SOAP client node. The next example shows SCWC_SDF_getItemPriceUE:

An additional aspect to all of the preceding examples is that the Direct Integration services are designed as two-part services, where the invocation and message translation occur in a sub-service, such as SCWC_SDF_getItemPriceUEService. The rationale and benefits of this design are explained in Components and parameters in the Service Definition Framework.