Service Desk and Charm Concept

Service Desk consists of the following parties

• A Requester
• A Message processor
• Sold to Party (the division/client being charged)
• SAP

Basically what happens in service desk is, a issue occurs, let's say printer not printing out something, so it goes to the message processor, and they raise what we call an "incident". The message processor in turn goes through the solution database and SMP in order to find a solution, if they do, they just send the solution to the requester and that is the end of it. 

Requester -Problem->  Message processor--Investigate in solution db and SMP--Find solution---> Requester --> Record into solution db.

If in the solution db and SMP they are unable to trouble shoot the problem they will go to SAP who will provide the solution and then the message processor will convey the solution to the requester.

Requester --> Message processor-->SAP --> Processor---> Requester --> Solution db.

however if there be a problem that can only be fixed by apply a note, or a SP or some customization, basically something that cannot be resolved without touching the system, then it will result in what we call a "Change". 

Changes are handled by ChaRM, who has the following parties:

• Change Manager
• Requester
• Developer
• Tester
• Change advisory Board
• Technical Admin

A Change must go through the Change manager, to either approve or reject. If he rejects the change does not happen, but if he does approve, it goes through several phases:

1. In Development
2. to be Test
3. Tested
4. CAB approval
5. Production

Each change has a ticket, and each ticket is a record of a request for change, this keeps the transparency in check, it also makes way for paperless approvals.

That's the probably the overview of what Change and incident management is all about. Nothing on the set-up here. Might consider putting the customization later though.

Setting up a CUA

Note this is only sharing of what I learnt, never to be used as official documentation :).

Overview of CUA

The purpose of CUA is to help make user administration easier and reduce security gaps such as forgetting to lock/ expire a user in one of the systems in your landscape. It also helps in the creation of users by enabling you to create one user in the CUA client, and distributing it to all the daughter systems(of your choice) from just one system.

List of things you can define with CUA:

• Which user masters are in which client
• Which roles and profiles are assigned to these users
• Initial passwords
• Locked users

Pre-requisites

• A large number of identical users in multiple clients
• Complex system landscape with large amount of clients to be managed
• You want the reduction of costs of complex distributed user administration by implementing CUA

Important notes

• Can only be implemented on systems that are 4.6c and above, with latest support packages and kernel patches.
• CUA can be used cross-released, but child systems must be 4.5B and above (with most current Support Package)
• Can be used for BW, CRM and SRM too, but always check the sap notes on how to implement it on those systems.

CUA can also be hooked up to external systems like LDAP using the data exchange method IDoc and RFC as the communication protocol.

Caution:

Make sure roles and profiles are transported separately because setting this up, will no help you to transport roles and profiles to other child systems. To enable the role problems based on CUA follow the note: 571276 (PFCG:Transporting roles using transaction SM30 by setting the USER_REL_IMPORT entry table PRGN_CUST to NO in all the child systems in CUA)

Setting Up the CUA

Note: when creating users, create them as “system” as “communication” users require password change. Also bear in mind that the CUA lies within a certain client, and is not client independent, so all children system may include the ones in the same system, on different clients.

Defining the Logical System

1. Go to Transaction SALE and navigate from Basic Settings  Logical Systems  Define Logical systems, or use BD54.
2. Create a new logical system in UPPER CASE, use the naming conventions: <SID>CLNT### (e.g. QASCLNT100 for a system id of QAS with a client 100)
3. Save, and include it to a transport request.
4. Create all Logical systems for the central system and child systems to be included.
5. Transport the, Transport requests over to the child systems.

Note: you can also edit table T000 with transaction SM30 to define a logical system.

Creating “System” users for Central system RFCs

1. Create a “system” user through SU01 using the following naming convention: CUA_<SID>_###
2. In PFCG assign the following rolls: SAP_BC_USR_SETUP_CUA_CLIENT & SAP_BC_USR_CUA_CLIENT. (please take note that system users cannot have these roles directly assigned to them, so it is necessary to make copies of these roles and rename them with names such as: Z_SAP_BC_USR_SETUP_CUA_CLIENT & Z_SAP_BC_USR_CUA_CLIENT)
3. The role Z_SAP_BC_USR_SETUP_CLIENT is only required for the setting up of CUA and can be removed from child systems later on.

Tip: To increase security you might want to consider the following roles (which is created the same way as the roels you created above): Z_SAP_BC_USR_CUA_CLIENT_RFC & Z_SAP_BC_USR_CUA_CLIENT_BATCH.

Z_SAP_BC_USR_CUA_CLIENT_RFC: Authorization to receive IDocs (assign to the system user described above)

Z_SAP_BC_USR_CUA_CLIENT_BATCH: Update authorization for inbound IDocs (assign to any background processing user you might be using)

Take note: for information on system users, read note 492589: Minimum Authorizations for communication users.

Creating “System” users for Child system RFCs

1. Create a user with the name: CUA_<SID>
2. Assign the following copied authorizations:
   1. Z_SAP_BC_USR_SETUP_CENTRAL
   2. Z_SAP_BC_USR_CUA_CENTRAL
   3. Z_SAP_BC_USR_CUA_CENTRAL_BDIST

Note: the role Z_SAP_BC_USR_SETUP_CENTRAL is only required for setup of CUA.

Caution: Z_SAP_BC_USR_CUA_CENTRAL_BDIST is only needed by a user in the RFC connection if SCUM attributes are set to Redistribution.

You will also need a user for the central system to connect to itself with the following authorizations:

1. Z_SAP_BC_USR_SETUP_CENTRAL
2. Z_SAP_BC_USR_CUA_CENTRAL
3. Z_SAP_BC_USR_CUA_CENTRAL_BDIST

Creating RFC Connection

Use SM59 to create an RFC with the above names. And assign the users created earlier accordingly.

Note: that the RFC connections MUST be in Capitals! And the same name as the logical system .

Configure and activate CUA

1. Log on Central system
2. Go to T-Code SCUA, or SALE modeling and implementing business processes  Configure predefined ALE business process  Cross-Application Business process  Central User Administration  Select model view for central Administration.
3. Enter the name of your distribution model e.g CUA.
4. Choose create
5. Enter logical names of all child systems <sid>CLNT###
6. Save.
7. Results will show you a list of logs, all should be green. In the case there is a problem please view note: 333441:CUA: Tips for problem analysis

Set partners for distribution

1. Go to SCUM.
2. Adjust the settings according to your liking:
   1. Global
      1. The user data can only be maintained by the central system, which then distributes it to the child systems. The child systems however may display the information.
   2. Local
      1. You can maintain the data in the child system. But are not distributed to other systems.
   3. Proposal
      1. You maintain the default details initially from the central system, which is then distributed to the child systems, after which it is all maintained locally and not redistributed.
   4. Redistribution
      1. You can change data both centrally and locally, if it is changed locally it will be distributed back to Central system, then to the other child systems.
   5. Everywhere
      1. This option is only for Lock tab and initial passwords. When you maintain the locks and initial passwords centrally, it will be distributed to other systems, but when you change it locally, it is not distributed.

Caution: If you change from Local/proposal  Global/Redistribution it might cause inconsistency, only exception is the lock tab data being changed without an issue.

Check Note: 611972

Sync Company Addresses

1. Go to T-code SCUG
2. Click on child system
3. Click Synchronize Company addresses in central system.
4. OR you can use SUCOMP to administrate company address data.
5. OR Comapare with child systems using SCUC. (only compare no synchronization tho).

Sync user Groups

To be able to transfer users from a child system to the central system or to distributing them from the central to the child systems, the user group to which theuser is assigned must exist in all systems in which the user exists.

Look at SAP note: 395841: CUA: Assign target system-specific parameters and user groups

Transfer users to central administration

1. Go to Transaction SCUG in the central system
2. Choose the child system
3. Choose copy ysers to the central system

Note: Make sure your users are unique across the landscape before synchronizing.

Checking Distribution Status

1. Go to T-code SCUL
2. View the logs to see

Hint: if the status is unconfirmed, it means that there was not enough dialog work processes available in the child system at that time. If that’s the case you can use BD87 to do post processing of IDocs in the child system. Or you can use Inbound processing of IDocs using background processes, described in note: 399271: CUA: Tips for optimizing ALE Distribution performance.

useful logs

sap:
work directory:

• dev_w#
• dev_disp
• dev_msg
• stderr
• list goes on in this directory...

r3trans -d => for a trans.log to see db connections.

oracle:
$oracle_home/saptrace/background -alert log file
listener.log

db2:
Db2diag.log -> E= External users, I = internal users, D = developers
db2level ->db versioning n patch
db2nodes.cfg

below are found in the DIAGPATH:

• trap files = t###.<partition>/p####.<partition> -> info about db2 if it is stuck due to a trap violation or exception
• dump files -> occurs when there is an error, for extra info on the error.
• stack files
• core files = C###.<partition>
• db2 event log = infra events in db2 engine desc (after restart will be overwritten) read using db2support tool
• db2dart
• db2qpt.nfy = notify log
• db2trc output et al

use of db2support:
db2support <output path> -d <database name> -c

Oper sys log files
usr/bin/errpt -a (aix)
/var/adm/messages* or usr/bin/dmesg(solaris)
var/adm/syslog/syslog.log or usr/bin/dmesg(unix)
windir\drwtsn32.log (windows)
AIX:

• lsps -a = how paging space is being used
• lsattr -l sys0 -E = displays various OS parameters
• topas = reports stats on activities of sys
• xmperf = graphic monitor collects n displays performance data (only for motif)

UNIX/LINUX

• df -h
• truss = tracing system calls
• pstack(solaris) = stack traceback info
• pargs(solaris) = env of certain process pargs -e <pid>
• ldd = dynamic dependencies
• top = monitor sys activities
• vmstat = paging rate pi= page in po = page out
• iostat = i/o activities
• netstat = network traffic
• db2osconf = check hpux/solaris os kernel
• ipcs -l for linux
• prtctl -t privileged <pid> = show setting per process (solaris)

JAVA

• dev_jcontrol = Trace file for the JControl process
• dev_<node name> = Jlaunch process info
• jvm_dispatcher.out = file for JVM outputs.
• std_server#.out = started manafer/services
• std_dispatcher.out = same as above.

SAPOSCOL through ST06

I thought it might be useful to take note that SAPOSCOL can be called through ST06 as well instead of the conventional ways.

just go to ST06 and click Operating System collector:


Then from there you can start, stop, check the status and version, ect.. But take note no automatic refreshing:


Enjoy! :D