Skip to Content
Author's profile photo Former Member

Service Enable Your SAP Application Component

How to service enable my SAP systems (or, more fancifully, SAP application assets)?”  More and more often we are facing this question.  “Oh, that’s easy.  Just deploy ESA!”  You may hear people saying.  Sure, that’s certainly a correct answer, but it may or may not be helpful, depending on where you are in our release upgrade cycle.  In this blog, I will try to give a more practical, comprehensive, and accurate roadmap for service-enabling your SAP application components.

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.20

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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.

For more information about the Web Services Framework, see SAP library
SOAP Framework

and  Web Service Toolset

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:

    1. Import the RFM or IDoc object from the target SAP application component to the XI Repository.
    2. Define the necessary Interface Objects (Data Types, Message Types, and Message Interface) for your XI-brokered Web Service in the XI Repository.
    3. 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.

Other Options

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.

    1. 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.

    2. 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 .

    1. 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.

    2. 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!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      A great weblog Robert, was quite useful in understanding the SOAP roadmap.

      But, what was disturbing was your statement that the 620 sytle SOAP processor is deprecated. I was not aware of it, in fact, we are using it extensively to "service-enable" a lot of back end business logic. (Our architecure follows the principle desribed in Joerg's weblog - [original link is broken] [original link is broken] Joerg, if you are reading this, please start writing again.)

      Even though the 640 method offers a good functionality, in its raw form, the 620 method was a very nice way of allowing SOAP calls to any FM (basically build alternative front ends). For example, use MS Infopath to create forms that can access SAP FM via SOAP. The 620 sytle processor does work on a 640 system, so i guess we can do an incremental upgrade; but it definitely means that we have budget time and money. Too bad, i hope SAP continues support for the 620 processor.

      Regards, Parag.

      Author's profile photo Former Member
      Former Member

      Thanks for the comments!

      Regarding the 6.20 SOAP Processor:

      - In WebAS 6.40 (NW2004) SAP provides the redesigned Web Services Framework, which replaced the 6.20 SOAP Processor.

      - A SOAP Migration Guide 6.20 to 6.40 is provided here:

      - In WebAS 7.0 (NW2004s), the SOAP Processor is “deleted” (meaning: not supported any more):

      Happy New Year!



      Author's profile photo Former Member
      Former Member
      Thanks Robert,
      this blog gave us the details that we can develop webservice using out side in approach without having XI in our landscape.
      I have tried generating server proxy in ECC60 ( WAS 7.0 )as you mentioned.It generates proxy class but in Enterprise Services-->client proxy folder. Can you please let us know how we can create WSD in SE80 as it generates only class not RFM.

      Abdul Raheem S

      Author's profile photo Former Member
      Former Member
      I’ve updated the blog with additional information on Outside-In approach to service-enable 6.40-based application components.

      Hopefully this little blog now provides a comprehensive and accurate roadmap for service-enabling your SAP application components.  Enjoy!

      Author's profile photo Former Member
      Former Member

      This is great synopsis of how to use web services with more coarse grained interfaces to be leveraged in lots of integration scenarios.

      One quick question. If we've done a lot of "inside out" or direct Java based exposing of web services within WAS what will the effort to move them into the ESR once its released? Are there ways to plan in advance for this?


      Author's profile photo Former Member
      Former Member
      Good question!  It’s great that people like you are keeping an eye on the future.

      We have all been waiting for the coming of ESR, and SAP has yet to publicly release detailed information about it.  But one thing I guess I can safely say is that the ESR will be based on XI Integration Repository.  So the outside-in scenarios will have an easier time migrating to ESR.  I would hope that some help (tools, guidelines, etc.) will also be provided to publishing inside-out scenarios in ESR, but that remains to be seen.


      Author's profile photo Former Member
      Former Member
      Thanks Robert...this provides some good details about how customers and partners can service enable their solutions to begin leveraging the benefits of SOA and ultimately ESA.