Categories
- ABAP Development
- BASIS Security
- BASIS Administration
- BASIS Database
- BI - Business Intelligence
- CRM Customer Relationship
- EP Enterprise Portals
- FICO Financials
- HCM HR Human Capital
- JAVA Development
- Management Accounting
- Master Data Management
- MM Material Management
- PLM Customer Service
- PLM Data Management
- PLM Plant Management
- PLM Project Management
- PLM Quality Management
- PP Production Planning
- SAP Analytics
- SAP ERP Fundamentals
- SCM Discreet Mfg
- SCM Inventory Warehouse
- SCM Logistics Execution
- SCM Process Mfg
- SCM TM Transportation
- SD Sales and Distribution
- SMI Solution Manager
- SOA Service Architecture
- SRM Supplier Relationship
- XI PI Process Integration
Most Rated Articles
»
BASIS Administration
Rate Author : Current :
2.86 /5
Rate this Article : Current :
3.59 /5
Distributing User Data Using the CUA
With an activated CUA, you continue to use transaction SU01 for user administration. However, there are a number of differences in its operation. The following list should provide you with an overview of the differences in user maintenance when CUA is implemented.
New Systems tab page:
This tab page specifies the logical systems in which it is possible for a particular user to log on. However, you only rarely enter values directly on this tab page , because if a system assignment is removed from a user on the Systems tab page, the user is deleted from the relevant child system.
Roles tab page:
On this tab page, you can assign roles to a user in the systems of the CUA. The central system should know all role names of all connected systems. It is always possible to manually assign a role that exists only in a child system, but not in the target system. However, you can only use the F4 help with current data if you have first performed the Text Comparison from Child Systems . When setting up the CUA, an initial text comparison is automatically performed. Therefore, F4 help is available immediately. If you want to use F4 help with current data, ensure that you perform a new text comparison between the central system and the child system after creating new roles in the child system.
During the text comparison, specify as the Target System the system from which the central information is to query the new information.
Note: If roles were created or changed in a child system, you can choose, in transaction PFCG in the child system, Environment -> Text Comparison for CUA Central System.
Profiles tab page:
The same statements apply to this tab page as to the Roles tab page. The Role Assignment dialog box also appears from this tab page. However, this dialog box is not displayed when assigning profiles.
Change to the New Password/Change Password and Lock User functions
The "New Password/Change Password" function now contains an option for specifying the child system for which the user is to receive a new password. In the future, this option is also to be provided for the "Lock User" function.
The following changes occur for transaction SU01 in the child system.
• All tab pages: restricted changeability
• It is no longer possible to create new users
• It is no longer possible to delete existing users (after complete user transfer)
• User in the Last Changed field
All tab pages:
On all tab pages of transaction SU01 in the child system, you are now able to administer only the fields that you released for local administration during the configuration of the parameters. Local administration is allowed if you chose an administration setting other than Global.
It is no longer possible to create new users or delete existing users (as soon as the users have been completely transferred to CUA).
Last Changed field:
The name of the user that was stored with the RFC connection from the central system to the child system, such as CUA_QAS_200, is specified in this field in the child system for all users that have already been centrally changed.
Fields whose field distribution parameters are set to Redistribution send their content back to the central system, from which this field value is then forwarded to all child systems. Existing entries are updated in this way.
For more information about optimizing the performance of the data distribution of your CUA landscape, see the documentation in the area BC-SEC-USR -> Central User Administration -> Activated Background Processing. To do this, you should have at least basic experience using ALE.
Troubleshooting for the CUA
If the distribution of user data is not functioning, follow the checklist below:
• Transaction SCUL in the central system
• Transaction SM59 in the central system
• Transaction BD64 in the central system
• Transaction SCUA in the central system
• Transaction BD87 in the child system
• SAP Note 333441: CUA: Tips for problem analysis
1. View the distribution log in transaction SU01: Environment -> Distribution Log. Alternatively, call transaction SCUL . If Errors are displayed here, you can choose Resend User as a first step. Trace whether the problem persists or whether the data is sent successfully this time.
2. If the display of the distribution log informs you of tRFC with Errors, you should check the RFC connections used in transaction SM59.
3. In transaction SCUL, choose Environment -> ALE Distribution Model (transaction BD64), to check the consistency of the ALE model that you are using. To do this, select the model for your CUA and check whether the required BAPIs USER.Clone and UserCompany.Clone are assigned to your model.
4. Check whether your CUA distribution model is displayed in transaction SCUA.
5. If it was not possible to completely process IDocs with user data changes in the child system (Unconfirmed status in transaction SCUL), this can be because there are not enough dialog work processes available (in the child system or in the contacted instance). In this case, you can start postprocessing of the IDocs in the child system using transaction BD87, or opt for inbound processing of the IDocs in a background job. The second variant is described in more detail in SAP Note 399271: CUA: Tips on optimizing performance of ALE distrib..
You should also take a look at SAP Note 555229: IDocs hang in status 64 for tRFC with immediate processing.
6. For more advanced analysis, use the tips in SAP Note 333441: CUA: Tips for problem analysis.
Caution: Ensure that you read the important SAP Notes, which are listed in the composite SAP Note 159885: CUA: Composite note for Central User Administration.
Removing the CUA
It is important to differentiate between two (three) possible scenarios for removing the CUA.
1. A child system is to be removed from the CUA (permanently or temporarily).
2. The CUA is to be completely removed.
These scenarios are presented here. Steps to permanently remove a child system from the CUA:
1. Choose Delete in transaction SCUA or call report RSDELCUA directly in transaction SA38.
2. In the Delete area, choose the option Child System, and then select the child system to be removed using the F4 help.
3. Choose Test and Execute.
4. On the following screen, the system lists the data to be deleted and the tables affected. By double-clicking a table name, you jump to the display of the table content (as it is displayed using transaction code SE16).
5. If you are sure that you want to delete the displayed data, choose Back (F3) and deselect the Test option. Choose Execute.
6. In transaction WE20 , under Partner Profiles for Partner Type LS, delete the message types CCLONE and USERCLONE for the child system.
7. Start transaction BD64, and switch to change mode.
8. Delete the methods of the child system and save your entries.
9. Distribute the distribution model of your CUA by choosing Edit -> Model View -> Distribute and selecting the child system that you have just deleted in the selection in the dialog box.
10. Use transaction SCUA to check whether the child system was deleted from the CUA.
11. If there are no additional child systems of the CUA in the SAP system that contains the child system to be deleted from the CUA, change the communication user (such as CUA_QAS) in transaction SU01 by removing the role Z_SAP_BC_USR_CUA_CLIENT on the Roles tab page. If there are no longer any roles or profiles assigned to the user, you can delete it.
Steps to delete the entire CUA:
1. Start report RSDELCUA on the central system with the options Complete CUA and Test.
2. If you are satisfied with the list of data to be deleted, run the report again, but this time without the Test option.
3. In the central system, delete the data about the central system and the child system(s) in transaction WE20; that is, delete the message types CCLONE and USERCLONE under Partner Profile for the Partner Type LS.If only the standard message type SYNCH then remains, you can delete the partner profiles completely.
4. In transaction BD64, delete the distribution model of the CUA.
5. Repeat steps 3 and 4 in the child systems.
6. Remove the CUA roles (such as Z_SAP_BC_USR_CUA_CENTRAL and Z_SAP_BC_USR_CUA_CLIENT) from all communication users (such as CUA_QAS_200 or CUA_DEV).
Caution: Delete the RFC connections of the CUA only if you are certain that these connections are not used in other ALE scenarios.
With an activated CUA, you continue to use transaction SU01 for user administration. However, there are a number of differences in its operation. The following list should provide you with an overview of the differences in user maintenance when CUA is implemented.
New Systems tab page:
This tab page specifies the logical systems in which it is possible for a particular user to log on. However, you only rarely enter values directly on this tab page , because if a system assignment is removed from a user on the Systems tab page, the user is deleted from the relevant child system.
Roles tab page:
On this tab page, you can assign roles to a user in the systems of the CUA. The central system should know all role names of all connected systems. It is always possible to manually assign a role that exists only in a child system, but not in the target system. However, you can only use the F4 help with current data if you have first performed the Text Comparison from Child Systems . When setting up the CUA, an initial text comparison is automatically performed. Therefore, F4 help is available immediately. If you want to use F4 help with current data, ensure that you perform a new text comparison between the central system and the child system after creating new roles in the child system.
During the text comparison, specify as the Target System the system from which the central information is to query the new information.
Note: If roles were created or changed in a child system, you can choose, in transaction PFCG in the child system, Environment -> Text Comparison for CUA Central System.
Profiles tab page:
The same statements apply to this tab page as to the Roles tab page. The Role Assignment dialog box also appears from this tab page. However, this dialog box is not displayed when assigning profiles.
Change to the New Password/Change Password and Lock User functions
The "New Password/Change Password" function now contains an option for specifying the child system for which the user is to receive a new password. In the future, this option is also to be provided for the "Lock User" function.
The following changes occur for transaction SU01 in the child system.
• All tab pages: restricted changeability
• It is no longer possible to create new users
• It is no longer possible to delete existing users (after complete user transfer)
• User in the Last Changed field
All tab pages:
On all tab pages of transaction SU01 in the child system, you are now able to administer only the fields that you released for local administration during the configuration of the parameters. Local administration is allowed if you chose an administration setting other than Global.
It is no longer possible to create new users or delete existing users (as soon as the users have been completely transferred to CUA).
Last Changed field:
The name of the user that was stored with the RFC connection from the central system to the child system, such as CUA_QAS_200, is specified in this field in the child system for all users that have already been centrally changed.
Fields whose field distribution parameters are set to Redistribution send their content back to the central system, from which this field value is then forwarded to all child systems. Existing entries are updated in this way.
For more information about optimizing the performance of the data distribution of your CUA landscape, see the documentation in the area BC-SEC-USR -> Central User Administration -> Activated Background Processing. To do this, you should have at least basic experience using ALE.
Troubleshooting for the CUA
If the distribution of user data is not functioning, follow the checklist below:
• Transaction SCUL in the central system
• Transaction SM59 in the central system
• Transaction BD64 in the central system
• Transaction SCUA in the central system
• Transaction BD87 in the child system
• SAP Note 333441: CUA: Tips for problem analysis
1. View the distribution log in transaction SU01: Environment -> Distribution Log. Alternatively, call transaction SCUL . If Errors are displayed here, you can choose Resend User as a first step. Trace whether the problem persists or whether the data is sent successfully this time.
2. If the display of the distribution log informs you of tRFC with Errors, you should check the RFC connections used in transaction SM59.
3. In transaction SCUL, choose Environment -> ALE Distribution Model (transaction BD64), to check the consistency of the ALE model that you are using. To do this, select the model for your CUA and check whether the required BAPIs USER.Clone and UserCompany.Clone are assigned to your model.
4. Check whether your CUA distribution model is displayed in transaction SCUA.
5. If it was not possible to completely process IDocs with user data changes in the child system (Unconfirmed status in transaction SCUL), this can be because there are not enough dialog work processes available (in the child system or in the contacted instance). In this case, you can start postprocessing of the IDocs in the child system using transaction BD87, or opt for inbound processing of the IDocs in a background job. The second variant is described in more detail in SAP Note 399271: CUA: Tips on optimizing performance of ALE distrib..
You should also take a look at SAP Note 555229: IDocs hang in status 64 for tRFC with immediate processing.
6. For more advanced analysis, use the tips in SAP Note 333441: CUA: Tips for problem analysis.
Caution: Ensure that you read the important SAP Notes, which are listed in the composite SAP Note 159885: CUA: Composite note for Central User Administration.
Removing the CUA
It is important to differentiate between two (three) possible scenarios for removing the CUA.
1. A child system is to be removed from the CUA (permanently or temporarily).
2. The CUA is to be completely removed.
These scenarios are presented here. Steps to permanently remove a child system from the CUA:
1. Choose Delete in transaction SCUA or call report RSDELCUA directly in transaction SA38.
2. In the Delete area, choose the option Child System, and then select the child system to be removed using the F4 help.
3. Choose Test and Execute.
4. On the following screen, the system lists the data to be deleted and the tables affected. By double-clicking a table name, you jump to the display of the table content (as it is displayed using transaction code SE16).
5. If you are sure that you want to delete the displayed data, choose Back (F3) and deselect the Test option. Choose Execute.
6. In transaction WE20 , under Partner Profiles for Partner Type LS, delete the message types CCLONE and USERCLONE for the child system.
7. Start transaction BD64, and switch to change mode.
8. Delete the methods of the child system and save your entries.
9. Distribute the distribution model of your CUA by choosing Edit -> Model View -> Distribute and selecting the child system that you have just deleted in the selection in the dialog box.
10. Use transaction SCUA to check whether the child system was deleted from the CUA.
11. If there are no additional child systems of the CUA in the SAP system that contains the child system to be deleted from the CUA, change the communication user (such as CUA_QAS) in transaction SU01 by removing the role Z_SAP_BC_USR_CUA_CLIENT on the Roles tab page. If there are no longer any roles or profiles assigned to the user, you can delete it.
Steps to delete the entire CUA:
1. Start report RSDELCUA on the central system with the options Complete CUA and Test.
2. If you are satisfied with the list of data to be deleted, run the report again, but this time without the Test option.
3. In the central system, delete the data about the central system and the child system(s) in transaction WE20; that is, delete the message types CCLONE and USERCLONE under Partner Profile for the Partner Type LS.If only the standard message type SYNCH then remains, you can delete the partner profiles completely.
4. In transaction BD64, delete the distribution model of the CUA.
5. Repeat steps 3 and 4 in the child systems.
6. Remove the CUA roles (such as Z_SAP_BC_USR_CUA_CENTRAL and Z_SAP_BC_USR_CUA_CLIENT) from all communication users (such as CUA_QAS_200 or CUA_DEV).
Caution: Delete the RFC connections of the CUA only if you are certain that these connections are not used in other ALE scenarios.