Usage Type Deprecation for Systems Based on SAP NetWeaver 7.3 EHP1 and Higher

[BorisZarske]

Short summary

To simplify the handling, usage types as structuring element got deprecated for the installation and maintenance process of systems based on SAP NetWeaver 7.30 including Enhancement Package 1 and higher releases. By eliminating one abstraction layer and using a harmonized model for the provisioning and the maintenance of SAP systems, customer experience of all lifecycle management processes is improved and the number of issues due to inconsistencies can be reduced.

 

Background

With SAP NetWeaver 7.0x, we introduced usage types as structuring element for SAP software on a technical level. Per definition, usage types determine the role an SAP system plays in a given (distributed) scenario and represent the capabilities offered by a collection of installed and configured (technical) software components.

 

Examples of usage types are AS ABAP, AS Java, Enterprise Portal Core, and BI Java. The installation procedure offered to select required usage types during the installation procedure accordingly.

 

Motivation for Deprecation

While the installation and the initial configuration used a model with usage types, later processes in the lifecycle of a Java system use other models (based on our Production and Product Management System, PPMS).

 

Let’s take a more detailed look at the lifecycle of a Java system from customer perspective:

1. You as a customer had to select usage types with specific names during the installation to define the role that the Java system is intended to fulfill in your landscape.


2. After the installation, you had to select and execute configuration templates based on usage types for the initial setup of the installed Java system.


3. As prerequisite for any maintenance activity, you had to ensure that PPMS entities were maintained in the Landscape Management Database (LMDB) – as these entities use different names than the usage types used before, this represented the first break in naming.


4. When this prerequisite was fulfilled, you could plan a maintenance task in the Maintenance Optimizer (MOpz), again using PPMS entities.


5. Finally, for delta package deployments (such as an upgrade), you had to consider both PPMS entities and usage types.

 

Overall, this break of used entities lead to confusion, additional efforts and possible inconsistencies, resulting in longer projects and additional costs due to issues in handling PPMS data and in maintenance projects.

 

Therefore, we decided to remove dependencies towards usage types for the installation and configuration of Java systems based on SAP NetWeaver 7.31 and higher – instead, we switched to a representation based on the same data model as used by the maintenance procedure (using product instances based on PPMS data). This change is reflected in the corresponding tools (such as software provisioning manager 1.0) as provided with Software Logistics Toolset 1.0 SPS12. The change leads to a harmonized internal modeling for both ABAP and Java systems and to the elimination of most of the issues caused by inconsistencies in customer landscapes, as now, harmonized structures/entities based on one reliable model can be used everywhere, as shown on the following figure:


Even if the visible changes for you in the affected procedures might be minor, we are sure that the procedure got more reliable and that a consistent model and naming will make the overall handling smoother and easier for you.