Introduction

The solution is the sum of a company’s systems, applications and processes. It acts as a container for versions (branches) of solution documentation, one of which is the production version.
A branch represents a version of the solution documentation containing processes, libraries, and systems.
Branches are used to separate different versions of solution documentation content: Branches are the linchpin of the SAP Solution Manager content lifecycle concept. They control the visibility and changeability of solution documentation content. By default, when you create a solution, there will be a production and a maintenance branch. While the production branch only contains productive documentation, the maintenance branch offers a version of solution documentation content in a staging area to maintain the solution documentation without any interference with productive content.
SAP recommends the following initial setup of branches:

The branch setup allows you to clearly differentiate between solution documentation content that is productive and content that is still work in progress.

Usage of branches during project implementation

In the project phase, you will mainly work with the following branches:
•        Import branch for content import and scoping
•        Design branch for fit/gap and definition of the customer to-be processes
•        Development branch to build the actual solution.
To control the changes to the process models (definition of processes, process steps and process flows) during the project implementation it is recommended to do those activities only in the Design branch. After the process definition is finalized, the processes can be released to the Development branch. In the Development branch further documentation (e.g. functional and technical specifications can be created/uploaded and the objects (e.g. configuration and development items) can be documented.

The design branch should be used for:
•        Definition of the process folder structure
•        Definition of the libraries’ folder structure
•        Fit/gap analysis
•        Definition of the customer to-be process: processes and process steps
•        Definition of process model diagrams for implementation
•        Creation of design documentation.

The access to any branch (e.g. Design or Development) can be limited with authorization objects SM_SDOC and SM_SDOCADM, which are part of the SAP_SM_SL_* authorization roles.

Perquisite: Decide who will be allow to:
•        Work in the Design branch
•        Release changes to the Development branch
•        Work in the Development branch.

Example – Adjusting the Role SAP_SM_SL_ADMIN

Copy the Role SAP_SM_SL_ADMIN to a customer name space to adjust the authorization.
The role SAP_SM_SL_ADMIN is one of the major roles when working with the new Process Management application, transactions SOLADM.
It provides all authorizations for solution documentation and solution administration. This role contains the two important authorization objects SM_SDOC and SM_SDOCADM. The authorization objects can be found in the section “Solution Manager”:

The role SAP_SM_SL_ADMIN allows to perform creation/administration actions in the solution landscape and the solution/process documentation, for example:
·       Creation of libraries structure and libraries’ content
·       Creation of process folder structure
·       Creation of scenarios and processes
·       Creation of assignments for scenarios, processes and process steps
·       Administration of document types
·       Update of the Search Index from the Solution Administration directly
·       Import of SAP Best Practices
·       Use of the Library Generation Cockpit
·       Maintenance of the solution landscape
·       Display the change control landscape
·       And other activities.
It does not contain an authorization object (S_SMDDOC) to work with documents (create or edit).

The authorization object SM_SDOC  can be used to provision access to functionalities of solution documentation for a specific solution and a specific branch of a solution, e.g.:
Solution: E_PRD
Branch: DESIGN

You need to modify this object in this way:

The authorization object SM_SDOCADM  can be used to provision access to functionalities of solution administration for
a specific solution and a specific branch of a solution, e.g.:
Solution: E_PRD
Branch: DESIGN

You need to modify this object in this way:

After you assign the modified authorization role to the end user, the user will only be able to access this one solution and this one branch.
Such modified role will limit the actions within the Solution Administration transaction (SOLADM) – the user will not be allowed to create/change any content which is cross branches relevant. Now, the authorization will allow, for example for:
–          Creation of libraries structure and libraries content
–          Creation of process folder structure
–          Creation of scenarios and processes
–          Creation of assignments for scenarios, processes and process steps
–          Display of the solution landscape only
–          Display the change control landscape only
–          Display document types (add/remove from scope only).

The user will only be able to access and work within the branch which is specified in the authorization objects:

If a user tries to access another branch of this solution, she or he will get an authorization error:

Additional information

The authorization object SM_SDOCADM is used with a combination of the field SBRAASPECT (Aspect).
This object controls all administration activities in the solution administration UI (transaction SOLADM or SLAN), and some in the solution documentation UI (transaction SOLDOC). The scope of an activity can be controlled with the field aspect. An activity like ‘Create’ can control the creation of a solution when the aspect is SLAN. It can control the creation of a branch when the aspect is SBRA. The following checks are made:

• Display solution administration: A user without display activity cannot enter solution administration at all. Display authorization is only checked against the field SLAN. It is not possible to restrict it on any other aspect.
• Aspect SLAN – Create/delete a solution
• Aspect SBRA  – Create/delete a branch
• Aspect VIEW – Maintain a view or a scope
• Aspects for change properties: Properties are divided into subgroups, depending on the criticality of changes
  • aspect PROPERTIES – General properties, includes all regular attributes
  • Aspect NAME – The name of a solution or branch is critical to a change, because it may be used in existing authorizations. You can protect it with a separate aspect NAME
  • Aspect CH_CONTROL – Change control properties. This aspect controls whether change request management can be activated or deactivated at a branch.
• Aspect SITE – Activate sites functionality in a branch
• Aspect LOGCOMP – Create/delete/change logical component groups and logical components
• Aspect LIBRARY – Generate the libraries
• Aspect SRCH_INDEX – Generate the search index in case of problems
• Aspect DERIV_ATTR – Generate the derived attributes in case of problems
• Aspect DOCU_TYPE – Scope (assign) document types
• Aspect SITE – Maintain sites:
  • 07: Activate sites functionality in a solution or branch
  • 23: Create or change sites
  • 06: Delete sites
• Aspect CONT_LANGU – Maintain content languages
  • 23: Maintain (create, change, delete) content languages
• Aspect SBPP – Importing SAP Best Practices Packages or uploading other solution documentation content from a file or by third party API (activity import)
• Aspect SBPP – Exporting solution documentation to a content file or by third party API (activity export)
• The above operations are solution/branch-specific. There are also some cross-solution documentation type maintenance operations that are controlled by this object. These checks ignore the field SLAN. Only the aspect is relevant. The activities create, change and delete are checked. For example, aspect DOCU_TYPE and activity delete, control whether a user is allowed to delete documentation types. Cross-solution aspect checks are:
• Aspect – DOCU_TYPE Documentation Types
• Aspect LAYOUT – Saving public (not personal) layouts in list view (activity maintain)
• Aspect SRCH_CRIT – Saving public (not personal) search criteria for advanced searches (activity maintain)
• Aspect SYSROLE – Maintaining system roles (activity maintain)
• Aspect REPORT  – Maintaining reports (activities create, change, delete).

Defined fields

• SLAN: Solution Landscape NameSBRA: Process Landscape or Branch Name
• SBRAASPECT: Aspect (CH_CONTROL, SBPP, DERIV_ATTR, DOCU_TYPE, LAYOUT, LIBRARY, LOGCOMP, NAME, PROPERTIES, REPORT, SLAN, SRCH_CRIT, SRCH_INDEX, SYSROLE, VIEW)
• ACTVT: Activity (display, create, change, delete, activate, assign, maintain, import, export).