Working with WebSphere Commerce SOI services
Working with WebSphere Commerce services involves developing client libraries, new commands, and business logic. The Java Emitter Template (JET) is documented to assist you with these tasks.Note: WebSphere Commerce parses the top-level element in a Web service response. If your Web service requires more parsing, for example, the entire body, IBM recommends that we use a WebSphere Application Server JAX-RPC client.
- Use a client library
A client library is used to create a web service request to WebSphere Commerce. We can use a WebSphere Commerce services client library (for example, MemberFacadeClient) in a standard Java application.- Deploying the client library
The client library for a WebSphere Commerce service can be deployed in one of four possible environments:- WebSphere Commerce service commands
The service command is the entry point on the component facade where the Business Object Document (BOD) begins to be processed by the business logic.- Testing a WebSphere Commerce service with a unit test case
After you apply the WebSphere Commerce service module pattern, a MyServiceModule-UnitTest project is created as a place to put JUnit tests for the created services. JUnit is a simple and commonly used Java testing framework for unit tests.- Design patterns
To understand the WebSphere Commerce services architecture, as well as customization, there are two important design patterns: Design pattern for Get service implementation and Design pattern for Process, Change and Sync service implementation.- Client library for WebSphere Commerce services
The client library's simplifies and eliminate code on the client. The client library is a Java layer that helps Java applications integrate with your service architecture, without additional code generation. The client library already has support for session and authentication and provides Java-based clients a standardized mechanism to create the OAGIS SDO objects to represent service requests.- WebSphere Commerce services error information
When an exception occurs during the processing of a message, the OAGIS convention is to return a well-formed response message, with the error data embedded. The ChangeStatus element is used to store exception data; if the request was completed successfully, this area is not populated. Because only one action per message is supported, there can be only one error per message. For this reason the limitation of one ChangeStatus area per message is reasonable.- Client library exceptions
Client library exceptions consist of one or more instances of the ClientError object.