Consuming a Web Service
Purpose
To create and configure a service consumer, you must first generate a consumer proxy. The consumer proxy encapsulates communication and takes over the control of technical processes. The consumer proxy is used to create a connection to the server of the Web service required. While the developer programs the business application, the technical part – for example, the automatic packing of calls into a SOAP message or the evaluation of incoming messages – is completed using the proxy.
It is not important to a service consumer which technology is used on the service provider side. It is possible to use Web Services from a non-SAP system, irrespective of the implementation behind it.
After proxy generation, you can call the service from a program.
Implementation Notes
Before you consume a Web service, you must first perform the steps described under the section Configuring the Web Service Runtime.
Features
Consuming an enterprise service comprises the following steps:
...
2. Configure a service consumer.
During proxy generation, all the objects required to call a Web service are created. This includes the logical ports as well. This is an SAP-specific concept for the configuration of runtime features for consumer proxies. Runtime features are features that must be configured in the runtime environment when the service consumer is activated. So, for example, the logical port contains the URL address to be used for calling the service.
For more information, refer to the section Configuring a Consumer Proxy (SOA manager) and Working with ServiceGroups.
3. Call a service from an application.
During proxy generation, a proxy class as well as data types for parameter transmission are generated.
Create a program and drag the consumer proxy using
Drag&Drop to the required position in the program.
The service can be used directly after the proxy has been generated, the
logical port has been configured, and the services from a program have been
called.
Using the outside-in approach, you develop the Web service in the Enterprise Services Repository. Choosing an interface pattern when modeling a service interface determines which programming model and which Web service processing type is to be used.
There are four different interface patterns. The following chapters are set up accordingly:
Consuming a Stateless Web Service
Consuming a Stateless Web Service (XI 3.0 compatible)
Consuming a Stateful Web Service
Consuming a TU&C/C Web Service
While the Stateless and TU&C/C interface patterns can be used with both synchronous and asynchronous communication, Stateful and Stateless (XI 3.0 compatible) interface patterns only support synchronous communication.
For more information, refer to: