Please note that I was unable to find the wizard for setting it the Services registry in PI 7.1 EPH1, which means I did it manually.

Make sure everything is correct in the Services Registry Management

Go to the NWA (http://host:port/nwa).

Go to SOA Management> Technical Configuration>Services Registry Management.
In theory, there is nothing to do here, however I did specify the discovery URL api parameter as the hostname of the server (no port). If you have changed some settings, on the maintenance tab you can click reinitialize, which should reset any changes you have made back to the initial state.

Configure the ServicesRegistrySiPort

Go to SOA Management> Application and Scenario Communication> Single Service Administration

Click the Consumer Proxies tab.

Search for “ServicesRegistrySi”.

Click on the result and click the Configuration Tab and click on ServicesRegistrySiPort.

The service endpoint name should be ServicesRegistrySiPort.  Don’t change it.

Click security.

You have to give it an http authentication. If you don’t give the authentication, you will eventually have problems like not being able to publish to the SR, even though you may be able to access the registry.

Click on the user ID/ password, click details, and input your http authentication parameters.

Configure the third party UDDI (Only if not using SAP’s UDDI)

If you are using a non-sap UDDI, you will need to go to NWA>Destination Template Management and create a UDDI_DESTINATION and a CLASSIFICATION_DESTINATION to point to the respective urls of your uddi. Don’t forget to click security and select User ID/Password Authentication for both destinations. Otherwise, you will get a 401 not authorized error when you try to access the services registry–similar to if you mistyped your password at ServicesRegistrySiPort.

Security

Make sure that your user has  UDDI_TierN and SERVICES_REGISTRY_READ_WRITE authorizations or you will get a 401 not authorized error.  Of course. in your system you should use a technical user instead of your userid as which I did for the purposes of this blog.

Please note, I did run into an issue where it suddenly stopped working a day everything was configured. All I can say is Gremlins. I switched the user to a technical user with the authorization listed above on the ServicesRegistrySiPort as well as on the destination templates and I haven’t had a problem since.

Debugging a web service on the ABAP stack of SAP Web Application Server is a very useful procedure to know.  Here’s how you do it.

Note: This example is for ECC 5.0

1. Locate the web service definition in the HTTP Service Hierarchy.  There are two ways to do this:
   • Option 1: Use transaction WSCONFIG and display the configuration for your web service.  Click on the ICF Details button
     

   • Option 2: Start transaction SICF. Navigate directly to /sap/bc/srt/rfc/sap for your default host.
2. Regardless of the method used to get to the service definition for your web service enabled function module, you should have it selected as in this example.
   

3. Next, enable the debugger by selecting the Edit\Debugging\Activate Debugging menu.

   
   

4. In the ensuing dialog box, confirm the debugging options (the defaults are usually OK).
   

5. To exercise the debugger, test your web service.  For this example, I will use the SAP WAS web service test tool, but the application calling the web service can be anything as long as it connects with the debugger’s user ID.
   

6. When the web service is executed, the debugger will start in a new SAPGUI session (make sure you are already logged in via the SAPGUI prior to executing the web service).
   

7. In the debugger, choose Breakpoints\Breakpoint at\Function Module from the menu to create a new breakpoint.
   

8. Specify the function module that implements your web service.  In the debugger, press F8 to run to your newly created breakpoint.
   
   If the debugger doesn’t get to your breakpoint, the most likely culprit is malformed input XML.  Check the payload of the message to ensure that it conforms to the specifications of the web service.

Once the debugger has started, it is just like debugging any other SAP application. If you have any specific tips or tricks regarding debugging web services, please share them in the comments section of this blog.

My colleague, Steve Park, wrote a two part blog explaining how to turn any ABAP function into a web service.  (Find Part 1 here.  Find Part 2 here.)  But, what happens when you change the function module interface as my friend in the above example did?  SAP does not automatically update the web service interface (called the virtual interface).  You have to manually rectify this conflict.  There are two main options to do this.  Both are quite easy.  Which option you choose depends on how the external systems consuming the web service are handling changes.

Note: The examples listed below are for ECC 5.0.

Option 1: Update Virtual Interface

In cases where all systems consuming the web service will be using the new function/web service interface, when the underlying structure of complex data type changes, or when mandatory fields of a function interface are added or removed, it is best to change web service virtual interface.  The consuming application may have to re-import the WSDL to

In transaction SE80, navigate to the virtual interface for the function whose interface has changed.  Right click on the virtual interface and select “Change”.

SAP will compare the virtual interface to the function interface.  If the interfaces are different, SAP will display the following prompt.

Simply select “Yes” and SAP will update the virtual interface to match the function interface.  Once you have activated your changes, you can check the WSDL to ensure that the function interface changes have been successfully migrated to the web service virtual interface.

Option 2: Create new virtual interface version

In cases where optional fields are added to the existing function interface and/or when some of the web service consumers will NOT need to use the new function interface, it is possible to create a new virtual interface version.  This is possible only in cases where the old virtual interface can still execute the function module with the new interface without causing syntax errors.

In transaction SE80, navigate to the virtual interfaces for the function whose interface has changed.  Right click on the virtual interface node and select “Create”.

In the ensuing dialog, create a new virtual interface version with the endpoint mapped to the  function module.

Now that the virtual interface is created, create a new version of the web service.

Conclusion

Changing the web service virtual interface to match changes in the underlying function module interface is easy. Whether you choose to create a new virtual interface version, or if you choose to update the virtual interface to match the new functional interface, the process is quick and easy.

I will show how to configure and test the Web Service on ECC with Service pack 14 and higher.   Before Service Pack 14, the configuration is completed in ECC, however after SP14 the configuration is completed on the Java Stack.

Now let’s get started.

Execute the following transaction:
Transaction: SOAMANAGER

This will initiate a Web session and prompt you to log into the WebAS.
Once you have logged in, the next step is to locate the Enterprise Service that you created earlier.
To locate your Enterprise Service go to
Business Administrator Tab  –> Web Service Administration

First we will want to find the Enterprise Service that we created.   In our scenario, we named our test service as “ZTESTWEBSERVICE”.  After you have found your service, you need to display it by pressing the “Apply Selection” button.

This will display the current settings for this service.  Since we have not yet defined the configuration we will want to create a new service.  In the Configuration tab, select “Create Service”.

Enter a Service Name and a Binding name that you would like.  I usually put a prefix of “SN” and “BN” when defining a Service Name and a Binding name.

Here you will see all of the different type of runtime configuration options that are available.  As you can see you can configure other security and authentication options.  Once you are complete, press “SAVE”.

Now you are complete.  The Web Service should be up and running ready for an external application to call it.  Our next step is to obtain the wsdl location and execute a test a call to the Web Service from an external application..

Testing the Web Service

Before we can test the service we will first need to get the wsdl locations. With your service displayed,  go to the Overview tab.

Here you will want to click on “Open wsdl document for selected binding”

This will display the wsdl in another web session.  This is the URL that needs to be given to the external application that is initiating the call.  In our case, we will be using the WS Navigation tool to be doing this call.   Copy this URL.

Now we have the wsdl location, we will use the WS Navigator to perform the test.
In Overview tab, select the following link:
“Open Web Service navigator for selected binding”

Here you will enter the wsdl URL that you copied in the previous step.
Then press ‘Next’

Enter a valid user that will log into ECC when calling the Web Service

Now press ‘Test’.

Here is a list of available operations to call  this  Service.   Remember since we built it from just a function module it will only contain one operation.  If we want to build an service with multiple operation we would generate this service from a function group.

For this simple  example, the service will take any input and bring back a successful response.

And there you have it.  You know how to turn a function module into a Web Service and test the service with WS Navigator.

I have broken this down into 2 blogs
Part 1 will show how to create the simple structured web service
Part 2 will show how to configure and test the web service using SOAMANAGER and WSNAV

For this scenario, I created a really simple function module with one input and one output that will send back a response of “Response successful from test”   This will only create one operation for this service.  However, if you want to create multiple operations for a Service you can also generate the service from a function group.

You will need to ensure that the attribute is set as Remote-enabled in the function module.

Now go to transaction SE80 and right-click–>Create–>Web Service

Since SAP will be hosting this web service we will want to select  “Service Provider”

Select the radio button “Existing ABAP Object(Inside Out)”

Since we are building this web service from a Function Module.  The difference between and inside out vs. an outside is approach is where the structure is built.  From a design perspective, it is recommended that you use an Outside-in approach whenever possible.  This means that you would build out  the structure in the ESR and then implement the code behind it in SAP..  However, there will be cases when you will want to turn a Standard SAP remote enable function module into a Web Service, thus using this approach, the Inside out approach..)

Give a name to what you want to call your Enterprise service and specify that the endpoint will be a function module.

Enter the name of the Function module that the web service will call in the backend.

Here you will have to specify which authentication you want this service to have.  For this example I have set it to no authentication.

Now you are complete with building this web service.  However at this point you have just built the Web Service but you will now need to configure it so that an external application can call this web service.

This will come in my next Blog for configuring the newly created Web Service and as well as testing this  service.