WebSphere Commerce as a service consumer
WebSphere Commerce Enhancements for version 6 provides features and integration scenarios that enable WebSphere Commerce to act as a service consumer, especially with order management systems (OMS) and enterprise resource planning systems (ERP). The outbound web service integration scenarios are described in Outbound web services integration scenarios.
Service invocation
When WebSphere Commerce acts as a service consumer, a component client API will be called from your task command. The client API will use the invocation service and the invocation service will require a deployed configuration file to determine how to communicate with the remote component. Each component will have a separate configuration file to configure the client API. Each store can also have a version of the configuration file that will take precedence over the default configuration. This allows the store to override some or the entire configuration without changing the default configuration.
For additional information, see Customizing the web service client invocation XML file
Messaging system
WebSphere Commerce uses its messaging subsystem to invoke web services on external systems. The client API will use a WebSphere Commerce message type, which will carry the service request to its destination over the specified transport. To see the mappings provided by default, see Outbound service message mappings enabled for service-oriented integration.
WebSphere Commerce Enhancements for version 6 provides two new Java Connectors to be used when WebSphere Commerce acts as a service consumer. Messages types can be assigned to a transport method for a site or store.
Web Service over HTTP Connector
This connector will send Web service requests over HTTP. The web service HTTP JCA connector will wrap the web service request message inside a SOAP envelope and allow the security credentials to be specified. The additional SOAP header information will be interaction specification properties associated with the web service JCA configuration. The JCA will set these properties when constructing the SOAP message. Additionally, this connector will throw exceptions when SOAP faults are returned as part of the service request.
As a feature of this particular connector, when an exception occurs when executing the request based on the connection properties, this connector will wait a specified period of time before allowing the same request to execute again. This prevents the backend system from being flooded with a series of requests when it is unavailable or unresponsive. Certain communication exceptions will be caught and cached and assigned a timeout value. When requests based on the same connection information are made, the cached exception will be thrown instead of executing the request. When the timeout expires, the request will be made as usual. The purpose of this is to provide the caller with an exception while trying to avoid making repeated requests to a backend system that currently is not responding.
Web Service over JMS Connector
The web service JMS JCA is an extension of the current JMS messaging JCA connector that will wrap the message inside a SOAP envelope and allow security credentials to be specified. This connector throws exceptions when SOAP faults are returned as part of the service request.
Further recommendations
For complex service definitions, such as OAGIS documents that utilize complex XSD features of the XML specification, the recommended approach for Web service client development is to leverage the Eclipse Modeling Framework (EMF) tooling and capabilities offered by the Rational Application Developer. A demonstration of using this alternative for developing Web service clients can be found on the WebSphere Developer Domain at the following URL:
http://www.ibm.com/developerworks/webservices/library/ws-emfsdo/
Enabling WebSphere Commerce as a service consumer
WebSphere Commerce can consume a business operation defined by an external system as a Web service. In this scenario, WebSphere Commerce acts as the service consumer to an external system.-
Customizing existing outbound service requests
With WebSphere Commerce, you can customize the existing outbound service requests, such as extending them to include additional user data. -
Create a Web service client API for WebSphere Commerce
For each component that is to consume external Web services, a client API is required to construct different request messages and then call the invocation service. The client API is essentially a Java utility class that contains construction code to create the appropriate message and send it. No business logic is performed in the client API. -
Customizing the Web service client invocation XML file
When WebSphere Commerce acts as a service consumer, a component client API will be called from your task command. The client API will use the invocation service and the invocation service will require a deployed configuration file to determine how to communicate with the remote component. Each component has a separate configuration file to configure the client API. Each store can also have a version of the configuration file that will take precedence over the default configuration. This allows the store to override some or the entire configuration without changing the default configuration. -
Service-oriented outbound integration points
Outbound service requests map to message types, and APIs invoked on the service provider. -
Outbound service interfaces
WebSphere Commerce Enhancements for version 6 provides the capability of integrating with external systems by calling their web services. Integration code has been provided to support integration scenarios with Enterprise Resource Planning (ERP) systems and Order Management Systems (OMS). Each service interface is described in terms of a request, response, message type, task command, and usage scenario:
Related concepts
Understanding the WebSphere Commerce Web service framework
WebSphere Commerce Web services with JSP pages
Related reference