Solution Documentation

This is the complete documentation content of a solution, including the libraries and business processes. Each Solution Documentation version is a branch.

Solution

This is the sum of a company’s systems, applications and processes. It acts as a container for versions of Solution Documentation, one of which is the production version.

From a process perspective, a solution covers all the company’s business processes. From a system perspective, a solution covers all productive systems that are connected through interfaces.

As solutions form independent areas with very limited access to functionality outside of themselves, there is typically only one productive solution per company. Even for an international multi-site company one solution will generally be sufficient.

Multiple productive solutions typically cover the use case of a service provider running multiple productive solutions for different clients.

System landscape

All systems of a company listed in the landscape management database (LMDB). In a solution, systems are added by adding logical component groups (see below). The term system landscape is used descriptively – there is no corresponding technical object of type system landscape.

Branch (incl. production branch)

Branches can be understood as “version contexts” of a solution. The currently productive solution is documented in the production branch. If you run a development environment in which you are setting up a new product version (which will be set productive in the future), maybe including own custom developments, you would represent this by a development branch for the systems in the development track. Typical maintenance activities such as implementation of SAP Notes would normally be handled in a separate maintenance branch, not in a development branch. By default, a newly created solution has a production and a maintenance branch.

Logical component group

As a rule of thumb, a logical component group comprises all systems of a solution that have the same productive system and system type e.g. ABAP or Java. Hence for each ABAP based and for each non-ABAP based productive system you create a separate logical component group. For example, a solution could contain the logical component groups HR, ERP, CRM, BI, PI, BOBJ, PORTAL.

As an important exception to the rule, companies with e.g. multiple ERP productive systems per site (country, plant) have to use only one ERP logical component group.

Technically, logical component groups are created within solutions.

Logical component

A logical component is the “branch view” on a logical component group i.e. the subset of systems which belong, for example, to the production, maintenance or development tracks of your solution. Similar to SAP Solution Manager 7.1 a logical component is a vector of technical systems and system roles that usually correspond to a transport track of your landscape.

System role

Intended purpose of a system-client combination (ABAP) or system (Java) within a logical component, for example, Development, Test, or Production. Applications within SAP Solution Manager use the system role to determine which system to use for various operations. For example, an analysis of usage statistics needs to run on a production system.

The limit of creating custom roles is to 52.

Note: Apart from numbers you can also use all lower and upper case letters except C, D, E, F, P, S, T, V.

Library

Collection of redundancy-free, reusable objects that you can reference from your solution to avoid duplicate content and reduce maintenance effort. Libraries are organized based on logical component groups and the application component hierarchy. You can use or create libraries for the following objects:

For example, the process step library contains all process steps and documentation that is not dependent on a particular business context. You can then reuse these process steps as the basis of your business process documentation and add context-dependent information where necessary.

You can fill the executable and the development libraries automatically in solution administration on solution level.

Executable

Executable objects used to perform certain tasks. For example, transactions or Web Dynpro applications. Executables are always objects which can be accessed or executed by a user.

Element

Structure nodes and object list items are called elements.

View

Visible scope of a solution. You can divide the structure of a solution into different views so that only certain parts of the structure are visible. In theory each user could create a view for the scenarios they are interested in. The initial default view on a solution contains the root element of the production branch as the top element and therefore shows the whole solution.

Site

The site concept is relevant for companies that run one SAP product on separate productive systems, e.g. in different branch offices, countries or regions and where those productive systems have a lot in common regarding software logistics and Solution Documentation but are also used to support local features. For each site, productive systems may be supplied through local maintenance and development systems while they can also be connected to a common development system that handles software that is uniform across all locations. Similarly, for Solution Documentation, parts of the documentation can be the same across all sites, supplemented by special documentation written for individual sites. Technically, the site context selects during navigation within the application the relevant managed systems based on logical component group, site and system role where the site determines the appropriate logical component within a logical component group and the system role picks the right logical system. Furthermore, each Solution Documentation element can be linked to one or more site attributes in order to restrict their validity to those sites. An empty attribute value stands for documentation that is universally valid across all productive systems in a logical component group and is called global.

Scope

With a scope, you can narrow down the Solution Documentation content to a view definition plus additional filter criteria for structure filtering. Scopes are also used for the generation of process documentation and for the execution of reports. Furthermore, they can be used in third party integration.

Report

With reports, you can check the status of your Solution Documentation, for example the completeness of documentation or assignments of objects. You can define and execute your own reports in Solution Documentation based on reports that are delivered by SAP.