All SAP BASIS

background job failed because of authorization

2009-03-11T12:25:00.001+05:30

We have a job which runs OK in foreground but when defined in background.
It failed and the log said it is an authorization problem. Unlike a
foreground job which we can always run SU53 after the execution to get
which auth is needed, the log of the background job didn't tell more
detail other than "it is an auth problem". Pls help us with this. is
there a way to find out what is the exactly reason after a background job
failed because of authorization?

thanks.

Answer:
Several solutions:
1) Copy the batch user to a dialogue user, then logon and run the job. You will then have your error online and maybe the SU53 you are looking for.
2) Check S_PROGRAM value for the batch user. Maje sure the batch user has activity BTCSUBMIT for the program auth group. Have you checked the job log in SM37?? You can usually drill-down to see some type of error. Common errors are S_PROGRAM and S_DATASET authotizations' missing.

Answer:
You can also run an authorization trace from ST01 for the "job step executor" (the background user) -- not the batch job scheduler, unless if they're run by the same people.

Also -- make sure you run ST01 on the exact application server the batch job is running to capture the trace.

Answer:
Tried to run the job online, it went through w/o problem.

Tried it in background again, failed with same authorization problem.

Does this make sense for you guys? Should running online and running in background have the same authorization check?

Background Jobs

2009-03-11T12:24:00.002+05:30

What is the general practice for running Background jobs? Under the individual's user ID or one generic ID which has wide authorisations?

If it is run under the individual ID, then how is it handled when the person leaves the company?

What are the pro's and con's of running it under one generic ID?

Thank you
Jaynick
_________________
SAP Rules!!!

Answer:
We make sure that all background jobs are scheduled against a background user. This way we ensure that there is sufficient access to complete the job without having to give the individual users the same level of access. At the same time we can lock leavers and inactive users without being concerned of jobs falling over

To do this, you need to make sure that only a limited number of people can schedule batchjobs against the background ID. If not, you risk people obtaining access they should not have.

You can also ensure that the jobs won't have a negative performance impact on the system, as they will be scheduled with the right parameters.

Hope it helps

Answer:
If you currently allow users to create background jobs, checking for jobs scheduled for a particular ID should be a standard part of user decomissioning.

Answer:
Thanks Henrik! Any other input from SAP fans as to what the general practice out in the world is?

Jaynick

Answer:
I have a question about this also. I understood that a Basis admin could schedule background jobs to run under the userid of a system user, so that the system user (non dialog) could be granted broad authorizations, and not the dialog user, and also no maintenance is required if basis admin leaves the company.

I know that there are a few things that will require that the basis admin who schedules the background job to run under the auths of the system user id, also have the authorizations in his/her role also, or they will not be allowed to schedule it to run under the system id, even if the system id has the auths. Which is an understandable security measure. But these are only for a few things like os command and program execution considered critical, and not like broad business applications which the admin would not have in his admin role, and yet there is no problem scheduling jobs under the system id which does process business application jobs.

I have been told by some that they needed to create a generic dialog user like "JOBSCHEDULER" and use it to schedule jobs. I don't understand why they need to do this. Can anyone tell me why there would be a technical problem if they simply used their own id to schedule these jobs to run under the authorizations of the system id set up for this purpose?
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net

Answer:
Hi Gary,

Do you mean that the job admin is a generic account? That makes the connection between the dialog user ID and the name of the background user in which the job step is running even more obscure...

The belief that SOD conflicts between dialog users with S_BTCH_NAM = 'BATCHUSER' and the authorizations of 'BATCHUSER' itself is bad enough!

If you mean the job steps running in the name of the generic account as a dialog user, I have observed some OSS notes on a related topic which you can find with a search on 'call transaction' (I was looking for something else). Some programs may call a transaction screen which is not a parameter transaction and requires dialog interaction - at least that is what I understood the notes to be describing.

If I find an example again, I will post it.

Noddy

Answer:
There are two types of background jobs:
1. Repetative Production scheduled jobs to support a business process.
2. Adhoc reporting in background to keep the dialog processes free for "real" work. ( transaction processing)

The repetative Production jobs should be formalized with a standard naming convention for the job name and scheduled by the Batch administrator at the appropriate time, generally on a basis person's id not a generic one as there is no accountability on a geeric ID. The batch admin will need sufficient access to create the job, not run the report if internal authorization is needed to run the report (generally S_BATCH_NAM and S_PROGRAM, plus the S_BTCH_ADM access is sufficient. This allows scheduling the jobs in ANY class to limit their run to a specific batch processes controled by basis), and the STEPS should be run under an ID setup as a batch ID for the specific module ( not a user and not the batch admin person), like BATCH_FIAR , BATCH_HR, BATCH_MM, BATCH_SEC, etc. the batch Ids (setting in SU01) should have broad functional module access, not all access.

Adhoc reporting SHOULD be encouraged to keep the dialog processes free to enter the data into the system that SAP was purchased for, entering sales orders, getting money, and paying bills, ALL more important tha a poorly defined batch job report.

The user should have access to schedule jobs but NOT S_BTCH_ADM, this then forces all the job into class C which allows basis to manage when and where batch jobs are run. Since the user is running a report in backgroung that they could run in foreground, the report SHOULD be part of their role and the report tied to the role menu and the access in the report granted. The job is then scheduled on the user' s ID and run under the user's ID.

Answer:
Thanks John, That is exactly what I have told others, but for some reason I did not understand, they were saying they had some kind of technical problem when using system admin IDs, instead of this generic one. I will try and narrow done exactly what it was. They understand that the job will not fail if the admin leaves if it is scheduled under a batch-id but they still want to use a generic dialog user to schedule all of the jobs under one batch id.

Will they encounter a technical problem if they schedule too many jobs under the same user? Will there ever be any difference in the performance of the background processing with the same user such as maybe some kind of wait time when the same system id is logging in for multiple jobs, whereas if the user ids were different it would not have waited? Or rfc trace files getting wierd error messages because the background user is trying to authenticate when it is not necessary such as wrong classification of the user id causes the kernel to handle the login in a way that it would not if the classification of the user type trying to connect was set to cpic instead of system etc..

background jobs via background users

2009-03-11T12:24:00.001+05:30

I need some opinions about following issue:

We have some jobs who have to be done every day. So, these jobs are planned every morning. The jobs are backgroundjobs and [b]one[/b] system user runs [b]all the jobs[/b]. Therefore, this system user has a SAP_ALL.
A system user can't login on a normal basis but I don't feel well with the SAP_ALL.

I have the idea to split this user in several system users, with a big profile of the module which need some background jobs. (HR-user for HR-backgroundjobs, FI-user for FI-backgroundjobs,...)

Is this realistic or is there an other solution? Maybe our situation at this moment isn't so bad as I think???
Can someone help me?

Thanks in advance!
Bart

Answer:
It's perfectly feasible to split them by function or module.

For non-sensitive stuff I generally have a user e.g. FIBATCH with auths to cover what's needed. It takes a bit more work to set up but helps keep things arranged in an orderly manner.

Answer:
I’ve been through audits in the past where they have been satisfied with the background user having SAP_ALL as long as you have tightly controlled who can actually schedule jobs etc against that ID.

Answer:
I’ve been through audits in the past where they have been satisfied with the background user having SAP_ALL as long as you have tightly controlled who can actually schedule jobs etc against that ID.

Its all about risk. System users can also be used as communications users and there are some tricks that could allow someone to abuse a systems user in an RFC call. (They involve a kind of password hack). If you restrict the authority of the systems user you can diminish the opportunity for abuse.

You also have to be very restrictive about authority for S_BTCH_NAM.
_________________
bwSecurity

Answer:
I’ve been through audits in the past where they have been satisfied with the background user having SAP_ALL as long as you have tightly controlled who can actually schedule jobs etc against that ID.
When I perform audits I prefer not to see the ID with SAP_ALL - as there are plenty of ways it can be misused if the required restrictions are not in place.

If you do want to use one user, at least use a chopped down version of SAP_ALL with some of the more sensitive auths removed or very tightly controlled to grant what specifically is used.

Background Processing VS Batch processing

2009-03-11T12:23:00.000+05:30

Can someone tell me what the difference between backgroud processing and batch processing is. Also does the access to this function be limited.

I have a requrinment where they want everyone to have access to batch processing and just wanted to know how i should be handling this request.

Please help

Answer:
You have to get clarification from the requester. Most often Batch and background mean the same. There is a SAP useage which means Batch Data Communication ( BDC) that is sometimes refered to as Batch but most often refered to as BDC. Batch anf Background is controlles with S_BTCH_JOB and BDC is S_BDC_MONI. You need clarification fromt he requester.

Answer:
And if the user also has S_BTCH_ADM = Y and S_BTCH_NAM = DDIC (or *), then they can schedule the jobs, release, delete etc (as per S_BTCH_JOB actions permitted), but.. in the name of and with the authorizations of the other user names.

You can check with SUIM reports who can use your user account (for example) without having to know your password.

The myth that one cannot logon with a batch user is therefore true, because you don't need to logon with it...

Cheers,
Bob

Answer:
There is no myth about "loggin on to a Batch id" it does logon to run the batch job it just cannot be used in DIALOG mode. S_BTCH_NAM allows you to run a batch job using that users' access be it DDIC ( which should not have SAP_ALL) or any other id BATCH or DIALOG.

Answer:
There is no myth about "loggin on to a Batch id" it does logon to run the batch job it just cannot be used in DIALOG mode. S_BTCH_NAM allows you to run a batch job using that users' access be it DDIC ( which should not have SAP_ALL) or any other id BATCH or DIALOG.

It does logon, but unlike Communication users, the password is not critical for this login so you can change it. Like Communication users, one does not have to know what the password is... just access to see that someone once did and left it behind in the system. For Communication users one does not need to know the password either, but changing it, would make the access to the user more difficult.

Deleting a scheduled Background job in SAP

2009-03-11T12:22:00.002+05:30

To delete a job:
Go to Transaction SM37. Select a job (or jobs) from the Select Background Jobs screen. In the Job Overview, mark the job or jobs you want to delete by checking the box to the left of the job name. Choose Job --> Delete.

Deleting Jobs That Have Dependent Jobs:

If you delete a job that must be processed before another job can be started, the dependent job can no longer be started. The system will inform you of any such existing dependent, or successor, jobs. You'll then need to either reschedule or delete the dependent job.
If you try to release a job whose predecessor job was deleted, the system sets the status of the job to Planned. To start this job, you must release it and specify the start conditions.

Schedule Manager

2009-03-11T12:22:00.001+05:30

Automate your routinue task with Schedule Manager. It facilitate the definition, scheduling, execution, and review of tasks that are executed on a regular basis, such as period-end closing.

SCMA - Schedule Manager

how you can assign a Background work process as a Class A Background Work process

2009-03-11T12:21:00.002+05:30

Go to transaction code rz04 then button Operation Modes / Instances. Then select the Operation mode and double click on it. Then you will see a window with no of Background work process. In the field named Class A increase the no to 1 (use the + button to increase that). Default value is zero. Then click on the save button to save the configuration

How To Delete a Scheduled Job in sap

2009-03-11T12:21:00.001+05:30

I am working in production support and have been asked to stop a scheduled jobs. The job will run on the first of next month and I need to stop it from running.

To delete a job:

Go to Transaction SM37. Select a job (or jobs) from the Select Background Jobs screen. In the Job Overview, mark the job or jobs you want to delete by checking the box to the left of the job name. Choose Job --> Delete.

Deleting Jobs That Have Dependent Jobs:

If you delete a job that must be processed before another job can be started, the dependent job can no longer be started. The system will inform you of any such existing dependent, or successor, jobs. You'll then need to either reschedule or delete the dependent job.

If you try to release a job whose predecessor job was deleted, the system sets the status of the job to Planned. To start this job, you must release it and specify the start conditions.

Checking your program Background Job Status

2009-03-11T12:20:00.002+05:30

Checking your job status with SM50 (processor type BTC) is more accurate then SM37. SAP updates the tables TBTCO wheneveryour background jobs status change. If SAP is shutdown, the currentjobs might not be update ontime to the table. (e.g. a background job wasshown as Active (SM37), in fact it real status should be Cancelled.

The type of work process:

DIA - work process for executing dialog steps in user transactions
UPD - update process for executing U1 (time-critical) database changes
UP2 - update process for executing U2 (non-critical) database changes
ENQ - for setting and releasing locks on SAP lock objects
BTC - for executing background jobs
SPO - for spool formatting processes

PID: Process ID of the work process

Availability Check on Quotation

2009-03-11T12:20:00.001+05:30

SAP standard does not do an availability check on the quotation, as it is not a definite order, usually just a pricing quote.

When it is converted to an order, the first availability check is carried out, as well as credit checks. The system will check stock in the plant, plus what is contained in the availability checking rule (scope of check) eg: can add POs for replenishment, purchase reqs, different planned orders, and subtract sales orders, deliveries etc already created against that material in that plant (and possibly Storage location).

If there is enough stock in the plant/SLoc, the system will give you a confirmed date, or give you a date based on the production time or purchasing time from the material master. The date the system proposes is based on the customer's requested delivery date.

SAP first backward schedules looking at the required delivery date, less transportation time, less transportation lead time, less pick and pack time, less production/purchase time if applicable. If the date it calculates is equal or later than today’s date, then it will confirm the customer’s required date. If it falls in the past, SAP will then forward schedule for today’s date, plus the times listed above to get the date when the customer can actually have it.

ATP is the single most complex part of the SD module, depending upon how PP and MRP is set up.

MRP works semi-separately, depending on how it is set up. Basically, MRP looks at the demand on the plant, and if it the stock does not meet expected sales orders and deliveries, it will create a purchase requisition (outside purchase) or requirement or planned order (for production) to cover the shortfall. When MRP is started, it will turn the PR into a PO or the requirement into a production order.

SD material Determination based on availability check

2009-03-11T12:19:00.002+05:30

For SD material Determination you can create a Substitution reason and on the Strategy field, the following info. is available:

Product selection in the background is performed on the basis of the availability check.

We want to have the material determination only in case on material shortage. We expect the Substitution reason to give us this functionallity. It does not hovever take the availabilty into account before substitution.

We thought the worse case is to create a ABAP which is linked to the "requirement" field in the Procedure (OV13).

Has anyone had the same requirement? Is this a bug or just incorrectly documented?

I also encountered this abnormally recently using material determination. In order to combat the problem, the first product substitution should be for the original material. I've illustrated this below:

Original Product: ABC
Substitutes: DEF, XYZ

In order to perform product substitution ONLY in the case of ATP failure for product ABC, structure the Material Determination record as follows:

Material Entered: ABC Substitutes: ABC
DEF
XYZ

There seems to be a devaition at availability check and or on a conceptual note still.

Availability check can be configured both at requiremnt class and at the schedule line categories level.

Whilst the availabilty check at the requirement class level via global and mandatory configuration the schedule line catgry availability check deals with the order.

It is mandatory that the reqmnt class is flagged off for avlblty check and the schdelu line cat need not be.

The following are the mandatory for Availability check to happen--

1. Must be swithced on at the requirment class level and at the schedule line level.

2. Reqmnt type must exist by which a requiremnt class can be found

3. There must exist a plant and is defined

4.Checking group must be defined in Material Master records(it controls whthr the system is to create individual or collective reqmnt)

A combination of checking gropup and checking rule will determine the scope of availbaility check.

Creating Multiple Materials in Material Determination

2009-03-11T12:19:00.001+05:30

Material Determination is used to swap one material for another.It is possible to get a list of materials for substituiton,but remember you can substitue only one material from the list.

This can be done through substituiton reason T Code [OVRQ]
See the substitution reason number for Manual Material Selection
- check the Entry box
- check the Warning box
- select A for Stategy
- save.

Go To VB11 to create Material Determination (taking into consideration that all the previous steps for material determiantion i.e. maintaining condition types,maintaining procedures for material determination and assigning procedures to sales doc. types have been done)

Create one material determination,dont forget to give the Subst reason on top and also on the line.

Click the Variants Icon on top left-Sreen opens

Specify different materials you want to swap with the material you have enterd

Note that the subst reason is already copied on the screen

Remember materials should be of the same sales area,atleast Divisions should be same

Backward and Forward Scheduling

2009-03-11T12:18:00.002+05:30

Backward scheduling is the calculation of deadline dates: the arrival time at the customer site is calculated as the earliest possible goods receipt time at the customers unloading point on the requested delivery date. All four of the delivery and transportation scheduling lead times are subtracted from the customer's requested delivery date to determine if this date can be met.

The transit time, loading time, and pick/pack time are subtracted from the customer’s requested delivery date to calculate the required material availability date.

The system calculates backward scheduling as follows:

Requested delivery date minus transit time = Goods issue date
Goods issue date minus loading time = Loading date
Loading date minus transportation lead time = Transportation scheduling date
Loading date minus pick/pack time = Material availability date

By default, the system will calculate delivery dates the closest day, taking into consideration the working days of the shipping point and a rounding profile. In this case the system assumes a 24 hour work day and lead times can be entered in days up to 2 decimal points. This is referred to as daily scheduling.

Precise scheduling calculated down to the day, hour and minute is supported. This allows the scheduling of a delivery within a single day. It is activated by maintaining the working hours for a particular shipping point.

Backward scheduling is always carried out first. If the material availability date or transportation scheduling date is calculated to be in the past, the system must then use forward scheduling.

Forward scheduling is also done if no product is available on the material availability date calculated by backward scheduling. The system does an availability check to determine the first possible date when product will be available. This new material availability date forms the starting point for scheduling the remaining activities. The loading time, pick/pack time, transit time, and transportation lead time are added to the new material availability date to calculate the confirmed delivery date.

SAP Authorization Concept

2009-03-11T12:18:00.001+05:30

The SAP authorization concept is based upon the logical relationship between a user ID and the range of system authorizations with which it can be associated. The architecture of the authorization system is based upon the utilization of several individuals but related logical components: Profiles, Objects, Fields, and Authorizations. The user ID refers exclusively to profiles. Each profile grants a set of specific system access authorizations to user. Figure 2 illustrates the hierarchical authorization concept in SAP.

Figure 2

2.2 Composite Profiles

Composite profiles refer to the various employee roles available in the corporation (for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name suggests, composite profiles may contain multiple user IDs necessary to perform all the business operations associated with a particular role. A composite profile may encapsulate another composite profile(s). In practice, a model composite profile should be recognized for each possible role in the organization, which may be used to produce hybrid composite profiles. The over-existence of the hybrids can defy the very purpose of composite profiles and they should be created only when specific needs arise.

2.3 User Ids

User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the role(s) an individual user is responsible for, in the business processes.

2.4 Authorizations

Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: "You are not authorized..." is displayed at the bottom of the screen.

An authorization process may ask for second associated authorization process which in turn asks for third and so on. For example, the task of paying a vendor invoice may require 10 different authorizations.

SAP’s TCODE checks with the authorization tool

2009-03-11T12:17:00.004+05:30

What are the checks that the SAP authorization tool performs when a TCODE is executed in order to ensure authorization of that user?

EXPERT RESPONSE

When initiating a transaction, a system program performs a series of checks to ensure the user is authorized.

1. The program checks whether the transaction code exists in table TSTC.

2. The program checks whether the transaction code is locked by the administrator (transaction code SM01).

3. The program checks whether the user has the authority to start the transaction. Authorization object S_TCODE (transaction start) contains the authorization field TCD (transaction code). The user must have the appropriate authorization for the transaction code to be started (for example, FK01, Create Vendor).

4. The program checks whether an authorization object is assigned to the transaction code. If this is the case, the program checks whether the user has an authorization for this authorization object. The transaction code/authorization object assignment is stored in table TSTCA.
Note: An SAP program controls steps 1 through 4. It displays an automatic message to the user if an authorization attempt fails in the step.

5. The system performs authorization checks in the ABAP program using the ABAP statement AUTHORITY-CHECK.

Listing TCODE transactions used to view what users are logged in to SAP

2009-03-11T12:17:00.003+05:30

I want to get a list of all transactions used per user in a specific time period. Basically I’m looking for a list of all users logged in SAP and the details of the tcodes they used. Is there any standard report or tcode available to view this info?

EXPERT RESPONSE

There is no standard transaction. The information is available for configurable time periods using transaction ST05N but it is not organized to readily provide a report of users and transactions. Also the information available summarizes a user’s use of a transaction. There will be one entry (with count data) per user per time period. Daily, weekly and monthly summaries can be created and they are stored for configurable durations.
The information is summarized into a cluster table called MONI based on the STAT files that are written in the file system and regularly refreshed. MONI cannot be queried via SE16 etc., but SAP delivers a number of function modules that retrieve data from these tables.

It is also possible to configure audit logging via SM19 and read the log files via SM20. This will provide more detail but it also introduces new file management issues and requires a change to system settings.

Authorization Check

2009-03-11T12:17:00.001+05:30

The following actions are subject to authorization checks that are performed
before the start of a program or table maintenance and which the SAP
applications cannot avoid:

 Starting SAP transactions (authorization object S_TCODE)
 starting reports (authorization object S_PROGRAM)
 Calling RFC function modules (authorization object S_RFC)
 Table maintenance with generic tools (S_TABU_DIS)

The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS
are standard SAP provided.
Creating a new authorization object is not in the scope of ABAP developer. It will
be taken care by SAP BASIS team.

This is a preview of Authorization Check:

SAP BASIS (BC) Authorization Concepts

2009-03-11T12:16:00.003+05:30

SAP Authorization Concept

Composite Profiles

User Ids

Authorizations

Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: “You are not authorized…” is displayed at the bottom of the screen.

Unlocking a blocked admin user ID in an Oracle DB

2009-03-11T12:16:00.001+05:30

My admin user ID has been locked out. Is there a table I can update in Oracle to reset the flag and enable myself to log in?

EXPERT RESPONSE

Select all entries of table USR02 where ‘UFLAG’=128. These users are locked by reason of incorrect logons. ‘UFLAG’=64 will give you the users that are blocked by Administrator. Set ‘UFLAG’ to 0, to unlock your account.

How to Check Missing Authorisation for User

2009-03-11T12:15:00.001+05:30

How to check the missing authorisation for the user not having the option "/nsu53 ?"

You can use the following procedures to determine which authorizations a user requires to carry out a transaction:

You can use Trace function, ST01, you can trace the user activity and from the log you can see the authorization missing.

Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked.

This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check.

Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.

Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts.

Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).

SAP Profile Generator tables

2009-03-11T12:14:00.004+05:30

---Original Message-----
Subject: Profile Generator tables?
From: Paul Ellis

We maintain profiles in a Development system using Profile Generator, but only transport the authorisation profile and not the activity group to Staging/Production.

We are about to refresh the Development system with a copy of Production. What tables do I need to export from Development prior to the refresh, and later re-import, to ensure that Profile Generator is able to maintain the activity groups created in Development?

Thanks in advance.

Paul Ellis

-----Reply Message-----
Subject: Re: Profile Generator tables? - more
From: Mike O'Carroll

oh, and maybe these tables for profile genrator stuff......
(from top include for PFCG)
000010 function-pool rhum.
000020
000030 tables: hrv1220, hrp1001, hrp1000.
000040 tables: pchdy, pphdx, p1000,
000050 pt1220, t77fc, t77fd.
000060 tables: *objec, objec, *p1000.
000070 tables: pdrhum, t77aw, t777o.
000080 tables: xu213.
000090 tables: t777e, usr05, tprprof.

and you may need to do the same with menu tables - I'm not sure which ones
-
(from top include from SSM1)
000010 function-pool smnu. "MESSAGE-ID ...
000020 *
000030 tables: indx, tstct, dsyax,
000040 smenca_new, smen_obnew, smen_conew,
000050 smenusenew, smenentnew,
000060 smen_dates, ssm_stat, ssm_start, ssm_langu,
000070 smensapt, smencust, smenentt,
000080 smensapnew, smencusnew,
000090 smenselect, t002t,
000100 ssm_rele, smenintnew, smenintt.

--------------------------------------------------------------------------------

Regards,
Mike O'Carroll

-----Reply Message-----
Subject: Re: Profile Generator tables? (Document link: Michael O'Carroll)
From: Michael O'Carroll/UK

user masters: USR01 to 09, UST04,
profiles: USR10, USR11, UST10S, UST10C,
authorisations: USR12, USR13, UST12.
password exceptions USR40.
History tables(may not be applicable but FYI): users: USH02, USH04,
profiles: USH10, auths USH12.

activity groups are stored in table PLOGI along with loads of other object types. the activity groups are object type T.
You could export the table data with a manual transport request via SE01, using R3TR TABU and specify the keys to use for all objects of type T(ie all activity groups). Remember to include all clients in the selection.

OR, if you are using the client copy functions to refresh you DEV from PROD, then you could use the RSCCEXCT (see OSS note 70290) to list all these tables and exclude them from the copy, hence the corresponding original DEV tables should not be overwritten in DEV.
I suggest you export a transport request with with all these tables from DEV just in case, so you can re-import them again if it goes pear shaped.
In 3.x I don't think the activity group names involve client number or SID, but I've heard some differences in 4.6 - Guy Holchester has sent many notes to the list about it - have a look at the archives, but I think as long as you aren't copying between different versions (eg from Prod 4.6 to Dev 3.x, or vice versa) then it should be OK.

If you choose to re-import the tables from transport requests, you might want to run the sync tool in the target client (DEV) afterwards - ie run function module SUSR_SYNC_USER_TABLES, or run SU30, just to check for any dodgy links or inconsistencies.

Also, if you are re-importing user masters too, run RSSODELT and RSSOUSER to recreate all SAPOffice mailboxes and link them to the new user IDs in the target client.

hope this helps.
cheers,
Mike

-----Reply Message-----
Subject: Re: Profile Generator tables?
From: Kenneth Marquardt

I would use RHMOVE30 and create a transport of your activity groups. To be safe test import the activity groups to QAS prior to refreshing DEV with PRD. Then once you have completed the refresh import the transport you created. For more info on this look at the Authorization is made easy guide available online on page 11-6 release 4.0b.

Remember to run SUPC after you import to regenerate the profiles.

-----End of Reply Message-----

Query About Tcode PFCG

2009-03-11T12:14:00.003+05:30

1. How to check the name of all users who has been authorised to use a particular transaction? I am trying to find through SUIM, but failing to find the name or total number of users of a particular t-code say SPRO.

2. I know that a particular transaction say SPRO is available in a particular role and I want to remove that t-code from that role. But I am unable to find that node through PFCG. If I am using the search for a t-code inside menu tab after putting the edit mode it is not coming in PFCG, but through SUIM its existence is coming in that role. That particular role contains a lot of t-code and reports, say about 2000.

1. Goto SUIM and select USER node, then select USERS BY COMPLEX SELECTION CRITERIA node then execute BY TRANSACTION AUTHORIZATION report then give the Tran. code and it will return you the number of users having that trans with relevatn details.

Follows these steps :-

- Go to SUIM .
- Choose Roles --> By Transaction assignment.
- Enter Transaction : "SPRO"
- Choose execute.
- Double click on a role in which you want to remove "SPRO" authorisation.
- Click on pen mark to change into change mode.
- Go to tab "Authorization"
- Choose change authorization data.
- Choose Utilities --> Technical names on .
- Choose --> cross application authorization objects-->
- Expand the selection for Object "s_tcode" , under the corresponding profile look the values maintained for "TCD" and remove value "SPRO" from the list to eliminate the authorization.
- Don't forget to regenerate profiles.

2. You should able to find this via menu tab otherwise try to do this in authorization tab --> change authorization data by search.

How To Compare The Roles

2009-03-11T12:14:00.001+05:30

How to compare the roles where created or defined in two different systems?

For role comparision both the roles must be in the same system, in same client

Transaction code SUIM -> Comparision-> Roles

If the roles are in different system, then tranport the role into one of the system and do comparision. If no transport connection defined then, you can use the upload and download option in the PFCG

Steps for Role Comparing:

1. Run the t-code SUIM

2. Go To Comparison and select the option of roles

3. Click on Across systems option it will give option to select the sys name under Remote Comparison there enter the SYS ID between which system you want to do comparison and put the role name in compare role section then execute it will give you the result.

4. If there is any difference b/wn the t-codes it will b in red colour otherwisein yellow.

Creating New User With Authorizations

2009-03-11T12:13:00.002+05:30

I want to create new user for SAP module. I am having user id as sap* (someone has said that this is super user id); when I login with this id and go to IMG for configurations. A message is displayed that I am not authorised to change the details with sap* user.

What is the procedure for creating new user which have all features define under SAP* user and which could allow me to make the configruations.

Creating new user with superuser authorizations.

1. Goto SU01 --
username : sapuser
|-->Create.

2. In default settings, give
:Mr
first name : sap
lastname : user

3. Goto next tab,
give initial password :1234
repeat password : 1234

4. Goto profiles.
type- sap_all (say enter)
sap_new (say enter)
Then save....
See the message in status bar, (user created successfully)

5. Login with the new user. change the password. now this user contains all superuser authorizations.

Introduction on Authorizations

2009-03-11T12:13:00.001+05:30

Authorization objects enable complex checks of an authorization, which allows a user to carry out an action. An authorization object can group up to 10 authorization fields that are checked in an AND relationship.
For an authorization check to be successful, all field values of the authorization object must be maintained accordingly. The fields in an object should not be seen as input fields on a screen. Instead, fields should be regarded as system elements, such as infotypes, which are to be protected.
You can define as many system access authorizations as you wish for an object by creating a number of allowed values for the fields in an object. These value sets are called authorizations. The system checks these authorizations in OR relationships.

Troubleshooting authorization in SAP R/3

2009-03-11T12:12:00.002+05:30

When you encounter errors during testing of roles, you can use SU53 and ST01 to analyze the error.

Ask the user to run SU53 to display the result of the last failed authorization. It is important the user run SU53 immediately after failed authorization check, as only the last object the failed the authorization check is saved.
You can run trace using ST01 to further analyze the error. For more detail follow the link…

Shortcut to create role with many reports /tcode

2009-03-11T12:12:00.001+05:30

Once I had couple of roles which where made just t hold reports. The number of reports where huge. Here is how I did it.
First create a CATT script with a dummy role and add one tcode. Make the role and T-code as variant. Once you have this you can add any number of tcode to any existing role. Icould resuse this tocreate another roles where I had to insert lot of T-codes.

check which authorisation objects are checked within a transaction

2009-03-11T12:11:00.002+05:30

1. Open two sessions

2. Execute transaction ST01 in one of the sessions

3. Select the authorisation checkbox, note the other traces you can perform (SQL, RFC, Table Buffer etc)

4. Click the ‘Trace On’ button

5. Within your other session execte the transaction/report you want to trace or get the user in question to do it

6. Return to the session where you turned the trace on and click on ‘Trace Off’ otherwise it will continue to record all athorisation checks

7. Click on the ‘Analysis’ button

8. Enter appropriate data into selection screen such as Username, type of trace records (i.e. Authorization check)

9. Click on the Execute button.

10. Report displaying trace results will now be displayed

What are the Authorizations Required

2009-03-11T12:11:00.001+05:30

Administrators who use the Profile Generator require authorization for the following authorization objects: S_USER_AGR Authorization Check for Activity Groups

S_USER_TCD Transaction Assignment of Transactions to Activity Groups

S_USER_GRP User Master Maintenance: User groups

S_USER_PRO User Master Maintenance: Authorization Profile

S_USER_AUT User Master Maintenance: Authorizations

S_USER_VAL Maintenance of Authorization Values in Activity Groups

How do I go about creating an authorization group

2009-03-11T12:10:00.000+05:30

This all depends. In some cases authorization groups must exist in a custom table before they can be used. This is true for table authorization groups (authorization group in table TBRG assigned to tables in table TDDAT via transaction SE54) and user groups(created in transaction SUGR). In some cases authorization groups are merely created when they are assigned to the object in a standard maintenance transaction (e.g. vendor master data, customer master data, material master data etc.) In other cases the authorization group has an optional validation table that is used in search helps but no where else (ABAP programs in table TPGP and TPGPT, report writer authorization groups (via table TBRG) etc. Authorization groups are essentially labels that you assign to objects (tables, programs, master data etc.) that allow authorization checks for access to the objects with the label.

Frequently Asked Questions on Authorization

2009-03-09T09:08:00.001+05:30

Role & Profile

What is the difference between role and a profile?

Role and profile go hand in hand. Profile is bought in by a role. Role is used as a template, where you can add T-codes, reports..... Profile is one which gives the user authorization. When you create a role, a profile is automatically created.

What is the use of role templates?

User role templates are predefined avtivity groups in SAP consisting of tyransactions, reports and web addresses.

What is the different between single role & composite role?

A role is a container that collects the transaction and generates the associated profile. A composite reole is a container which can collect several different roles

What profile versions?

Profile versions are nothing but when u modify a profile paarameter through a RZ10 and generate a new profile is created with a different version and it is stored in the database.

Is it possible to change role template? How?

Yes, we can change a user role template. There are exactly three ways in which we can work with user role templates
- we can use it as they are delivered in sap
- we can modify them as per our needs through pfcg
- we can create them from scratch.
For all the above specified we have to use pfcg transaction to maintain them.

Personalization Tab Within PFCG

Please expalin the personalization tab within a role.

Personalization is a way to save information that could be common to users, I meant to a user role... E.g. you can create SAP queries and manage authorizations by user groups. Now this information can be stored in the personalization tab of the role. (I supposed that it is a way for SAP to address his ambiguity of its concept of user group and roles: is "usergroup" a grouping of people sharing the same access or is it the role who is the grouping of people sharing the same access?)

How to insert missing authorization? Ways?

su53 is the best transaction with which we can find the missing authorizations.and we can insert those missing authorization through pfcg.

Table of authorisation field settings

Is there a table for authorisations where I can quickly see the values entered in a group of fields?
In particular I am looking to find the field values for P_ORGIN across a number of authorisation profiles, without having to drill down on each profile and authorisation.

AGR_1251 will give you some reasonable info.

Table with deleted users

Someone has deleted users in our system, and I am eager to find out who. Is there a table where this is logged?

Debug or use RSUSR100 to find the infos.

Run transaction SUIM and down its Change documents.

How can I make T_Code SPRO Read Only

I have a requirement to make SPRO read only. As you know it has a tree like structure and to make it read only seems like impossible.

You cannot make SPRO 100% display only by ANY setting. The SCC4 option only turns configuration tables to not-modifyable but still allows the non-config delivery class tables (or those configured to be changeable) to be modifed. It does nothing for the tcodes that are NOT table maintenance and not controlled by S_TABU_DIS. These will still allow configuration. All the tcodes in the SPRO are in several tables CUST_ACTOBJ (spelling?) is one.

You only real option is to create a role with all the tcodes in them that are in the SPRO , remove the create and change to display ( generally by changing the last nunmer on the 4 digit tcodes to 3) and removing all the Create and change access in all the activities and allow only the display.

PFCG allows you to create a role from a SPRO project so the usermenu will come close to the SPRO menu, which your changes it will be display.

Mass Delete of Old Roles

How can i do a mass delete of the roles without deleing the new roles.

There is a SAP delivered report that you can copy, remove the system type check and run. To do a landscape with delete, enter the roles to be deleted in a transport, run the delete program or manually delete and then relase the transport and import them into all clients and systems.

It is called: AGR_DELETE_ALL_ACTIVITY_GROUPS.

To used it, you need to tweak/debug & replace the code as it has a check that ensure it is deleting SAP delivered roles only. Once you get past that little bit, it works well.

What is an Authorisation Object?

2009-03-09T09:07:00.005+05:30

An Authorisation Object is a structured group of Authorisation Fields that can be populated with Authorisation Values

Create authorization object

2009-03-09T09:07:00.004+05:30

Question: Hello,

I need to restrict access for a specific field of a table.

Can you tell me how to know the authorization object links to this field AND how to create a auth. object ?

Thanks.

Answer:
There is no easy way doing this. Auth Object(s) for standard tables are S_TABU_DIS, S_TABU_CLI. You can use this to restrict access to display only or client specific tables. However if that requirement is mandatory you need to create a custom t.code to display table restricting the field.

Answer:
What do you mean by the statement "restrict specific field of a table?"
Can you be a bit more specific in your problem?
_________________
Regards
Vijay

Answer:
One option could be S_TABU_LIN, but I think you are better off with a custom transaction

Answer:
Exact.

We find a solution by creating a specific transaction.

Creating an auth group and assigning a table

2009-03-09T09:07:00.001+05:30

Question: How do I create an new auth group and assign a table to this group in S_TABU_DIS

Answer:
Tcode SUCU, The "group" does not have to exist but you can create one in SE54

creating authorization levels

2009-03-09T09:06:00.003+05:30

Question: hello,

I found note that names a report that needs to be run so that I can
change a field and make it organizational level(done it). But when I look at that field within a certain object in the PFCG, its still yellow like before, and I cant find it under the button "organizatinal level"......do I have to somehow generate my new organizational level field? And in that case how, because the su24 and others are just for transactions.

grateful for some help
//Vinnie

Answer:
1. Did you run the reports in test mode and not change mode?
2. are you relying on the text name or the technical value of the field. The program PFCG_ORGFIELD_CREATE uses the techincal name and there are several fields that look the same in text but are not technically, Company code and Company come to mind.

Note that if you create the org level and then decide to remove it there is a bug in the PFCG_ORGFIELD_DELETE program that corrupts the SU24 entries the the customer adds that are not in the SAP source table. you will have to corrext these manually.

Answer:
Hello,

I managed to create a organizational level object running the report. But normally when you see standard organizational levels they appear red until they are filled in. When I look in the object containing the field I changed, and add it to a role, its still yellow. That is my problem, it doesnt really change and it does not show under the button organizational level. So what do I have to do to see it there, and also to see the field red in the object.

thank you in advance
Vincent
_________________
6-years experience. Prepared to work all over the globe, but so far Sweden and Denmark. Speak english, swedish, finish and spanish fluently.

Answer:
Was the object added by you in SU24 or was it SAP delivered?. GO to SU24 and remove the object from the tcode that is brining it in and readd and see if it correts itself.

Answer:
the object I used is ygo_sec_op and is not connected to any tcode......I checked that too..............more ideas please......maybe we can solve this:)

//Vincent
_________________
6-years experience. Prepared to work all over the globe, but so far Sweden and Denmark. Speak english, swedish, finish and spanish fluently.

Answer:
ygo_sec_op? the "Y" implies a customer developed object. The report that creates the org level manipulates the customer table in SU24 and then changes AGR_1251, but it your ygo_sec_op was not changed then the code may ignore MANUALY inserted objects (highly possible I did not pay attention to this part of the code). So it may be working as designed.

The best practice it to tie all required objects to a tcode and configure it in SU24 with the most restrictive access ( usually view if the tcode has to be shared between change and view) and the you ADD manual authorization to increase access with the priviso that you have a standard to support its inclusion in the role. If you have a manual ( there are some exceptions) without a standard, this would indiate to you that the tcode needing the access has been removed and the MANUAL should also be removed.

Try removing the object fromthe role, exit PFCG entirely and re-open the role and add it back ( the exit entirley may not be needed in all cases).

Answer:
thanks for your input, stupid me playing with y fields.

It works fine for the standard fields, but not for the customized ones, atleast it seems like. Just like you said.

thanks for your help

cheers
Vincent
_________________
6-years experience. Prepared to work all over the globe, but so far Sweden and Denmark. Speak english, swedish, finish and spanish fluently.

Answer:
Custom Fields ot Objects? you can add the fields in the table and link your custome fieild to an SAP variable. Table USorg is the link between Field and variable in table USVAR. If you add a USVAR then you MUST transport talbe USVART to get it to work in the other systems ( you should take USVAR as well).

Did removing the object and re-add help or is it truely a 'Y' onject and new fields?

Creating Authorization profile

2009-03-09T09:06:00.001+05:30

Question: Hi,
We normally use Role(PFCG) and authorization profiles are generated automatically .
I need to create Authorization profile in 3.1h .Both simple and Composite.

Can anyone guide me how to do?
Is it through su02? what has to be added in Object ? and in Authorization?

Thanks.

Answer:
You create and modify Authorization roles in SU02. The values assigned to each authorization object must be determined by members of each business unit. Either that or you asign no values to any of the parameters and let the users test each transaction assigned to the role and determine the different org levels and parameters through testing. It is a long process however if the business cannot help you define the roles it is the only other way to do it.

Answer:
And I assume you will need to create custom authorisations as well. That is done through SU03.

creating custamizing autharization objects

2009-03-09T09:05:00.004+05:30

Question: Hi

I am new to sap security can any body explain how to create custamizing autharization objects , i know we can create through su21 any body explain briefly

Answer:
Read the documentation in SU21.

NOte: First look for an appropriate SAP standard object before you create deviations from the standard.

Creating new authorization object

2009-03-09T09:05:00.003+05:30

Question: Hi all,

Is it possible to create new authorization object, fields for that and the values. If yes, please guide me regardint the same.
_________________
Regards,

Sailesh K

Answer:
New Authorisation object can be created using transaction SU21 and fields for that can be created in SU20. You need to assign a class for athorisation object

Creating New Organizational Levels

2009-03-09T09:05:00.001+05:30

Question: We are creating derived roles, a master role with individual derived roles.
As we know the only values that don't get pushed down are the org. values.
However we are controlling on values that are not org levels. So I would like to make them org levels, for instance company code.

I know you can create org levels in SE38 with PFCG_ORGFIELD_CREATE.
However if you do this will it make company code an org value in every role that it exists?

If so do we have to go into every role or will a value be populated automatically from the role itself?

Is it possible to pick and chose which role you want the new org levels to adhere to?

Any help would be greatly appreciated!!!

Thanks!

Answer:
I know you can create org levels in SE38 with PFCG_ORGFIELD_CREATE.
However if you do this will it make company code an org value in every role that it exists?

Yes

If so do we have to go into every role or will a value be populated automatically from the role itself?

IIRC Values in the fields will become populated as org levels without any further action required from you

Is it possible to pick and chose which role you want the new org levels to adhere to?

No. This is the downside to creating org levels. You can force individual fields in roles to ignore org level behaviour but this is on a role by role basis and not practical to maintain. If you find yourself needing to do this then your design does not suit creating additional org levels.

Answer:
If you create an org level from a field you have already used you may not get the desired results. If you have mixed values in different authorizations where they need to be descrete for different object, the creation of the org level will combine ALL the values into all the authorizations. So be careful and analyse the results of the report BEFORE commiting the results.

Answer:
Test mode

Create org level field KOSTL
Update authorization value proposals (SU24 data)
Conflicts (manual follow-up needed)
Values collected in role: SAP_CA_CL_MAINTAIN
Original values:
Authorization objectAuthorization Values
I_KOSTL T_P092043200
New org level values:
*

Values collected in role: SAP_ESSUSER
Original values:
Authorization objectAuthorization Values
P_TRAVL T_8000022406
P_TRAVL T_8000022407 *
New org level values:
*

Values collected in role: SAP_HR_REPORTING
Original values:
Authorization objectAuthorization Values
P_TRAVL T_P092020100 *
New org level values:
*
01

Thanks so much for your help!!!

Answer:
Looking at my last reply, I didn't get the entire message in.

What is in the last reply is the report that you run PFCG_ORGFIELDS_CREATE, and the results that I get.

My question is why does it say (manual follow up needed) for some of the roles.
All roles affected are at the end of the report. But it lists out conflicts above the list.

S_TABU_LIN

2009-03-09T09:04:00.004+05:30

Question: Hi everyone

I am currently trying to test the limitations of the restrictions that can be enforced by using object S_TABU_LIN, this allows users to only see particular rows of a table depending the restrictions in place.

I am having problems when testing this, as I do not know many table names or what fields lay in what tables - can anyone suggest the values that should sit in S_TABU_LIN and the table/s this relates to?

I dont mind what it does or doesnt let me see because at the moment its simply for testing, i just want it to produce an authorisation error so can see it working and work from that.

Answer:
also does the role have to have access to the authorisation group (in S_TABU_DIS) which the table lies. For example if you are trying to restrict seeing parts of HR master data in S_TABU_LIN would you need authorisation group PA in S_TABU_DIS??

S_TABU_LIN set up as organizational level

2009-03-09T09:04:00.003+05:30

Question: Hello,

I have started to look at the use of S_TABU_LIN to restrict table record maintenance on BUKRS , KOKRS; WERKS and EKORG. What I want is to be able to set these restricitons as organizational levels as we are using template roles which by inheritance will be used at about 200 different companies.

Has anyone tried this ?

Is it possible or not ?

Answer:
You can create orglevels using the report SAP provides (PFCG_ORGFIELD_CREATE) . Note BUKRS already is an orglevel . SO test it before you go too far and read the results of the test results closely before you implement.

Answer:
This is not possible. It would mean 2 fields as OrgLevel:
First defining the field OrgCriteria definition as organzational level, and supplementary to that the needed values.
Both fields are in the object S_TABU_LIN. How would the system know which value belongs to whicht OrgCrit?

S_TCODE

2009-03-09T09:04:00.001+05:30

Question: Is there a way to insure that the values in S_TCODE are only the tcodes assigned to the role thru the menu tree? We are try to prohibit ranges and the value of * in the S_TCODE object.

Thanks,

Mark

Answer:
You can have a look through table AGR_TCODES, and look for * values. That's the way I usually do it

Answer:
This would have to be a manual process. Analyze the data under AGR_TCODES vs AGR_1251 S_TCODE,TCD.

Answer:
I beleive there is a report in SAP that gives you this the report is PFCG_AGRS_WITH_MANUAL_S_TCODE, you cannot prevent them for doing it just after the fact detec

S_TCODE check after upgrade to 4.7

2009-03-09T09:03:00.002+05:30

Question: With the upgrade version to 4.7 regular transactions, do not work the
same way anymore.

Example transaction VL10H on the Tab ‘General Data’ there is column
named OriginDoc. When you click on one of these fields, it calls the
transaction VA03 (In version 4.6C) but now it is calls VA02 (In Version
4.7).

Why and how can I fix that without giving new roles with transactions
they did not have before and that used to run in the background without
requesting any S_TCODE check?

I have many requests for this kind of problem but for different roles
calling different S_TCODE. If I find a way to fix, one I will know for
all the other roles that call other S_TCODE’s.

Someone told me I could use SE97 to skip S_TCODE check BUT! What if the
transaction really require another transaction to work I do not want to
skip it otherwise we will have another kind of problem? Or I am wrong.

Please help

Nancy

Answer:
Sorry I did not find the one I posted yesterday and I thought I did not saved it.

Sorry for the duplicate of S_TCODE check after upgrade to 4.7

Nancy

Answer:
Dear Nancy,

In higher releases of SAP they are cleaning up their navigation paths. Upgrading, when you business process used a path which has changed (it became stricter to click on), does not mean that the process is any different.

You can call anything what you want. E.g. You can use SE97 to MAINTAIN the check on the CALLED tcode based on which tcode is CALLING it. But if the user can switch their sy-tcode, then the relationship changes. Take a look at table TCDCOUPLES.

SAP also provides other confusing messages though, which might be the case here. SU53 says "no auth tcode" ? But this may be caused by your having "BACK"ed (the ESC or OK problem) or the abap didn´t react sufficiently to the check and met a second auth fail, but gave you a message from either the one, or the other and a SU53 from the last check failed... i.e. the last one before '/nsu53'... not necessarily the one which gave you a "message" or caused your navigation path to change.

The change of the called transaction you mentioned (i.e. from VA03 -> VA02) may also be having an implication based on an application auth object check at tcode start, and not the tcode itself. Check SE93 for VA02.

For this you need to look beyond the tcode and compensate for SAP´s max-confusion-strategy. SU53, PFCG, ST01 and the SoD tools loitering around SAP are fully integrated into this strategy.

Kind regards,
Verne

Answer:
The only thing I found in the table TCDCOUPLES is an entry for
TCODE CALLED
VL10H VA03
VL10 VA02

But I am really in VL10H and I keeps having the message
You are not authorize to use the transaction VA02 !!!

I went in SE97 I created a list of called transactions for VL10H
Do not check VA02
Check Warning VA03
Do I have something else to do after what I did or when I use the role everything will work whitout any other configation.

I really need to know how to configure VL10H to call VA03 instead of VA02. Even with the table TCDCOUPLES or SE97 I am not able to change this setting !!!!

Need help
Nancy

Answer:
You will need to,
1. Call SAP and report the problem, or
2. Search on OSS for a fix
3. Debug the code and see if it is configurable in a table ( probably is not and TDCOUPLES has nothing to do with your want, It must be in the code).

Answer:
The last person who called SAP got 335277 - VL10: VA03 instead of VA02 in display of orders

You will need to work together with your developer and application person for the area.

An afterthought: That is also why, when you have outsourced your development work and application consulting, you will need to get yourself a Miles-and-More card and learn at least one exotic foreign language.

s_tcode display only problem

2009-03-09T09:03:00.001+05:30

Question: Hi Guru's

How to allow user to see only Area Menu and SAp Menu but not the list of transactions asssigned to his role. I tried in 2 ways..

1. I blocked the User menu , which also blocks Area menu.
2. Deleted transaction code list from Menu of User role and generated the profile. So now in usermenu i can not see any transactions. It is worked.
Here problem is S_tcode is in Display mode only, so we can not add any additional transactions in future. I do not like to uncheck transaction codes in SE97.

Apart from these, is their any other ways to solve this.

Thanks in advance

Pranu

Answer:
Pranu

User menu vs Sap menu and restricting views of transaction ahve been discussed oin ths forum many times before. Usually in those discussions the question is asked "Why do you not want users to see transactions they are allowed to use? It does not add to security, so what is the purpose of hiding access?"

The display only status of S_TCODE has been disucssed a lot recently too. I'm not gonig to answer your question here, because the S_TCODE issue and the menu issue could both be answered by you using the search facility.
_________________
Sandi
~~~~

Apparently Father Christmas, the Easter Bunny, the Tooth Fairy and Star Wars aren't real

Answer:
"Why do you not want users to see transactions they are allowed to use? It does not add to security, so what is the purpose of hiding access?"

If you cannot trust your users enough to let them see the transactions they have access to, then your design should be changed to only give them the access that your risk profiling permits.
Security by obscurity is not proper security

S_TCODE is not in change mode

2009-03-09T09:02:00.004+05:30

Question: Hi All

we are working on 4.7x1.10 SR1.

when we tried to add some transactions in Authorization object S_TCODE

it is showing us only in display mode rather it should be in change mode.

Is there any parameter that we need to add in 4.7 or what is the procedure to make S_TCODE as change mode?

pls help me out ........thanks in advance

Answer:
If you are using PFCG then the tcode needs to be added to the MENU not the authorization. If you are in SU02, Profiles created from PFCG cannot be changed in SU02

S_TCODE Lookup

2009-03-09T09:02:00.003+05:30

Question: I need to be able to find all roles that have have a TCD value in S_TCODE of *.

How can I do that? Suim's logic seems to give all roles. I need the specific value to be a '*'.

Thanks for your help.

Answer:
Hi bluedevil,
I usually use SE16 on AGR_1251 table to get what you are looking for...

be sure about to use '=' single value selection option,
instead of '[*]' pattern selection option, in the tcode field.

hope this helps, regards.

S_TCODE with * Value

2009-03-09T09:02:00.001+05:30

Question: Does anyone know the name of the report or how to find no standard Values such as ranges or * in the S_Tcode object. I think there is an SAP report but don't remember what it is.

Answer:
Look at report PFCG_AGRS_WITH_MANUAL_S_TCODE

Also use table AGR_TCODES and look for '*' by setting the selection option to "equals to" rather than blind entry of '*'

S_TRANSPRT versus S_CTS_ADMI

2009-03-09T09:01:00.002+05:30

Question: We're trying to restrict rights to release transports (DTRA); one role has most activities for S_TRANSPRT but not 43 (release). However, one user with this role managed to release a transport. The same role has S_CTS_ADMI with activity * (all activities); is this effectively "overriding" the restrictions in S_TRANSPRT ?

Can't find any info on this elsewhere... tried SAP, SDN...

thanx...

Answer:
look into Su24 and Su21 and from there into the documentation, this will give the requested info

Answer:
The SAP documentation is (as often is the case) very opaque, to say the least. I think we have a decent idea of the relation between these objects, even though we haven't found a clear, logically structured explanation on exactly what are the limitations and interoperability of the two objects. Probably never will...

Answer:
Tronds,

I guess the generic problem here is that values were granted
for the activity field based on the principle "ALL - except (43)".
I advocate the 'need-to-have'.

Check whether activity 75 is in. This allows you to release
other users' objects.

S_USER_ALL

2009-03-09T09:01:00.001+05:30

Question: Hi...

I am about to administrate users and roles on a SAP system. Previously I was always given SAP_ALL, but this time I wanted more adequate access rights. I therefore requested the profile S_USER_ALL (All Authorizations for user and authorization maintenance).

But... only to find out that it did not include any value for TDC (transaction code) or the authorization object S_USER_VAL (which gives access to change values in PFCG).

Anybody with experience in this ares

What profiles/roles are you guys using for user/role administration

Thanks for any reply

Answer:
Requirements will depend on your segregation of duties for user and role/profile adminsitration.

We developed our own and did not depend on the SAP provided Roles.

Assign your self SAP_ALL in a test client, set up a trace and run through your actions to see what auths and values you need.

SAP Auditor role/authorization

2009-03-09T09:00:00.002+05:30

Question: Is there a SAP role for SAP auditor (internal control)? Is there a role to view the Implementation Guide customizing settings?

Answer:
Is there a SAP role for SAP auditor (internal control)? Is there a role to view the Implementation Guide customizing settings?

If you are still looking for the SAP delivered roles like S:A_SHOW etc, then rather go back to doing your accounting on paper.

SU53 Authorization Check

2009-03-09T09:00:00.001+05:30

Question: If there is a message in SU53 saying "T-DV76526201 Exists in user buffer" for the role T-DV76526201, and then below I would find the list of the transaction codes affected, does that mean that there was an error or is it just an informational message?

Are all messages appearing in SU53 just error messages or even infomational messages?

Answer:
SU53 records the last authorisation failure for a user. The first block shows the system's authorisation requirement and the list below shows the authorisations present for that object for a particular user.

Answer:
I have seen the message you are talking about. The SU53 actually states something about an authorization existing in the user buffer but it still fails. I have found this is a throwback to pre-4.5 where the user must log off and back on again and it will usually work then. give it a shot.

Authorizations in sap

2009-03-09T08:59:00.000+05:30

Access control in SAP is composed of several concepts:

Program code that calls an authorization check using the authority-check statement. This will look something like:
authority-check object id field
Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:
ACTIVITY: defines the type of activity the user is doing with the data. Possible values are 'DISPLAY', 'MODIFY', 'DELETE', etc.

COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as '0438' and '0600' thru '1100')
Authorization objects that define a group of fields. For example, an authorization object called 'CO_MDATA', containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.
Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object 'CO_MDATA', called 'CO_MDATA_ALL', that grants all access to all company master data. Then 'CO_MDATA_ALL' would have the following values:

FIELD VALUE
ACTIVITY *
COMPANY_CODE *
Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]
Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.
Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user's system authorizations.

It sounds complicated, but once you start working with authorizations, it's pretty easy.

System Administration: Authorization Concepts

2009-03-09T08:56:00.000+05:30

Authorizations
Access control in SAP is composed of several concepts:

1. Program code that calls an authorization check using the authority-check statement. This will look something like:

authority-check object id field

2. Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

ACTIVITY: defines the type of activity the user is doing with the data. Possible values are 'DISPLAY', 'MODIFY', 'DELETE', etc.

COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as '0438' and '0600' thru '1100')

3. Authorization objects that define a group of fields. For example, an authorization object called 'CO_MDATA', containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

4. Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object 'CO_MDATA', called 'CO_MDATA_ALL', that grants all access to all company master data. Then 'CO_MDATA_ALL' would have the following values:

FIELD	VALUE
ACTIVITY	*
COMPANY_CODE	*

Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]
Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.
Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user's system authorizations.

It sounds complicated, but once you start working with authorizations, it's pretty easy.

Authorization Checks

2009-03-09T08:55:00.002+05:30

When a user starts a transaction, the system performs the following checks:

The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
The system then checks whether the user has authorization to start the transaction. The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.
- The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
- If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
  If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.
The check is not performed in the following cases:
- You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
- This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
- You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
- So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to “Y” (using transaction RZ10).

All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.

Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

Authorization Check

2009-03-09T08:55:00.001+05:30

The following actions are subject to authorization checks that are performed

before the start of a program or table maintenance and which the SAP

applications cannot avoid:

 Starting SAP transactions (authorization object S_TCODE)

 starting reports (authorization object S_PROGRAM)

 Calling RFC function modules (authorization object S_RFC)

 Table maintenance with generic tools (S_TABU_DIS)

The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS

are standard SAP provided.

Creating a new authorization object is not in the scope of ABAP developer. It will

be taken care by SAP BASIS team.

What is authorization

2009-03-09T08:54:00.000+05:30

Authorization is the process of giving someone permission to do or have something. In multi-user computer systems, a system administrator defines for the system which users are allowed access to the system and what privileges of use (such as access to which file directories, hours of access, amount of allocated storage space, and so forth). Assuming that someone has logged in to a computer operating system or application, the system or application may want to identify what resources the user can be given during this session. Thus, authorization is sometimes seen as both the preliminary setting up of permissions by a system adminstrator and the actual checking of the permission values that have been set up when a user is getting access.

auth/new_buffering

2009-03-09T08:53:00.000+05:30

Question: Does anyone have any experience relating to performance impact of enabling/disabling the user buffer?

As of now, we have a system running with auth/new_buffering set to 4.
I have a feeling that not using the buffer may influence our performance, but it is hard to verify without running traces in the productive system?

If the buffering does indeed affect performance, will this effect be larger or smaller using structural authorizations?

I hope someone can help clarify the issue?

/Morten P. Koehler

Answer:
THe user buffer referenced in AUTH/New_buffering has nothing to do with structural authorizationsa as these are stored in a table ( if turned on) and only retreived if the user encounters a HR authorization check.

THe system impact from performance is based on logon time and the number of records SAP has to retreive from UST04 and UST10 and UST12. If you have a properly designed security it can be minimized but the use of composite and task oriented roles increase the records SAP must resolve at logon. It also impacts the size of the system you must have and the swap space you will need for processing if you have 1000's of records to store in memory. In either case the buffer exists, it has more to do with logon times.

The MAjor imact is opening up your system to a host of back doors id auth/new_buffering is > 0.

SAP's claim is a 4 must be used so you can change the users access without having them log off and back on, does not work 100% of the time.

Also the >0 setting is based on a table that are not in sync with the real security tables. SAP only syncs them once and if you do not sync them yourself ( you have to use the sync function module correctly or nothing happens) you are loading incorrect data and orphaned data.

Answer:
The symptom is "without connection to user". I.e. no logon time.

SAP also mentioned that we could also deactivate the buffering in the data-dictionary, but no client (with John's performance pre-requisities) has been willing to take the step to date. Would that (SE11) have an impact from any experiences?

Auditing Information System AIS

2009-03-09T08:52:00.002+05:30

Auditing Information System (AIS)

SAP Audit Information System (AIS) serves as a centralized repository for reports, queries, and views of interest to auditors. It is designed to address the overall system configuration as well as SAP business processes and their related control features, providing audit and security practitioners with the critical information they need to conduct effective reviews of their SAP systems. SAP administrators can use AIS for security auditing. The AIS plays a supportive role in providing security services for SAP systems. The primary function of AIS is auditing but auditing features can derive the measures that help in developing the security policy for SAP systems.

Administration and Maintenance

A successful security set up of a SAP system concludes with proper management and administration of user IDs, password resetting, audit trails, audit logs, access control list, and personnel responsibilities.

Security administration in SAP includes maintenance of the overall SAP security environment using the SAP Profile Generator, creating user-level activity groups and creating user master records.

The concept of SAP security is flexible as well as complex. SAP has a multi-layered integrated framework. To ensure adequate protection, security measures must be factored into all layers of the SAP infrastructure. With client/server architecture, SAP systems include many components that exchange information, each of which constitutes a layer of the SAP security infrastructure. Security is often not a priority in an implementation and as a result, the default security is not strong. SAP security functionality could be enhanced using various measures as discussed above.

Enterprises must develop a security strategy to ensure a secure and functional SAP system. A business critical application like SAP needs continuous monitoring and improvement of its security features.

Interview Questions

2009-03-09T08:52:00.001+05:30

Question: Hi all,

I'm new to security admin, Is there any transaction codes available for security and audit logs.

thanx

Answer:
Hi lola,

If you use the search functionality on this forum you will see this has been covered a number of times.

SM19,20 and 21 will get you started but red the posts and you will get lots more info

cheers,

al.

Answer:
Also look at transaction SERC as it has a Basis security component on "things that should be done" and are low hanging fruit for auditors.

Audit

2009-03-09T08:51:00.002+05:30

Question: Hello,

Can someone tell me what the difference between Security Audit Log and AIS is.

Thanks

Answer:
Security Audit log will record events corresponding to user defined filters - e.g. dialog logon, transaction start.

AIS is a list of reports which can be used for some system audit tasks. In no way should AIS be relied on, however there are some useful (standard) reports which can be used as part of an auditing framework.

Audit and/or Authorization maintenance tools

2009-03-09T08:51:00.001+05:30

Question: Hello,

Can you tell experiences about audit and authorization maintenance tools?
like PCI, VRAT, APM

Thanks

Answer:
Search the forum and you will see this has been covered a few times.

Deletion of Vendor Consignment Records

2009-03-09T08:50:00.002+05:30

Steps for Deletion of Consignment Records:
To delete the Consignment Record, use transaction MSK2 or menu-path:
Logistics - Materials Management - Material Master - Special Stock - Vendor Consignment - Change and select the data of the record you want to be deleted.

To start the archiving:
Process, follow the menu path:
Logistics - Materials Management –Material - Master - Other - Reorganization - Special Stock – Choose to select the records to delete and
Logistics - Materials Management - Material Master - Other - Reorganization - Special Stock - Reorganize to create archive file.

Create Archive File: Consignment Record: Data selection
a) Select Action: Archive and enter a new Variant, for example: Z_CONS_SELE_01, press 'Maintain'
b) On selection screen enter the data range (Vendor, Material, etc.) you want to archive.
c) Select the 'Create Output File' if you want the selected records outputted
d) Press the green back-arrow and enter the description of this new variantt on the screen which follows.
e) Save the variantt which brings you again to the selection screen. Press green the back arrow again.
f) To start archiving process (batch-job), press the 'Start Date' button and select the time when you want to start this process. Select 'Immediate' for instant processing and press the 'Save' button on the bottom of the 'Start Time' window.
g) Select the 'Spool Parameter' button and save entries. Eventually enter a valid printer to have the result outputted.
h) You are ready now to start the process. Press the 'Start' button and monitor the success with the 'Job Overview' button
You can also go the 'fast path' by using transaction SE38, program MMREO002 for selecting the data to archive. For large data archiving, use the background jobs and run those during off-peak times. Create Archive File: Consignment Record:

Archiving process:
a) Select Action: Archive and enter a new Variant, for example: Z_CONS_ARCH_01, press 'Maintain'
b) On selection screen, select the 'Sequential Dataset' if you selected data as described in the Data Selection step, otherwise enter the material number and plant for the deletion of a single record.
c) Select the fields 'Consignment' and 'Special Stock' and Test mode, if you want to try out first.
** This applies for SAP systems prior to release 3.1H: Select also the flag called 'BATCHES'. The SAP program MMREO020 has a bug which can be worked around with this selection. Without selecting 'BATCHES', the archived records cannot be deleted. For systems with applied Hotpackages for 3.1H this workaround is not necessary
d) Press the green back-arrow and enter the description of this new variantt on the screen which follows.
e) Save the variantt which brings you again to the selection screen. Press green back arrow again.
f) To start archiving process (batch-job), press the 'Start Date' button and select the time when you want to start this process. Select 'Immediate' for instant processing and press the 'Save' button on the bottom of the 'Start Time' window.
g) Select the 'Spool Parameter' button and save entries. Eventually enter a valid printer to have the result outputted.
h) You are ready now to start the process. Press the 'Start' button and monitor the success with the 'Job Overview' button
You can also go the 'fast path' by using transaction SE38, program MMREO020 for selecting the data to archive. For large data archiving, use the background jobs and run those during off-peak times. If you run the program online, you will see a confirmation on the status bar telling 'New Archive file created:....'

Delete Archived Records: Info Record
a) Follow the menu path: Tools - Administration - Administration - Archiving
b) Select the Object Name MM_SPSTOCK for consignment / Special Stock
c) Select the menu button 'Delete'
d) Select the menu button: 'Archive Selection'
e) Click the archive created in previous step
f) Select Start Date for process and Spool Parameters for output
g) Submit selection.
h) Check status by pressing the Job Overview button

Archive DEFINITION

2009-03-09T08:50:00.001+05:30

1) An archive is a collection of computer files that have been packaged together for backup, to transport to some other location, for saving away from the computer so that more hard disk storage can be made available, or for some other purpose. An archive can include a simple list of files or files organized under a directory or catalog structure (depending on how a particular program supports archiving).

On personal computers with the Windows operating system, WinZip is a popular program that lets you create an archive (a single file that holds a number of files that you plan to save to another medium or send someone electronically) or extract its files. WinZip also compresses the files that are archived, but compression is not required to create an archive. A WinZip archive has the file name suffix ".zip".

In Unix-based operating systems, the tar (tape archive) utility can be used to create an archive or extract files from one. On mainframe operating systems such as IBM's MVS and OS/390, procedures for archiving or backing up files are often automated as a daily operation.

2) On Web sites as well as in libraries, an archive is a collection of individual publications that are often cataloged or listed and made accessible in some way. Magazines, journals, and newspapers with Web sites sometimes refer to their back issues as an archive.

3) Web and File Transfer Protocol sites that provide software programs that can be downloaded sometimes refer to the list of downloadable files as an archive or as archives.

Applying Hot Packages Using OSS Material free downloads

2009-03-09T08:49:00.002+05:30

Applying Hot Packages Using OSS

Audit Information System

2009-03-09T08:49:00.001+05:30

The Audit Information System (AIS) has been developed to provide internal and external auditors, Security Administrators and those with data protection and controlling responsibilities with a tool to assist in understanding and completing required tasks in the complex SAP environment. The SAP Audit Information System (AIS) provides a centralized repository for reports, queries, and views of data that have a control implication. AIS was first available for SAP R/3 Version 3.0D, and is delivered as standard in SAP R/3 Versions 4.6 and above. AIS is provided at no additional cost from SAP, and allows an auditor or manager to work online in the production system on a real time basis..

Emergency Role Firefighting

2009-03-09T08:48:00.000+05:30

How good you do your security there may come a time when user might need emergency authorizations. Such authorization can be necessary in exceptional situations. It could be a month end close, which got closed before the month end.
Virsa provides tool called firefighter, which can help you. First you have to define what is an emergency for your company. You might have to create roles for these emergencies, and also define the time frame this role will be assigned to users. You might have to define an approval procedure for this. Hoe is this going to be audited. Work with your audit team to make sure they are ok

The Alert Monitor CCMS

2009-03-06T13:03:00.001+05:30

The monitoring architecture, a solution within SAP NetWeaver, centrally monitors any IT environments – from individual systems through networked SAP NetWeaver solutions, to complex IT landscapes incorporating several hundred systems. It is provided in SAP NetWeaver and can be used immediately after installation. You can easily extend the architecture to include SAP and non-SAP components.

Alerts form a central element of monitoring. They quickly and reliably report errors – such as values exceeding or falling below a particular threshold value or that an IT component has been inactive for a defined period of time. These alerts are displayed in the Alert Monitor; this reduces the workload for the system administration, since they now only need to watch the error messages, instead of endless system data.

The Alert Monitor is therefore the central tool with which you can efficiently administer and monitor distributed SAP NetWeaver solutions or client/server systems. The Alert Monitor displays problems quickly and reliably.

Implementation Considerations

If you want to use the Alert Monitor for central monitoring (that is, you want to monitor the systems of your IT landscape from a central monitoring system), you must perform various configuration steps yourself. These are described under Configuring the Monitoring Architecture.

Features

The Alert Monitor provides the following functions:

· You can use the Alert Monitor to perform complete and detailed monitoring of all SAP and non-SAP systems, the host systems, and the database.

· All errors generate alerts, which are displayed in a tree structure.

· The alerts contain a status indicator with a color and a numerical value. Yellow means a warning, red means a problem, and the numerical value shows the severity of the reported error. In the tree structure, the most severe alerts are passed upward in the display hierarchy. If a tree node is not displaying an alert, there is also no error in the entire branch below it.

· You can assign certain analysis and auto-reaction methods to the alerts, which contribute to faster processing of the error. If you double-click an alert, the monitoring architecture starts the assigned analysis method (such as the job administration transaction for a prematurely terminated job). An auto-reaction method, on the other hand, starts automatically as soon as the alert occurs. This includes executing operating system commands and sending an e-mail or an SMS message to the system administration.

· The Alert Monitor contains various view in which either the current or the open (that is, the unanalyzed) problem messages are displayed. Alerts are also archived.

· Threshold values, methods, and detailed help for many monitoring attributes and three extensive monitor sets with monitors for all aspects of system management are predefined on the basis of Best Practices in the monitoring architecture and are available in every SAP system.

· You can adjust all settings individually, and configure your own monitors.

Technical Basics: Data Supplier in CCMS

2009-03-06T13:02:00.003+05:30

Data suppliers deliver all of the values that are displayed in the Alert Monitor. They each belong to the individual system components and create monitoring objects that report values to the monitoring architecture. These values are displayed in the monitor sets.

The monitoring architecture is delivered with the data suppliers for the most important components of your SAP system and its environment and can therefore be immediately used. When starting the Alert Monitor, you can see that the data suppliers for reporting for the following components are already active:

· The host systems on which your SAP system is running

· The database

· SAP instances (application servers) and their services and components

· Components outside the system

You do not need to prepare or activate the monitoring architecture. The data suppliers in your system are either started automatically when the system is started, or are started as they are required. There are two different types of data suppliers:

· Passive Data Suppliers are started by the monitoring architecture, which is why they must be defined there. “Passive” describes the behavior of the data supplier in relation to the monitoring architecture: it does not start itself, but rather must be started by the monitoring architecture. Passive data suppliers are also known as data collection methods.

· Active Data Suppliers are started by the monitored application rather than the monitoring architecture. These data suppliers are active in their start behavior in relation to the monitoring architecture.

A data supplier writes the values for the monitored objects in a segment of the shared memory known as the monitoring segment. This monitoring data can be transferred to the monitoring architecture in two ways:

· Using a defined ABAP interface, in the case of an SAP instance ‑ a free work process is required for this

· Using a CCMS agent, for any server; the transfer is performed using a Remote Function Call (RFC)

As the connection method using a CCMS agent does not require a free work process, the access method is therefore independent of error states of the SAP instance and therefore more robust. The CCMS agents also use push technology with which the agents report alerts automatically, if the central monitoring system is running SAP Web Application Server 6.10 or above. This helps to ensure a good performance, as the central monitoring system then no longer needs to periodically query the agents for alerts. We therefore recommend that you use CCMS agents when connecting remote systems to the central monitoring system.

Changing Properties and Method Assignments

2009-03-06T13:02:00.001+05:30

Monitoring objects and attributes are assigned various properties and methods. There are default settings in the standard SAP System (which is delivered with the properties variant SAP_DEFAULT) for most nodes for properties and methods, meaning that you can already work with these settings.

Auto-reactions are an example. There are very few assignments of these in the standard SAP System. You can make your own assignments of these (see also: Selected Methods of the Alert Monitor).

If the standard settings do not meet your requirements, you can change the properties and method assignments at any time. You can make the changes both in the Alert Monitor and in the Customizing transaction RZ21. You can either make changes for the individual node itself or for the MTE class or attribute group, to which the node belongs (we recommend the latter).

Features

The following cases occur most often in practice:

Desired Change	Procedure
· the descriptive text for the node · Severity and maximum number of alerts for the node	Change the General Properties of the node or of the MTE class ad described in Changing the Properties in the Alert Monitoring Tree and in Changing Properties in the Customizing Transaction RZ21
Trigger an alert if no value is reported for the node (heartbeat alert)	Change the general properties of the node or of the MTE class as described in Triggering a Heartbeat Alert if no Values Are Reported
Frequency of the data collection method of the node	Change the general properties of the node or of the MTE class as described in Changing the Frequency of the Method Execution
· Threshold value of the node (performance attribute) · Conditions for messages for which alerts are to be triggered (status and log attributes)	Change the Specific Properties of the node or of the MTE class ad described in Changing the Properties in the Alert Monitoring Tree and in Changing Properties in the Customizing Transaction RZ21
Assigning an auto-reaction method (especially Automatic Alert Notification)	Change the method assignment of the node or of the MTE class as described in Assigning Methods to MTE Classes or Individual MTEs

Alerts CCMS

2009-03-06T13:01:00.002+05:30

Definition

The Alert Monitor generates alerts in the monitored systems using threshold values and rules, if the status of the systems deviates from the norm. These alerts attract your attention to critical situations so that you do not have to search for them yourself. Auto-reaction methods can inform you about a problem, or react to it in some other way, even if you are not currently working in the Alert Monitor.

For the system administrator, an alert is an error report or a service request. You should react to every alert. Use the Alert Browser and the analysis method contained in the Alert Monitor to investigate the alert. If you have solved the problem, or are sure that you can safely ignore it, set the alert to complete. The system then removes this alert from the display and saves it to the alert database.

The alert monitor reports alerts up through the monitoring tree. This means that the color indicator for a node is always the color of the highest alert in all elements of its branch. If, for example, a host system has a red indicator, one or more components in the monitoring tree for the host system are displaying red alerts.

An alert is uniquely assigned to one monitoring tree element (MTE) in the monitoring tree. The alert is generated when values are sent from a data supplier to an MTE. The alert monitor evaluates this incoming information against alert thresholds. If the incoming data exceeds or violates a threshold, then the alert monitor triggers an alert. The alert monitor generates an alert for every abnormal status and keeps track of every alert until it is set to status complete.

You can also use a heartbeat alert to configure an MTE in such a way that an alert is generated if a data supplier fails to report values (see Triggering a Heartbeat Alert if No Values Are Reported).

Alert Threshold Values and Assignment to Attribute Groups

Reliable values for threshold values and the severity of alerts are predefined for all monitoring attributes. These settings are based on our extensive experience with SAP production systems.

Monitoring attributes are combined into attribute groups. An attribute group contains the threshold values that have common associated monitoring attributes. In this way, all instance-specific occurrences of the Response Time monitoring attribute belong by default to one attribute group. This means that the same threshold values are set for the response time in all instances of a system. If you want to change threshold values, you only need to change the value for the corresponding attribute group.

Alert Colors and their Meanings

Color	Meaning
red	Problem or Error
yellow	Warning
green	Everything OK
gray	No information available

By default, no alert is generated in the case of a green message. However, you can activate the generation of “green alerts” for selected nodes (see Working with All-Clears (Green Alerts)).

Monitoring Objects and Attributes CCMS

2009-03-06T13:01:00.001+05:30

Definition

A monitoring object represents a component of the IT environment that is to be monitored, such as the CPU of a server, the dialog system, or background processing. Monitoring attributes are values, statuses, or texts that are reported to this object, such as the CPU utilization, or the average response time in the dialog system. A monitoring attribute can be assigned an alert. The selection of the monitoring objects is performed using the data suppliers that exist for all areas of system management.

Structure

Monitoring objects and their attributes are displayed in the alert monitoring tree as individual nodes in a hierarchical tree. If the data reported to the monitoring architecture exceeds or falls below the defined alert threshold values, an alert is triggered in the corresponding monitoring tree element.

There are five different types of monitoring attributes:

Attribute Type	Description
Performance Attribute	Collects reported performance values and calculates the average
Status Attribute	Reports error message texts and alert status
Heartbeat Attribute	Checks whether components of the SAP system are active; if no values are reported for a monitoring attribute for a long time, it triggers an alert
Log Attribute	Checks log and trace files (these attributes can use an existing log mechanism, such as the SAP system log, or they can be used by an application for the implementation of a separate log)
Text Attribute	Allows a data supplier to report information that is not evaluated for alerts; the text can be updated as required

You can assign methods to monitoring attributes. A method can be a report, a function module, an SAP transaction, or a URL that is to executed as a reaction to an alert. You can execute these methods within the Alert Monitor. If you double click, for example, the MTE for prematurely terminated jobs, the monitoring architecture automatically starts the job management transaction, in which the job reported in the MTE is already selected.

See also:

Properties of Log Attributes

Properties of Performance Attributes

Properties of Status Attributes

MTE Classes and Attribute Groups ccms

2009-03-06T13:00:00.002+05:30

Definition

The alert monitoring tree consists of individual monitoring tree elements (MTEs). They are either components of your IT landscape that are to be monitored (monitoring objects), or values, statuses, or texts that are reported for these objects (see Monitoring Objects and Attributes). These MTEs are assigned to MTE classes and attribute groups in the monitoring architecture:

· An MTE class describes the general properties and method assignments that are common to a particular group of monitoring tree elements.

· An attribute group describes the common threshold values for alerts for a particular attribute type.

Use

MTE classes and attribute groups simplify the Customizing of the Alert Monitor, since you do not need to change threshold values, properties, or methods individually for every MTE, but only for the corresponding attribute group or MTE class.

MTE classes also simplify the creation of your own rule-based monitors, since you do not need to specify every MTE individually when constructing the alert monitoring tree, but rather only the corresponding MTE classes.

The classification of the MTEs to MTE classes and attribute groups is already fully predefined. You do not need to make any changes to be able to use this classification.

If you want to change the properties, methods, or threshold values, the system displays a message informing you whether the change refers only to an individual MTE or to the corresponding MTE class or attribute group. You can change this default value (see Changing Properties and Method Assignments).

Examples

· MTE Class:

The Space Management monitoring object and the Free Space monitoring attribute both belong to the MTE class CCMS_DB_Freespace_MT. This means that both MTEs have the same general properties and method assignments.

· Attribute Group:

All instance-specific occurrences of the Response Timemonitoring attribute belong by default to a single attribute group. This means that the same threshold values are set in all of the instances of a system and that changes to the threshold values apply to all instances.

Methods CCMS

2009-03-06T13:00:00.001+05:30

Use

You can assign methods to monitoring attributes, and access the method definitions using the Customizing transaction for the Alert Monitor, RZ21. A method can be a report, a function module, an SAP transaction, or a URL that is to be executed as a reaction to an alert. You can execute these methods within the Alert Monitor. If you double click, for example, the monitoring tree element (MTE) for prematurely terminated jobs, the monitoring architecture automatically starts the job management transaction, in which the job reported in the MTE is already selected.

All methods required for standard monitoring functions are predefined. You only need to change the method assignments if you add a new method or if you want to replace one of the SAP standard methods with a method of your own. You can transport method definitions to other SAP systems. However, this is only necessary for your own method definitions; the methods delivered by SAP already exist in all systems with the same SAP release.

Monitoring tree elements are assigned to MTE classes. An MTE class describes the general properties and method assignments that are common to a particular group of monitoring tree elements. The MTE class is also used in rule-based monitor definitions.

The Space Management monitoring object and the Free Space monitoring attribute, for example, both belong to the MTE class CCMS_DB_Freespace_MT. This means that both MTEs have the same general properties and method assignments.

You can also group methods assigned to MTE classes in properties variants. This has the advantage that you can run different methods in different properties variants, making the monitoring of SAP systems more flexible. Another advantage is that long-running methods can be run in the background.

The following methods exist:

· Data Collection Methods

These methods allow the collection of information about the SAP system and its environment that is then reported to the monitoring architecture. The method starts automatically or is automatically started by the Alert Monitor at specified time intervals.

A data collection method is, for example, an ABAP program that is responsible for the collection of information about an MTE.

· Auto-Reaction Methods

These methods start automatically when an alert is triggered. Almost no assignments are made in the standard SAP system; however, there are several predefined auto-reaction methods in the monitoring architecture that you can assign to any MTE classes:

· Send an E-Mail

· Execute an Operating System Command

· Execute an Auto-Reaction in the Central Monitoring System

· Analysis Method

This method allows a detailed analysis of error situations without leaving the Alert Monitor. You start an analysis method manually when you want to display information or investigate an alert.

An analysis method is, for example, an ABAP program for displaying information about a node in the monitoring tree and for collecting information about the problem that triggered an alert in this node.

You can display the current method assignments of the MTEs of a monitor and the status of the assigned data collection and auto-reaction methods in an overview screen. To do this, display the technical views of the Alert Monitor.

See also:

Changing Properties and Method Assignments

Operating the Alert Monitor CCMS

2009-03-06T12:59:00.000+05:30

Purpose

The following section contains a short overview of the operation of the Alert Monitor. For more information, see the Tutorial for the Alert Monitor.

Process Flow

To perform a a periodic check of your monitored systems, follow the procedure below:

Start the alert monitor by calling transaction RZ20.

The system displays the CCMS Monitor Sets screen. Every monitor set contains monitors that deliver information for a particular system management topic. Expand a monitor set and choose the required monitor by double clicking it.

You can copy, change, and create new monitor sets and monitors. The icons after the monitor sets display whether a monitor set was delivered by SAP () or created by the customer (), and whether you are authorized to change the set () or not ().

The system displays the

tree structure

of the desired monitor. The system is displaying the Current Status view in which you can monitor the current values of your monitoring attributes. If you want to analyze an alert, choose the corresponding monitoring tree element (MTE) by double clicking it.

You can then check what has happened since the last check in the system. Use the Open Alerts monitoring view to see if there have been yellow or red alerts (warnings or problems). If you choose an alert in this view by double clicking it, the system displays the

Alert-Browser

. This displays all alerts that have not yet been analyzed in a flat hierarchy.

After you have analyzed an alert and taken the necessary action, set it to Completed to remove it from the display of open alerts.

See Also:

Change Views: Current Status/Open Alerts

Tutorial for the Alert Monitor CCMS

2009-03-06T12:56:00.002+05:30

Use

The following section provides a detailed guide to using the Alert Monitor.

Procedure

...

1.CCMS Control/Monitoring Alert Monitor, or call transaction RZ20.

The system displays the CCMS Monitor Sets.

2.Expand one of the monitor sets by placing the cursor on the CCMS monitor sets and then choose Edit ® Expand Tree.

SAP delivers various standard monitor sets, such as SAP CCMS Monitor Templates or SAP CCMS Technical Expert Monitors. These monitor sets are always available.

3.Display the Entire System monitor of the SAP CCMS Monitor Templates monitor set by placing the cursor on the monitor and choosing Start Monitor.

The monitor displays the tree in the last-used format. The monitoring tree is a hierarchical display of monitoring objects (system components) and monitoring attributes (information types for objects) in the system.

For this tutorial, expand the alert monitoring tree, if the entire hierarchy is not displayed. Place the cursor on the Entire System line and choose Edit ® Tree ® Expand Tree ® Expand Subtree.

In addition to the Entire Systemmonitor, there are also predefined monitors for particular purposes. For example, if you are a database administrator, you can open the Database monitor instead of the Entire System monitor.

Another special monitor is the CCMS Selfmonitoring monitor in the SAP CCMS Technical Expert Monitors monitor set. This monitor displays possible problems in the alert monitor and the monitoring architecture. Check in this monitor whether all of the data collection methods started by the Alert Monitor are running correctly.

4.Check the current status of your system.

a.Display the current system status in your monitor.

Choose the Current Status view, if it is not already selected. In the Current Status view, you can see the performance values and status messages that have been most recently reported to the Alert Monitor.

Older alerts that are still open (that is, not yet completed) are no longer labeled with colors.

b. Check the color indicators in the monitoring tree.

The colors of the nodes in the tree mean the following:

Green: The component is running correctly.

Yellow: The system is issuing a warning.

Red: The system is reporting a problem or a critical state.

Gray: No data is being delivered for the node.

To display a legend for the colors and icons used in the Alert Monitor, choose Extras ® Legend.

The alert monitor passes the highest alert level up the monitoring tree. For example, if the monitoring tree element (MTE) with the name of your system is green, this means that all components in the monitoring tree for the system have this status. There are therefore no warnings or problems.

Choose an MTE by double-clicking it to start the associated analysis method. The analysis method displays more detailed information about the current status of the MTE.

You can optionally specify an automatic refresh of the display. Choose Extras ® Display options, and switch to the General tab. In the Refresh display box, select the option Yes, interval and enter the interval for the refresh. The default value is 300 seconds or longer. If the automatic refresh is deactivated, the alert monitor displays the data that was available when the alert monitor was started.

5.Check what has happened recently in the Open Alerts view

The color indicators in this view do not show the current status of the system (see Changing Views: Current Status/Open Alerts).

At the start of your working day or after your lunch break, you can use the Open Alerts view to check what has happened in the system during your absence. The monitor stores the alerts for you, even if the status that triggered the alert has improved in the meantime.

6.React to an alert.

In the monitoring tree, yellow entries mean warnings and red entries mean errors.

Proceed as follows:

Ensure that you are in the Open Alerts view.

The monitor is now displaying how many alerts exist for each MTE. It is also displaying the most important of the waiting alert messages.

Place the cursor on a yellow or red MTE and choose Display Alerts.

The system opens the Alert Browser and displays the open alerts for the relevant MTE. The Alert Browser displays all alerts in the branch of the tree that you selected. Move the cursor further up the monitoring tree to display a wider range of alerts. Select an MTE on the lowest level to display only the alerts for this MTE.

Analyze an alert.

Each line in the Alert Browser provides overview information for an alert, including the alert message.

The browser also provides two additional information sources. Select an alert and choose one of the following buttons:

- Start Analysis Method
By choosing this button, you start the transaction for problem analysis or the analysis method for an alert. New analysis methods are constantly being added to the system. Not all MTEs already have an analysis method (see Starting Methods).

For problems with buffers, for example, you can start the Buffer Tuning Summary from the Alert Monitor.

- Display Details
You can use this function to display the details for the monitoring tree element. These include the current values or status messages, the alert threshold values, and the performance data for the last measurement period (only for performance MTEs). You can display the performance data graphically by selecting the relevant line and choosing Display Performance Values Graphically.

7.If the alert is resolved, set it to Complete.

Once you have analyzed the problem and have either resolved it or ensured that you can safely ignore it, you can set the problem to Complete.

Select the alert and choose Complete Alert. The Alert Monitor deletes the alert from the list of open alerts (see Completing Alerts).

Start and Change Monitors CCMS

2009-03-06T12:55:00.002+05:30

A monitor provides monitoring objects and attributes for a system administration topic. These monitors are grouped into monitor sets that each contain several monitors.

To be able to quickly check all relevant monitoring objects (for example, during a periodic check of your monitored systems), it can be useful to switch between monitors quickly and without intermediate steps.

Start a Monitor

Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

Expand the monitor set that contains the monitor that you require, choose Start Monitor, or choose the desired monitor by double clicking it.

Switch Between Monitors

You can switch between monitors in a monitor set without first closing the monitor that you have open.

Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.
Expand the monitor set that contains the monitors that you require and choose Start Monitor.
To switch to the next monitor in the monitor set, choose Goto ® Previous Monitor () or Next Monitor ().

Actions in the Alert Monitoring Tree CCMS

2009-03-06T12:55:00.001+05:30

The alert monitoring tree provides you with an overview of the system status of monitored systems. There are various options for displaying and checking the alerts that have occurred. The most important commands that you can use in the alert monitoring tree are described here.

Activities

Choose Expand Tree () or the folder icon () directly in front of the relevant branch in the Alert Monitor to expand the individual branches of the alert monitoring tree.

Choose Compress Tree () or the folder icon () directly in front of the relevant branch in the Alert Monitor to compress the individual branches of the alert monitoring tree.

Select an element in the monitoring tree and choose

to display a description of the element.

If the central data cache is active in the display of the alert monitoring tree (this sentence is then displayed at the top of the monitoring tree), you can delete the entries of the central data cache and regenerate the monitor. To do this, choose Refresh and Invalidate Data Cache ().

This command is useful if you want to ensure that the alert monitoring tree is correctly displayed after making changes to individual monitoring tree elements or entire subtrees (see Setting Up the Central Data Cache).

In the Current Status display, choose an element by double clicking it to start the analysis method assigned to this element. You can use this to analyze and complete any alerts that exist (see

Starting Methods

In the Open Alerts display, choose an element by double clicking it to start the

Alert Browser

. This displays all alerts that have not yet been analyzed.

Choose Display Details () to display the detail data for this element. This includes, above all, the values reported for this element during the last 24 hours (see

Display Detail Data and Tailor Display

Choose Properties to display the

Properties

and

Methods

assigned to the element. These include, above all, the threshold values for warnings and problems (yellow and red alerts) and the associated analysis and auto-reaction methods.

Choose Extras ® Activate Maintenance Function to be able to make changes to monitors. The Change Monitor pushbutton () then appears in addition on the toolbar.

To switch between different monitors or monitor sets, choose Previous Monitor () and Next Monitor ().

See also:

Selecting Nodes in the Alert Monitoring Tree

Tutorial for the Alert Monitor

Selecting Nodes in the Alert Monitoring Tree CCMS

2009-03-06T12:54:00.002+05:30

You can only access many functions for monitoring tree elements (MTEs) in the alert monitoring tree once you have selected the relevant MTEs. This is simplest for individual MTEs, which you can select by selecting the indicator in front of the MTE. There are also various commands with which you can quickly select a larger number of MTEs.

Procedure

Selecting MTEs in the Tree

To call the individual functions in the table, choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20. Now select the required monitor and choose Edit ® Selections ® Select and one of the following options:

Menu Path	Function
Node (MTE)	Select the currently selected node
Subtree	Select the currently selected node with the complete subtree below the selected node
All Nodes (MTE)	Select all nodes in the current monitor
Objects Only	Select all monitoring objects (see Monitoring Objects and Attributes) below the selected node (including the selected node)
Attributes Only	Select all monitoring attributes (see Monitoring Objects and Attributes) below the selected node (including the selected node)
Nodes (MTE) of a Class	Select all MTEs that belong to the same MTE class as the selected MTE

Deleting Selection of MTEs in the Tree

Menu Path	Function
Node (MTE)	Delete the selection of the currently selected node without the subordinate subtrees
Subtree	Delete the selection of the currently selected node with the complete subtree below the selected node
All Nodes (MTE)	Delete the selection of all nodes in the current monitor
Objects Only	Delete the selection of all monitoring objects (see Monitoring Objects and Attributes) below the selected node (including the selected node)
Attributes Only	Delete the selection of all monitoring attributes (see Monitoring Objects and Attributes) below the selected node (including the selected node)
Nodes (MTE) of a Class	Delete the selection of all MTEs that belong to the same MTE class as the selected MTE

Display Overview of All Selected MTEs in the Monitoring Tree

Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

Expand the monitor set that contains the monitors that you require and choose Start Monitor.

Select the desired MTEs.

Choose Edit

Selections ® Show selections.

Set Selection Behavior

Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

Expand the monitor set that contains the monitors that you require and choose Start Monitor.

Select Edit

Selections ® Selection Behavior.

In the Selections by Operation group box select one of the radio buttons Hold or Delete. By doing so, you decide whether the selection is retained after an operation (such as Display Details).

See Also:

Actions in the Alert Monitoring Tree

Elements of the Alert Monitor CCMS

2009-03-06T12:54:00.001+05:30

The following section describes the most important elements of the Alert Monitor and their relationships to each other.

Purpose

When you start transaction RZ20, the system first displays the monitor sets available to you. These monitor sets group the monitors.

A monitor set usually consists of different monitors. A monitor is a collection of monitoring tree elements (MTEs) in a hierarchical structure that deliver information for a particular aspect of system management.

The hierarchical structure of a monitor is the alert monitoring tree. In this tree, you can check the status of your IT system landscape. The MTEs are nodes of this tree, where the root node also has the name of the monitor.

Different MTEs are Elements of the Alert Monitoring Tree: monitoring summary nodes, monitoring objects, and monitoring attributes. Monitoring summary nodes (summary MTEs) provide a better overview in the tree, without performing a monitoring function themselves.

A monitoring object represents a component of your IT environment that you want to monitor (such as the CPU of a server or background processing), while a monitoring attribute displays a value, status, or text that is reported for this object (for example, the CPU utilization during the last 15 minutes).

If a value that deviates from the norm is reported for a monitoring attribute, the Alert Monitor generates an alert. The conditions under which an alert is generated, the criticality of the alert, or which message is assigned to an MTE – all of these are properties of an MTE.

In addition to its properties, an MTE has methods: the data collection method allows the collection of information about the MTE, the auto-reaction method and analysis method are executed as a reaction to an alert.

To simplify Customizing, the properties and methods do not need to be edited for each MTE individually: There are attribute groups for attributes, and MTE classes for objects.

Operation and Customizing of the Elements of the Alert Monitor

Element	Operation	Customizing
Monitor set		Creating and Editing Monitor Sets Transporting Monitor Sets and Monitor Definitions
Monitor	Starting and Changing Monitors	Copying, Renaming, and Deleting Monitors Creating and Changing Monitors
Alert Monitoring Tree	Actions in the Alert Monitoring Tree Selecting Nodes in the Alert Monitoring Tree
Methods	Starting Methods	Defining, Releasing, and Transporting Methods Selected Alert Monitor Methods
Properties		Properties of Performance Attributes Properties of Status Attributes
Alerts	Handling Alerts
MTE Classes and Attribute Groups	Rule Node: Rule Description and Use

Monitor Sets CCMS

2009-03-06T12:53:00.004+05:30

Definition

As a system administrator, you can conveniently monitor your system with monitor sets. A monitor set contains several monitors. In turn these monitors consist of subtrees of all available objects. You can group the monitors according to task, by setting up several monitor sets in parallel.

You can either create the monitor sets temporarily, in order to solve a problem and then delete them, or you can store them permanently in the system.

Use

The SAP System contains three predefined standard monitor sets:

· SAP CCMS Monitor Templates

The monitors in the SAP CCMS Monitor Templates monitor set display the monitoring objects and attributes that are crucial for the monitoring of your SAP systems and which are used for normal system administration.

· SAP CCMS Technical Expert Monitors

Use the monitors in the SAP CCMS Technical Expert Monitors monitor set to monitor the monitoring architecture itself and to analyze problems in this area.

For example, you can use the CCMS Selfmonitoring monitor for internal monitoring or All Monitoring Contexts to view all available contexts in your systems.

· SAP CCMS Monitors for Optional Components

Use the monitors in this set to monitor components that are not part of the standard SAP system.

Monitors CCMS

2009-03-06T12:53:00.003+05:30

Definition

A monitor is a set of monitoring tree elements (MTEs) that are arranged in a hierarchical structure (the Alert Monitoring Tree). As monitors are organized by topic, you can quickly check all of the important objects for this topic. Monitors are combined in monitor sets.

Use

The quick collection of information and warning messages for specific areas of the system is normally part of the daily system administration work. For most problem situations, only a fraction of the information available in the monitor is required. For database problems, for example, you only need to work with the monitoring tree elements for the monitoring of the database.

There are therefore different monitors for the Alert Monitor, that each display information for an aspect of system management. These monitors are grouped into monitor sets. Within the monitoring architecture, you can create, copy, and edit monitors yourself, and transport monitors to other systems. In this way, you can create monitors that contain precisely the information that you need for your daily work. You can save and reuse all of your own monitors.

As the definition process is quick and easy, you can use a monitor of your own not only as a long-term, specialized work center, but also for short-term problem analysis or special monitoring. If, for example, you want to monitor the response time of a particular server, you can define a temporary monitor that monitors the response time, CPU utilization, and other relevant parameters for this server.

During the definition of monitors, you can use not only the existing nodes, but also virtual nodes and rule nodes. A virtual node structures the monitor; it is a heading or a description for the nodes created below it. A virtual node does not have a monitoring function itself.

A rule node specifies a rule that defines what should be included in the new monitor. The monitoring architecture interprets the rule and includes in the monitor the nodes that fulfill the selection criteria in the rule. The rules are regularly reinterpreted, so that your own monitor automatically corresponds to the current system landscape. A monitor defined with rules will, for example, automatically include a newly started SAP application server.

SAP deliver a range of predefined standard monitor sets with the SAP system. The standard monitors contained in these sets provide system administrators with a complete overview of the system and ready-to-use views for special tasks such as monitoring the database, background processing, the operating system, the system log, and the spool system. There is even a monitor for monitoring the monitoring architecture (CCMS Selfmonitoring).

Alert Monitoring Tree CCMS

2009-03-06T12:53:00.001+05:30

The monitoring tree is the component hierarchy displayed by the Alert Monitor. If problems occur in your system, they are displayed as alerts in the monitoring tree. The system displays a schematic representation of the monitoring tree:

To give a better overview, alerts are assigned certain colors - yellow for a warning and red for a problem - and a numerical value for the severity of the error. The alert with the highest severity appears at the top of the monitor that displays the monitored IT components (such as the CPU of a server) including their attributes (such as CPU usage) in a tree structure. In accordance with this, a node of the tree structure displays the most severe alert of the whole branch below it. If a node is not displaying an alert, there is no error in the whole branch below it. The system administrator can choose between different Views of the Alert Monitor, and display the current or open (that is, those that have not been analyzed) problem messages.

See Also:

The Monitoring Architecture: Concept

Actions in the Alert Monitoring Tree

Components of the Alert Monitor

Elements of the Alert Monitoring Tree

2009-03-06T12:52:00.002+05:30

The monitoring architecture displays a tree in the Alert Monitor that contains all monitoring tree elements (MTEs) for your monitored systems. The elements are clearly structured and arranged in the tree. There are three types of MTEs:

· Summary MTEs (Monitoring Summary Nodes)

These act as titles or headings in the alert monitor and do not have any monitoring functions themselves. No alerts can be triggered for summary MTEs. However, alert statuses and messages can be displayed.

There are two kinds of monitoring summary node:

¡ Real monitoring summary nodes: are stored in the monitoring segment

¡ Virtual monitoring summary nodes (): are not stored in the monitoring segment, but exist only to provide a clearer display of real MTEs in a monitor

· Monitoring objects ()

Monitoring objects are particular components of your systems that the monitoring architecture monitors (such as SpaceManagement or CPU). They are created by the data suppliers. The objects combine various monitoring attributes that belong to the same component or the same attribute of a system.

· Monitoring attributes

Monitoring attributes are data types that can be reported for a particular monitoring object. The monitoring object CPU, for example, has the attributes CPU utilization and 5MinuteLoadAverage. A data supplier reports data for these attributes, and the alert monitor triggers alerts for the attributes if the data violates the defined alert thresholds.

Properties of Monitoring Objects and Attributes

2009-03-06T12:52:00.001+05:30

Monitoring objects and attributes are assigned various properties. These include:

· An explanatory text

· When and under which conditions Alerts are generated

· The criticality that an alert is assigned

· The maximum number of alerts that are to be stored for an attribute

The properties therefore provide settings options for the alert that can be assigned to a monitoring attribute, and also more detailed information through the assigned message. In the same way as the properties, methods are assigned to a monitoring attribute.

The properties for most monitoring objects and attributes in the monitoring architecture are already predefined and are available in every SAP system. However, you can also change the settings in accordance with your wishes. Your changes to the properties and methods are grouped in properties variants, which prevents an accidental reset of your adjustments when the SAP predefined settings are updated (for example, during an update).

Structure

The properties are divided into two groups:

· General Properties

This includes the assigned message that contains more detailed information about the monitoring object or attribute. As the properties contain the class and the number of the message, you can also make your own changes here.

Setting options for the alerts are also general properties. For a monitoring object, these properties are only valid for the attributes that belong to this object.

· Properties of the Individual Monitoring Attributes

There are five different attribute types in the monitoring architecture, each of which have their own special properties. In this way, you can, for example, define the threshold value only for performance attributes. These properties only exist for monitoring attributes, not for monitoring objects.

See also:

Properties of Log Attributes

Properties of Performance Attributes

Properties of Status Attributes

You can edit properties both from the alert monitoring tree and from the Customizing transaction RZ21 (see Changing Properties and Method Assignments).

General Properties of Monitoring Tree Elements CCMS

2009-03-06T12:51:00.004+05:30

Every monitoring tree element (MTE) has properties that contain more detailed information about the element. The properties are divided into two groups:

· Properties that depend on the type of the MTE; these are:

Properties of Log Attributes

Properties of Performance Attributes

Properties of Status Attributes

· Properties that are independent of the type of the MTE. These are called general properties.

The general properties of an MTE include a message class and message number; these contain a short description of the MTE. The general properties also contain information about possible alerts. However, as alerts can only be generated for monitoring attributes, the following properties apply only for the attributes that belong to the object:

· Criticality and severity of the alert that is associated with the MTE

· Maximum number of alerts to be stored for this MTE

· Conditions under which no alert is to be generated

By default, the properties for the different MTEs in an MTE class are identical, however, you can change the properties individually for single MTEs (see Changing Properties and Maintaining Methods).

Use

The general properties determine, above all, the handling of alerts. If alerts for particular MTE classes or individual MTEs are especially important for the monitoring of your IT landscape, you can ensure that these alerts are, for example, reported further up the alert monitoring tree, or that a large number of these alerts is stored in the monitoring segment, by changing the general properties.

Structure

The general properties are as follows:

Property	Description
Message Class and Message Number	Message ID that contains a description of the MTE. You can change this is you have created your own message text
Severity of Alerts to be Triggered	Meaning of an alert; if two alerts have the same color, the alert with the higher severity is displayed further up in the alert monitoring tree (CCMS only uses values up to 50 here, so that you can ensure that this alert is displayed further up the alert monitoring tree by entering a higher severity)
Maximum Number of Alerts Kept	Limit of the number of alerts that are to be retained in the monitoring segment of shared memory
Which alerts should be kept?	*all: Additional alerts for this MTE are stored as long as there is still free storage space in the monitoring segment, irrespective of the maximum number of alerts kept. If there is no more free storage space, half of the supernumerary alerts (that is, the alerts over the maximum number) are deleted. The maximum number of alerts kept* is 10, but there are 50 alerts for the MTE in the monitoring segment. If the segment is now full, the monitoring architecture reduces the number of alerts from 50 to 30, as half of the supernumerary 40 alerts are deleted. *the oldest: If the maximum number of alerts kept is reached, no more alerts are stored for this MTE until alerts have been completed. the newest*: If the maximum number of alerts kept is reached, the oldest existing alert is deleted for each new alert. We recommend this setting.
Do not trigger alerts within the first …	Avoids the generation of alerts after the application server is started, while there are no meaningful values for many MTEs (such as for the buffer quality)
In the absence of values deactivate after …	Number of seconds after which the MTE is assigned the color status gray with the message “Value is obsolete”; this provides the possibility of identifying inactive nodes
Also Trigger Heartbeat Alert	Option to generate an alert if no values are reported (see Triggering a Heartbeat Alert if No Values Are Reported)

The number and selection of alerts that are to be stored have a critical importance for the function of the monitoring architecture: incorrect settings can cause the monitoring segment in which the alerts are stored to become full. We therefore recommend:

§ You should store the newest alerts. You can use the report RSAL_KEEPALTYPE_MODIFY to change all occurrences of All alerts should be kept to the newest alerts should be kept. Execute the report once for each affected SAP system and after every upgrade of the monitoring architecture.

§ You should complete alerts regularly to gain available storage area in the monitoring segment. With a large number of MTEs, it is useful to define conditions under which the system should automatically complete alerts.

§ Observe the Space subtree of the CCMS Selfmonitoring monitor. If there is insufficient free storage space in the monitoring segment, a corresponding alert is generated there.

Properties of Log Attributes CCMS

2009-03-06T12:51:00.003+05:30

Log attributes (icon ) are monitoring attributes that capture messages in their context. This means that the data collection method does not just write isolated messages in the Alert Monitor, but also the content of a log or trace.

Features

Log attributes have a number of special features in the display of properties and methods. These are described here. If you want to display the properties of a log attribute, select the attribute in the alert monitoring tree and choose Properties.

Display "Current Value" like Group Box

If there are multiple messages in the selected log attribute, you can choose which message should be displayed:

Always display only the newest message (Last incoming message)
The message with the severest alert, irrespective of its age (Highest alert)
The message with the severest alert that is not longer than a specified time (Maximum value from the last)

Alert Settings Group Box

You can select whether and how the messages for this log attribute should trigger alerts. Every message is assigned a color and a severity level. You can set as of which color and which level of severity an alert is to be triggered (From value), whether all messages should trigger the alert that is assigned to them (evaluation of Reported like), or whether no messages should trigger alerts (Never).

Internal Storage of Message Lines Group Box

The messages are stored in an internal message log. You can decide how many messages are stored (Maximum number of lines to be saved). If you select the radio button As much as possible, the system will store messages as long as there is enough space available in the monitoring segment of the shared memory.

See Also:

Detail Display for Log Attributes

Properties of Performance Attributes CCMS

2009-03-06T12:51:00.001+05:30

Use

Performance attributes (symbol ) are monitoring attributes that collect certain reported performance data and calculate the average.

Features

In the display of the properties and methods, performance attributes have a number of special characteristics that are described here. To display the properties of a performance attribute, choose the attribute in the alert monitoring tree and choose Properties.

Comparison Value

In the Comparison Value group box, you define how the value of the performance attribute is to be calculated from the reported values. You have the choice between the last reported value (last reported), the average value of the last minute, last five minutes, or last fifteen minutes (Smoothing) and the average value of the last full quarter of an hour or hour (Average).

Threshold values

In this group box, you can edit the threshold values with which an alert is triggered if the reported value exceeds or falls below the appropriate value. Note when doing so that the change applies not only to the concrete monitoring tree element (MTE), but for the whole MTE class. This is displayed at the top of the screen.

You have the option to assign different threshold values for a Change from GREEN to YELLOW and the Reset from YELLOW to GREEN (the same also applies for the Change from YELLOW to RED and the Reset from RED to YELLOW). This prevents a constant switching between the alert levels, if the attribute is wavering around the threshold value, which would generate a new alert every time.

The display of a rule of this type would look as shown in the graphic below. To find out the alert level, start from any value for the performance attribute and move upwards until you meet the curve. If the value is climbing from a lower alert level, the lower part of the curve is valid for determining the alert; if the value is falling from a higher alert level, the upper part of the curve is used.

The unit of the threshold value is determined using the data supplier.

Explanation for an Alert

If an alert is triggered, it is displayed in the Alert Browser. A short explanatory text for the alert is displayed there in the Alert Text column. Choose the relevant line of an alert and choose F1 to display a more detailed text about the alert. The system displays its short text and the associated message class and number here. You can use these to adjust the delivered message texts.

Properties of Status Attributes CCMS

2009-03-06T12:50:00.000+05:30

Use

Status attributes (symbol ) are monitoring attributes that report error message texts and alert status.

Features

Status attributes have a number of special characteristics in the display of properties and methods. To display the properties of a status attribute, choose the attribute in the alert monitoring tree and choose Properties.

When should a message trigger an alert?

Always (at every message): The Alert Monitor triggers a alert with the corresponding message value for every message.

Message value (color) has changed: The Alert Monitor only triggers an alert if the alert color of a reported message changes. For example, an alert is triggered if a red message follows a yellow message.

The message sent has changed: The Alert Monitor only triggers an alert if the color or severity of a message changes or if a new message is sent.

Never: The Alert Monitor does not trigger any alerts.

Changing the value for alert generation

You can control the generation of alerts by influencing the criticality reported with every status message. Note that each setting only applies to the selected monitoring attribute and not to the associated MTE class.

You have the following options:

Accept value unchanged: Choose this option to use the value reported by the application for a message. The default value for the message remains unchanged. This is the default option for the Alert Monitor.
Red is transferred as yellow: Choose this option to display all reported red messages as yellow alerts. This means that the Alert Monitor displays only yellow alerts. No red alert messages are logged.
Yellow is transferred as red: Choose this option to display all reported yellow messages as red alerts. This means that the Alert Monitor displays only red alerts. All reported yellow messages are logged as red alerts.
Red is transferred as yellow and yellow is transferred as green: Choose this option to reduce the weighting of the reported messages. The Alert Monitor displays incoming red messages as yellow alerts and incoming yellow messages as green alerts.

Display Types and Views of the Alert Monitor CCMS

2009-03-04T21:04:00.001+05:30

Purpose

The Alert Monitor provides two system views (Current Status and Open Alerts), with which you can display the status of your monitored systems. In addition, there are also the display types Alert Browser and Detail Data for displaying more detailed information about open alerts or selected monitoring tree elements (MTEs).

Current Status

This system view displays the current data for every MTE. When you begin to check the system, you begin with this view:

Heartbeat alerts are not displayed in this view (see Triggering a Heartbeat Alert if no Values Are Reported).

Open Alerts

The following image shows the Open Alerts view. This view shows where alerts exist that have not yet been analyzed and set to complete. The color indicator for alerts is set in accordance with the most serious alert that has not yet been processed. Switch to this view to see whether problems have occurred since the last time you used the Alert Monitor.

This view does not necessarily correspond to the current status of the system.

Alert Browser

A third display type is the Alert Browser, which you start through the Alert Monitor. The Alert Browser displays a list of the open alerts in a flat hierarchy. To do this, select the MTEs for which you want to display the alerts that have not yet been completed. The Alert Browser tool is therefore well suited to systematically processing all alerts that have not yet been completed.

Technical Views

The Technical Viewsshould be considered separately from the above display types. In technical views, the displayed information is not current values or alerts for nodes, but rather information about properties and methods of the nodes. You can also display this information for individual nodes by choosing the Properties pushbutton, however you can see the relevant information for all nodes of a monitor in the technical views. There are the following technical views:

· Technical View: Info on MTE

· Technical View: Method Allocation

· Technical View: Status Data Collector

· Technical View: Status Autoreaction

· Displaying the Technical View: Threshold Values

· Technical View: Central Performance History

Displaying Detail Data

You can display the detail data for one or more MTEs from both system views of the Alert Monitor. The display of the detail data shows you:

· The most serious alert that has not yet been processed (if one exists)

· For performance attributes, the current performance data, the associated alert threshold values and the combined, smoothed data for the last 30 minutes and 24 hours

· For status and log attributes, the last message

· The general properties of the selected MTEs

Displaying the Technical View: Info on MTE

2009-03-04T21:02:00.000+05:30

Use

MTE classes and attribute groups group nodes of the alert monitoring tree by topic and therefore simplify Customizing, as you no longer need to adjust the properties of all affected monitoring tree elements (MTEs), but rather only of the corresponding MTE class or attribute group. You can find out the assigned MTE class and attribute group by selecting an MTE and choosing Properties. This method is very time-consuming for obtaining an overview of the assigned MTE classes and attribute groups of the MTEs of an entire monitor. The technical view Info on MTE exists as an alternative for this purpose. This view displays the following information for the MTEs of the entire monitor:

· MTE class to which the MTE belongs

· Attribute group to which the MTE belongs (for performance, status, and log attributes)

· Short text that is assigned to the MTE class as help (usually activated using the F1 key)

To additionally display the long help text for an MTE, choose the relevant MTE by double clicking it.

· The nodes are always colored green in the technical view Info on MTE; as it contains no alert information.

· If the corresponding general or specific properties of the MTE are not determined by an MTE class or attribute group, but rather individually for this MTE, no class or group is displayed in this view.

Procedure

To activate the Info on MTE technical view, follow the procedure below:

...

1.Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2.Expand the monitor set that contains the monitor that you require, and choose Load Monitor.3.Choose Views ® Info on MTE. The alert tree now no longer displays the alert status and reported values, but information about the MTEs of the monitor.

Displaying the Technical View: Method Allocation

2009-03-04T21:01:00.004+05:30

Use

The individual monitoring tree elements (MTEs) of the Alert Monitor are assigned methods. These methods determine the data collection of the MTEs (data collection methods) and the possible reactions to an alert in the MTE (auto-reaction and analysis methods). You can find out the assigned methods by selecting an MTE and choosing Properties. This method is very time-consuming for obtaining an overview of the assigned methods for the MTEs of an entire monitor. The technical view Method Allocation exists as an alternative for this purpose. This view displays the method assignments for the MTEs of the entire monitor:

· Assigned data collection method: If the MTE is assigned an active data supplier, the system will display in the corresponding column, as the active data suppliers are not defined in the monitoring architecture

· Assigned auto-reaction method

· Assigned analysis method

· The nodes are always colored green in the technical view Method Allocation; as it contains no alert information.

· Summary nodes or monitoring objects can always be assigned methods; these assignments only take effect for the subordinate monitoring attributes, which can inherit their method assignment from the superordinate nodes.

· If no analysis or auto-reaction method is assigned to the MTE, is displayed in the corresponding column here.

Procedure

To activate the Central Method Allocation technical view, follow the procedure below:

...

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. Choose Views ® Method Allocation. The alert tree now no longer displays the alert status and reported values, but information about the methods assigned to the MTEs of the monitor.

Displaying the Technical View: Status Data Collector

2009-03-04T21:01:00.003+05:30

Data suppliers deliver values that are displayed in the Alert Monitor. They each belong to the individual system components and create monitoring objects that report values to the monitoring architecture. These values are displayed in the monitor sets.

It can be useful to check the status of the data collection methods if problems occur in the monitoring architecture. You can find out the most important information about the assigned data collection methods on one hand by choosing Properties, if you choose the data collection method in the Methods tab page by double clicking it. On the other hand, you can find out the definition and runtime status of the data collection method of an MTE by choosing Display Details ()

This method is very time-consuming for obtaining an overview of the data collection methods and their status for the MTEs of an entire monitor. The technical view Status Data Collector exists as an alternative for this purpose.

In this technical view, you can also manually start the data collection method for any MTE to which a data collection method is assigned. To do this, choose the relevant MTE by double clicking it. This is useful, for example during test phases or for MTEs for which you require the current value, even if it is not yet time for the next start of the method.

Note that when you start a data collection method manually, it runs under your user name and therefore also under your authorizations. As the method runs under the SAPSYS user when it is started automatically, and this user has only very few authorizations, you can assume from a successful test with a manual start that the method will also run without problems during normal operation.

Procedure

To activate the Status Data Collector technical view, follow the procedure below:

...

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. Choose Views ® Status Data Collector. The alert tree now no longer displays the alert status and reported values, but information about the data collection methods of the MTEs of the monitor.

Result

The view displays the following information about the data collection methods that are assigned to the individual MTEs of the monitor:

· Type of the data collection method; depending on the definition of the method, the following types are possible:

Type	Description
[Running in agent]	The method is periodically executed in a CCMS agent
[Running in Autoabap]	The method is executed periodically in the dialog process.
[Running in Background]	The method is periodically executed in the background process as a job.
[Kernel function]	The method is automatically executed in the C kernel.
[???]	The method type is not yet known; this type is only displayed for a short type after the method is created.

· Definition status of the method:

Type	Description
PRESET	The method has just been created; the properties of the method are still determined by the settings in the data supplier. After a maximum of five minutes, the system reads the current settings of the method from the active properties variant and changes the definition status.
DBSET WPSET	The settings of the active properties variant are already included in the properties of the method in this status. However, as it is not in the CHECKED definition status, you should check whether the method is released as a data collection method.
CHECKED	The method is released and can therefore be executed.
CEN_CHECKED	The method is executed in a CCMS agent; as all settings for the method are set in the agent, do not change these settings manually.

· Runtime status of the method:

Type	Description
Ready	The method is ready for the next execution; however, this is not yet due.
Run required	The method is to be executed, however the responsible dispatcher has not yet started the method.
Running	The method is currently running; the color of the corresponding attribute is yellow.
Error Fatal Error	An error occurred during the last run of the method. The difference between the two statuses is that a method in the status Error is started again at the next scheduled run, a method in the status Fatal Error is not. A method in the status Fatal Error is only started again after a warm start of the monitoring segment (see Resetting the Segment to WARMUP Status). The color of the corresponding attribute is red. You can also reset the method status by selecting the corresponding MTE, choosing Display Details (), and, on the following screen, choosing Edit ® Method Status ® Reset ® Select Data Collection Method.

The time specification after the runtime status shows the time since which the method has been in this status.

· Frequency of the method call in seconds (Cycle):

The color of the nodes is not passed upward in the alert monitoring tree. Monitoring objects and summary nodes therefore always have the color Green.

Displaying the Technical View: Status Autoreaction CCMS

2009-03-04T21:01:00.001+05:30

In the monitoring architecture, you can react automatically to an alert using auto-reaction methods. These methods are automatically started in the case of an alert and by default are executed in the system in which the alert occurs. Almost no assignments are made in the standard SAP system; however, there are several predefined auto-reaction methods in the monitoring architecture that you can assign to any MTE classes.

As of SAP Web Application Server 6.10, you can also define central auto-reaction methods. The auto-reaction methods are not started in the system, in which the alert occurs, but rather in the central monitoring system. In this way, it is possible for reactions to events that occur in monitored components to be performed immediately in a central location.

If problems occur during the execution of auto-reaction methods, it can be useful to check the status of the auto-reaction methods. You can find out the definition and runtime status of an MTE by choosing Display Details (). This method is very time-consuming for obtaining an overview of the auto-reaction methods for the MTEs of an entire monitor. The technical view Status Autoreaction exists as an alternative for this purpose.

In this technical view, you can also manually start the auto-reaction method for any MTE to which an auto-reaction method is assigned. To do this, choose the relevant MTE by double clicking it. This is especially useful during test phases.

Note that when you start an auto-reaction method manually, it runs under your user name and therefore also under your authorizations. As the method runs under the SAPSYS user when it is started automatically, and this user has only very few authorizations, you can assume from a successful test with a manual start that the method will also run without problems during normal operation.

Procedure

To activate the Status Autoreaction technical view, follow the procedure below:

...

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. Choose Views ® Status Autoreaction. The alert tree now no longer displays the alert status and reported values, but information about the auto-reaction methods of the MTEs of the monitor.

Result

The view displays the following information for the active monitor about the auto-reaction methods that are assigned to the individual MTEs:

· Assigned auto-reaction method

· Type of the auto-reaction method; depending on the definition of the method, the following types are possible:

Type	Description
[Central Autoreaction]	The method is defined as a central auto-reaction method.
[Running in Autoabap]	The method is executed in the dialog process.
[Running in Background]	The method is executed in the background process as a job.
[???]	The method type is not yet known; this type is only displayed for a short type after the method is created.

· Definition status of the method:

Type	Description
PRESET	The method has just been created; the properties of the method are still determined by the settings in the data supplier. After a maximum of five minutes, the system reads the current settings of the method from the active properties variant and the definition status is changed.
DBSET CEN_SET WPSET	The settings of the active properties variant are already included in the properties of the method in this status. However, as it is not in the CHECKED definition status, you should check whether the method is released as an auto-reaction method.
CHECKED	The method is released and can therefore be executed as a local auto-reaction method.
CEN_CHECKED	The method is released as a central auto-reaction method.

· Runtime status of the method:

Type	Description
Ready	The method is ready for the next execution; however, this is not yet due.
Run required	The method is to be executed, however the responsible dispatcher has not yet started the method.
Running	The method is currently running; the color of the corresponding attribute is yellow.
Error Fatal Error	An error occurred during the last run of the method. The difference between the two statuses is that a method in the status Error is started again at the next scheduled run, a method in the status Fatal Error is not. A method in the status Fatal Error is only started again after a warm start of the monitoring segment (see Resetting the Segment to WARMUP Status). The color of the corresponding attribute is red. You can also reset the method status by selecting the corresponding MTE, choosing Display Details (), and, on the following screen, choosing Edit ® Method Status ® Reset ® Select Auto-Reaction Method.

· The time specification after the runtime status shows the time since which the method has been in this status.

· The color of the nodes is not passed upward in the alert monitoring tree. Monitoring objects and summary nodes therefore always have the color Green.

Displaying the Technical View: Threshold Values CCMS

2009-03-04T20:58:00.000+05:30

Threshold values dictate which reported values generate an alert for the node for performance attributes (see Properties of Performance Attributes). To display these threshold values, select the corresponding node and choose Properties. This method is very time-consuming for obtaining an overview of the threshold values for the MTEs of an entire monitor. The technical view Threshold Values exists as an alternative for this purpose. This view displays the following information for the MTEs of the entire monitor:

· Attribute group to which the MTE belongs

· Threshold values of the MTE for which a yellow and a red alert are generated; also the threshold values at which the alert level is lowered again.

· Unit of the reported performance values

· Comparison value that specifies how the value of the performance attribute is calculated from the reported value, such as the last reported value, the average of the last few minutes (smoothing), or the average of the last full quarter hour/hour (average).

· Information, about whether an alert is to be generated when the value of the performance attribute falls below the threshold value or when the value exceeds the threshold value

To additionally display the long help text for an MTE, choose the relevant MTE by double clicking it.

· The nodes are always colored green in the technical view Threshold Values; as it contains no alert information.

· If the properties of the MTE are not specified by the attribute group, but are defined individually for this MTE, the view displays instead of the attribute group.

Procedure

To activate the Threshold Values technical view, follow the procedure below:

...1.Choose CCMS Control/Monitoring Alert Monitor, or call transaction RZ20.

2.Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. The alert tree now no longer displays the alert status and reported values, but the threshold values for the MTEs of the monitor.

Displaying the Technical View: Central Performance History CCMS

2009-03-04T20:56:00.003+05:30

he Central Performance History of the monitoring architecture allows you to save performance values of the monitoring architecture long-term, and to output these values in reports to compare the current performance data with its earlier development.

The system only collects values for the MTE classes that you have selected for this purpose. You do this by assigning MTE classes to Collection and Reorganization Schemata. These schemata contain information about how long, and in which resolution, performance values should be collected. To obtain an overview of this type of which data is collected in the Central Performance History, you required the collection and reorganization schemata that are assigned to the individual nodes.

The view displays the following information:

· Assigned collection and reorganization schema

· Resolution of the collected performance values

· Collection method (see Collecting and Reorganizing Performance Values)

· Time zone of the data collection (if explicitly specified)

Procedure

To activate the Central Performance History technical view, follow the procedure below:

1.Control/Monitoring Alert Monitor, or call transaction RZ20.2.Expand the monitor set that contains the monitor that you require, and choose 3.Choose Collect./Reorg.Schema Assignment, or choose Display Assignments of the Central Performance History (). The alert tree now no longer displays the alert status and reported values, but the assigned Collection and Performance Schemata.

Processing Alerts CCMS

2009-03-04T20:56:00.001+05:30

Purpose

Alerts are assigned methods using the associated monitoring tree elements (MTEs). A method can be a report, a function module, an SAP transaction, or a URL that is to executed as a reaction to an alert. You should differentiate between auto-reaction methods that the system automatically executes as a reaction to an alert (see also Selected Methods of the Alert Monitor, such as an Automatic Alert Notification), and analysis methods that you start manually when analyzing an alert (see Starting Methods).

After you have analyzed an alert and corrected its cause, you no longer need to display the alert in the Alert Monitor: you can complete the alert. This means that it is deleted from the Alert Monitor and saved to an Alert Database. You can display completed alerts from the Alert Database. The Alert Database is also monitored using the Alert Monitor: if the size of the database reaches a defined limit, an alert is triggered. To limit the size of the database, you can reorganize completed alerts.

By default, an alert represents a problem message. You can, however, activate the generation of “green alerts” for selected nodes, that is, an alert of this type for an all-clear or for an explicit message that an action was successful (see Working with All-Clears (Green Alerts)).

Starting Methods CCMS

2009-03-04T20:43:00.005+05:30

Use

Monitoring tree elements (MTEs) in the Alert Monitor and alerts in the Alert Browser are assigned methods. You can call these methods to investigate the status of an alert. For example, you could analyze a component of the SAP system with an analysis method, integrate additional monitoring functions into the monitoring architecture with data collection methods, and use auto-reaction methods if you want the system to react automatically to an alert.

Prerequisites

To be able to start all three method types from the monitor display, you must first activate the maintenance functions. If the maintenance functions are deactivated, you can only start analysis methods. The reason for this is that the manual start of an analysis method is part of the everyday work of an administrator, while the manual start of other methods is only necessary more rarely. Possible scenarios are:

· To obtain the current measured value for an attribute immediately, start the associated data collection method manually. This can be especially useful if the method is only called infrequently (for example, if it is called as a job).

· To test an auto-reaction method, start the associated auto-reaction method manually.

Procedures

You can start the methods from the alert monitoring tree, from the Technical Views or the Alert Browser.

Data collection and auto-reaction methods run in the monitoring architecture either in dialog under the SAPSYS user (which has only very restricted authorizations) or in the background under the user that created the corresponding job. If you start methods manually, these methods run in dialog under your user. The method could therefore behave differently to the way it behaves when started automatically by the monitoring architecture. Therefore, if you want to, for example, test new methods, do not rely solely on the results that you obtain from manual starts of the methods.

Starting a Method from the Alert Monitoring Tree

1.CCMS Control/Monitoring, or call transaction RZ20.2.Choose a monitor from the monitor sets.3.Choose Extras Activate Maintenance Functions.4.Select an MTE in the monitor.5.Node (MTE) or Start Data Collection Method or . You can also start the analysis method by double clicking the node.

Starting a Method from the Technical Views

... 1.Choose CCMSAlert Monitor, or call transaction RZ20.2.Choose a monitor from the monitor sets.3.Choose Extras Activate Maintenance Functions.4.To start a data collection method manually, choose Views Status Data Collector. Choose the node for which you want to start the associated data collection method by double-clicking it, and confirm the following dialog window (see also Displaying the Technical View: Status Data Collector).

5.To start an auto-reaction method manually, choose Views Status Data Autoreaction. Choose the node for which you want to start the associated auto-reaction method by double-clicking it, and confirm the following dialog window (see also Displaying the Technical View: Status Autoreaction).Starting a Method from the Alert Browser...1.Choose CCMS Control/Monitoring Alert Monitor, or call transaction RZ20.2.Start a monitor from the monitor sets.3.Select an MTE in the monitor display.4.Open Alerts and then Display Alerts. 5.Select and alert, and choose EditNode (MTE) Start Method Start Analysis Method or Start Auto-Reaction Method. You can also start the analysis method by double clicking the node.See also:Defining, Releasing, and Transporting Methods

Completing Alerts CCMS

2009-03-04T20:43:00.001+05:30

When you set an alert to completed status, it is removed from the active alerts that are displayed in the Alert Monitor and the Alert Browser. Set alerts to completed as soon as you have solved the underlying problem or have determined that the alert was triggered by a temporary problem and can be ignored.

When you set an alert to completed, it is saved in the Alert Database. The alert is retained there until you delete it by reorganizing completed alerts.

Procedure

Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

Expand the monitor set that contains the monitors that you require and choose Start Monitor.

Call the Open Alerts view for this monitor.

Start the Alert Browser by selecting a node in the monitor and choosing Display Alerts.

In the Alert Browser, select the Alerts that you want to set to completed.

Choose Complete Alerts.

See Also:

Automatically Complete Alerts