Enterprise Services
Enterprise Services are highly-integrated Web services (based on open standards like WSDL, XML, UDDI and SOAP etc.) that are implemented by using some sort of underlying technology or vendor product. They are encapsulated with business logic representing actions against data entities that have scope across application domains and can be reassembled quickly to implement new innovative Business Services. Enterprise Services thus allows implementation of cost effective business processes in a timely manner to meet changing business requirements.
There are times where we need to enhance a standard Enterprise Services or create a Custom Enterprise Service to accommodate our business requirements. In this weblog we will have look into the methods for creating a Custom Enterprise Service using ABAP.
Creating Custom Enterprise Services in ABAP
To create services in ABAP, there are essentially two ways.
Inside-Out: We start at the back end, with an existing application to service enable any particular piece of functionality. This is called the inside out approach because we start with the implementation and move out toward the interface.
Outside-In: In outside-in approach we start with the interface and work in toward the implementation or we can say starting with modeling we move towards the implementation to create Enterprise services.
Apart from starting at different places, the inside-out and the outside-in approach also differ in other important ways. Services created from the inside-out follow the message response pattern, which is synchronous whereas Services created from the outside-in can be synchronous or asynchronous, not requiring a response from the service consumer; as a result, such services are even more loosely coupled and more flexible.
The Inside-Out approach
Creating a service from the inside out takes a piece of application functionality and makes it available as a web service. That piece of application functionality can be a BAPI, a remotely enabled function module(entities that are callable from outside the application), or a Remote Function Call (RFC).
For example, a Management person might ask for a service to retrieve Partner data but in our SAP CRM system there's already a Partner Read function . If we could simply turn that into a web service, it could solve the problem. Creating services from the inside-out provides an easy way to turn that functionality into a web service within short time frame.
So, creating services from the inside-out approach is a straightforward process, as shown in Figure -1. We start with a piece of existing functionality, starts a wizard to generate the web service, and finally we activate (in ABAP terminology) or deploy the service (if Java based). Generating the web service creates all the necessary deployment artifacts, including the Web Services Description Language (WSDL) file, automatically for us. Having created the service, we can test it using SAP's Web Service Homepage.
Figure -1. Steps involved in creating a service from the Inside-Out approach
To create a service we can either start by service enabling a remote-enabled function module in the ABAP Function Builder using transaction SE37 or we can start service creation from transaction SE80 in the ABAP Development Workbench.
To start the wizard in SE37, by locating the function module that we want to service enable and then select Utilities -> More Utilities -> Create Web Service -> From the Function Module, as shown in Figure -2.
Figure - 2. Creating a web service based on a function module
Selecting this option starts the Web Service Creation Wizard, shown in Figure -3. The wizard provides an overview of the process on the left side of the screen. In the center of the screen, we can see the function module (ZCFT_CUSTOMER_GETDETAIL) that will be service enabled.
Figure -3. The Web Service Creation Wizard
Pressing Continue displays the next screen, shown in Figure -4. Here we specify a name for the service definition and a description, then select the endpoint type. The endpoint type defaults to the function module since we started the wizard while viewing a function module.
Figure -4. Web Service naming
We press Continue to display the screen shown in Figure -5. Here the wizard confirms which endpoint we want to service enable, defaulting to the function module where we started the wizard. The checkbox for the mapping of names (shown in German in Figure -5) allows us to map ABAP-style names to a more conventional style by removing the underscores and turning uppercase letters to lowercase. This determines how the names appear in the WSDL file.
Figure -5. Choosing an Endpoint
We press Continue to display the screen shown in Figure -6. This screen configures the web service using profiles. These profiles include details such as the type of authentication the web service will use. We assign a SOAP profile, choosing either secure SOAP or the basic authorization SOAP profile.
Secure SOAP offers HTTP authentication using SAP logon tickets and X.509 certificates. The basic authorization SOAP profile is more common, with HTTP basic authentication (username and password). It is also possible to choose a profile that offers no security, which can be used for a public web service. We can change these options later also.
Selecting the checkbox releases the web service to the SOAP runtime immediately after completing the wizard. We can also release the service manually using the transaction WSCONFIG and by providing the name of the web service.
Figure -6. Choosing a Profile for Security Settings
We press Continue to display the final screen in this wizard, as shown in Figure -7.
Pressing Complete on this screen creates objects for the interface and web service description, and releases the service to the SOAP runtime (as we have the checkbox “Release Service for Runtime” checked).
A Create Object Directory Entry pop up appears where we are prompted to save the service definition objects; if they are local objects, save them in the temporary directory.
We are also prompted with a Customizing Request pop up where we can specify that this service be moved from the test system to the production system, for example. We click OK to continue.
Figure -7. Completing the Web Service Wizard
In the Object Navigator, enterprise services are found in a folder under the Function Modules folder. Opening the Enterprise Services folder displays the Service Definitions folder. In this folder, we can see the object we created.
At this point, we can improve the service definition and interface, by making some fine adjustment, in a couple of different ways. To start, we select the service definition we created and edit that object, selecting the Interface tab. We can change the names of the fields in the interface, perhaps customizing them for a partner. By default, the interface for the web service includes all the same parameters as the function module on which it is based. But in many cases, this is not optimal. Each field in the interface has an associated Exposed checkbox and deselecting it results in hiding the field. We can also customize the defaults for the fields in the interface like e.g. for a given partner we can streamline the process by filling in their name, customer number, and shipping address as defaults.
Now once we are done with the service creation we move on to the testing part. To test the created web service “Z_Customer_GetDetails_WS”, we go to a transaction called WSADMIN, which displays the Web Service Administration for SOAP Runtime screen. Testing of Service using WSADMIN is discussed at the end of this weblog.
The Outside-In approach
Outside-in development essentially involves modeling, generating stubs, and providing the implementation for the web service. Outside-in development starts at a business level, looking at critical business processes and modeling them into services that implement those processes.
From a developer's perspective, to create a service from the outside in, we start in the SAP NetWeaver XI Integration Repository. As we start developing services from the outside in, we use more of the principles of ESA, such as abstraction from programming languages, hiding the implementation details, and reusing data types where possible.
Figure -8. XI Integration Repository and its relationship to XI Integration Builder
The three major steps in this process are modeling the message interface in the SAP NetWeaver XI Integration Repository, generating a proxy from that model, and finally providing the implementation.
In the XI Integration Builder, software component versions are listed down the left side of the screen as a means of structuring the content. We can browse the repository to find out what interfaces exist. If two interfaces have the same name, the system can use the associated namespace to resolve any conflicts, definitively determining which one is intended. Typically, when we are developing, we creates a new namespace to separate our services from others that might have the same name.
Modeling a message interface in the repository requires three smaller steps:
1. Create the data type, using XML schema.
2. Create the message type, an XML entity that describes the message that will be sent over the wire.
3. Create the interface that uses the message type to describe the request and the response.
Although each step involves XML, we don't have to write the XML. Instead, the XML entities are automatically generated for us based on our work in the XI Integration Builder.
In the hierarchy for the namespace we create, we'll see Interface Objects, which include all the elements needed to define a service from the outside in. We start by creating a new data type. In our example, we'll create data types for Sales Order request. First, we create the input data type, which includes two elements: the Sales_Order_No and Sales_Document_Item type, as shown in Figure -9. As we can see, we also specify the type. Also note on this screen that the elements can be defined in mixed case rather than uppercase, as is the convention with ABAP.
Figure -9. Creating the input data type
Next, we create an output data type that has several elements, including Material_Number, Material_Group, and Division etc. as shown in Figure -10.
Figure -10. Creating the output data type
Creating the message type is the next step. The message type defines the request and response messages that will be sent over the wire. We create the input message type, as shown in Figure -11. To specify the data type, we drag-and-drop the input data type from the left hand panel to the field. Similarly, we drag-and-drop the namespace to fill in that field. Creating the output message follows the same process.
Figure -11. Creating the input message type
The final step is to create the message interface. Creating a new message interface displays a screen similar to Figure -12.
This service is synchronous, so both input and output message types must be specified.
At this point, we are finished modeling the interface. Now we use the transaction SPROXY to generate the proxy. The proxy generation retrieves the WSDL description of the interface from the Integration Repository using HTTP. In order for this proxy integration to occur, the system has to be preconfigured accordingly on the SAP NetWeaver XI side (in the system landscape directory) and in the ABAP backend (using transaction SM59, RFC Destinations).
Figure -12. Creating the message interface
SPROXY displays a view of the Integration Repository that we just used for modeling the message interface. Double-clicking on the message interface we created, MI_SalesOrder_Sync, brings up a popup box where we specify that we want to generate a proxy for this service, which displays the screen shown in Figure -13.
Figure -13. Generating the proxies
Figure – 14. Proxy Structure
Generating a proxy creates all the entities we need. Save the proxy, and then activate it. The next step is to create the implementation in the backend system using the ABAP Development Workbench. The class and proxy have already been given ABAP names; all that remains is to implement the class itself in the ABAP system. Double-clicking the class name displays the method of the class in the Class Builder. Double-clicking the method allows us to insert the implementation code. The developer can also use ABAP Development Workbench using transaction SE80 to implement the class and insert the code for the method, as shown in Figure -15.
Figure -15. Inserting the implementation
Having created this functionality from the outside in the next step is to enable it as a web service using the Web Service Creation Wizard (Figure -16).
Figure -16. Exposing it as a Web Service
Running the wizard is essentially the same process described earlier, with one difference; in this case, we choose Message Interface as the endpoint instead of Function Module (Figure -17) and then in the “Choose Endpoint” step (Figure 18) we put the ABAP Name of our Message Interface as generated by SPROXY transaction.
Figure -17. Chose Message Interface
Figure -18. Provide Message Interface name as Generated by SProxy
So to sum up all these steps, first we model the interface in the Integration Repository, generate a proxy from that, insert the implementation for the class, and finally service enable the newly created XI endpoint using the Web Service Creation Wizard. In the new version of SAP NetWeaver PI, this final step is no longer necessary.
Testing Service using WSADMIN
As discussed earlier to test the web services we use the transaction WSADMIN. It displays the Web Service Homepage, which lists all the available services. We select the service we created and click the Web Service Homepage icon (as displayed in Figure 19) or press “Ctrl+F8”. A “Settings for WSDL Generation” pop up appears, asking for a WSDL style; we choose Document Style.
Figure -19. Web Service Administration (WSADMIN)
The Web Service Homepage appears (Figure-20). We authenticate with username and password, and then the overview page for the web service will appear.
Figure -20. Web Service Homepage
From the Overview page for the Web Service (Figure-21), we can see the URL for the WSDL document, review the features assigned to the web service, and see the service's Universal Description, Discovery, and Integration (UDDI) status.
Figure -21. Overview page for the Web Service
We press the Test button to display the test page, which lists the operations for the web service (in this case, there is only one as shown in Figure -22); we select the operation and click Test. The interface appears, as shown in Figure -23.
Figure -22. Test page for the Web Service
Figure -23. Web Service Input Interface
We fill in the fields and click Send. The request is sent to the SOAP runtime and the screen displays both the request and the response, as shown in Figure -24. The call goes to SOAP via HTTP and the appropriate response is returned.
Figure -24. The results from testing the web service
This weblog shows how you can easily create custom enterprise services using ABAP and XI (or PI 7.0). I hope this will help some of you and provide all the relevant information at one place.
.
we looked for alternatives.
