Contents

Migration of Netweaver 6.40 based Web Service Configurations

With Netweaver release 6.20 a SOAP processor was introduced, offering the possibility to publish remote-enabled ABAP function modules as Web Service, but with limited support, and no out-of-the-box Web Service client support. This shipment was replaced with the Netweaver release 6.40 Web Service framework, but this release did not implement a fully matured feature set needed by the upcoming new requirements for Web Service frameworks (e.g. extended security handling and Web Service protocol support were not fully supported).
Starting with Netweaver Release 7.00 (SP14), a completely new designed and implemented ABAP Web Service framework was shipped addressing the needs for the new requirements and with the intension to replace the Netweaver 6.40 Web Service framework.

If you are using 6.40 framework based Web Service providers and/or consumers, you are not urged to replace these with new style Web Service configurations, but it is recommended not to use the old framework for newly introduced Web Service configurations any more.

The tools used for 6.40 based Web Service configurations are these transactions:

1. WSCONFIG: Release Web Services
2. WSADMIN: Administrate released Web Service
3. LPCONFIG: Generate Web Service consumer configurations

In the new Web Service framework, you are only dealing with the transaction SOAMANAGER for all aspects of Web Service related configuration work. Beside this online transaction, all publicly available ABAP APIs are only dealing with configurations based on the new framework.
The new and old framework are co-existing to a great extend independently from each other and can be used simultaneously.
Nevertheless, it is recommended to have only one type of Web Service configuration in use, which is the new type of configurations. To support an administrator responsible for old-style Web Service configurations on an ABAP backend, this article describes how you can use the transaction WSMIGRATE to migrate your old-style Web Service configurations (consumer and provider side) to the new-style configuration framework.

For configurations, which can not be migrated (for whatever reason) you have always the option to create a new Web Service configuration via transaction SOAMANAGER and/or via the new public Web Service configuration APIs.

Concept

The configuration migration process provides a semi-automatic way of converting Web Service configurations. The first step is that you select the context (provider or consumer) of the Web Service environment you want to convert, you may choose a simulation mode (i.e. no real processing on the existing configurations) and select from a list of existing old-style configurations, what service you actually want to migrate.
In addition you always have the choice of deleting the old-style configurations via their specific administration tool (WSCONFIG, LPCONFIG) and recreate them in the new framework via UI (SOAMANAGER) or public ABAP-API.

Prerequisites

The semi-automatic migration process is only available in these Netweaver releases:

Other 7.0x and 7.x Netweaver releases (700, 701, 710, 711) require a delete of the old and a recreation of new Web Service configurations.

You need the authorizations of the following roles for the user performing the migration process in the ABAP system:

• role SAP_BC_WEBSERVICE_ADMIN for the administration of the old-style configurations

• role SAP_BC_WEBSERVICE_CONFIGURATOR for the generation of the new Web Service configurations.

  See SAP Note 1120273 for more details on the migration process and its prerequisites.

   

  Back to top

Migration Procedure via Migration Tool

In this procedure detail only the provider side gets viewed. The consumer side is analog to this procedure.

1. Start transaction WSMIGRATE
   You get the selection screen of this transaction where you can determine the context you want to migrate: provider or consumer side. By default the simulation mode is pre-selected, i.e. all changes you trigger on the subsequent screen, is not actually performing any changes on the configurations.

   

   
   See above for release information, if this transaction is actually available in your system or try to start transaction WSMIGRATE to check its existence.

   We recommend that you first migrate one or a few providers and the related consumers. You can use these migrated WS configurations to selectively check whether the basic business scenarios with the existing WS configurations that may not have been migrated yet are still valid. Subsequently, you can migrate further or all of the remaining WS configurations.

   If you start the transaction in simulation mode, then do not forget after your migration test to uncheck this option on the selection screen and start the migration process again without simulation to really perform the migration.

2. See the existing old-style configurations
   After you pressed execute on the selection screen, you see all the existing old-style configurations currently existing in your SAP client.

   

   
   The column labelled Status gives via an icon the current status of the existing old-style configurations. You may press the legend button (second from the right) to get more information on the status reported.

   

3. Optional: Display details of old-style configurations
   If you need more details on a certain entry of the list, you may mark that entry and press the Details button (third button from the right).
   This shows an example of the details of a provider configuration. Here you have also the option to navigate to service's node in the Internet Communication Framework (ICF) as alternative to tthe transaction SICF.

   

4. Optional: Remove old-style configurations
   If you decide to skip the migration transaction for certain configurations without trying to convert them into a new ones, or that attempt already failed previously, then you can press the Delete button (second button from the right) to remove all highlighted old-style configurations without generating a new Web Service configuration. You do the generation of the new configuration from scratch, e.g. via the SOAMANAGER transaction.
5. Optional: Refresh displayed configuration list
   The Refresh button always allows you to see the most current list of (still existing) old-style configurations. This function is automatically called on startup of the transaction.
6. Migrate configurations
   The migration process takes all the high lighted configurations of the list into account. By pressing the Execute button (first button from the left in the button row), the transaction tries to process them.

7. Result
   If the migration fails, you get an information popup about it (see also the information popup's long text) and a short text gets added to the line at the end about the error condition. You also see a status change in the status column.
   In case of success, you get a new entry in the history about the successful execution of the migration process for the selected configurations and this entry is not shown any more in the list of configurations to be migrated.
   Example: This screen shows a typical issue reported by the migration process: The authentication method in the configuration is None, but the design time object used demands a Basic authentication. For this, no new Web Service provider configuration can be genrated.

   

   In Netweaver release 6.40 it was possible to generate configurations not completely alined with the underlying design time object. Furthermore, later changes on the design time object (via transaction SE80, e.g.) were not taken into account for Web Service configurations created before based on the old design time object's version.
   On the provider side in the new Web Service framework, that checking is more strict and may prevent to migrate a certain configuration with a design time to runtime incompatibility.

8. Optional: View History
   You can also view via the History button (first button on the right) the already performed or manually deleted old-style configurations.