Manager
Increase the security of your satellite systems by performing a few simple configuration changes. With these changes, you can prevent developers and testers from creating, managing, and releasing transport requests directly in satellite systems, which will ensure that only the person responsible for these actions (usually the change manager) can execute them.
Key Concept
Change Request Management (ChaRM) manages the entire change process in your SAP systems. It is the central point of access for all SAP non-productive systems in an organization, which include the development and test systems. ChaRM is not used to access the productive systems, as it only transports tested changes into these systems.
Transport requests store every change performed in a SAP system, and you can think of them as change packages. These packages are transferred among the systems in an SAP landscape for testing or to become active and used. The number of transport requests in your environment can grow exponentially, especially when your project reaches the test phase. In that particular phase, key users identify defects or enhancements that need to be performed while developers perform changes — all this, in turn, creates more and more transport requests.
A lack of control over transport requests is one of the greatest concerns facing project managers that lead large development teams. Development teams are usually comprised of programmers (who create and change programs), functional resources (who perform configuration changes), testers, and key users. Before SAP Solution Manager, teams worked with several techniques because the SAP native transport system (the Transport Management System [TMS]) does not offer advanced tools to perform this task. Most teams worked with spreadsheets that needed to be filled out by each team leader and had to include the number of each transport request, the transport sequence, and the dependencies between them. Considering normal projects have several teams, you can see how complicated this can become when you factor in consolidating all the spreadsheets and managing the cross-dependencies. Problems that result from incorrect transports are the most common reason for long rework nights.
Note
SAP recommends at least three systems for an ideal change environment. The first is the development system, where changes take place. These changes are transported into the second system, usually known as the test or quality assurance system. This is where the changes are tested. This test system is necessary because a development system usually holds many changes that could affect tests performed in this development system. Therefore, when changes are transported to a test system, the tester is able to identify if something is wrong or missing before transporting the changes to the third and final system: the productive system. This set of systems (development, test, and productive) is known as an SAP landscape. SAP refers to these systems as satellite systems because SAP Solution Manager centrally connects to all of them as if they were the satellites around the central system (i.e., SAP Solution Manager itself).
Some companies develop complex workflow processes using homemade databases, email confirmations, and approvals to control the change flow among the systems in their landscape. By using Change Request Management (ChaRM) in SAP Solution Manager, you can automate the transport of changes with its built-in workflows to manage the creation, release, approval, and transport of changes with well-defined roles and responsibilities. This reduces the number of change transports.
For example, you can ensure that a release can only be performed by the appropriate designated individuals (usually the technical leader or project manager). You can do this in either SAP Solution Manager or directly in the satellite systems, with user authorizations (but this second approach is harder to implement and even harder to manage, because there are not many authorization objects to manage). However, this doesn’t help you avoid the execution of some tasks directly in the managed (i.e., satellite) systems by people who think that doing this the “old way” is faster. That’s why you have to manage user authorizations in satellite systems accordingly. You can set up your SAP Solution Manager system to correctly manage the user authorizations and take the better control over your SAP landscapes.
Background Information
SAP Solution Manager uses Remote Function Calls (RFCs) to establish communication among systems and between systems and external systems. An RFC can be considered a protocol, much like TCP/IP. SAP Solution Manager uses three types of RFCs:
- Trusted RFC: Allows users to perform actions in satellite systems without the need to log in to these systems. The password is stored in SAP Solution Manager (or synchronized between the systems) so the user can access other systems automatically. The user needs proper authorization in the satellite system to perform any actions.
- Read RFC: As the name suggests, this type of RFC is used to allow read-only access to satellite systems. SAP Solution Manager uses this to recover statuses, logs, and other information from satellite systems.
- Transport Management Workflow (TMW) RFC: This type of RFC is used to perform actions related to transports (e.g., create, release, delete, transport, and manage transport requests)
Based on this, the best approach is to configure SAP Solution Manager to use only TMW RFCs when working with transport requests so users do not have direct access to the described activities (create, release, delete, transport, and manage transport requests).
Note
There is one exception to the RFC approach: to release his or her own tasks, the developer has to execute a specific administration transaction (e.g., transaction SE09 or SE10). A transport request stores several tasks, which are where developers save their changes if the changes are all in the same context. To allow the transfer of a transport request from one system to another, all tasks must be released (as well as the transport request itself). Only the developer should release his personal tasks because only that developer knows what he did, the status of the changes, and so on. This is why tasks should be released directly in the development system, not through SAP Solution Manager. There is no configuration necessary to allow this exception because SAP Solution Manager does not manage the task release — this is done natively in the correct satellite system.
After implementing the configuration I describe in this article, you will only be able to execute transport request management through SAP Solution Manager. As a result, system administrators can control access using SAP Solution Manager authorizations. In other words, there is no need to manage these authorizations in each satellite system.
To illustrate the process, I will briefly explain the following steps to perform:
- Step 1. Customize the cluster. A cluster is a group of correlated tables. The cluster /TMWFLOW/VC_CPVR is where SAP Solution Manager checks which actions have to be performed using the TMW RFC.
- Step 2. Check table TSOCM_ACTION_O_S. You can also adjust the table, if necessary. This table is where SAP Solution Manager checks which actions (e.g., transports or create a transport requests) can be executed in each transaction type (a transaction type is a workflow in SAP Solution Manager).
I will also provide information on other useful tables and an example of the results of this process.
Customize the Cluster
The first step is to change cluster /TMWFLOW/VC_CPVR. SAP Solution Manager checks this cluster to verify if a specific action needs to be performed using the TMW RFC. This particular cluster is structured into three levels: Participant, Variant, and Actions of a Participant in a Variant. Each action has a related action executed by the system behind the scenes (I will explain more about this internal action later in this section).
To start, execute transaction SM34 in SAP Solution Manager, type /TMWFLOW/VC_CPVR in the selection field, and press F8 to execute. Select the participant CRMS (Change Transaction Management in Service Desk) and double click the Define Variants folder on the left side of the screen. Then, select the variant SDDV (Change Transaction: Development Release) and double-click the Actions of a Participant folder on the left side of the screen (Figure 1).
Figure 1
The structure of the cluster /TMWFLOW/VC_CPVR
The two Text fields in Figure 1 are filled automatically. SAP Solution Manager always uses CRMS as the Participant. The Variant depends on the transaction type being used. A transaction type is the type of workflow configured in SAP Solution Manager, and there are two major types: urgent corrections and regular (or normal) corrections. The names are straightforward: an urgent correction is used to manage changes that need to reach the production system as soon as possible (e.g., legal or tax changes), so these corrections have a shorter life cycle. A regular correction is used to manage wider, more complex changes that need to go through several approvals and tests (e.g., the development of an entirely new process), so these corrections have a longer life cycle. For more on corrections, you can refer to my article “Crossing Transport Request Boundaries with ChaRM.”
The variant SDDV shown in Figure 1 is related to a development cycle (development cycles have longer life cycles) and is used for regular corrections. The variant SDMN is used for urgent corrections because it is related to the maintenance cycle. Usually, it isn’t necessary to execute the same configurations in both the SDDV and SDMN variants (personally, I’ve never had to). However, if an action related to transport request management is in fact performed through a non-TMW RFC, my recommendation is to copy the configuration from one variant to another by manually repeating all the configuration steps and then performing a complete set of tests.
Note
There is a third variant, SDMM, that is not used in the context of this article and you don’t need to maintain it to perform these steps. This variant exists only for backward compatibility with previous SAP versions.
As you can see in Figure 1, the Actions of a Participant area has two columns. The first contains the actions executed by the user by clicking the Actions button in a transaction document. The second contains the actions executed by the system in the background. The value of the first column is the name of the action (which corresponds to the actions configured in a transaction type using transaction SPPFCADM) suffixed by the standard transaction type. For example, the action to release all transport requests in transaction type SDMJ (which corresponds to regular corrections) is RELEASE_ALL_SDMJ. I use the phrase “standard” transaction type because when you execute configuration in ChaRM, the correct procedure is to copy the standard transaction types to other ones, only changing the names so they begin with Y or Z (e.g., you would change SDMJ to ZDMJ). You should then perform customizations on the copies so the standard ones are kept as-is for further reference. The names of the actions in the first column in Figure 1 must reference the standard names (e.g., SXXX), not the customized ones (e.g., ZXXX or YXXX).
The name of the action in the second column is difficult to determine because there is not much documentation on it. The best way to find the correct name is to check the log in the ChaRM tasklist by opening the change document using transaction CRMD_ORDER or CRM_DNO_MONITOR. Click the Parameters tab and then refer to the Action line (Figure 2).
You might have noticed that the second column has values suffixed by UC. There are two possible suffixes: RC for Regular Corrections and UC for Urgent Corrections. You must follow this pattern when configuring your system. I explain a few exceptions to this rule in the next section.
Figure 2
The task list log
Sometimes you reach a trouble spot here: There are situations in which the system uses the trusted RFC instead of the TMW RFC and doesn’t show the corresponding action in the tasklist log (i.e., the Action line has an empty value). Remember, the action name corresponds to the second column in the configuration. In turn, this means another configuration is missing in table TSOCM_ACTION_O_S. I will explain this in the next section, “Check Table TSOCM_ACTION_O_S.”
Check Table TSOCM_ACTION_O_S
As I stated, there can be situations when your task list shows empty actions and uses the trusted RFC instead of the TMW RFC. This occurs when values are missing in table TSOCM_ACTION_O_S. To maintain this table, use transaction SE16 or follow IMG menu path SAP Solution Manager > Change Request Management > Extended Configuration > Change Transaction > Change Transaction Types > Actions in Change Request Management > Actions — Depending on Status (Figure 3).
Figure 3
Table TSOCM_ACTION_O_S
This table assigns actions (via column ACTION_ID) for each status (column USER_STATUS) in a transaction type (column PROCESS_TYPE). When the issue I describe occurs, the corresponding action X transaction type may be missing. Simply create a new line with the correct values and test. Note that one line is frequently missing in this table in the current version of SAP Solution Manager: Create a new task in an existing transport request (action CREATE_TASK).
This table has one important rule: The transaction type here is the real one, not the standard one. Therefore, if you made a copy (e.g., from SDMJ to ZDMJ), enter ZDMJ — not SDMJ. Notice that the action here corresponds to the first column in the cluster /TMWFLOW/VC_CPVR.
As I said, there are a few exceptions to the prefix rule (i.e., RC or UC). One undocumented exception that I discovered after several hours of debugging is that to create tasks, SAP Solution Manager always considers the prefix RC even if the transaction type being checked corresponds to an urgent correction.
Another tip: To release transport requests, the action RELEASE_REQU is not enough. The action RELEASE_ALL_XXXX must be configured as well (where XXXX is the transaction type). This is because when the system is releasing transport requests, sometimes it performs several checks (the release itself, deleting empty requests, and in some cases, triggering import jobs). If only one of the actions is configured, the system may behave inconsistently. For example, if there is no empty transport request to delete, the system works fine with only the action RELEASE_ALL. Otherwise, the system tries to work around the missing action by executing another one: DELETE_EMPTY. Because this action is also missing, it executes the action using the trusted RFC instead of the TMW RFC.
Useful Tables
You can review the following tables with transaction SE16:
- To find out the existing transaction types, check table CRMV_PROC_TYPE
- To determine the configured user statuses, check table TJ30
-
For all possible actions (first column in the cluster /TMWFLOW/VC_CPVR), check tables PPFTMETETX and PPFTCONDTR. For the second column (in the same cluster), use the drop-down list of the field by pressing F4 after selecting any line of the column.
Results and Final Suggestions
After you have configured all the actions related to the transaction types your company uses and followed the steps I described, SAP Solution Manager will only connect to the satellite systems through TMW RFCs. You can verify this by checking the tasklist log shown in Figure 3. After checking that all actions are being executed through TMW RFCs, you can remove the corresponding authorizations from the satellite systems from all user profiles. I suggest that before you remove the authorizations, you inform the users of the removal and explain the reasons behind and benefits of this procedure. This helps you avoid users who think that something went wrong with the system.
If you want to reach the highest level of security in your satellite systems after performing the steps I explained, you can change the password of the users in these systems. SAP Solution Manager connects to these systems using the TMW RFC and, when users have to log on to the systems to perform some task, they will be able to do so through SAP Solution Manager (the passwords don’t have to match). This way you can ensure that, for example, particular developers are able to log in to a development system only if they are assigned as developers on a change in that system and only if the phase of that change is development. If the phase changes to test, for example, the developer won’t be able to access the system anymore. The same could apply to testers in test systems and so on.
The approach I’ve described should only be adopted after a complete mindset alignment among all the team members. This will help your organization avoid issues such as people thinking they are losing power, or teams that are used to working in urgent situations where they have “anytime and anywhere” access. I suggest a series of workshops to explain the benefits and give team members space to discuss the pros and cons and adjust your approach to their suggestions if you agree with them.
Cristiano Canzone
Cristiano Canzone is an SAP Solution Manager-certified consultant who has worked at SAP Brazil since 2008. In his 12 years of SAP experience, he has also worked at PricewaterhouseCoopers and IBM as an SAP Basis-certified consultant. Cristiano is currently the SAP resource responsible for the SAP Solution Manager initiatives at Petrobras, the largest oil company in Latin America. He lives in Rio de Janeiro, Brazil with his wife, who is also an SAP consultant (specialized in SAP ERP HCM).
You may contact the author at cristiano.canzone@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
