Section 15.3. What are two ways to create services in ABAP?
15.3. What are two ways to create services in ABAP?When creating services in ABAP, there are essentially two ways to approach the problem. You can start at the back end, with an existing application, and say, "I want to service enable that particular piece of functionality." This approach quickly gets some services that you need up and running. In SAP parlance, this approach is called creating services from the inside out because we start with the implementation and move out toward the interface. Creating services from the outside in is the opposite approach; you start with the interface and work in toward the implementation. While creating services from the inside out entails starting with a piece of application functionality, creating services from the outside in asks you to start with modeling. Creating services from the outside in, starting with modeling, is the preferredone might say the ultimateapproach to creating enterprise services. The process as it stands at this writing involves modeling data types; at the end of this chapter, we'll look at the direction this process will take in upcoming releases of SAP NetWeaver, where modeling becomes more important and entails working with business objects, as discussed in Chapter 5. Obviously, creating services from the inside out and the outside in starts from different places; the semantics of the terms imply as much. But they also differ in other important ways. Services created from the inside out follow the message response pattern, which is synchronous. 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. 15.3.1. What does it mean to create services from the inside out?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 might be a remotely enabled function module, a Remote Function Call (RFC), or a BAPI. It might be application functionality that you or a custom programmer has created, or a function of SAP's software. For example, in looking at the IT landscape, managers might request a service to retrieve employee address data. But wait, you might say, there's a Get Address function in our SAP HR system. If we could simply turn that into a web service, we could solve the problem at hand. Creating services from the inside out provides an easy way to turn that functionality into a web service in short order. Creating services from the inside out is a straightforward process, as shown in Figure 15-1. You start with a piece of existing functionality, you start a wizard to generate the web service, and finally you activate (in ABAP terminology) or deploy the service (if it is Java based). Generating the web service creates all the necessary deployment artifacts, including the Web Services Description Language (WSDL) file, automatically for you. Having created the service, you can test it using SAP's Web Service Homepage. Figure 15-1. Steps for creating a service from the inside out 15.3.2. How do you create a service from the inside out using ABAP?For our first example, we'll service enable a remote-enabled function module in the ABAP Function Builder.[*] Remote-enabled function modules are entities that can be provided to the outside world; they are callable from outside the application.
To start the wizard, we locate the function module that we want to service enable and then select Utilities Selecting this option starts the Web Service Creation Wizard, shown in Figure 15-3. The wizard provides an overview of the process on the left side of the screen. In the center of the screen, you can see the function module that will be service enabled; this name (Z_EMPL_PRIVATE_ADDRESS_QUERY) will become the default throughout this example, but we will have a chance to change it. Pressing Continue displays the next screen, shown in Figure 15-4. First, 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. We press Continue to display the screen shown in Figure 15-5. Figure 15-2. Creating a web service based on a function module Figure 15-3. The Web Service Creation Wizard Figure 15-4. Naming the web service 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 15-5) allows you 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. We press Continue to display the screen shown in Figure 15-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 makes sense for a public web service, for example. You can change these options later, but this pulldown provides an easy way to specify the features desired for your web service while you are running the wizard.
Figure 15-5. Choosing an endpoint Selecting the checkbox releases the web service to the SOAP runtime immediately after completing the wizard. You can also release the service manually using the transaction WSCONFIG. We press Continue to display the final screen in this wizard, as shown in Figure 15-7. Pressing Complete on this screen creates objects for the interface and web service description, and releases the service to the SOAP runtime. 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 you can specify that this service be moved from the test system to the production system, for example. We click OK to continue. 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, you can see the object we created. At this point, we can tweak the service definition and interface in a couple of different ways. To start, we select the service definition we created and edit that object, selecting the Interface tab. You can change the names for 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. Perhaps the order entry function module has 45 fields, but only 10 of them are relevant for a particular partner. Each field in the interface has an associated Exposed checkbox. Deselecting this checkbox hides a given field. You can also customize the defaults for the fields in the interface. If you were customizing a service for a given partner with whom you do a lot of business, you might streamline the process for them by filling in their name, customer number, and shipping address as defaults. Figure 15-6. Choosing a profile To test the web service, we move to a transaction called WSADMIN, which displays the Web Service Administration for SOAP Runtime screen, shown in Figure 15-8. From here we can display the Web Service Homepage, which lists all the available services. We select the service we created and click the Web Service Homepage icon. A Settings for WSDL Generation pop up appears, asking for a WSDL style; we choose Document Style. For ABAP developers, the integration with the ABAP Development Workbench here is a plus; you need not log out of ABAP to take these steps. The Web Service Homepage appears. We authenticate with username and password, and then the overview page for the web service will appear. From this screen, you 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. The SAP NetWeaver Application Server (SAP NetWeaver AS) includes a UDDI server. Currently, it supports UDDI 2.0; UDDI 3.0 support is featured in an upcoming release. Figure 15-7. Completing the web service Figure 15-8. Web Service Administration (WSADMIN) We press the Test button to display the test page, which lists the operations for the web service (in this case, there is one); we select the operation and click Test. The interface appears, as shown in Figure 15-9. Figure 15-9. Testing the web service 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 15-10. This is a test of the web service, not just a test of the function module (which can be done through the development environment). The call goes to SOAP via HTTP and the appropriate response is returned. Figure 15-10. The results from testing the web service So far, this section outlined how to create web services using the wizard. Next we will describe how to create services from the outside in. 15.3.3. What does it mean to create services from the outside in?Outside-in development essentially involves modeling, generating stubs, and providing the implementation for the web service. While development from the inside out starts with existing application functionality, outside-in development starts at a business level, looking at critical business processes and modeling them into services that implement those processes. While SOA sounds like it is all about services, ESA is, at a higher level, a blueprint for being process oriented rather than service oriented. It asks you to take a step away from the IT landscape and really consider the essential processes that bring you business value. These processes, rather than applications or even services, ultimately form the basis for ESA. From that standpoint, outside-in development is not dependent on any existing applications, not even SAP applications. 15.3.4. How do you create a service from the outside in using ABAP?Before we dive into the steps for creating a service from the outside in, let's be clear about who is doing the creating. In this chapter, we discuss creating services from the outside in from a developer's perspective. To create a service from the outside in, you 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 15-11 shows the XI Integration Repository and its relationship to the XI Integration Builder. Figure 15-11. SAP NetWeaver XI Integration Repository and 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. You 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 you are developing, you will create a new namespace to separate your services from others that might have the same name. Modeling a message interface in the repository requires three smaller steps:
Although each step involves XML, you don't have to write the XML. Instead, the XML entities are automatically generated for you based on your work in the XI Integration Builder. In the hierarchy for the namespace you create, you'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 a Get Address application. First, we create the input data type, which includes three elements: the employee ID, date, and address type, as shown in Figure 15-12. As you can see, you also specify the type. In this case, all three elements are defined as XML Schema Definition (XSD) strings. Also note on this screen that the elements can be defined in mixed case rather than uppercase, as is the convention with ABAP. Figure 15-12. Creating the input data type Next, we create an output data type that has several elements, including first name, last name, street name, and zip code; they are also of XML type string, as shown in Figure 15-13. Figure 15-13. 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 15-14. To specify the data type, we drag-and-drop the input data type from the lefthand 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 15-14. 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 15-15. 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.[*]
Figure 15-15. 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, Z_Get_Address, brings up a pop-up box where we specify that we want to generate a proxy for this service, which displays the screen shown in Figure 15-16. Figure 15-16. Generating the proxies Generating a proxy creates all the entities you 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 you to insert the implementation coding, as shown in Figure 15-17. The developer must write the implementation for the class and insert it here. (In this case, we had the implementation ready in advance and just pasted it in.) Having created this functionalityfrom the outside inthe next step is to enable it as a web service using the Web Service Creation Wizard. This is essentially the same process Figure 15-17. Inserting the implementation described earlier, with one difference: in this case, you choose ESIRepository Service Interface as the endpoint instead of Function Module. Since running the wizard is essentially the same procedure described earlier, we'll spare you the details, but you can see the process of outside-in development at work: first you 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 an upcoming release of SAP NetWeaver, this final step will no longer be necessary. |
More Utilities 
EAN: 2147483647
Pages: 265