Use Pi71 Tools for Provisioning and Consuming Enterprise Services in Abap

No portion of this publication may be reproduced without written consent. 65

As the concept of enterprise service-oriented architecture (enterprise SOA) becomes a reality for an increasing number of companies, the question of how best to create and provision enterprise services gains in significance. Businesses with core ABAP development groups need concrete guidance to develop services. For example, how does an individual programming language relate to an enterprise SOA environment with its emphasis on openness and standards? To answer this question, IT teams must under-stand the fundamental principle of enterprise SOA: It enables you to create loosely coupled services that separate the service interface from its actual implementation. This functional separation is the core of enterprise SOA flexibility. Enterprise SOA also offers other benefits, including its abilities to reuse existing IT assets and to adapt processes to changing requirements.

Version 7.1 of SAP NetWeaver Process Integration (SAP NetWeaver PI) is SAP’s SOA middleware offering; it is also the latest release from SAP that is based on the Business Process Platform. SAP NetWeaver PI plays an important role in supporting enterprise SOA. Today, enterprise services are the backbone of most business processes in customer IT land-scapes. These services interact across intra- and inter-company boundaries, application-to-application (A2A) and business-to-business (B2B) situations, and human-centric and composition scenarios. SAP NetWeaver PI 7.1 is based on an open architecture that uses open standards, and it offers services that are essential to both SAP and non-SAP applications in a heterogeneous and complex system landscape.

You can develop enterprise services in either ABAP or Java. Most of the business functionality that SAP has delivered as services through enhancement packages has been implemented in ABAP, so ABAP is the programming language we discuss in this article.

This article walks you through the steps of modeling, implementing, configuring, publishing, and consuming enterprise services in ABAP using

Use SAP NetWeaver PI 7.1 tools for provisioning and consuming enterprise services in ABAPby Prasad Illapani and Susanne Rothaug

Prasad IllapaniSolution Architect, NW-RIG, SAP Labs LLC

Susanne RothaugProduct Manager SAP NetWeaver, SAP AG

(Full bios appear on page 94.)

This article originally appeared in the September/October 2008 issue of SAP Professional Journal, and appears here with the permission of the publisher Wellesley Information Services. For information about SAP Professional Journal and other WIS publications visit www.WISpubs.com

SAP Professional Journal • September/October 2008

66 www.SAPpro.com ©2008 SAP Professional Journal. All rights reserved.

SAP NetWeaver PI 7.1 tools for service provisioning and consumption. First, we briefly explain some of the concepts of enterprise services: what distinguishes them from Web services and the basic methodology for their development. This is the same information found in the specification phase of the “Provisioning enterprise services in ABAP” section and includes data about SAP’s business process component archi-tecture and the model types it provides.

Next, the article looks more closely at the SAP NetWeaver PI 7.1 tools that provide and consume enterprise services, starting with SAP Enterprise Services Repository (ESR) and its ability to design and model enterprise services in a top-down fashion, as in the design phase on page 68. In the implementa-tion phase, we show you how to employ enterprise services in ABAP on an ERP system and how to configure and publish them to the Services Registry. Since the Services Registry is a new feature of SAP

NetWeaver PI 7.1, the article also outlines the main capabilities of the Services Registry in the section “The Services Registry” on page 82. The final section of the article covers how you consume an enterprise service using an ABAP consumer application.

To illustrate the development process, the article walks through the various steps (see Figure 1) involved in developing and implementing an enter-prise service in ABAP in an actual business scenario using the SAP NetWeaver PI 7.1 SOA middleware offering. The article concludes by testing the enter-prise service invocation, using the SAP Web Services Navigator tool to verify the test results. Whether you are an IT architect, an integration consultant, or a business process expert (BPX) seeking to understand the concept of enterprise services in the SAP world,

Note!

For more information on how to develop services in Java, see “Web Services or RFCs — choosing the right technology for your SAP integration challenges” by Willi Nüßer (SAP Professional Journal, May/June 2006).

1a

Createprocesscomponentmodel

1b

Modelserviceinterface

2a

Generate/implementproxy

Createruntimeconfiguration

3

Publishto ServicesRegistry

4a

Createconsumerproxy andlogical port

4b

Createconsumingapplication

5

Invokeservice

Providing the service Consuming the service

Createruntimeconfiguration

2b

Figure 1 Steps for providing and consuming an enterprise service

Prerequisites

This article assumes that you are familiar with the basics of middleware technologies such as SAP NetWeaver PI, with enterprise SOA, Web services, and object-oriented (OO) ABAP programming. Some knowledge of XML and XML Schema Definition (XSD) is also helpful. More information on these topics can be found in the SAP Help Portal at http://help.sap.com.

Use SAP NetWeaver PI 7.1 tools for provisioning and consuming enterprise services in ABAP


this article is a good starting point. It can help you to understand and implement enterprise services in your landscape.

Provisioning enterprise services in ABAPWhen you’re talking about Web services, it’s impor-tant to keep in mind that the central Web service paradigm consists of a provider side — the application that offers a certain functionality in the form of a Web service (i.e., it is callable via open Internet standards) — and a consumer side — the application that uses the Web service that the provider offers. To make the provider known to the consumer, there is typically a registry or directory of services in place that acts much like a Web services “yellow pages.” The SAP NetWeaver version of this registry is called the Services Registry.

Figure 2 provides a schematic representation of the provider-consumer relationship.

The first part of this article deals with the provider side of this equation. You can also refer to the process of providing a service as “developing” or “creating” a service. To create enterprise services in accordance with SAP’s guidelines, IT architects must understand the typical service-development cycle, which has the following three major phases at SAP:

• Specification phase: In this phase, you model business requirements as business process models, which allow you to define a static view of process components, their internal structure, and the rela-tionships among the various process components. The idea behind this approach is to enable a semantically meaningful, redundancy-free struc-turing of the business application content you plan to offer as enterprise services. If you propose large pieces of business functionality to be enterprise services, it’s essential to have an efficient way to

Publishto ServicesRegistryServices Registry

Webservice

consumer

Web

ser

vice

WSDLdocument

3

2 1

Web service execution

Discover Web service Discover client application

Web service provider

Businessfunctionality

Create Web service Create WSDL Publish WSDL (optional)

Direct WSDL exchange

Figure 2 The Web services paradigm



depict the relationships among these services. SAP’s concept of process component architecture models provides this information at various levels of detail so that you have a complete picture of the services you’re planning to use — from the upper-most level of the solution map down to the operation of the actual service.

Note!

The specification step is mentioned only for the sake of completeness; the primary efforts of specification take place before your actual work with the SAP NetWeaver PI tools, so it is considered to be a prerequisite to the service-enabling process.

• Design phase: In this phase (Figure 1, steps 1a and 1b), you define the details of the enterprise service interfaces. The models created during the specification phase form the basis for concrete design-time entities. These models also include the enterprise service’s operations and data types. The model types Process Component Model (SAP ProComp Model) and Process Component Interaction Model (PCIM) are particularly inter-esting because they represent the transition from specification to design and assign concrete design objects to the graphical models (for the details of this process, see “How to design an SAP ProComp Model” on page 71).

• Implementation phase: In this phase (Figure 1, steps 2a, 2b, and 3), you insert the executable coding into the service interfaces. The interfaces you created during the design phase were programming language-independent; now you need to generate their platform-specific repre-sentations. This phase, also referred to as proxy generation, creates the implementation classes for these services. Next, you add the services’ actual business and integration logic to the generated proxy classes. Typically, you would program this

step manually. Finally, you create a runtime configuration and publish the service to the Services Registry.

Now, let’s focus on the methodological back-ground behind SAP’s service-enabling technology and find out why you need to distinguish enterprise services from Web services, what the basic guidelines of enterprise service definition at SAP are, and how they translate into the SAP ProComp Model architecture.

Understanding SAP’s concept of enterprise SOA

To grasp the approach that SAP takes to enterprise SOA and envision its benefits, it’s helpful to remember the traditional opposition between the business and IT worlds. In many companies, the IT infrastructure dictates what you can and cannot do on the business side. Within the enterprise SOA paradigm, the IT side typically consists of technology that enables you to provision services based on open standards.

However, business requirements shouldn’t depend on the available technology; the business itself needs to drive the IT landscape. This separation between technology and business is of major impor-tance because SAP merges the two points of view in the concept of enterprise SOA. Due to this conver-gence, the scope of this article includes both the pure technology side of exposing business functionality as a Web service and any related methodological concepts required to structure business content in a meaningful way.

Let’s begin by establishing the difference between Web services and enterprise services. Web services are primarily self-contained, self-describing applica-tion functionalities that you process through open Internet standards. An enterprise service is a Web service that also adheres to the following criteria:

• Based on open standards (Web Services Description Language [WSDL], Simple Object Access Protocol [SOAP], Universal Description, Discovery, and Integration [UDDI], etc.)



• Provides business functionality

• Based on a metamodel that structures the business application content in a redundancy-free way

• Metamodel based on Global Data Types (GDTs), process components, and business objects (for more information on GDTs, see the sidebar on this page)

• Published in the ESR

• Well-documented and follows architectural guide-lines and standards

• Ensures governance during design time and runtime and enables reusability

Process component architecture models and model typesTypically, the process component is the central modeling object with which you describe part of a business application process. The different model types that SAP has developed concentrate on specifi-cally defined aspects of the business process, so that you can understand the whole process from different

Global Data Types GDTs:

• Are reconciled data types with business-related content that SAP defines and uses in its applications

• Represent the business-related subject matter that a specified structure describes

• Are data types defined as completely as possible that contain all of the elements required for the subject matter in different contexts

• Add business semantics to the standards-based Core Component Technical Specifications (CCTS) types; apply the CCTS methodology in a unification and standardization process to develop data types in XML schema in the ESR

The illustration below depicts the relationship between plain XSD types, types based on the CCTS stan-dard, and SAP’s GDTs. You can use any XSD type in any number of CCTS data types, and you can use each CCTS type in any number of GDTs. Only the GDTs contain actual business semantics.

Global Data Type Businesssemantics

Nobusinesssemantics

CCTS core data type

1

1

World Wide WebConsortium (W3C)

data type



angles. Basically, each process component describes a unique part of the process.

• The first model type of relevance is the process component model (SAP ProComp Model), which models the data that the process compo-nent uses as well as the service interfaces needed.

• One level higher is the process component inter-action model (SAP ProComp interaction model), which depicts the relationship between two process components.

Note!

For more information about modeling business processes and their components, see “Improve your business agility with enterprise SOA — a model-driven approach to flexible application development” by Robert Heidasch (SAP Professional Journal, July/August 2008).

Now that you know what occurred in the speci-fication phase of creating an enterprise service and how to create a context within an SAP solution for the enterprise service’s functionality, let’s examine concrete design and implementation by looking more closely at the ESR. After a brief introduction to the ESR and its main capabilities, this article shows you how to create an SAP ProComp Model and a service interface using the associated message types and data types that an actual service imple-mentation requires.

Enterprise Services Repository

Companies are moving to enterprise SOA to provide themselves with increased productivity and business agility. Central to this move is the need to define, model, govern, and manage reusable objects. The ESR and the Services Registry address this specific

need. With these capabilities, SAP provides a single point of control within the enterprise SOA infrastruc-ture that lets you govern service components and reusable objects based on Web services standards. In addition, the ESR is the pivotal point in the way that SAP merges business and IT in enterprise SOA.

Note!

The combination of the ESR and the Services Registry also accommodates customers and partners that only need a lean development environment. SAP offers two different shipment options for the ESR and the Services Registry. You can get the ESR and the Services Registry with SAP NetWeaver PI 7.1, which also includes the Integration Directory and the Integration Server; or you can get them with SAP NetWeaver Composition Environment (SAP NetWeaver CE) 7.1, which provides full-service provisioning and consuming capabilities but without the full integration functionality of the Integration Directory and the Integration Server. In this way, the combination of the ESR and the Services Registry accommodates customers and partners with different requirements and system landscapes.

The main functions of the ESR are as follows:

• Facilitating the building of service interfaces, which form the basis of enterprise services

• Providing for the versioning of service reusable objects

• Supporting SAP’s concept of building services based on SAP ProComp Model methodology

• Shipping with a pool of SAP-defined GDTs based on the CCTS, ensuring that data types are aligned and reusable (the core components are the building blocks for data modeling)



Now, let’s look at how to use the ESR to enable customers and partners to enrich the content that SAP ships with the additional services that they need for their own use.

How to design an SAP ProComp ModelTo create an SAP ProComp Model, let’s look at an enterprise service that finds and manages purchase order data. To produce the model, you use the inte-grated modeling capabilities of the ESR.

1. From the content navigation area on the left side of the initial ESR screen, select the software component SC_SOA_ABAP 1.0.

2. Expand the Modeling node, and right-click on Models.

3. Select Create Folder, and enter the folder name PurchaseOrder.

The system stores all of the modeling objects you create for this example in the PurchaseOrder folder.

Figure 3 shows you the directory structure for this example.

Now, let’s create a new model:

1. From the ESR start screen, right-click on the PurchaseOrder folder to display a context menu with the following options: New, Edit, Delete, Rename, and Edit Authorizations.

2. Select New to create a new SAP ProComp Model (for more information, see the sidebar below). A pop-up window opens in which you specify the

Figure 3 Creating a folder for your modeling objects

From specification to designThe SAP ProComp Model represents the stage at which the specification phase of a service transitions into the design phase. It’s also where you create the physical objects and assign them to the graphical models. Once the graphical representation of a process component is in place, you can begin to create the design objects required to define the enterprise service in a top-down fashion. These objects are:

• Data types, which define the structures and sub-structures used in the messages exchanged at runtime. The recommended approach is to use GDTs.

• Message types, which define the type of data exchanged in messages between a service provider and a consumer. A message type is based on a data type.

• Service interfaces, which are programming language-independent representations of the service objects used at runtime. A service interface can consist of one or more operations and the associated message types. A service interface can include both synchronous and asynchronous operations. The consumer can select any operation from the same service interface. The service provider can supply a single interface for any number of operations.

Each synchronous operation contains a request message type, a response message type, and, optionally, a fault message type. An asynchronous operation only contains a request message type and an optional fault message type.



properties for this new object, such as name, model type, etc. Enter the model name POModel in the Name field.

3. From the Model Type drop-down list, select SAP ProComp Model as Model Type, and click on the Create button at the bottom of the screen. The modeling work area opens, as shown in Figure 4.

4. Click on the Save button to save the model.

5. When you move your mouse pointer over the object symbols on the left side of the work area, the system displays the object types. Click on the service interface symbol (see the callout in the figure) to insert a service interface into the new SAP ProComp Model.

6. Click anywhere in the free space of the modeling work area to insert a service interface shape with an empty Name field.

7. Enter the name ManagePO.

8. Click on the business object symbol (see the callout in the figure).

9. As you did with the service interface, click again in the free space of the modeling work area to insert a business object.

10. The system inserts a business object shape with a business object Name field, as highlighted in Figure 5. Enter the business object name PurchaseOrder in the highlighted field.

11. Select the PurchaseOrder business object, and then click on the operations symbol (see the callout in Figure 4).

12. Select the Operation uses/Is realized by PurchaseOrder radio button, and click on ManagePO.

13. In the subsequent pop-up, select the Connection occurrence checkbox and click on OK.

14. The system inserts an operations shape with an empty Name field. Enter the name of the operation as CreatePO.

15. Resize the objects, and repeat this procedure to create the second operation, SearchPO.

Figure 4 The modeling work area for SAP ProComp Models in the ESR

Business object symbol

Service interface symbol

Operations symbol



16. Save this model. At this point, the model should look like Figure 6.

Until now, the model has been assigned only to a Software Component Version, not to a namespace. You need to assign concrete objects to namespaces now so you can assign these objects to the model later.

17. Click on the ManagePO interface box, and then from the context menu, select Service Interface Assignment → Create Assignment. A pop-up window appears in which you can open a drop-down list for namespaces.

18. Select the namespace http://sap.com/soa/abap for your interface object from the value list that

Figure 5 Insert a business object into POModel

Figure 6 Schema of the SAP ProComp Model for ManagePO



appears, and click on the Save button. A new icon appears in the lower-left corner of the interface, indicating that an assignment exists.

19. Double-click on the Assignment icon to create the interface object ManagePO.

20. Then save the ManagePO interface object without further editing. You can return to it later.

21. Return to the modeling work area by clicking on the POModel (SAP ProComp Model) tab.

22. Right-click on the CreatePO operation box, and then select Operation Assignment → Create Assignment from the context menu.

23. Accept ManagePO.CreatePO as the proposed Operation Name, and select your namespace from the value list (a selection list of different namespaces) shown when you click on the context menu’s arrow button.

24. Save the operation assignment. See Figure 7.

25. Double-click on the Assignment icon (as you did with the interface assignment), and click on the Create button to generate the operation object CreatePO. Then, the service interface ManagePO window opens.

26. In the Definition folder, click on the minus sign button to delete the operation ManagePO. This

operation was generated automatically during interface creation with the same name as the service interface. It’s not required here, so you should delete it to avoid any confusion with the operation name.

27. Select the CreatePO operation on the lower-left side of the operations editor, and then select mode Asynchronous because the CreatePO operation is asynchronous.

28. For the service interface, select Inbound as the Attributes Category.

29. Save the service interface. The screen now looks like Figure 8.

Now, repeat the same steps to create the second operation, SearchPO. This time, select Synchronous as the mode.

1. To create the message types for the service inter-face, go to the navigation area on the lower right side of the Messages area and open the context menu of the namespace http://sap.com/soa/abap.

2. Select New, and a pop-up window appears.

3. Expand the Interface Objects folder, and select Message Type.

4. Fill in the required fields, as shown in Figure 9.

Note!

An asterisk on an input field means it’s manda-tory that you enter a value for that field.

5. Enter CreatePO for the Name parameter, and click on the Create button to complete the Message Type creation.

The procedure is basically the same for the second operation, SearchPO, but for this one you need to create two message types: request and response.

Figure 7 The operation assignment



Since the steps are essentially the same, you only need to walk through them once in detail.

To complete creation of the service interface, you need to assign data types that define the signature of

Figure 9 Creating a new message type

Figure 8 ManagePO service interface with one operation



the service to the newly created message types. For this, you create a new data type called PO_DT.

6. To create the data type, open the context menu of the Data Types folder, and select New.

7. In the pop-up window, enter PO_DT as the name of the data type, and click on Create to get to the data type object window.

8. On the Type Definition tab, right-click on the name of the data type, and select Insert → Insert Sub-element from the context menu.

9. Enter PONum as the name of the first sub-element and specify it as being of type xsd:string.

Proceed in the same way to create the other sub-elements in Figure 10. The POItem sub-element, in turn, consists of the data type POIT_DT, which you create the same way you did PO_DT. When you finish creating the sub-elements, save your settings.

You also create the other data type for this example, PO_REQ, in the same way. When complete, it looks like the example in Figure 11.

Now that the data types are in place, you can complete the message types by assigning them to the data types.

10. On the left side of the context menu under Software Component Version, expand the

Figure 10 Creating the structure of the PO_DT data type

Figure 11 Creating the structure of the PO_REQ data type



namespace to see the message type object. Then, open the message type CreatePO.

11. Using the Message Type screen, drag and drop the PO_DT data type object from the left side of the context menu onto the hand icon in the Data Type Used section on the right side of the Message Type editor. This feature in SAP NetWeaver PI adds the data type object to the message type object’s listed parameters without you having to type any names.

12. In the same way, you assign the PO_REQ data type to the request message SearchPO_ReqMT of the CreatePO operation, and the PO_DT to the response message SearchPO_ResMT of the same operation. Save your settings.

Now, the message types are ready for use in the service interface. Open the ManagePO service inter-face on the left side of the context menu under

Software Component Version, expand the namespace, and look at the service interface object. Drag and drop the message types to the name fields of their respec-tive messages. (Ignore the Fault message in this exercise.) Figure 12 illustrates the procedure of assigning message types to the service interface.

On the left side of the context menu of the session window, you can see the objects you created, as shown in Figure 13 on the next page.

The last step is to activate these objects:

13. Switch to the Change Lists tab to activate all of the objects that have no errors and generate the code used during runtime.

14. Click on Open for the SC_SOA_ABAP 1.0 soft-ware component, and then activate the object.

The objects created in the ESR are now active and the service interface is complete. Next, let’s look

Figure 12 Assigning the synchronous message type to the ManagePO service interface



at how to implement these programming language-independent, reusable metadata objects in a concrete ABAP environment.

Implementing enterprise services in ABAP

After you have completed the modeling of the service interface in the ESR, you come to the next step (Figure 1, step 2a). This step is the ABAP-specific implementation of the enterprise service’s business logic.

Note!

Applications based on SAP NetWeaver 7.0 (Service Pack 14 or higher) can make use of most of the ESR functionality described in this example, such as the support of multiple operations. There are some limitations, however. For details, please refer to the SAP Help Portal at http://help.sap.com.

Generate an ABAP proxy for the service interfaceABAP proxy generation is basically the platform-specific implementation code for the service interface you designed above. You construct proxy objects, such as data structures, classes, and methods, based upon the design elements created in the ESR. The prerequisite for proxy generation is that you must configure the ESR connection from the corresponding SAP application via transaction SM59 (Configuration of RFC Destinations). In the PO example in this article, you generate the proxy objects from the corresponding service interface designed in the ESR. After you create the proxy objects, you add the imple-mentation code in the methods of the class program.

After the code is implemented, you generate and activate all of the necessary proxy objects of the service interface, as follows:

1. Log on to the ABAP system (client: 001) via the SAP GUI using your user ID and password.

2. Run transaction SPROXY (Smart Proxy).

3. In the left pane, under Enterprise Service Repository, expand the service interface node of your software component SC_SOA_ABAP 1.0.

4. Select the ManagePO service interface object, right-click on it, and select Create Proxy, as shown in Figure 14.

5. In the pop-up wizard window, click on the Local Object checkbox and enter ZPO in the Prefix field, as shown in Figure 15.

6. Click on the Continue button, and then click on the Finish button to finish proxy generation.

7. Save the proxy object, and then activate it.

Figure 13 Viewing the list of objects created in the ESR

Figure 14 Create Proxy button under ManagePO service interface



You now have the necessary proxy objects for the service interface you designed in the ESR. Next, you need to implement the proxy.

Implement the proxy for the service provider A service provider supplies the service WSDL to the consumer application. The service provider has to implement the service in its own application based on the business functionality of the service interface. There are two methods to be implemented in the proxy of this example: CreatePO and SearchPO.

• CreatePO method: In the Class Builder window on the right under Properties, double-click on the interface provider class ZPOCL_MANAGE_PO. Then, double-click on the ZPOII_MANAGE_PO~CREATE_PO method name, and insert the code between the method and end method lines (see Figure 16).

Figure 15 Enter Package & Prefix screen wizard with updated screen

method ZPOII_MANAGE_PO~CREATE_PO.

*** **** INSERT IMPLEMENTATION HERE **** ***

data : l_str_po_data type ZPODATA.

* Collect proxy input to local compatible variables.

l_str_po_data-ponum = input-Create_PO-ponum.

l_str_po_data-podate = input-Create_PO-podate.

l_str_po_data-potype = input-Create_PO-potype.

l_str_po_data-pogrp = input-Create_PO-pogrp.

l_str_po_data-vendor = input-Create_PO-vendor.

l_str_po_data-itemno = input-Create_PO-POItem-item_no.

l_str_po_data-matno = input-Create_PO-POItem-mat_no.

l_str_po_data-plant = input-Create_PO-POItem-plant.

l_str_po_data-deldate = input-Create_PO-POItem-del_date.

l_str_po_data-qty = input-Create_PO-POItem-qty.

l_str_po_data-price = input-Create_PO-POItem-price.

* Create vendor.

CALL FUNCTION 'ZCREATEPO'

EXPORTING

PODATA = l_str_po_data.

* Wait up to 160 seconds.

commit work.

endmethod.

Figure 16 Creating the method ZPOII_MANAGE_PO~CREATE_PO



(Typically, you would write your own code here.) Save the method and then activate it.

• SearchPO method: Double-click on the method name ZPOII_MANAGE_PO~SEARCH_PO and insert the code between the method and end method lines, as shown in Figure 17. Save the method and then activate it.

At this point you have implemented the code for

the methods you have created. Finally, you save the objects and activate them, so that they are available for consumers that use the enterprise service.

Configure the enterprise service endpoints With the completion of service implementation in the previous section, you now have the business logic you need for the enterprise service. Its actual functionality

method ZPOII_MANAGE_PO~SEARCH_PO.

*** **** INSERT IMPLEMENTATION HERE **** ***

data: l_str_po_data type ZPODATA,

l_po_num type EBELN,

l_vendor type LIFNR.

* Collect proxy input to local compatible variables

l_po_num = input-SEARCH_PO_REQ_MT-ponum.

l_vendor = input-SEARCH_PO_REQ_MT-vendor.

CALL FUNCTION 'ZGET_PO_DETAILS'

EXPORTING

PONUM = l_po_num

VENDOR= l_vendor

IMPORTING

PODATA = l_str_po_data.

* Exporting the data outside to the proxy structure

output-Search_Po_Res_MT-ponum = l_str_po_data-PONUM.

output-Search_Po_Res_MT-podate = l_str_po_data-PODATE.

output-Search_Po_Res_MT-potype = l_str_po_data-POTYPE.

output-Search_Po_Res_MT-pogrp = l_str_po_data-POGRP.

output-Search_Po_Res_MT-vendor = l_str_po_data-VENDOR.

output-Search_Po_Res_MT-POItem-item_no = l_str_po_data-ITEMNO.

output-Search_Po_Res_MT-POItem-mat_no = l_str_po_data-MATNO.

output-Search_Po_Res_MT-POItem-plant = l_str_po_data-PLANT.

output-Search_Po_Res_MT-POItem-del_date = l_str_po_data-DELDATE.

output-Search_Po_Res_MT-POItem-qty = l_str_po_data-QTY.

output-Search_Po_Res_MT-POItem-price = l_str_po_data-PRICE.

endmethod.

Figure 17 Creating the method ZPOII_MANAGE_PO~SEARCH_PO



— creating and searching for purchase orders — is now in place. However, to enable you to call that service in consumer applications, you still need to specify its behavior with regard to concrete security and transport settings. This is referred to as creating a runtime configuration for a service. Since the secu-rity requirements for an enterprise service might differ depending on the context in which it is used, it’s possible to configure several endpoints for each service. This doesn’t affect the functionality of the service; it still creates and searches for purchase orders. Using the new enterprise SOA management functionality, you can conveniently configure an enterprise service’s endpoints. This step is represented as Figure 1, step 2b.

1. Log on to the application system client 002 via SAP GUI. You need to simulate the integration server client 002 as an application for the example shown. In reality, customers can use any SAP application.

2. Run transaction SOAMANAGER (Service-enabling with SAP NetWeaver Process Integration 7.1 [ABAP-Based]). A new browser page window opens displaying the SOA Management page.

3. Click on the Business Administration tab, as shown in Figure 18.

4. Click on the Web Service Administration link.

5. Now, search for the Web service definition.

Type in the service name for the Search Pattern parameter. In this case, the enterprise service defi-nition is ZManagePO, as shown in Figure 19 on the next page.

Note!

You can check the Web service definition name in transaction SPROXY under your software component.

6. Select your service definition in the Search Results area, and click on the Apply Selection button.

7. In the Details section of the service definition, click on the Configurations folder to create the endpoint, i.e., the runtime configuration for the service definition, as shown in Figure 20 on the next page.

8. Click on the Create Service button to start the creation of the runtime configuration. Enter the New Service Name, Description, and New Binding Name parameters, as shown in Figure 21 on the next page.

9. Click on the Apply Settings button to apply the settings that you just entered to the service name you created in the previous step.

Figure 18 The SOA Management screen



10. In the Web Service Configuration work area in the Provider Security folder, as shown in Figure 22, click on the User ID/Password checkbox in

Authentication Settings to add authentication steps for the service definition.

At this point, you have configured the endpoint for the service definition via enterprise SOA management tools. The service provider supplies the location of the service as a URL.

The Services Registry

So far, we’ve been talking mostly about enterprise SOA reusable design-time objects: how to centrally create and store the metadata relevant for service-provisioning. The implementation of an enterprise service, however, resides in a particular back-end system, so you need to know how to find the informa-

Figure 19 Searching for the ZManagePO service definition

Figure 20 Finding the configuration for ZManagePO

Figure 21 Creating an endpoint for the service definition



tion that enables you to call an enterprise service that contains the endpoint information as well as the semantic criteria for service retrieval. If business users cannot easily find these enterprise services, the promise of enterprise SOA is lost to them. If devel-opers cannot readily find and reuse these services, they might as well not exist.

SAP’s solution is the standards-based Services Registry where you publish your enterprise services as well as external Web services. It is located centrally within an enterprise SOA landscape. It contains infor-mation about the services provided in that landscape, with references to the services’ relevant WSDL metadata and to the locations of the callable service endpoints. By publishing service information, theBy publishing service information, the Services Registry becomes not only the overall system of record for your entire enterprise SOA, but also the basis for service management and configuration. ThisThis is realized by SAP-specific classification systems that exceed the UDDI standard. The classifications shipped with the current version of the Services Registry include:

• Deployment unit, process component, business object, service interface, service operation

• Life-cycle status, application name, extended-by industry, relevant-for industry

• Software component, software component version

SAP enhances these classification systems on an ongoing basis. Planned for the next version of the Services Registry are business application, Web service profile, organization name, and business system.

To summarize, when using services you should distinguish between the service provider and the service consumer. In the simplest case, you can assume that the service provider knows the service consumer and informs the latter where to find the services. However, this contradicts the idea of a global service platform. What makes using Web services attractive is the idea that you can build applications from services that are available in a central registry: in this case, the Services Registry.

The various services in a system landscape must be made available in the Services Registry. This process is referred to as “publishing a service.”

Figure 22 Establishing the authentication settings for the service provider



Publish an enterprise service to the Services RegistryIn the Services Registry, the providers of the services supply their definitions to the service consumers. These consumers log on to the Services Registry to browse and search for the services.

1. Log on to the service provider’s application, which in this case is Integration Server client 002, with your user ID and password.

2. Run transaction WSPUBLISH (Publish Web Services).

3. In the Parameters section of the Publish web services screen, select your service name, and the Services Registry to which you want to publish the service, and then click on the Execute button. See Figure 23. A log file displays automatically informing you whether publication was successful.

4. To check the published service in the Services Registry, log on to the Services Registry URL:

http://<host name>:50000/sr with your user ID and password.

5. Enter the service name ManagePO in the search area, select the service provider system, and then click on the Go button.

You can see the published service in the Services Registry; it’s shown as the highlighted line at the bottom of Figure 24.

6. Click on Go again to see the details of the published service in the Services Registry, as shown in Figure 25.

At this stage, you have published the service definition and checked it into the Services Registry.

Consuming an enterprise serviceYou can consume enterprise services in ABAP via the Services Registry, the ESR, or the WSDL file. In the Services Registry, the service provider publishes the enterprise services to it for consumption. The consumer logs on to the Services Registry, browses and searches for the services, and consumes the service in its application. There are other options for consuming services using both ABAP and Java tools, such as SAP NetWeaver Developer Studio, SAP NetWeaver Visual Composer, Enterprise Services Explorer for .NET framework applications, etc.

Looking back at Figure 1, you can see that you have moved to the consumer side of the equation. Steps 4a, 4b, and 5 are discussed here.

1. Log on to the service consumer application (in this case, it’s client 003, which you launch from the SAP GUI tool) using your user ID and password.

2. To generate a client proxy, run transaction SE80 (Object Navigator).

3. Select Local Objects because you’re not trans-porting objects in this case. Expand the folder under your object name and then click on the Display button.

Figure 23 Setting parameters for publishing Web services

Execute button



4. Right-click on the Enterprise Services folder, and select Create, as shown in Figure 26.

5. Click on the Service Consumer radio button, as shown in Figure 27 on the next page, and click on Continue.

6. Select the URL/HTTP destination radio button as source, as shown in Figure 28 on the next page, and click on Continue.

7. In the next window, enter the URL for the Web

Figure 24 Finding the published service in the Services Registry

Figure 25 The details of the published service ManagePO

Figure 26 Creating an enterprise service



service you generated in client 002 earlier. To get the URL, log on to the service provider applica-tion (in this case, client 002), and then run transaction SOAMANAGER.

8. On the Web Service Administration screen, find the service definition ZManagePO and then click on it. Scroll down to the Overview tab, as shown in Figure 29.

9. Click on the Open WSDL document for the selected binding link. A new browser window page opens, as shown in Figure 30.

10. Copy the URL address from the new browser page, paste the URL in the wizard’s destination window, and click on Continue.

11. Click on the Local Object checkbox and enter ZPOC in the Prefix field (as shown in Figure 31

Figure 27 Selecting the object type for an enterprise service

Figure 28 Selecting the source for an enterprise service



on the next page), click on Continue, and then click on Finish.

12. In the next dialog, enter your user ID and pass-word to log on to client 002.

13. Then, save and activate your client proxy.

14. Define the logical port for the consumer proxy.

15. Log on to consumer client 003 using transaction SOAMANAGER.

16. Go to the enterprise SOA management page (Figure 18), and click on the Web Service Administration link.

17. Search for your consumer proxy service definition. In this example, the service definition for your consumer proxy is ZPOCCO_MANAGE_PO.

Figure 29 Displaying an overview of the ZMANAGEPO service definition

Figure 30 Sample WSDL document



18. Select your service, and click on the Apply Selection button.

19. The Details section of the service appears next. Click on the Configurations tab, and then click on the Create Logical Port button.

20. In the Logical Port Create pop-up window, enter the logical port parameters, as shown in Figure 32.

Note!

To get the value for the parameter URL for WSDL access, follow the steps described in steps 10 and 11 on page 86.

21. Click on the Apply Settings button to enter the input values, and then save the settings on the Web Services Administration page.

Now, you have created and generated consumer proxy objects in ABAP via the wizard, using WSDL and configuring the necessary connection and security settings to be consumed.

Implementing the client proxy via an ABAP report

To implement the consumer service application in ABAP, you create a report in which the consumer can use the client proxy program to execute the service.

1. In the consumer application (client 003), run trans-action SE80. Open the $TMP context menu.

2. Right-click on the folder named Programs, and select Create → Program. Enter the program name as Z_CREATEPO_CLIENT_002.

3. Uncheck the With TOP INCL. checkbox, and click on Save.

4. In the corresponding window, enter the title name Z_CREATEPO_CLIENT_002, as shown in Figure 33.

Figure 31 Entering the package/request for the proxy object

Note!

You can check the consumer proxy service definition name in transaction SE80.



Figure 32 Setting up the logical port parameters

Figure 33 ABAP program attributes



REPORT Z_CREATEPO_CLIENT_002.

DATA: ZCREATEPO TYPE REF TO ZPOCCO_MANAGE_PO,

m_seq_prot TYPE ref to IF_WSPROTOCOL_SEQUENCE,

m_seq TYPE ref to IF_WS_CLIENT_SEQUENCE,

l_wsprot type ref to if_wsprotocol,

lv_seq TYPE SRT_SEQ_ID.

data: INPUT type ZPOCREATE_PO.

*parameters: VendorNo(10) type c.

parameters: PONum(10) type c.

parameters: PODate(8) type c.

parameters: POType(4) type c.

parameters: POGrp(4) type c.

parameters: Vendor(10) type c.

parameters: ItemNo(5) type c.

parameters: MatNo(10) type c.

parameters: Plant(4) type c.

parameters: DelDate(8) type c.

parameters: Qty(10) type c.

parameters: Price(10) type c.

input-Create_PO-ponum = PONum.

input-Create_PO-podate = PODate.

input-Create_PO-potype = POType.

input-Create_PO-pogrp = POGrp.

input-Create_PO-vendor = Vendor.

Figure 35 Code for the ABAP program

Figure 34 Creating an empty program



5. Select Executable program as Attributes Type, and click on the Save button to automatically create an empty program, as shown in Figure 34.

6. Copy the code in Figure 35 into this empty program after the line REPORT Z_CREATEPO_ CLIENT_002.

input-Create_PO-POItem-item_no = ItemNo.

input-Create_PO-POItem-mat_no = MatNo.

input-Create_PO-POItem-plant = Plant.

input-Create_PO-POItem-del_date = DelDate.

input-Create_PO-POItem-qty = Qty.

input-Create_PO-POItem-price = Price.

try.

CREATE OBJECT ZCREATEPO

EXPORTING

logical_port_name = 'LP_PO'.

* Generation of the sequence protocol and the sequence.

m_seq_prot ?= ZCREATEPO->get_protocol( if_wsprotocol=>sequence ).

m_seq = m_seq_prot->create_persistent_sequence( ).

* start sequencing and get ID

m_seq->begin( ).

m_seq_prot->set_client_sequence( m_seq ).

lv_seq = m_seq->get_id( ).

CALL METHOD ZCREATEPO->CREATE_PO

EXPORTING

INPUT = input.

* end sequencing and commit work

m_seq->end( ).

cl_soap_tx_factory=>commit_work( ).

write:/ 'Purchase Order Successfully created'.

CATCH CX_AI_SYSTEM_FAULT

CX_AI_APPLICATION_FAULT.

write : 'Error during proxy call'.

exit.

ENDTRY.

Figure 35 (continued)



7. From the Program menu, select the option to save and activate your program.

8. Then, click on Test → Direct Processing to test your program.

9. On the next screen, enter the values as shown in Figure 36. After you execute the report, you get a success message.

At this stage, you have successfully created and executed the service consumer client application via the ABAP report to create a purchase order in the consumer application. In the next section, we check to see whether the SearchPO operation of the service definition interface has successfully created the PO.

Testing the enterprise provider service using the Web Services Navigator tool

In this section you use the SAP Web Services Navigator tool to test the service using the service definition operation SearchPO. You enter the input parameters of the PO you created earlier.

1. Go to the SOA Management page (Figure 19) and select your service, ZMANAGEPO.

2. Click on the Apply Selection button to display the service’s Details section.

3. On the Overview tab, click on the Open Web Service navigator for selected binding link. The Web Service Navigator tool opens in a new browser page.

4. Log on with your user ID and password, and then click on OK.

5. Select the operation SearchPO.

6. Enter the input values, as shown in Figure 37; for example, PONum is 0000012345 and Vendor is 0000301000.

7. Click on Execute; for your results, see Figure 38.

At this stage, you have completed all of the necessary steps to design, implement, configure, publish, and test an enterprise service in ABAP from scratch using the enterprise SOA middleware tools for service-provisioning and service-consuming in SAP applications. In addition, using the SAP Web Services Navigator tool, you have learned how to test enterprise services easily.

Conclusion This article contains an introduction to the funda-mental concepts of provisioning and consuming

Figure 36 Program Z_CREATEPO_CLIENT_002



you to go deeply into the best-practices approach of defining the model and the business process first, and then implement the actual functionality.

What we want you to take away from this article is an understanding of how convenient it is to base a service implementation on a reusable service inter-face, and how well SAP NetWeaver tools interact to ensure a seamless, end-to-end scenario for provi-sioning and consuming services. Finally, it’s possible

enterprise services in ABAP within the overall context of the enterprise SOA approach. Through this overview of the main development steps and tools involved in this process, you can see the basic principles of the enterprise SOA approach. It involves combining a central repository of programming language-independent enterprise SOA metadata with back-end implementations of business functionality using ABAP. You can reuse an enterprise service in multiple processes. Creating it in the example enabled

Figure 37 PO input parameters

Figure 38 SearchPO results



to leverage the ABAP business functionality for which SAP is renowned in an open, standards-based enterprise SOA environment.

Acknowledgments

We would like to thank Harish Mehta (Developer NW-F SOA, SAP AG, Germany) for his valuable input and feedback on this article.

Prasad Illapani is a solution architect with the SAP NetWeaver integration team at SAP Labs LLC in Redmond, Washington. He focuses on both the development and systems areas of SOA middleware technologies at SAP. He is a regular speaker at SAP TechEd, Wellesley Information Services’ SAP Insider, and SDN conferences. He has been with SAP Labs for almost seven years. During this time, he has been part of the SAP Supplier Relationship Management (SAP SRM) team working as a Regional Implementation Group (RIG) Specialist in various Ramp-Up SAP SRM integration projects. Prasad holds a master’s degree in Computer Science and a bachelor’s degree in Civil Engineering. You may reach him at [email protected].

Susanne Rothaug is a product manager on the SAP NetWeaver SOA middleware team for SAP in Walldorf, Germany. She joined SAP six years ago and has worked in several areas within SAP NetWeaver product manage-ment. Currently, Susanne is focused on process integration and SOA topics. You may reach her at [email protected].

Note!

For more information, please visit the enterprise SOA middleware knowledge center on the SDN at www.sdn.sap.com/ irj/sdn/nw-soa.

When your team is searching for answers, turn to SAP Professional Journal — the deepest and broadest

independent knowledgebase of SAP expertise. With an electronic license to SAP Professional Journal,

you have instant access to thousands of programming tips and how-tos, admin best practices, portal

development advice, troubleshooting tutorials, and much more to help you support and optimize SAP

functionality. All from the world’s leading experts on SAP.

Call 1-781-751-8799 to tailor an electronic license for your team, or contact us by email at [email protected].

I GOT IT!

Use Pi71 Tools for Provisioning and Consuming Enterprise Services in Abap

Documents

Transcript of Use Pi71 Tools for Provisioning and Consuming Enterprise Services in Abap