The Service-Oriented Architecture (SOA) is the current paradigm in which one type of software communicates with another software written in a different language and exchanges information. In a service-oriented design, we have a service provider that provides a particular service. Web service technology is not specific to SAP.

For a Web service, a Web Service Definition Language (WSDL) file exists that contains the necessary information required in calling the Web service in question, such as the input and the output parameters (that is, the interface). The information about the necessary input and output parameters for Web service call is specified using the WSDL. The WSDL and the SOAP and HTTP are universal concepts and therefore allow SAP integration with the outside world.

There is a registry called UDDI (acronym for Universal Description, Discovery, and Integration ) where the service provider may be registered and the necessary information about the service is stored. The caller or potential consumer may refer to the registry for information about the service. We may also have a direct binding between the service provider and the service caller using SOAP and HTTP. The necessary input is sent to the provider, which then returns the relevant results after the Web service execution back to the consumer.

In a service-oriented architecture (SOA) world, the service consumer and the service provider may use different technologies, and both of them do not need to worry about the technology used by the other. They communicate using SOAP over HTTP. A SAP system can call a Web service provided by a non-SAP system and vice versa. A Web service encapsulates a particular process and accepts input as well as provides output to the caller. The consumer may call the service to send input data into the specified format and receive the results. The technology used inside the service is not to be of concern to the consumer.

SAP allows you to both create, as well as consume Web services from the outside world. This chapter will take an approach from the SAP side—the creation and consumption of services. The wizard that quickly and easily creates Web service providers and consumers will also be discussed. We will start with the creation of a Web service using the Web service creation wizard and then cover the configuration of the Web service in question using the SOAMANAGER transaction. While defining a Web service, an endpoint is specified, which is the ABAP object used as the basis for the creation of the Web service. This could be a function module, a BAPI, an entire function group, or an XI message interface. We will use the existing objects (in our case, a function module) to generate or create a Web service. This approach is known as an Inside-Out approach in the chapter. The primary emphasis of this chapter will be on the Inside-Out approach.

In order to create a consumer program for calling a Web service, a consumer proxy has to be generated. It creates a link to the Web service that is to be consumed. During the generation of the proxy, a class is generated that encapsulates the process of communicating with the Web service provider and the formation of SOAP messages that are to be sent to the provider. Once you have generated a proxy (and then a logical port is created), the ABAP code may be written for calling the Web service and getting the desired results. We will cover recipes related to consumer proxy generation, creation of a logical port, and the coding related to service call.

For the sake of illustration, in this chapter we will create a Web service in our system and will generate a proxy for calling the same service from within the system (though practically the service consumer and provider will not be in the same system). All the recipes in this chapter are based on this service provider and consumer scenario.

A diagram showing the client service relationship of Web service consumer and provider is as follows: