Steps to Set Up the CUA

1. Create Administrator
2. Specify Logical systems
3. Assign logical systems to client
4. Create system users
5. Create RFC destinations
6. Create CUA
7. Set field distributor parameters
8. Synchronization of company addresses
9. Transfer Users

Below are the systems considered as an example to set up CUA:

• System ABC with client 123
• System PQR with client 456
• System XYZ with client 789

Here, we will set system ABC (client 123) as a CUA central system and other systems as child systems. As per this structure, we will proceed with above mentioned steps:

1. Create Administrator User

In a completely new system that is to be set up, an administration user needs to be created with which all further steps can be performed. To create such administrator user:

• Login to all systems with user SAP* and create the user in t-code SU01
• Assign the relevant administrator role to user
• Apply the security measures to secure SAP* user against misuse

2. Specify Logical systems

In CUA landscape, SAP systems are identified with Logical system names. Due to this, Logical systems need to be created for every system which is going to be included in CUA landscape. This is one time task to be performed before setting up CUA. The Logical systems can be defined be following below steps:

• Login to system ABC (client 123) with administrator user created in step 1
• Go to t-code BD54 You can; alternatively maintain the table view V_TBDLS using transaction SM30.
• Choose Edit ? New Entries
• In the LogSystem column, create a new logical name in capital letters for every CUA system (that is, for the central and all child systems including those from other SAP Systems). Here, the standard naming convention for logical system is <System ID>CLNT<Client>. In this way, the below logical systems will be created in CUA central system (ABC system):
  • ABCCLNT123
  • PQRCLNT456
  • XYZCLNT789

In the same way, create the logical system name for the central system in all child systems.

3. Assign logical systems to client

We need to perform this cross-client procedure only once for each SAP system as per below procedure:

• Login with administrator user and execute the t-code SCC4
• Switch to change mode
• Call the detail display of the client that you want to assign a logical system by double clicking on the line of the client
• In the Logical System field, specify the name of the logical system to which the selected client is to be assigned

Ex: – If we execute the t-code SCC4 in system ABC then, open the client 123 and maintain the logical system name as ABCCLNT123

4.Create system users

System users are required for the internal communication of the systems in an ALE group. These system users, defined in the target systems, are entered in RFC destinations in the calling systems.

Note: – No license fees apply to these system users.

To simplify the maintenance of system users, use the following naming conventions:

• In the central system (system ABC), the naming convention will be CUA_<system Id>. This system user is used in the RFC destinations from child to central system. With this naming convention, we need to create the system user in system ABC with name: CUA_ABC
• In the child systems, the naming convention CUA__<System Id>_<Client>. These system users are used in the RFC destinations from central to child system. With this naming convention, we need to create the system users as below:

Below are SAP delivered roles for system users which need to be copied to customer namespace before assigning them to system users.

Roles in Central system:

• SAP_BC_USR_CUA_SETUP_CENTRAL
• SAP_BC_USR_CUA_CENTRAL
• SAP_BC_USR_CUA_CENTRAL_BDIST

Roles in child system:

• SAP_BC_USR_CUA_SETUP_CLIENT
• SAP_BC_USR_CUA_CLIENT

With these details, we need to create the respective users with their applicable authorizations in t-code SU01 as below:

5. Create RFC destinations

Till this step, we are ready with Logical systems and system users, Now, we need to create RFC connections between the systems as mentioned in below steps:

• Login to central system ABC, execute the t-code SM59 and Choose Create.
• Enter the following data:

Note: – You must create the name of the RFC destination in capital letters.

• Confirm your entries with ENTER
• Choose the option Host Name for Save as and Confirm your entries with ENTER
• Specify the name of the SAP system of the child system (such as PQR) in the target system ID field. To do this, overwrite the automatic entry.
• Specify the message server of the target system in the MessageServer field. To do this, overwrite the automatic entry.
• Save your entries.
• To define the return connection, repeat the procedure in the child system for the central system
• To determine whether the network connection between the two systems is functioning correctly, choose Test Connection.

In this way, we have created the RFC connections (with names identical to Logical system name of target system) in each SAP systems.

6. Create CUA

Till now, we have connected all the systems ABC, PQR and XYZ as in below figure:

Now, we will define the system ABC as CUA in this landscape as detailed in below steps:

• Login to system ABC and execute the t-code SCUA
• Enter the name of your distribution model, such as CUA.
• Choose Create.
• Enter the name of the child systems viz. PQRCLNT456 and XYZCLNT789
• Save your entries.

In this way, we have defined the system ABC as central system. After completion of this step, you can no longer create user master records in the child systems.

7.  Set field distributor parameters

In Central User Administration, we can use the distribution parameters in transaction SCUM to determine where individual parts of a user master record are maintained.

• In the central system
• Locally in the child system
• In the child system with automatic redistribution to the central system and the other CUA child system

Every input field of the user maintenance transaction SU01 has a field attribute that you set once in the central system with transaction SCUM during Customizing. To perform this customizing, perform the below steps:

• Login to system ABC and execute the t-code SCUM

The system displays the User Distribution Field Selection screen, with tab pages of the fields whose distribution parameters you can set. You can select the following options on the tab pages:

• To maintain the other parameters, too, switch to the other tab pages. The tab pages correspond to those of user maintenance.
• Save your entries. The distribution parameters are automatically transferred to the child systems.

8. Synchronization of company addresses

The company addresses are maintained in individual systems PQR and XYZ. To enable CUA to communicate properly you must ensure that at least the central system contains complete information about all valid company addresses. You then distribute this complete company address set to all child systems, meaning that there is a consistent status of company addresses in the entire CUA.

Steps:

• Login to central system ABC and execute the t-code SCUG
• Select the first child system PQR and choose Synchronize Company Addresses in the Central System
• Process all sub lists for the address categories in succession and repeat the above steps for system XYZ
• Choose Back to start the address distribution from the central system.
• Choose Distribute Synchronized Company Addresses to target Systems icon.

9. Transfer Users

As soon as we have configured the CUA, the users from child systems need to be transferred to Central system so that we can see their authorization details (such as roles to be assigned to users for child system and the roles assigned to them). The procedure is given in below steps:

• Login to central system ABC and execute the t-code SCUG
• Place the cursor on central system name appeared on the screen and click on the Transfer Users.
• The system displays the following tab pages:

• Select all new and changed users and choose Transfer Users.
• Perform the above 2 steps for child systems PQR and XYZ
• After you have completed the user transfer, remove the roles Z_SAP_BC_CUA_SETUP_CENTRAL and Z_SAP_BC_USR_CUA_SETUP_CLIENT from the system users.

At this stage, the CUA set up is completed.

However, this situation has some limits:

• There are large numbers of table which are not assigned to any authorization groups, these are included under authorization group &NC& but assignment of tables to this authorization group is not much useful while securing access to any particular table.
• The authorization group name can have up to 4 characters hence there is a limit to define the authorization group.
• If we need to give access to only one table belonging to some authorization group; say XYZ then it involves an additional efforts.

To overcome these limitations, we can use the authorization object S_TABU_NAM. This authorization object contains two fields as below:

• Activity (ACTVT) – Display or change access similar to ACTVT in S_TABU_DIS
• Table Name (TABNAME) – Name of table of view

With this object, the system checks the view names or table names directly so that an exact authorization check is possible. Also, this table is checked only if the authorization check on S_TABU_DIS is unsuccessful. In this way, this provision enables both features providing more flexibility.
The authorization object S_TABU_NAM is provided in recent versions of SAP Systems, a relevant note/correction instructions need to be applied to system with lower versions. At program level, the authorization check on S_TABU_NAM is implemented only in the module VIEW_AUTHORITY_CHECK.

• Sample Mock Test – CUA – SAP
• Sample Mock Test – SAP R/3 Security

1. How to create the user group in SAP system?
Ans :
User group can be created by performing the below steps:

• Execute the t-code SUGR
• Enter the name of user group to be created in the textbox
• Click on the create the button
• Enter the description and click on save button

2. How to find the Transport requests containing the specific role?
Ans :
The list of Transport requests containing the specific role can be retrieved by performing below steps:

• Execute the t-code SE03
• Double click on option “Search for Objects in requests/Tasks” under node “Objects in Requests” in left panel of screen. This will take us to new screen.
• In object selection screen, enter the field value as ACGR and check the checkbox present at left side.
• Enter the role name for which we need the list of transport request.
• In screen “Request/Task Selection” screen (below section of the same screen), check the status of the requests which we need in the list
• Click on execute button

3. How to check the transport requests created by other user?
Ans:
The t-code SE10 provide the option to enter the user name. By using this facility, we can search the transport requests created by other users.

4. How to generate the list of roles having authorization objects with status as “maintained”?
Ans:
This list can be generated by using the table AGR_1251 as below:

• Execute the t-code SE16
• Enter the table name as AGR_1251 and hit enter button
• Enter the field value as “G” in field “Object Status” and click on execute

The same table can be used to generate the list of roles with authorization objects having status modified and manual with field values M and U respectively.

5. How to find the email ids if given a list of users (say 100)?
Ans:
The list of email ids for given users can be generated by performing the below steps:

• Execute the t-code SE16
• Enter the table name as USR21.
• Upload the list of users using multiple selection option and execute. This will give us the list of users and their respective person numbers
• Extract this data to excel sheet
• Now, go back to SE16 and enter table name ADR6
• Upload the list of person number extracted from table USR21 and execute
• Now, table ADR6 will give us the list of person numbers and their email ids.
• Download the list in excel and perform V-look up in excel to map the email ids of users with their SAP IDs

6. How to find user defined, system default values for security parameters?
Ans :
The values for parameters can be checked by using the t-code RSPFPAR. After executing the t-code, given the parameter name and click on execute.

7. How to assign the logical system to client?
Ans :
Logical system can be assigned to client by using the t-code SCC4. We need to be very careful while doing this change as it can affect the CUA (if configured).

8. Which entities are not distributed while distributing the authorization data from master role to derived roles?
Ans:
During the distribution of authorization data from master role to derived roles, Organizational values and user assignment are not distributed. The Org. values and user assignments are specific to individual roles hence has no bearing on master-derived role relationship.

9. How to assign the multiple roles to more than 20 users in one shot in t-code SU10?
Ans :
To perform this mass role assignment, we need to follow below steps in SU10:

• In SU10 home screen, click on the button “Authorization Data”
• This will take to the new screen similar to screen in t-code SUIM -> User by complex search criteria. Enter the search criteria for users needed to be changed in SU10 and execute the same
• Once the list of users is reflected, click on “select all” button on left top corner of the list and click on “Transfer” button. This will take us back to SU10 screen with all the selected users in users
• Now, click on select all button in SU10 home screen and then click on change button.
• Above step will take us to the next screen where you can perform the role assignment as in normal case of SU10 t-code

10. What is the use of SU25 t-code?
Ans:
The t-code SU25 is used to copy the data from tables USOBT and USOBX to tables USOBT_C and USOBX_C. Generally, this t-code needs to be executed after the installation of system upgrade so that the values in customer tables are updated accordingly.

11. What is the use of authorization object S_TABU_LIN?
Ans:
This authorization object is used to provide the access to tables on row level.

12. What are the authorization groups and how to create them?
Ans :
Authorization groups are the units comprising of tables for common functional area. Generally, each table is assigned to a authorization group due to this reason we need to mention the value of authorization group while restricting the access to table in authorization object S_TABU_DIS.
The authorization group can be created by using the t-code SE54. The assignment of tables to authorization group can be checked by using table TDDAT.

13. What is SOX (Sarbanes Oxley)?
Ans:
Sarbanes-Oxley is a US law passed in 2002 to strengthen corporate governance and restore investor confidence. Act was sponsored by US Senator Paul Sarbanes and US Representative Michael Oxley.

The Sarbanes-Oxley Act is legislation enacted in response to the high-profile Enron and WorldCom financial scandals to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise. Sarbanes-Oxley defines which records are to be stored and for how long. The legislation not only affects the financial side of corporations, but also affects the IT departments whose job it is to store a corporation’s electronic records. The Sarbanes-Oxley Act states that all business records, including electronic records and electronic messages, must be saved for “not less than five years”. The consequences for non-compliance are fines, imprisonment, or both. IT departments are increasingly faced with the challenge of creating and maintaining a corporate records archive in a cost-effective fashion that satisfies the requirements put forth by the legislation.

Organizations should be able to guarantee the integrity of some of their operations like PTP or OTC which can have quiet a significant impact on the way the financial statements are projected if not controlled.

Organizations today are thereby moving in direction of automating their softwares for SOX compliance. A key factor towards achieving SOX compliance is to seperate the duties amongst individuals to such an extent that no one person has the authorization to fulfill a complete cycle say procurement or sales.

14. How to create a query in SAP R/3 system?
Ans:
The query can be created and executed using the t-code SQVI:

• Execute the t-code SQVI.
• Enter the name of query to be created and click on create button.
• Enter the Title and comments for query and select the data source such as table or table join.
• Select the preferred view as Basis Mode or Layout Mode and click on continue button.
• Above step will take us to the new screen, add the respective table on which we need to create a query.
• If Data source is selected as table join, select the respective tables as needed and joining fields.
• Save and come to main screen. Here, you need to select the fields to be displayed in output and their sequence.

The query can be created and executed using the t-code SQVI.

15. What is the use of ST01? What are the return codes of t-code ST01
Ans:
Transaction code ST01 is used to trace the user authorizations. This can be useful if we need to check which all the authorizations have been checked in background when any t-code is being executed by the business user.

Below are the return codes of ST01 :

• 0 – Authorization check passed
• 1 – No Authorization
• 2 – Too many parameters for authorization check
• 3 – Object not contained in user buffer
• 4 – No profile contained in user buffer
• 6 – Authorization check incorrect
• 7,8,9 – Invalid user buffer

• Login to system
• Execute the t-code SU01 and open the user
• Assign the role and save the changes

The above process can be simplified if Central User Administration system (CUA) has been installed in above landscape. Now, we will go through the detailed introduction to CUA in below section.
CUA is a SAP system to which all the SAP systems in landscape are connected through RFC connections. This enables user to perform user maintenance for all the connected systems from one central CUA system. Below is the pictorial representation of this concept:

As given in above diagram, the CUA system is connected with other SAP systems such SAP ECC, SAP BW and SAP CRM. Now, if we need to assign the role to user in all the systems present in the landscape then we need to perform the below steps in CUA system only.

• Login to system
• Execute the t-code SU01 and open the user
• Assign the role to user for respective systems and save the changes

However, to achieve this, the SAP IDs of user need to be same in all the system. We will discuss the technical background about CUA in our next blogs.

2 .  Which Authorization Objects are Checked in Role Maintenance ?
Ans:
The role maintenance functions (and the profile generator) check the following authorization objects.

Authorization Object	Description
S_USER_AUT	User master maintenance: Authorizations This authorization object defines which authorizations the administrator can process. You can use the activities to specify the types of processing (such as creating, deleting, displaying change documents).
S_USER_GRP	User master maintenance: User groups The authorization object is used in role maintenance when assigning users to roles and during the user master comparison. You can divide user administration between several administrators with this authorization object, by assigning only a certain user group to an administrator. You can use the activities to specify the administrator’s processing types for the group (such as creating, deleting, and archiving).
S_USER_PRO	User master maintenance: Authorization profiles Profiles are protected with this authorization object. You can use the activities to specify the administrator\'s processing types for the profile (such as creating, deleting, and archiving).
S_USER_AGR	Authorization system: Check for roles This authorization object protects roles. The roles combine users into groups to assign various properties to them; in particular, transactions and authorization profiles. You can use this authorization object together with the authorization objects S_USER_GRP, S_USER_AUT, S_USER_PRO, S_USER_TCD, and S_USER_VAL to set up a distributed user administration.
S_USER_TCD	Authorization system: Transactions in roles This authorization object determines the transactions that an administrator can assign to a role, and the transactions for which he or she can assign transaction authorization (object S_TCODE). Note that a user can only maintain ranges of transactions for the S_TCODE authorization object in the Profile Generator if he or she has full authorization for the S_USER_TCD authorization object. Otherwise, he or she can only maintain individual values for the S_TCODE object.
S_USER_VAL	Authorization system: Field values in roles This authorization object allows the restriction of values that a system administrator can insert or change in a role in the Profile Generator. This authorization object relates to all field values with the exception of the values for the object S_TCODE. The authorization to include transactions in a role or to change the transaction start authorization in a role is linked to the authorization object S_USER_TCD.
S_USER_SYS	Authorization object for system assignment in the Central User Administration (CUA). You can distribute users from a central system to various child systems of a system group. The object S_USER_SYS is used to check the systems to which the user administrator can assign the users. This authorization object is also checked when setting up the CUA.
S_USER_SAS	User master maintenance: System-specific assignments The authorization object S_USER_SAS is checked in transactions SU01, SU10, PFCG, and PFUD when you assign roles, profiles, and systems to users. It represents a development of the authorization objects S_USER_GRP, S_USER_AGR, S_USER_PRO, and S_USER_SYS, which the system previously checked when users made assignments. If you do not activate the authorization object S_USER_SAS using the Customizing switch, the previously-used authorization objects are checked. To activate authorization object S_USER_SAS, use transaction SM30 to create the Customizing switch CHECK_S_USER_SAS with the value YES in the table PRGN_CUST. All authorization checks for the objects S_USER_AGR, S_USER_PRO, S_USER_GRP, and S_USER_SYS with the activity assign are replaced by authorization checks for the object S_USER_SAS.
S_USER_ADM	Administration functions for user and authorization administration. The authorization object S_USER_ADM protects general Customizing and administration tasks for user and authorization administration. It consists solely of the authorization field S_ADM_AREA. Until now, there was only the fixed value CHKSTDPWD, with which special users (such as SAP*) could be displayed, including their default passwords. SAP extends additional fixed values as required for other general administration functions in the area of user and authorization administration, which are listed in SAP Note 704307.

3 .  Which T-Codes are used to see overview of the Authorization Object and Profile details?
Ans:
SU03 – overview of any authorization Object
SU02 – to see the details of profiles.

SU21 also provides the same editing structure as SU03 but we can create a new authorization object using SU21. Here, we need to click on “Display Object Documentation“ button to see the documentation for the authoriztion Object and we need to click on “Permitted activity values“ to see the list of permitted activities for the fields.

These details are fetched from table TACT.

4. How to restrict the user access to one particular table in display mode ?
Ans : If the system is BASIS 700, we can use the authorization object S_TABU_NAM. In this auth. Object, we can maintain the values for required activity and the table name.
If the system version is lower than 700, and the table is z* table then

• Create a new authorization Group using SE54.
• Assign the table in question to the newly created authorization Group in table TDDAT using SM30.

If the table is SAP standard table then we can restrict user access by creating new tcode in SE93.

5.How to check the table Logs ?
Ans:
First, we need to check if the logging is activated for table using tcode SE13. If table logging is enabled then we can see the table logs in t-code SCU3.

6. What’s the basic difference in between SU22 & SU24 ?
Ans:
SU22 displays and updates the values in tables USOBT and USOBX, while SU24 does the same in tables USOBT_C and USOBX_C. The _C stands for Customer. The profile generator gets its data from the _C tables. In the USOBT and USOBX tables the values are the SAP standard values as shown in SU24. With SU25 one can (initially) transfer the USOBT values to the USOBT_C table.

7. What is the difference between USOBX_C and USOBT_C ?
Ans:
The table USOBX_C defines which authorization checks are to be performed within a transaction and which not (despite authority- check command programed). This table also determines which authorization checks are maintained in the Profile Generator.
The table USOBT_C defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator.

8. What does user compare do ?
Ans:
If you are also using the role to generate authorization profiles, then you should note that the generated profile is not entered in the user master record until the user master records have been compared. You can automate this by scheduling report PFCG_TIME_DEPENDENCY on a daily or by executing the t-code PFUD.

9. Can we convert Authorization field to Organizational field ?
Ans:
Authorization field can be changed to Organization field using PFCG_ORGFIELD_CREATE or ZPFCG_ORGFIELD_CREATE.
Use SE38 or SA38 to run the above report.

• Organizational level fields should only be created before you start setting up your system. If you create organizational level fields later, you might have to do an impact analysis. The authentication data may have to be post processed in roles.
• The fields “Activity“, “ACTVT” and “Transaction code“, “TCD” cannot be converted into an organizational level field.

In addition, all affected roles are analyzed and the authorization data is adjusted. The values of the authorization field which is now to become the organizational level field are removed and entered into the organizational level data of the role.
Note: Table for Organizational Element- USORG. Refer to Note 323817 for more detail.

10. What is user buffer ?
Ans :
When a user logs on to the SAP R/3 System, a user buffer is built containing all authorizations for that user. Each user has their own individual user buffer. For example, if user Smith logs on to the system, his user buffer contains all authorizations of role USER_SMITH_ROLE. The user buffer can be displayed in transaction SU56.
A user would fail an authorization check if:

•  The authorization object does not exist in the user buffer
• The values checked by the application are not assigned to the authorization object in the user buffer
• The user buffer contains too many entries and has overflowed. The number of entries in the user buffer can be controlled using the system profile parameter auth/number_in_userbuffer.

11. How to remove duplicate roles with different start and end date from user master ?
Ans:
You can use PRGN_COMPRESS_TIMES to do this. Please refer to note 365841 for more info.

When in transaction SE16N use the command &SAP_EDIT in the command field in SAP. However, this works if you have debug with changes access for object S_DEVELOP, but S_TABU_DIS is ignored as well as the system settings regarding changes. If you use this function for transaction, master data or other tables that cannot be changed with SM30, you can cause quiet some damage.  So, use with caution.

The step by step information is given below:

1:  Use transaction SE16N  and enter a table of your choic

2: In the command field enter “&SAP_EDIT” and hit enter. The maintenance indicator in SE16N will be switched  on.

3) Execute the table for requried values and the table entries can be edited:

If you dont have access to S_DEVELOP with change activities for object type DEBUG, this function will not be possible.

If you want to allow this function, you can audit who changed data via SE16N by browsing the following tables;

SE16N_CD_KEY : Change Documents – Header
SE16N_CD_DATA : Change Documents – Data

Review the following:- 

 System security file parameters (TU02) (e.g. password length/format, forced password sessions,  user failures to end  session etc.) have been set to ensure confidentiality and integrity of password.

      Security-Parameter-Settings-Documentation

1.  Setup and modification of user master records follows a specific procedure and is properly approved by management. 

2. Setup and modification of authorizations and profiles follows a specific procedure and is performed by someone 
   independent of the person responsible for user master record maintenance. 

3. An appropriate naming convention for profiles, authorizations and authorization objects has been developed to help security maintenance and to comply with required SAP R/3 naming conventions. 

4. A user master record is created for each user defining a user ID and password. Each user is assigned to a user group, in the user master record, commensurate with their job responsibilities. 

5. Check objects (SU24) have been assigned to key transactions) to restrict access to those transaction. 

6. Authorization objects and authorizations have been assigned to users based on their job responsibilities and ensuring the SOD (Segregation of duties). 

7. Users can maintain only system tables commensurate with their job responsibilities

     Select a sample of :- 

1. Changes to user master records, profiles and authorizations and ensure the changes were properly approved. (The changes can be viewed with transaction (SECR). 

2. Verify that a naming convention has been developed for profiles, authorizations and in-house developed authorization objects to ensure that theycan be easily managed and will not be overwritten by a subsequent release upgrade (for Release 2.2 should begin with Y_ or Z_ and for Release 3.0 by Z_ only.) 

3. Assess and review of the use of the authorization object S_TABU_DIS and review of table authorization classes 
   (TDDAT)  whether all system tables are assigned an appropriate authorization class and users are assigned system table maintenance access (Through S_TABU_DIS) based on authorization classes commensurate with their job responsibilities. 

4. Assess and review of the use of the authorization objects S_Program and S_Editor and the review of program classes (TRDIR) whether all programs are assigned the appropriate program class and users are assigned program classes commensurate with their job responsibilities.

• In CCMS infrastructure , if the system identifies a problem, it should execute an auto reaction, such as informing the responsible person.

• Completed messages alerts are no longer stored in the monitoring segment, but rather in a database table (ALALERTDB). This table should be regularly cleaned up (report RSALDBRG). The completed messages can still be displayed using the Alert History.

• From a security point of view, it is recommended that you also define a second RFC connection between the systems, with which the analysis methods can be started in the remote system from the central monitoring system. If a problem occurs, you can therefore branch directly from the central monitor to the remote system to analyze the situation in more detail.

• SAP recommends that, for your regular work, you create your own monitors that display precisely the cross-system or local data that you require for your work. The sets and monitors delivered by SAP cannot be changed.

• Threshold values must be stored locally in every system. However, instead of maintaining the same threshold values in every system, SAP recommends that you maintain the values in the central monitoring system and then distribute them to the monitored SAP systems using the transport system.

• The delivered SAP monitors should always be used only as templates. The copied monitors are then adjusted to the customer’s requirements.

• Transfer as little data as possible by RFC

• Before you create your own monitor, you should clarify the purpose of the monitor. The monitor should display as little data as possible in as clear a way as possible.

• The prerequisite for transporting the threshold values to other SAP systems is that you have stored them in properties variants.
• In the RFC connection that is used for the start of the analysis method, do not enter a user, but rather check the field Current User.

• As a global guide value, SAP recommends 10-20 monitoring attributes for each monitored instance in the central monitor.
• Note the naming convention that your monitor set should not begin with SAP.

 Basis Support Packages (SAP KB 62050)

ABAP Support Packages (SAP KA 62050)

Application Support Packages (SAP KH 47050)

HR Support Packages (SAP KE 47050)

Prerequisites:

1. SPAU and SPDD list should be checked before start of support package application.

2. Objects in repair state needs to be released. 

3. It is recommended that latest SPAM/ SAINT version should be applied before starting and Support Package application.

4. Enough space to hold the support packs in “EPS” in directory USR/SAP/TRANS/EPS/IN. There should be no aborted packages from previous support pack or Plug In applied.

5.  Support Packages should be applied in the sequence of number of support packs.

6. Technical & functional consultants need to be informed while applying support packages.

7. Schedule downtime and inform the users.

8. Go through composite note thoroughly before applying support packs. If the support pack is  greater than 10MB then uncar the file using command SAPCAR – XVF .sar. When we uncar, two files are generated with extensions .ATT&  .PAT

EXECUTING SUPPORT PACKS

1. Go to transaction code Spam

2. Load Packages from the presentation server/Application server

3. Display all the new support patches to be applied

4. Select the support package to be applied

5. Import the Queue Support Package starts upgrading the system and it goes into various phases like TP connect to DB, DDIC import, DDIC Activation. These phases can be found in Table PAT01.  While applying support packages its stops to run SPAU/SPDD.

 SPAU: This is the transaction to update repository objects like programs, reports, transactions, function modules while applying support packs. This is the phase where functional consultant’s assistance is required.

SPDD: This is the transaction which is used to update Data Dictionary Elements while applying support packages. This is the phases where functional consultant’s assistance is required.

Note:  If the objects are changed earlier with the help of SAP notes, now these notes are part of the support packs which are modifying the system. In this scenario each and every object which were modified earlier with the help of Note are popped up on the screen whether to keep the original or change to newer version.