Application Components v.s. Technology Platforms
As you know, SAP offers many business solutions, such as mySAP CRM, mySAP SCM, mySAP PLM, mySAP ERP. One SAP business solution may consist of one or more SAP application components – (SAP applications). For example, mySAP ERP solution mainly consists of SAP Enterprise Core Component (ECC) – the successor of R/3. Since we are interested in service-enabling the business functionalities (v.s. pure technological capabilities), the SAP application components are what we need to look at first.
SAP application components run on certain technology layer. By now, the latest version of SAP application components all runs on SAP NetWeaver, which is SAP’s latest technology platform. Older versions of SAP applications, such as R/3 4.6C, does not run on NetWeaver; they run on the technology layer often referred to as SAP BASIS.
“Why should I care about the technology layer, if all I want to do is to service-enable my application functionalities?” You may ask. We care about the technology layer because it offers (or not) us the technical capabilities to service enable the application functionalities.
“Wait a minute“, you say, “Aren’t all SAP business functionalities already service enabled?” Well, eventually they will all be. But we are not there yet. So, depends on what SAP application component you have, you may not have the functionalities you want already service-enabled. So next we will look at how to service-enable your existing SAP application components. This task depends largely on the technology layer the application component is running on.
Directly Enabling Web Services on the SAP Application Component
If your SAP application component runs on SAP Web Application Server (WebAS) 6.20 or later, then you can directly enable Web Services on the application component by using the application server’s native Web Service capabilities. Depending on the release of the underlying WebAS, the procedures and capabilities are different.
WebAS 6.40 (as in NetWeaver 2004) and WebAS 7.0 (as in NetWeaver 2004s)
In WebAS 6.40, SAP has completely redesigned the SOAP runtime and offered a new Web Service Framework, and thus the 6.20 style SOAP Processor, although still works, is deprecated. In WebAS 7.0 there is little change to the Web Services Framework introduced in WebAS 6.40, except the 6.20 style SOAP Processor is officially “deleted” (meaning: not supported any more).
In a WebAS 6.40-based SAP application component, such as SAP Enterprise Core Component (ECC) 5.0, or a WebAS 7.0-based application component, such as ECC 6.0, by default, few Web Services are pre-delivered by SAP. But it is pretty easy to create Web Services in a WebAS 6.40-based system. Broadly speaking, there are two approaches: Inside-Out and Outside-In.
Inside-Out: if within the SAP application component there already exist one or several RFMs or BAPIs that suit your needs, you can create Web Services based on them without any additional programming. The basic steps include:
- Using the Service Definition Wizard, which can be started from transaction SE80, SE37, or BAPI, to create a (Web) service definition from an RFM, a function group, or a BAPI.
- When creating the service, you have the option to rename or hide operations (methods) and parameters, define default values for parameters, and changing parameter types.
- After the service definition is created, you need to use transaction WSCONFIG to release the service definition for the SOAP runtime.
- Afterwards, by using transaction WSADMIN, you can for any released Web Service, call the Web service homepage which provides utilities for using and testing the Web Service, generate WDSL, configure the logging and tracing settings, and publish the Web Service as a Business Service in an UDDI registry.
Outside-In: if there are no RFMs or BAPIs once exposed as Web Services directly satisfy your needs, you can try the Outside-In approach. The basic steps include:
- First, you need to define a platform-independent interface for your desired Web Service. You can do this either by writing a WSDL file yourself (manually or with the help of some authoring tool), or, preferably, if you have a SAP Exchange Infrastructure (XI) system within you landscape, using the XI Integration Builder to define a Message Interface. The benefit of using XI is that it serves as a central repository of all the Web Services in your enterprise.
- After that, you can then generate the Server Proxy for the interface within the 6.40-based application component system, using transaction SE80 with menu path Edit Objects -> Enterprise Services -> Server Proxy, or using transaction SPROXY and referring to the XI message interface.
- Once the server proxy skeleton is generated, you need to finish the implementation of the server proxy with ABAP coding, say, calling existing RFMs/BAPIs as needed.
- Afterwards, same as in the Inside-Out case, you create the Web Service Definition, configure it, and release it as Web Services, using transaction SE80, WSCONFIG and WSADMIN respectively.
This Server Proxy-based Web Service can then be directly consumed by outside Web Service clients. In addition, the Server Proxy can be used in XI scenarios, through native XI protocol communications between the XI Integration Engine and the 6.40 system’s local Integration Engine.
“OK. My SAP application component, say, R/3 4.6C, is not running on WebAS 6.20 or 6.40. What can I do to service-enable it?” Well, all hopes are not lost. For example, you can still use SAP Exchange Infrastructure to service-enable it.
Using SAP XI to Enable Brokered Web Services
SAP XI is a central enterprise-scale XML-based integration broker. You can use XI to enable brokered (mediated, managed, or “value-added”) Web Services for your SAP application components, even when these application components do not have native Web Services capability. The following diagram illustrates how XI can be used to service-enable SAP applications.
To implement such a XI-brokered Web Service, you need to:
- Import the RFM or IDoc object from the target SAP application component to the XI Repository.
- Define the necessary Interface Objects (Data Types, Message Types, and Message Interface) for your XI-brokered Web Service in the XI Repository.
- Define the necessary Mapping Objects (Message Mappings and Interface Mapping) in XI Repository to map your Message Interface to the SAP RFM or IDoc.
Define a Business System entry for your SOAP Client, and create a SOAP Sender communication channel. You need to specify the default Interface Namespace and Interface Name for this communication channel. Details can be found here .
Define a Business System entry for your target SAP system, and create the RFC (for calling RFMs) or IDoc (for posting IDocs) communication channel.
For IDoc communication, you also need to configure the Integration Server .
The generated WSDL can then be used by the SOAP client to invoke the Web Service.
More details of the wizard can be found here .
In addition to the SOAP Adapter, you can also use other XI adapters, such as the plain HTTP Adapter, to connect your client system with the XI system. Have a look at this article written by Christoph Claus for more details.
In addition to use SAP XI to implement brokered services for your application component that runs on a platform lacking native Web Services capability, there are a few other options available to expose the SAP application functionalities as Web Services.
- Using a WebAS 6.40 ABAP server
You can setup a 6.40 or later WebAS ABAP server in front of your application component system. You can then use the Inside-Out approach, i.e., writing a custom RFC-enabled function module (Z function module), in which you invoke the functionalities of the application component, e.g. by using the CALL FUNCTION … DESTINATION … statement to call an RFM or BAPI in the application component. Or you can use the Outside-In approach, i.e., define interface first, then generate Server Proxy, from which you invoke the functionalities of the application component.
Afterwards, you can then use the above-mentioned WebAS 6.40 ABAP’s Web Services Framework to expose your custom RFM or Server Proxy as a Web Service.
- Using a WebAS 6.40 Java server
You can setup a 6.40 or later WebAS Java server in front of your application component system. You can then develop an Enterprise JavaBean or a Java class, in which you invoke the functionalities of the SAP application component, by using the SAP Java Connector. Afterwards, you can then use the WebAS 6.40 Java’s Web Services Framework (this is different from that of ABAP) to expose the EJB or the Java class as a Web Service. Details of creating Java Web Services can be found here .
- SAP Enterprise Portal
The SAP Enterprise Portal is primarily a web portal product, and it is hard for me to figure out why one would want to expose SAP application functionalities as Web Services through portal. Nonetheless it is technically feasible. To do that, you first need to create a Portal Service that invokes the functionalities of the SAP application component using the SAP Java Connector. Then you can create a Web Service from the Portal Service. For details, please see your PDK document.
- SAP BC
SAP Business Connector (SAP BC) has been around for quite a while, and is gradually being replaced by SAP XI. So, for new projects, you should definitely stay away from SAP BC. But if you are still using SAP BC, you may know that you can also use it to expose SAP application functionalities as Web Services. To do that, you first need to build a BC service that invokes the functionalities of the SAP application component, e.g., by calling RFMs/BAPIs or posting IDocs. Afterwards, you need to register the BC service as target service for the BC Default SOAP Processor, or the BC SOAP RPC Processor, or if necessary, your own custom BC SOAP Processor. For details, please refer to the SAP Business Connector
SOAP Programming Guide.
The Future Is Going To Be Brighter
“Gee, I wish SAP could have already done all these service-enabling for me!” Well, we heard you saying. Sure enough, SAP is working hard towards that direction. Early this year (2005) SAP demonstrated an ESA preview system which has 500 or so enterprise services. Soon, SAP will introduce an Enterprise Service Community Process through which you, SAP customers and partners, will have opportunities to shape the Enterprise Services offerings. SAP is committed to service-enable all its application components and offer commonly-used business functionalities as Enterprise Services by 2007. As always, the future is going to be brighter 🙂 So, stay tuned!