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.

If you are looking for information on how to consume a web service in the ABAP stack: read this blog.

Questions that will be answered are:

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.

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

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

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 artifacts:

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

Testing the service

Go to transaction SE80 and select the Enterprise Services Browser (if not visible go to 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).

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.

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. This blog assumes you have configured the basic web service SOAP runtime (if not, read this blog).

Questions that will be answered in the blog are:

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.

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:

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

It was explained you can test the connection. Unfortunately there is no out of the box way to test this connection in a batch job on a frequent basis. If you want to frequently test and be alerted on issues with connection to the web service, you can read this blog to deploy a simple custom program that executes this function and can be planned in the background.

Background notes and blogs

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

Relevant OSS notes:

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.

Setting up the SOAP runtime

Setting up the SOAP runtime is extensively explained in OSS note

Start transaction SRT_TOOLS for reaching the main tool set:

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

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:

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

For the background jobs check OSS note 2231932 – ESI – How to schedule the SAP_SOAP_RUNTIME_MANAGEMENT standard background job.

Issue solving during setup

Issue solving program (run in SE38): WSS_SETUP.

Issue solving after setup

SOAP consistency check: see oss note

Consistency check for Business application ID: see oss note

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.

The generic troubleshooting note for security issues is 2321968 – SOAP Web Service Security Troubleshooting.

Issue solving tools are described in OSS note 3038290 – Tools for analyzing problems in Web Service framework.

Other testing issues:

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 and other system changes

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

Background: , and 3263624 – ESI – SOAMANAGER error: Read error in secure link ID.

In case of host name changes read OSS note 3235977 – Implications on Web Service Configuration in case of hostname change.

Removing a system from the configuration, read OSS note 3238552 – Removing a system from a local configuration.

Related bug fixes:

Retention of SOAP messages

Start transaction SRT_UTIL to go to 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 notes contain the background

If table SRT_MMASTER is growing fast, it is time for clean up of web service data: see OSS note 2231932 – ESI – How to schedule the SAP_SOAP_RUNTIME_MANAGEMENT standard background job

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.

Bug fix and explanation notes SRTIDOC:

SAP background wiki

Use of logical ports is explained in this OSS note: 3237511 – Using default logical ports in Web Service scenarios.

Using SE80 to consume a Web Service in SAP, inlcuding ABAP code to then execute it

The below steps will take you step by step and show you how to first consume any webservice WSDL using an SAP
enterprise service and then call it using an ABAP program.

For this example we will use the currency converter available via WSDL link http://www.webservicex.com/currencyconvertor.asmx?WSDL
It is supposed to take 2 currency codes (i.e. GBP, AUD, USD) and returns the conversion value.

If you are on a very old version of SAP you might want to check out this guide to creating an ABAP proxy which was
the original version of the enterprise service consumer.

Step 1 – Enterprise service consumer creation wizard via SE80

To create an enterprise service that “consumes” a web service choose Service Consumer.
This seems obvious but this caused me a bit of a headache initially as for some reason I chose “Service provider”.
Quick tip: If you have a service which you think is a Service consumer but you don’t have the option to create
a logical port via SOAMANAGER check it’s not a Service Provider.

Now choose External WSDL/Schema and click continue

Select URL and click continue

Highlight the soap entry(top) and click continue

Now enter the package details or just click the local object check box. Also enter a prefix of something
like ‘ZESC_’, which I use to stand for Enterprise Service Consumer.
When the auto generation occurs SAP only has a finite size for the name of the proxy,
this prefix helps ensure it does not encounter any duplication problems.
Now press Continue.

and on the final screen press complete

Step 2 – Activate the created enterprise service

You should then be returned to the SE80 main screen displaying the new class based service consumer object.
You simply need to active it using the activate option.

You could also double click on the class within the ABAP Name field and ensure it is also active

Now return to the previous screen and test the service by pressing the test button

But you will soon realise the service is not ready to test yet as you haven’t created a logical port yet.
See for yourself and use the search help / F4 to confirm there aren’t any available to select.

Step 3 – Create logical port for enterprise service consumer via SOAMANAGER

To create a logical port first execute transaction SOAMANAGER. This used to be done via t-code LPCONFIG
but this is now obsolete.

SOAMANAGER will open up in a web browser window and ask for your login details. These are the same ones
you log into the backend SAP system

Select the Web Service Configuration option

now search for your service consumer object by selecting “Consumer Proxy” and entering the ABAP name
of your service (found on the earlier SE80 screen).

your created object should be returned in the search results, simply click on this

Step 4 – Enter logical port details

leave screen three as default and press next

again leave screen four as default and press next

familiarize yourself with the auto entered settings on screen five but again you should be
able to leave these as default and simply press next

on screen six simple press next

and again have a look at the options on screen 7 and press next

finally on screen 8 press finish

Step 5 – Test your enterprise service consumer again using the logical port

Now return to se80 and re-test the service consumer using the test button.

This time you should be able to select the logical port name that you have just selected

Press the execute button

You will now be presented with the XML to call the web service which you can modify. You can do this
by uploading a file but we will simply use the XML editor. To do this click the XML editor icon.

You will now be able to edit the XML request code. So enter two currency code such as AUD and GBP.
Then press the execute button

You will then see the result of the call to the webservice on the response tab. Please note i’m not sure
the response value of the web service is correct at the moment but it has at least called the webservice and you have
received the response sent back from the web service.

You can actually install
SOAPUI on your PC if
you want to test the webservice outside of SAP to confirm the response is the same. Also, check out
http://www.soapclient.com/?topic=soaptestl which seems to let you
check a web service WSDL from their web page.

Step 6 – Call this service consumer/web service from your ABAP code

this web service can be found here http://www.dataaccess.com/webservicesserver/numberconversion.wso?WSDL so give
it a try.

Step 7 – Heres the ABAP code to call this web service

For those that just want to see the code to call this web service here it is. I will add a bit more information
about how this is constructed based on the web service consumer service.

Related Articles

ABAP and SE80 to consume a Web Service – Example to demonstrate simple creation processABAP and SE80 to provide a Web Service to the outside worldSAP Visual composer application – modeling tool for rapid application developmentVisual composer example – Very simple to implementVisual composer application with layers to allow each input/output form to be on a separate screenConsuming a temperature conversion webserve with an SAP VC applicationConsuming a webserve with an SAP VC applicationSAP web services – Consuming a webservice and surfacing them in SAP for others to useABAP and SE80 to consume a Web Service – Example to demonstrate simple creation process

Well let’s start at the ground level i.e. the Netweaver Gateway where traditional SAP ABAP skills are required as part of building a Fiori app.
The SAP Gateway has actually been around for many years but with the move to Fiori/Mobile/Responsive apps it is being used more and more and is now a key part of your SAP landscape.
The Gateway allows data within your SAP system(s) to be accessed by the outside world via OData services.

The example below will show you how to quickly create your first OData Gateway service using basic ABAP code to select data from a standard table.

Step 1 – SAP Netweaver Gateway Service BuilderFirst go to transaction SEGW where you will be able to build your service

Step 2 – Create projectNext using the create button you have to create a project to store all your data models, implementtions, entity types, entity sets etc. Don’t
worry too much about the terminology at this stage, all will become clear.

Step 3 – Enter project detailsEnter a name, description and package. Leave everything else as default unless you know you need something specific.

Step 5 – Enter structure detailsEnter EKKO within the ABAP structure field and enter an object a name i.e. purchaseorder

We are just going to use the top few fields so select all the fields below Statu and delete them

Until it looks like this

Note: The reason I’m not going to use all the fields is because some are incompatible with a gateway service without changing the data type.
I will show you where you would get the error further down if you had used all the fields. This info might just help you understand the error
quicker when you are creating one for real in the future.

Step 7 – Create Entity SetSave your process so far and then right click on the Entity Set node and select Create

Step 8 – Alternate way to create Entity SetAlternatively double click the Entity Set node and then click the Append Row button

Step 9 – Entity set detailsGive the entity set name (usually a plural of the Entity Type)

Then select the Entity Type from selection input help

Once selected press ok (green tick)

Entity set has now been created

Step 10 – Generate gateway service

First double click the project node and generate the whole project using the “Generate Runtime Objects” button

You will now notice that Service Implementation Objects have been created.
Create, Delete, GetEntity(Read), GetEntitySet(Query) and Update

Step 11 – Active and maintain serviceNow you need to go to transaction “/IWFND/MAINT_SERVICE” I always find I can only get this working if i
add /n at the start i.e. /n/IWFND/MAINT_SERVICE

Step 12 – Add serviceWithin /n/IWFND/MAINT_SERVICE click the Add Service button

Then enter the information of the service you want to add (Notice you can use wildcards at this point to find your service)

Press enter to find your service or services that match your search criteria. Once it does click on the one you want to add

The next screen shows you the selected service details, enter package details(i.e. local Object) and leave everything as default. Then press the ok button (green tick)

You should now recieve a message popup that your service “was created and it’s metadata was loaded succesfully”

Return to previous page

Step 13 – Find your added serviceYou will now be returned to the service catalog, depending on how many services you have setup in your system you may need to use the filter
functionality to find your newly added service.

You should now see the service setup details and a green traffic light next to the ODATA ICF node in the bottom left hand corner.

Step 14 – SAP Netweaver Gateway ClientWe now need to test it using the SAP Netweaver Gateway Client, which is accessed via the “Gateway Client” button just above the ODATA node in the bottom left hand corner

Then, leaving the Request URI as default “/sap/opu/odata/sap/ZTEST_PROJECT_SRV/?$format=xml” simply click the “Execute” button

You should then get a HTTP respose similar to this with a green status_code

Step 15 – Further tests via SAP Netweaver Gateway ClientNow you can modify the URL so that it ends with “$metadata?sap-ds-debug=true” and then press execute again,
so that we can return metadata properties of the purchaseorder entity

Now change the URI to have “/purchaseorders?sap-ds-debug=true” at the end so that we can target the data of the
entity set purchaseorders

Step 16 – Implement GetEntitySet methodNow return to the SEGW transaction and find the service implementation methods created before. Find the one called
GetEntitySet(Query) and right click on it. Then select “Go to ABAP Workbench”

SELECT *UP TO 10 ROWSFROM ekkoINTO CORRESPONDING FIELDS OF TABLE et_entityset.

Step 17 – Re-test the serviceAgain change the URI to “/sap/opu/odata/sap/ZTEST_PROJECT_SRV/purchaseorders?sap-ds-debug=true”

This time you should get some data returned

Step 19 – Further developmentThe next step is to access this gateway service from your SAP Fiori App