Contents
Handling of Design Time Changes
This article describes how changes on ABAP Design Time (DT) objects which are relevant for the ABAP Web Service environment (like service definitions, proxy definitions, service groups) are changing Web Service configuration objects on consumer and provider side. Such DT object changes can be performed via the ABAP development environment (e.g. transaction SE80) or via the SAP transport system when these DT objects get imported into an ABAP system.
The handling of design time changes is currently not implemented in the Netweaver release (software component SAP_BASIS) 7.00. In the Netweaver releases 6.20 and 6.40, different kinds of Web Service environments were shipped, where no DT change mangagement is available. Furthermore, these Netweaver releases will not get any update on this subject in the future.
Motivation
Each Web Service configuration object is depending on its correpsonding DT object, which does not only provide an implementation for Web Service consumers or providers, but also provides the DT configuration. The DT configuration becomes during the configuration process part of the Web Service runtime configuration, because that configuration information is in addition required during the WS runtime to control the WS processing. On changes of the DT object, it is required, that the DT information copy stored in the configuration object gets adjusted correctly so the Web Service communication remains operational, if possible.
Concept
The adjustment process gets automatically triggered via the ABAP development environment or the SAP transport system. The changed object's name and type gets stored in a log table and gets processed asynchronously later on via a background process.
The background processing is currently only established on the following Netweaver (SAP_BASIS) releases: 8.0x, 7.02, 7.30, 7.03/7.31. All other Netweaver releases equipped with this automatic DT to runtime (RT) update feature, perform the Web Service configuration update right away in the same logon session as the DT update itself occurs. The background processing is implemented via the SAP auto-ABAP process, and gets used via the so called Web Service task watcher. This task watcher can be started or stopped using the transaction TWADMIN; it shows also the current status of the task watcher (active or inactive).
Ragardless if the adjustment process is running in an asynchronous task or in the ABAP session of the change trigger, the processing handling is always the same:
- all the currently logged DT changes get collected
- multible entries for the same DT object get aggregated
- all SAP clients, where depending Web Service configurations are stored, get collected
- in each affected SAP client a local thread gets started via a system-local RFC call performing the client local adjustment process of the Web Service configuration process.
It is possible, that for certain DT changes, there is no way of keeping the Web Service configuration up-to-date; e.g. the DT authentication level gets raised from basic to strong, which invalidates all Web Service configurations with a basic authentication method in it. Such Web Service configurations get automatically deactivated.
If you encounter that the automatic DT to RT change management leaves a configuration inactive due to incompatible changes performed on the DT object, then you always have the option to delete and recreate the corresponding configuration or adjust it manually in the SOAMANAGER's configuration view, if permitted.
During a delete and recreate configuration processing, you always get the most up-to-date DT information copied into your runtime configuration and the additonal (mainly security) settings are also correctly controlled by these latest DT information.
Prerequisites
The triggering of the SAP client local processing of the DT changes logged is done via regular RFC destinations also visible via the transaction SM59. These RFC destinations are automatically set up via the report SRT_ADMIN. This report is doing a setup not only for the descriped DT to RT change process, but is also required for an operational Web Service environment in the ABAP system.
More details of this setup process can be found in SAP Note 1043195.
Administration of the Design Time Changes
The transaction to view and administrate the logged changes is done via transaction WSUPDATECHECK in the ABAP backend.
This transaction allows an administrator to do the following tasks:
- view the changes logged so far (centrally and for each SAP client);
- see the history of all changes performed so far (and, in case the history became too large, allows the administrator to truncate it);
- check the existence and operation of the required RFC destinations;
- manually trigger the update process in all SAP clients, for which operational RFC destinations are available;
- remove the logged changes locally and centrally, if required;
- deactivate the automatic background processing (only in the releases, where the DT to RT change process is actually implemented via a background task).
Administration of Change Log Entries
Start transaction WSUPDATECHECK
You get the selection screen of this transaction where you can filter the changes you want to see. The default selection is to see all changes for all clients and for all DT objects.
In a Netweaver NGAP system (i.e. since SAP_BASIS 8.00), you have to be logged on to a system SAP client to be able to start this transaction.
See the pending changes
After you pressed execute on the selection screen, you see the change log entires already transferred to the SAP clients containing Web Service configurations for the listed DT objects.
This sample screen shows several DT changes each one with a unique counter (e.g. the service definition named /EXT/SERVICE_CENTER_FACADE_WS with the change number 15722). The changes got assigned to the affected SAP clients and the operation on this DT object is shown (currently we only have Change and Delete operations on the DT objects). In addition administration information about the creation and the last update is shown.
The entry Origin ID is used, when the current entry is a child from another entry, which got already archived, because is does not get processed directly, but only its children entries are of interest. Currently this is only the case for message type changes or deletions, which are used by depending service definitions or proxy definitions.See the central log
If you press the third button from the left, you see the so called central log, i.e. these are the entries which got entered initially by the changing thread itself.
In this screen, you see for each logged DT object only one entry, the unique change ID, the operation which took place on the DT object and the current status of the processing.
If the processing already started, the status is reported to be Started. This is an intermediate status, which you can only see, if the processing was not completed for all SAP clients affected by this change (e.g. due to missing SAP-client specific RFC destination for at least one SAP client). In such a case, the central entry remains until it gets deleted by the administrator or all entries in all affected SAP clients (see previous step) are successfully processed.
Via the refresh button you can update the list of all central entries.Ideally this screen is empty which means that no DT changes are pending. In this case, there are also no SAP local entries existing.
On this screen you have also the possibility to remove the listed logged DT changes, either all of them or selectivly for a certain DT object.See the history of changes
If you press the second button from the right, you can see the history of DT changes already processed in this system which are still available. In the resulting screen, you have also the option to truncate the history entries to reduce space consumption in the database system.
- Trigger the processing of pending changes
In the log screen listing the changes for the single SAP clients, you have the option to process all pedning changes by pressing the Eeecute (F8) button. Entries which can be processed successfully, get removed from this list. If a change can be processed in all SAP clients, then all SAP client local entries get removed and in addition the central log entry. Check if the RFC destination are operational
The check button allows you to check, if the RFC destinations for all SAP clients in the current SAP system are operational.
This check checks for all existing SAP clients for the existence of RFC destinations regardless, if there are changes logged for a SAP client or not.
A missing RFC destination for a certain SAP client means, that no processing at all will take place for this SAP client ever until the RFC destinations gets gererated.Activate or deactivate the change processing
You have also the option on the log screen listing the changes for the single SAP clients to activate or deactivate the change processing. This option is only available, if you have the auto-ABAP based background processing in your system (see above for Netweaver release dependencies on this feature).