Access SAP Business Functions (ABAP) via Web Services

Transcription

1 Applies To: SAP R/3 4.6c and ECC 5.0 SAP NetWeaver 04 WebAS 6.40 SP14 and up, XI 3.0 SP14, NWDS SAP NW2004s WebAS 700, NWDS Microsoft Visual Studio 2005, BizTalk Server 2006,.NET Framework 2.0 Summary The goal of this article is to show readers who are new to SAP and web services that there are many different ways to access SAP ABAP business functions via web services through different NetWeaver components, and accessing these web services from non-sap platform such as Microsoft.NET is very easy. This article analyzed the appropriate context in which each web service approach can be used. The web services capabilities discussed and revealed in this article play important roles in realizing SAP s ESA and its open ecosystem strategy. By: Wallace Su Company: SAP Labs, Palo Alto Date: 10 March 2006 Table of Contents Applies To:...1 Summary...1 Table of Contents...1 Introduction...2 History View...2 Business Scenario...2 Technical Overview...3 ABAP Web Services...4 Out-of-the-Box RFC Web Services...4 Create Your Own ABAP Web Service...5 XI Web Services...7 XI Proxy Based Web Services...8 Brokered Web Services via XI...9 1

2 Consume Web Services in XI...11 Java Web Services...12 Expose Web Service in Web AS Java (J2EE)...12 Consume Web Services in Java (Using NWDS)...15 Summary...16 Consume SAP Web Services from.net Application...16 Related SDN References...19 Conclusion...19 Author Bio...20 Disclaimer & Liability Notice...20 Introduction Accessing SAP business functions in ABAP using web services is a hot topic and there is lots of documentation explaining different pieces of it (see SDN references at the end of this article). In this article, I will try to pull together related information in this area and give readers who are new to SAP and web services a good overview of what s available and where to apply these techniques. This article will focus on accessing ABAP functions in ERP, SCM, CRM, and etc. As a developer, I want the flexibility to access these great ABAP business functions from a variety of development platforms using standard web service technology, and I should be able to do this from Visual Studio.NET just as easy as doing it from SAP s own NetWeaver Developer Studio (NWDS). History View Historically, SAP business data and processes are externally available through ABAP-based communication technologies (e.g., IDOCS, RFC, ALE, BAPI), which are the basis of many connector/adapter products, including those from SAP (such as the SAP Java Connector and the SAP.NET Connector). Accessing SAP business functions from the non-sap world had been limited to using these SAP proprietary technologies. Since WebAS 6.20, SAP started to make business functions available through standard based web service technologies. Building on its NetWeaver platform, SAP is exposing more and more business functions as web services today. The NetWeaver platform consists of many components that are capable of exposing web services. I will explore the web service capabilities in Web AS Java (SAP s J2EE server), Web AS ABAP, and XI in this article. I will also use Microsoft.NET applications as examples to show how easy it is to consume ABAP business functions once they are exposed as web services. Business Scenario To demonstrate how easy it is to consume SAP business functions as a web service, I chose to test a simple.net application built with Visual Studio 2005 (I tested both a C# application and a BizTalk process) to access an existing BAPI function module in the SAP ERP (I tested both ECC 5.0 and R/3 4.6C). I used an existing BAPI called BAPI_CUSTOMER_GETDETAIL which retrieves customer detailed information in my implementation. 2

3 Technical Overview Before I build the simple.net application, let s look at some options on how to expose web services for SAP ABAP business functions. The great news is that SAP has provided web services support in Web AS Java, XI, and Web AS ABAP directly to cater for different development needs. The following figure provides an overview of the web service capabilities exposed in different areas of NetWeaver: Figure 1 Many Choices of Using Web Services in NetWeaver In Figure 1, ABAP function modules in ECC 5.0 can be exposed as web services either directly or via proxy technologies. When using proxy technology to expose web services, services are defined in XI and exposed in the ABAP stack. A web service consumer application can then load the WSDL and invoke the ABAP web service. Alternatively, XI can front-end the ABAP function modules in both ECC 5.0 and R/3 4.6c via different inbound adapters (only RFC and XI Adapters are shown in this figure other adapters are also possible, such as using the receiver SOAP adapter). Then, XI can expose the message interfaces (XI term) as web services through the sender SOAP adapter with value-added functionalities (for example, data mappings between senders and receivers). A web service consumer application can then load the WSDL and invoke the XI web service. Similarly, EJB can also front-end the ABAP function modules in both ECC 5.0 and R/3 4.6c using JCo or consuming the ABAP web services directly (not shown in this figure) or through XI (web service call is shown in the figure Java proxy is also possible) as the intermediary. The EJB itself can be exposed as web service. A web service consumer application can then load the WSDL and invoke the Java web service. The message flow in red color in Figure 1 is used in the.net example implementation. Note that the possible web service invocation scenarios described above may not be a complete list. Nonetheless, we will focus on these scenarios and drill down into more details in the following sections. 3

4 ABAP Web Services Out-of-the-Box RFC Web Services Many SAP business processes and data can be accessed through RFC-enabled function modules. BAPIs are implemented as RFC-enabled function modules and provide standardized programming interface (you can call transaction BAPI to access the BAPI Explorer). All RFC-enabled function modules (so all the BAPIs) are exposed as web services by default (i.e. no work needed to make them web services). This feature is available since WebAS 6.20 and can be accessed through the following URL (see Figure 2): Figure 2 Web Service Browser for RFC-enabled Function Modules To retrieve the WSDL for an individual function module, use the following URL: This feature makes it very convenient for someone who needs to invoke a RFC or BAPI directly through web services and needs nothing else. But note that this feature is only available to out-of-the-box RFC function modules. Also, these vanilla web services do not provide much more than the basic web service invocation. For instance, if you need to change the input or output signature of the service, or add some additional processing logic before or after you invoke the web service, you cannot modify these web services to do so. There is also no way to set up web service security profiles. 4

5 Create Your Own ABAP Web Service The out-of-the-box RFC web service works great if it fits your needs. Since WebAS 6.40, web services can be defined for RFC-enabled function modules, function groups, business objects, and XI message interfaces (will be discussed in XI Proxy Based Web Services). This means you have the opportunity to build your own function modules, or add additional logic to existing function modules, and create your own ABAP web services for them. This is a good option to create web services if you are an ABAP developer, or enjoys doing some coding in ABAP. This is an inside-out approach to develop web services. This is done using SAP s Web Service Creation Wizard which is available from the ABAP Development Workbench (by calling transaction SE80 see Figure 3). Figure 3 Create Web Service Wizard (ABAP Workbench) I copied the following procedures from SAP online documentation in Table 1 as a quick reference: Action: Meaning: Creating a Virtual Interface The virtual interface is the interface between the Web service and the outside world. Enter a name and description for the virtual interface. Choose an endpoint. 5

6 If the checkbox Mapping of Names is checked, the wizard accepts the existing names for the endpoint. Initial letters are in upper case and underscores are removed If you do not want to do this, the virtual interface and Web service definition are created with the existing names from the endpoint. Choose the endpoint You choose the object that you want to offer as a Web service. For business objects, enter the application. Choose operations For BAPIs and function groups, choose the operations for which the Web service is to be created (see also: Creating a Virtual Interface for a Function Group/BAPI). Creating a Web service definition You use the Web service definition to assign features to the Web service. The features are based on, among other things, questions of security in data transfer and on the type of communication. The Web service definition refers to the virtual interface defined earlier. Enter a name and description for the WSD. Choose a predefined feature set from the profiles available. Basic Auth SOAP profile: 1. Communication type: Stateless 2. Caller authentication: User and password Secure SOAP profile: 1. Communication type: Stateless 2. Authentication: Client certificate 3. Transferred data is encrypted using the Secure Socket Layer protocol. For more information on the features in the profiles, see Creating a Web Service Definition. Release the Web service The system creates the virtual interface and the Web service definition. Finally, you release the Web service for the SOAP Runtime. Table 1 Steps of Using the Web Service Creation Wizard Web services created this way are built from inside-out, but they cannot be searched or browsed like in Figure 2. Instead, you can call transaction WSADMIN and use the highlighted buttons to obtain the WSDL for the 6

7 released web service individually (see Figure 4). Usually, web services generated this way have a URL prefix like the following: Generate a WSDL document for this Web service Launch this Web service home page Figure 4 Obtain WSDL of Web Service Published to SOAP Runtime Alternatively, you can also publish the web service to a UDDI registry, also from transaction WSADMIN. The Web service can then be searched for in the UDDI using either a browser or the standard UDDI APIs. Please refer to SAP documentation on how to do this. In addition, you can assign quality of services (QoS) to the web services created this way, such as assigning security profiles. However, both options I discussed above are not available if you are running older versions of the ERP such as 4.6C. In addition, if you are not an ABAP developer, either because you can only code in Java or do not want to code at all, SAP provides other options to expose web services for accessing the ABAP functions. XI Web Services XI is great because XI provides a lot of options (and flexibilities) when it comes to connecting the SAP ABAP world. For example, there are out-of-the-box RFC and IDOC adapters that you can use to connect to both ECC 5.0 and R/3 4.6C. In addition, XI provides configuration driven, value-added services such as data transformation (mapping), content-based routing, and business process orchestration (through the ccbpm 7

8 component). But most interestingly, in the context of web services, XI provides an interface-driven development approach that developers can use to design web services from outside-in. XI can be used to provide web services in two ways, which are explained next. XI Proxy Based Web Services First you model the message interface in the Integration Repository (using Integration Builder) in three 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. The next step is to move to the ABAP development system, and use the transaction SPROXY to generate the proxy. Then, you need to insert the implementation for the proxy class. This is also done in ABAP. So you must be able to do some ABAP coding (see Figure 5). Click this to implement your ABAP code for the proxy class Figure 5 ABAP Proxy Generation 8

9 Finally, you need to define the web service using the Web Service Creation Wizard described in Table 1 (only available since Web AS 6.40). Usually, web services generated this way have a URL prefix like the following: Please refer to the SDN References section for step-by-step details (and screen shots) on how to do this. What I like about this approach is that the development process is interface driven and done entirely in the XI design time environment. This approach does require writing some ABAP code to implement the proxy business logic, which may be a few lines of ABAP code that call an existing function module and return promptly or some additional processing logic. Note that only synchronous server proxies can be defined as web services. The web services designed this way are actually exposed from the SOAP runtime on the ABAP side, not from XI. In other words, XI is only used for design time activities. Although XI proxy technology was originally created as a XI connectivity tool, the web service enablement of the ABAP proxies makes it accessible in a different way. Brokered Web Services via XI In a bigger picture, XI can be viewed as a broker or intermediary to the ABAP function modules and expose them as web services. XI can be used to implement such common tasks like data transformation (mapping) and content-based routing without having to code in ABAP or other programming languages. More complex business orchestration logic can also be implemented in ccbpm (available from the same XI design time tool). In XI, I can access the ABAP function modules in a variety of different ways. For instance, I can have XI call the ABAP proxy we discussed in the previous section through the XI protocol (some people refer this as XI Adapter ), which is actually based on SOAP (with SAP extensions). Alternatively, I can import RFC or IDOC metadata from the ABAP applications and use the built-in RFC or IDOC adapters in XI to call them. Then I can wrap the ABAP functionality in a XI message interface (design data types and interfaces the same way as previously discussed) and create Receiver and Interface Determinations (XI terms). Next, I will configure a sender SOAP adapter in XI to expose the message interface as a web service. Finally, I will use the wizard in Integration Builder (Configuration) to generate the WSDL for this web service (see Figure 6). 9

10 Figure 6 Define Web Service Wizard from XI Note that the wizard only generates the WSDL for the sender SOAP adapter you configured. It does not make this web service available from browser interfaces or in any web service registry. In fact, you have to save the wsdl to a file for future consumption. To create the correct WSDL port address used by the XI sender SOAP adapter, type in the following URL prefix instead of clicking on the Propose URL button in the wizard (see Figure 7): You can leave party blank if there is no party in your XI configuration (but make sure to leave the : after party in the URL; service is the name of the sender service, and channel is the name of the sender SOAP adapter. Please see SDN References for configuration details. Although XI web services exposed this way are not browsable, you can easily wrap it around in a Java proxy object and expose that Java proxy object in an EJB web service (see next section). Then it will be available from the Java web service navigator page. 10

11 Consume Web Services in XI Figure 7 Using WSDL Generation Wizard in XI XI can also access backend ABAP function modules by calling web services exposed directly out of ABAP using the receiver SOAP adapter. To do this, you can create an External Definition in Integration Repository by importing the WSDL file of the exposed ABAP web services (See Figure 8). The imported web service message types can be used to design your XI message interfaces. 11

12 Java Web Services Figure 8 Load WSDL as External Definition in IR For those developers who use Java as their primary development platform, SAP NetWeaver Developer Studio (NWDS and are the versions that I tested) provides plenty of support to build web services. Expose Web Service in Web AS Java (J2EE) EJBs and Java classes can be exposed as web services in SAP s J2EE server. To create web service in Java, open the J2EE Development perspective, and create an EJB and its respective methods. The EJB can be exposed as a web service. To do this, use the web service creation wizard from the EJB (see Figure 9). 12

13 Figure 9 Create Web Service for EJB in NWDS After web service is defined for the EJB, the EJB needs to be deployed to the J2EE engine to be accessible. With successful deployment, you can use the following URL to access the WSDL of the web service. The WebServiceName and ConfigurationName in the URL correspond to the following values in the NWDS wizard (see Figure 10). 13

14 Figure 10 NWDS Web Service Creation Wizard The deployed Java web services can also be browsed through the following URL (see Figure 11): 14

15 Figure 11 J2EE Web Services Navigator Click on the web service of interest, and you will be able to download/view its details (including WSDL), and conduct basic testing (SOAP over plain HTTP only). Consume Web Services in Java (Using NWDS) To access web services exposed from ABAP or XI, NWDS provides wizard-driven GUI to create Java proxy objects for the web services without a single line of coding. First you need to create a project of type Web Services -> Deployable Proxy or Standalone Proxy (from File->New->Project). Next you can use the wizard to create a client proxy (New->Client Proxy Definition) for the web service you want to use (see Figure 12). The wizard will prompt you to enter the location of the WSDL. Once it s finished, it will create the logical port and the Java classes that you can use in other places of your project. 15

16 Figure 12 Create Client Proxy for Web Service in NWDS In both cases where NWDS is used to create an EJB that provides a web service interface, or to create a Java proxy that consumes a web service, you can configure security on both the transport level and document/message level. Summary As I showed you in the above discussions, accessing ABAP functions via web services has many choices. Which choice to take, or whether or not to use web services at all, depends on many other factors that I did not cover in this article. The factors to consider include performance, reliability and security of the messaging protocols, and the available tools and skill set in your project. Consume SAP Web Services from.net Application Now let s look at the implementation of how to consume a SAP web service discussed in the technical overview section from a.net application. In my first implementation, I have the.net application (a C# Windows Application) call the web service exposed by XI sender SOAP adapter. Only HTTP basic authentication is used for the SOAP request. I had used XI to design the message interface needed by the.net application and perform the data transformation so that only required input data are sent to XI and a subset of the BAPI_CUSTOMER_GETDETAIL return result are returned to the.net application. Then I configured a RFC adapter in XI to access the backend BAPI function. This call is synchronous and the message flow is illustrated in red color in Figure 1. In my Visual Studio 2005 project, I use Project->Add Web Reference to add a wsdl reference to the.net project (see Figure 13). The wsdl URL will be a URL outlined in the previous sections or a local file absolute path in the case of XI exposed web service. During my implementation, I found that Visual Studio 2005 has a problem importing XI generated wsdl file. The workaround is to use the wsdl.exe tool from Visual Studio

17 command line prompt to generate the proxy classes, or add the following namespace xsd in the <wsdl:definitions> element in the XI wsdl file: <wsdl:definitions... xmlns:xsd=" Figure 13 Import WSDL in Visual Studio 2005 The following C# code is used to invoke the get customer detail web service with HTTP basic authentication: // create web service proxy object. getcustomerdetail2service class is // generated by importing the wsdl getcustomerdetail2service customerproxy = new getcustomerdetail2service(); // set HTTP basic auth NetworkCredential credentials = new NetworkCredential("user", "pwd", ""); customerproxy.credentials = credentials; // set up HTTP proxy IWebProxy proxyobject = new WebProxy(" false); customerproxy.proxy = proxyobject; // assign input params 17

18 customer_getdetail2_req customerrequest = new customer_getdetail2_req(); customerrequest.companycode = ""; customerrequest.customerno = "C2000"; try { customer_getdetail2_resp customerresponse = new customer_getdetail2_resp(); // invoke the XI web service customerresponse = customerproxy.getcustomerdetail2(customerrequest); Console.WriteLine(customerResponse.customerAddress.name.ToString()); } catch (Exception reqexception) { Console.WriteLine(reqException.ToString()); } The above code sample demonstrated how easy it is to call a SAP web service from a C#.NET program. I then built an equally simple BizTalk process to call the same XI web service, as shown in Figure

19 Figure 14 BizTalk Process Calls the SAP Web Service In a separate article, I will show you the implementation details of how to secure the above implementation using Web Service Security standards in NetWeaver. Related SDN References There are lots of good content on SDN that discussed either the basics or the details of SAP s web services technology. The following are a partial list that I found on SDN. Here are some relevant SDN articles: Web Service Technology for SAP NetWeaver How to Set Up a Web Service Related Scenario with SAP XI And a list of related SDN web logs: Communication between SAP System & Web Service Using Proxies (and a related web log on ABAP Server Proxies) Developing ABAP Web Services Web Service Navigator Page for ABAP and Java and Part 2 Publishing ABAP Web Services to an External UDDI Server And the official SAP documentation: Web Services Toolset Web Service Development Manual Configure XI Sender SOAP Adapter And finally, the upcoming book from SAP (Enterprise Services Architecture: Designing IT for Business Innovation) has a really detailed chapter on How to Create Enterprise Services that covers the tools and processes of creating services. Conclusion SAP provides comprehensive web services support in NetWeaver Web AS Java, XI, and Web AS ABAP to cater for different development needs. This article reviewed different technical approaches of using web services to access SAP business functions in ABAP and demonstrated a.net example to consume those web services. There are other SAP NetWeaver components and developer tools that also provide web services support and you can find related information on SDN in areas such as EP, BW, MDM, and CAF. Whether or not to use web service and which web service to use to access SAP ABAP functions in your project depends on many other factors that I did not cover in this article. The factors to consider include performance, reliability and security of the messaging protocols, and the available tools and skill set in your project. 19

20 Author Bio Wallace Su supports early adopters within SAP's ecosystem to take advantage of the Enterprise Services Architecture and SAP s Business Process Platform in SAP s Market Development Engineering team. Prior to taking this role in SAP, Wallace has held senior technical and project management positions at TIBCO, Apple Computer, and other Silicon Valley companies with more than 10 years of industry experience. Wallace specializes in web services, enterprise application integration, and messaging systems. Disclaimer & Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document. 20