SAP interfacing: consuming web services

In the previous blog we have exposed a web service. Now we will show how to consume a web service in ABAP. As example we will consume the web service we exposed in the previous blog.

Questions that will be answered in the blog are:

  • How to generate a web service consumption proxy?
  • How to setup SOAMANAGER for web service consumption?
  • How to test the web service consumption setup in SE80?
  • How to use the generated web service consumption proxy in ABAP code?
  • What are the authorisation and security aspects for web service consumption?

Generating web service consumption proxy

Start in SE80 by exporting the WSDL file from your previously generated webservice. Goto the WSDL tab and press export to save the WSDL file locally:

In SE80 in your package select Enterprise Services and right click on it to create a new service:

In the object type screen select Service Consumer:

Now select External WSDL/schema:

Select local file:

Select the local file:

Select the package, transport and use Z as prefix:

Then select Finish to complete the roadmap.

Wait for the system to compile the software:

Save and Activate. Now the design time proxy is ready.

SOAMANAGER settings

In the previous steps we have setup the design time proxy. Now we add the runtime artefacts as well.

Now goto transaction SOAMANAGER:

Select Web Service Configuration, and search for the newly created design time object:

Click on the blue internal name to reach the configuration screen:

On the screen press Create and then manual configuration:

Give the logical port a name and description and mark the logical port is Default tickbox to true. Then continue with the roadmap.

Now fill out user ID and password. Continue and fill out user ID and password:

You can lookup the access URL from the service defined in the previous blog and check on the transport settings tab:

Do not use the WSDL URL address, but the binding URL!

Now fill out the URL details in the next screen.

Now finish the roadmap. And on this screen hit the ping web service test button to check if all is ok:

The design time artefacts can be transported. The SOAMANAGER settings need to be repeated in each system. This is wanted as well, since on a test system you might want to call a test web service URL and on production the same web service from the production URL.

Testing the web service consumption setup

Now go back to SE80 and test the web service consumption:

Select the port you created above in SOAMANAGER:

Edit the data:

And press test to get the results:

Using the web service consumption proxy in ABAP code

Now we are ready to use the web service consumption proxy in our ABAP code. ABAP code example:

*&---------------------------------------------------------------------*
*& Report ZCONSUMEWS
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zconsumews.

* Data Declarations
DATA: zcl_proxy TYPE REF TO zco_zbapidemowebservice, " Proxy Class
      zdata_in  TYPE zzbapidemo, " Proxy Input
      zdata_out TYPE zzbapidemoresponse, " Proxy Output
      zfault    TYPE REF TO cx_root. " Generic Fault

* Instantiate the proxy class providing the Logical port name
CREATE OBJECT zcl_proxy EXPORTING logical_port_name = 'ZDEMOWS'.

* Set Fixed Values
zdata_in-zimport = '1'.

TRY .
    zcl_proxy->zbapidemo( EXPORTING input = zdata_in
                          IMPORTING output = zdata_out ).
    WRITE: / zdata_out-zexport.
  CATCH cx_root INTO zfault.
* here is the place for error handling

ENDTRY.

Run the ABAP and see the result:

How to get the right parameters? All the required structures can be found on the SE80 ABAP web service consumption proxy internal view:

Authorizations

The end users using the ABAP that is consuming the web service must be given the rights for the correct S_SERVICE object. Otherwise they will get an error that they are not authorized to call the proxy service object.

Background notes and blogs

More information and details can be found in these 2 SAP wiki’s: wiki1 and wiki2.

Relevant OSS notes:

SAP interfacing: exposing web services

In the previous blog we have created a test RFC module. We now will expose this test RFC module as web service. This blog assumes the basic SOAP web service runtime has been done according to the manual in this blog.

Questions that will be answered are:

  • How can I generate a web service design time based on an RFC module?
  • How do I activate the web service runtime via SOAMANAGER?
  • How do I test my web service?

Creating the web service based on RFC module

Goto transaction SE80 and search for the test BAPI:

Now right click on the name ZBAPIDEMO function module and select the option Create / Enterprise Service:

Fill out the name for the service definition and the description. Press Cont. to continue to the next screen:

Press Cont to go to the next step:

Press Cont. to go to the next screen:

Fill out your package and transport request.

Important here: on a sandbox you might want to use a local object ($TMP). In a development system, NEVER use the local option. A lot of data structures and coding will be generated. If you later try to move the objects from $TMP to a real package, you will be faced with a lot of issues. See note  886682 - Proxy inconsistencies on the use of repair programs SXIVERI_PROXY_HASHID_CHECK and  SXIVERI_PROXY_HASHID_CHECK_70. After the cumbersome and painfull repair you will not make the mistake again... 

Press Cont. to goto the last screen:

On the screen you can already see the next action after completion: SOAMANAGER. But first press Complete to start the generation of the objects.

After the generation, do not forget to Activate the objects!

Activation success message:

Setting up the runtime with SOAMANAGER

To setup the runtime, start transaction SOAMANAGER. It is assumed that the basis team has performed the initial SOAP runtime setup. If not done, ask the basis team to follow the steps in this blog.

On the SOAMANAGER start screen choose the option Web Service Configuration:

In the next screen search for the design time object we created and activated in the previous section (if you forgot the activate, you will not find it now…):

Select the service and on the next screen press the button Create Service:

Fill out the definition details:

Press Next and define the security settings:

Remark: in the newer versions, the default security is set to high. If you need lower security, go back to SE80 definition in the tab configuration to change the security profile (save and regenerate!):

Press next and define the SOAP protocol settings:

On the last screen of the wizard press finish:

Wait for the runtime generation to finish.

The screen returns to the generated runtime artefacts:

The most important artefact is WSDL file which you can open from here.

Testing the service

Goto transaction SE80 and select the Enterprise Services Browser (if not visible goto menu path Utilities/Settings and add the tool):

Now open your service by clicking the Open Object button and search for the service in the second tab:

Check that the WSDL file is properly showing:

If ok, press the test button (F8) to start the test tool:

On the next screen first press the XML editor button to allow the content to be changed:

Now press execute to test. The result:

Web service security

The functionality security of the web service is the same as for the generic RFC handling (see blog on this).

The technical security of web services is mainly driven from the security settings in SOAMANAGER. There you can set the transport protocol security and you can indicate if you want simple user ID / password security or work with additional certificates for server to server authentication.

The user calling the SAP web service must have the authorization object S_SERVICE. In S_SERVICE you can define the specific web service it needs to be able to call.

Troubleshooting web services security issues

For troubleshooting web services note 2321968 – SOAP Web Service Security Troubleshooting refers to a very extensive SAP site for web service security issues troubleshooting.

Monitoring web services

For monitoring web services, read this dedicated blog.

Basic activation of webservice SOAP runtime

This blog will explain how to activate the SOAP runtime inside the ABAP stack. This is a mandatory step before you can set up web services in transaction SOAMANAGER.

Questions that will be answered are:

  • What steps are required for the setup?
  • How can I check if the setup is done properly?
  • What are potential issue solving actions?
  • What other tools are available?

Setting up the SOAP runtime

Setting up the SOAP runtime is extensively explained in OSS note 1043195 – Configuration of Web service runtime. The basic steps below have to be repeated twice: first you execute the actions in client 000, then in the main data client again.

Start transaction SRT_TOOLS for reaching the main tool set:

SRT_TOOLS start screen

In the Technical Configuration section select the tool for Technical Web Service Configuration. This will bring you to the main activation program:

Automated technical configuration

Hit Execute to start the automatic configuration. For more information see OSS note 2347013 – Configuration of the ABAP Web Service Runtime with transaction SRT_ADMIN.

In case of issues with the creation of user DELAY_LOGON, check this OSS note:

2848763 – Creation of DELAY_LOGON user using SRT_ADMIN does not work reliably.

Checking the configuration

To check if is ok go back to the main screen and select the Check Technical Web Service Config tool. This is the start screen:

Check technical configuration

Start the check. Result should be like screen shot below:

Technical check check result

Issue solving during setup

During setup things might go wrong. If you run without SAP_ALL, please check the notes that you have sufficient authorization. In the process both a background user (SAP_WSRT and¬†DELAY_LOGON) and RFC (BGRFC_SUPERVISOR) are created. If you don’t have authorization for that, issues will happen.

Use tcode SU01D to see if the users are created properly with the correct roles.

Use tcode BGRFC_SUPERVISOR and check the last tab that the supervisor destination is assigned. In systems with CUA there might be an issue with creating the supervisor destination. In this case follow the steps of OSS note 2775490 – Error in customizing while creating supervisor destination.

Issue solving program (run in SE38): WSS_SETUP.

Issue solving transaction: WSIDPADMIN.

Issue solving after setup

If you have issues after setup, run the above check tool via SRT_TOOLS, or directly via transaction SRT_ADMIN_CHECK.

Common root causes: changes in authorization, overzealous user admin deleted SAP_WSRT or DELAY_LOGON user, or somebody deleted the supervisor RFC destination, etc.

SOAP consistency check: see oss note 2353589 – Consistency Check for Soamanager.

Consistency check for Business application ID: see oss note 2347852 – Consistency check for usage of Business Application Id within Web Service Configuration.

SOAMANAGER and issue solving

In SICF activate the services /sap/bc/srt and /sap/bc/webdynpro/sap/appl_soap_managements.

After the steps above and the general activation, the transaction SOAMANAGER should start up properly.

If you have issues with SOAP webservices, you can check the reference OSS note 2553979 – SOAP Web Services ABAP – Guided Answers.

Other tools

The SRT_TOOLS transaction also lets you jump to other useful tools such as the WS message monitor and the web services utilities tool.

Webservice issues after system copy

After a system copy you might be confronted with data inconsistencies. Upon start of SOAMANAGER you might get this screen:

Webservice setup issue after system copy

Follow the instructions from OSS note 2353589 – Consistency Check for Soamanager. It might mean you need to run program SRT_WSP_INITIALIZE_WS_CFG to re-initialize the complete setup and reconfigure all the webservices again.

Retention of SOAP messages

Start transaction SRT_UTIL to goto the Web Service Utilities screen. From the menu now select the option Tools, Global Configuration. Here you can set the retention times (in days) to keep the SOAP messages:

OSS note 2611962 – WS retention period has some background.

Idoc webservices

Some web services will use idocs. To use this feature basis first needs to enable this option by registering this service.  This registration is performed via transaction SRTIDOC.

SAP background wiki

Please follow this link to the SAP background wiki on basic SOAP runtime activation.

Activating web services

Oss note 2175422 – Web service provider configuration in transaction SOAMANAGER [Video] contains an excellent video with all the step to activate and configure a web service on the ABAP stack. See also this blog on how to convert any remote function module into a web service. And this blog on how to consume a web service in ABAP.

Monitoring web services

For more information on monitoring web service message read this dedicated blog.