Troubleshooting CUA
- Check the logs. - SCUL Central User Management Log
Except for the logs for distributing users and company addresses, you can also display the logs for terminated tRFC calls (transaction SM58). With transaction SCUL.
- WE20 Change Partner Profiles
- WE21 Port definition
- WE09 iDoc search for contents (database)
- WE10 iDoc search for contents (archive)
You can call this in the central system and in the child systems. Filter for Basis type USERCLONE*
- WE02 or WE05 IDOC display and update status display call in the central system as well as in the subsystems. Select the CCLONE message type and transaction USERCLONE. The transaction must be called in the source and target system. Caution: The number of outbound IDOCs and inbound IDOCs are not identical.
Call this in the central system.Transaction BDM2 produces a link between the outbound IDOC number and the inbound IDOC number and can also start the IDOC display in both systems.
- BDM5 Technical Consistency Check
You can call this in the central system and in the child systems.With transaction BDM5, check the technical consistency of the partner profiles (also cross-system).
- BD87 manual processing of IDOCs
For example, you resend IDOCs that remain in status 03.
The correction instructions contain the report ZCUA_DELETE_IDOC that you can use to delete IDOCs without checking by the database. (You must therefore delete this report after use.
This transaction can also be used for updating with debugging. Incoming IDocs are then stopped and can be updated manually with BD87 (debugging breakpoint on function module BAPI_USER_CLONE).
Shows the BD87 error message for the tRFC (for example, IDoc entries in the tRFC queue) so you can analyze with SM58 which error occurs with the RFC (for example, for missing authorizations of the service user with which the IDocs are received in the target system): 'User CUAADMIN has no RFC authorization function group ERFC')
Authorizations of the communication users
The minimum authorizations for the communication users of the CUA are described in note 492589.
If a communication user in a subsystem is missing authorizations for the S_RFC authorization object (or S_RFCACL if using Trusted RFC), the tRFC call terminates. You can display logs for this as well as other tRFC errors using transaction SCUL or SM58. CALL_FUNCTION_SINGLE_LOGIN_REJ dumps (and CALL_FUNCTION_SYSCALL_ONLY dumps if using Trusted RFC) occur in this case in the daughter system, which you can display using transaction ST22.
The authorization check on S_RFC is activated with the auth/rfc_authority_check profile parameter.
Generating dumps with RFC logons that fail is defined with the rfc/signon_error_log profile parameter.
User groups for the authorization check
Transaction SCMP allows you to compare the table contents of different systems. For the user groups, these are tables USGRP and USGRPT (texts). Unfortunately a comparison is not possible. Use transaction SUGR to implement missing user groups in the central system.
Consistency check for role assignments
With the report ZCHECK_USLA04, which is contained in the correction instructions, you receive a list of all role assignments whose roles do not exist in the target system. The users affected must be revised with SU01.(See also table EDIDC messages to 01 49)
Counting profile assignments
A maximum of 312 profile assignments may exist for one user, while you may have several profile assignments for one role assignment.You cannot check this limit in the central system.
You can only count profile assignments in the child system.
Alternatives in the child system:
1. SE16 for table USR04
For the NRPRO field, the following is valid: NRPRO = 2 + 12 * n with n=number of profiles.
With the selection NRPRO > 3000, you get all users with at least 250 profiles (max. number that can be assigned is 312).
2. Report RSUSR002 of the user information system SUIM displays the profile assignments.
3. After report RSUSR002 has run at least once with some sort of selection, shadow table UST04 is up to date and can be evaluated with transaction SE16.
ST05 Enqueue and RFC trace
With the enqueue and RFC trace, you can analyse the flow of IDOC updates.To do this, log on to the application server specified in the RFC destination of the central system for the child system (the workload distribution should not be active).
Optional filtering criteria for the ST05 trace output:
User: Logged on users in the central system;RFC users of the RFC destination; Background user Object name: ES_EDIDOCE E_USR04
Unfortunately, the last character of the lock argument is sometimes truncated for the enqueue trace output.This is particularly impractical for IDOC numbers because you cannot identify the IDOC that has just been processed.
Transaction PFUD = Report PFCG_TIME_DEPENDENCY -> Start report RHAUTUPD_NEW
During updating of IDOCs, the user master comparison is started automatically. Nevertheless, the PFUD should run at night because this is when the static profile assignments are determined from the time-dependent role assignments.Enhanced consistency checks and corrections are also carried out (Remove the profile assignments of deleted roles, delete generated profiles and authorizations that are no longer used).
You can search for the message "No authorization profiles for activity group.......available" in the job log. These roles must be checked.
Company address
Maintain with transaction SUCOMP
The company address is distributed through Change+Save.
|
