Outside-In Development Approach
In the Outside-In approach, development of Service Interfaces (Inbound Service Interfaces and Outbound Service Interfaces) starts in the Enterprise Services Builder (ES Builder). In contrast to inside-out development (whereby a WSDL document is generated on the basis of an existing function and then published), the ES Builder creates the service implicitly as a WSDL document in the Enterprise Service Repository (ESR). The ESR is part of the SAP Process Integration (PI) or the SAP Process Orchestration (PO). Another possibility to create Service Interfaces is the Backend Repository.
Connected application systems can read these interfaces. Using the ABAP Proxy technology, a developer can create an ABAP Object that consists of one or more ABAP Methods. The name of the created Methods is identical to the name of the Operations in the Service Interfaces in the ESR.
Because development begins outside the application system, this approach is called Outside-In.
Modeling in the Back-end
The ABAP back-end supports modeling functions that are similar to those of the Java-based Enterprise Services Repository. It allows you to model data types, message types, and service interfaces directly in the ABAP development environment.
Note
Instead of "outside-in" and "inside-out", the SOA world commonly uses the following terms as well: "Contract-First" and "Code-First"; "Top-Down" and "Bottom-Up".
As a general guideline, you would use the inside-out approach if the objects are already there and you use the Web service for internal purposes only. Otherwise, you would usually model the objects. When modeling the Web services, the WSDL documents are cleaner and better to read for the outside world.
To create a web service using the Outside-In approach, follow this high level description:
Outside-In Procedure:
- Develop your Service Interface in the ESR.
- Generate a provider proxy.
While the service modeling takes place centrally in the ES Repository, the proxy generation and subsequent service implementation is done in a specific back-end. Before the corresponding Web service proxy is generated, the developer has to decide in which system the proxy is to be generated. Afterwards, he or she starts the proxy generation locally in this system. This transfers the entities from the ES Repository into the local system. The resulting proxies are stored in the back-end. The proxies can be used independent of of the ES Repository. The connection to the ES Repository is only required for generation, re-generation, and for checking the proxies against the ES Repository.
Call transaction SPROXY, select the inbound service interface, and choose Create Proxy from the context menu. Enter the name of a package.
The service definition is automatically generated during proxy generation.
After generation, the provider proxy contains methods for each service operation.
- Fill the operation with the required logic.
In the Propertiestab of the service interface, click the name of the provider class, and then specify the method name in order to get to the editor. You then implement the provider proxy.
- Create a runtime configuration for the provider proxy using the SOAMANAGER tool.
- Test your service in the Web Services Navigator (WSNavigator).
Select the service definition in the Object Navigator (Transaction SE80) and choose Start Web Service Navigator. Make sure that a connection to the Web Service Navigator has been set up. If the service has not yet been configured, a standard configuration is created before starting the Web Service Navigator. In this case, choose the appropriate pushbutton.
Outside-In Procedure:
- Develop your Service Interface in the ESR.
- Generate a provider proxy.
- Fill the operation with the required logic.
- Create a runtime configuration for the provider proxy using the SOAMANAGER tool.
- Test your service in the Web Services Navigator (WSNavigator).