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.

Technically, a solution is the root of a structure that contains all of those objects.

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.

In one logical component group, you could, for example, have one logical component containing the systems that are commonly used in the maintenance and production branch. Another logical component in that group could contain the systems for your development to quality assurance track (used in the development branch).

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 A, B, C, D, E, F, P, S, T, V. This is necessary to assign systems of multiple sites to the same logical component (countries, plants). We strongly recommend to use system roles for this purpose and not to create site logical components groups (see above).

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.