I need some basic information on SAP: What database platforms are supported? What operating systems are supported? And what kind of support is there for a mobile environment?

Have a look at http://service.sap.com/platforms*. All database and operating system platforms supported by SAP are listed there.

* Authorization required to access the SAP service marketplace.

How many backups are required from preparation to end of an upgrade and at which phases?

Take your daily online backups during the uptime phases as you would normally do. Please note that your system is still being used productively and you cannot afford data loss. In case of disaster, you will restore the daily backup, roll-forward up to the crash and roll-back the upgrade to re-start it from scratch. A backup is definitely needed at the beginning of the downtime phases as it is the point of no return. Another backup is needed before the go-live.

How can I clone an SAP system for a sandbox purpose? For example, our Enterprise production environment runs on 4 application servers and an Oracle database all on AIX OS. I can restore a copy of the database from a backup and copy the /usr and /sapmnt directories from one of the app server to the target sandbox, but what files should be edited/deleted to have the new system run on its own?

Congratulations -- restoring your database and getting it up and running is the hard part.

The rest should be easy.

The following needs to be changed after restoring the SAP file systems:
• The instance, default and start profiles (they reside in the profile directory).
• You need to copy the environment files from the adm homedirectory from your source system. The environment variables values should be changed accordingly.
• Copy and modify the database configuration files (init.ora, init.dba … )
• Don't forget to set the port names and numbers in the services file

What is the best way to create indexes in SAP? I want to avoid problems such as the index not being created in the database level. Should I first create the transport for an index and then create it in the database level?

Customer objects should always be created on the development system and transported to the other systems in your SAP landscape.

Our development system is way out of sync, both configuration- and data-wise. We would like to refresh our development system from the production system. How can this be accomplished? What things we need to be aware of? I know we can restore the production system (PRD) from from tape to the development system (DEV,) but that will wipe out everything including transports, notes history, etc

The system copy guides can be found at http://service.sap.com/instguides*. Different backup/restore procedures exist for the different databases supported by SAP.

If you restore PRD over DEV, it will wipe out everything. You should therefore find a point in time in which development projects finish and are brought into production. You should only re-create DEV from a backup of PRD if both systems are more or less in sync or if your development teams agree that certain developments are lost.
* User authorization needed to access the service marketplace.

What SPRO stands for?

SPRO stands for SAP Project Reference Object
.
It is used to configure the setting as per your client requirement by using the standard setting present in the system. This where you can do all the SAP configuration work. It is also known as the Configuration Menu.

What is full form IMG and SPRO? How are they different from each other?

IMG :- Implementation Guide.
SPRO :- SAP Project Reference Object.

SPRO------>IMG.

Type in the T-Code SPRO under That got to Main Menu which is IMG.

SPRO is basically used to organize the consultant customizing during the SAP Project Phrase.

How to close a window?

If we want to stop a transaction in the middle, Right click on the end button (X) on the top right corner of the window. Then select "stop transaction".
As we dont have STOP icon as we have in WINDOWS, this will help in the same way.

Its a very small tip, but will help a lot.

Tips by : Bhaskar

Name two ways to start a transaction.
- Dynamic Menu
- Command Field

Why do you create user-specific parameters?
They supply defaults to R/3 fields. If a field is indicated, the system automatically fills in default value. Depending on the field definition, the entry can also be replaced with a value entered by the user. (Concept of PARAMETER ID)

Name the three different kinds of messages in the R/3 system. What is the difference between them?
A message can have five different types. These message types have the following effects during list processing:

A (=Abend):
The system displays a message of this message type in a dialog window. After the user confirms the message using ENTER, the system terminates the entire transaction (for example SE38).

E (=Error) or W (=Warning):
The system displays a message of this message type in the status line. After the user chooses ENTER, the system acts as follows:
While creating the basic list, the system terminates the report.
While creating a secondary list, the system terminates the corresponding processing block and keeps displaying the previous list level.

I (=Information):
The system displays a message of this message type in a dialog window. After the user chooses ENTER , the system resumes processing at the current program position.

S (=Success):
The system displays a message of this message type on the output screen in the status line of the currently created list.

What is a data dictionary or repository?
Central catalog that contains the descriptions of an organization's data and provides information about the relationships between the data and its use in programs and screens.
The data descriptions in a Data Dictionary is also called metadata, i.e., data that describes other data.

The ABAP/4 Dictionary stores system-wide data definitions. When you create a new data definition, the Dictionary tool does all the processing necessary to create the definition. You can use the Dictionary tool to look up the "definition" of objects in your R/3 System.

What is a matchcode?
Comparsion key. A matchcode allows you to locate the key of a particular database record (e.g. account number) by entering any field value contained in the record. The system then displays a list of records matching the specifications.

If you want an end user to see a specific menu after logging on the R/3 system, how could you do that?
User maintenance transactions allow the system administrator to create and maintain user master records. This includes the generation and assignment of authorizations and authorization profiles.

Is there a way to determine the amount of data in a client for a given company code (client size by company code)?

Yes there is -- have a look at OSS NOTE 489690: CC INFO, copying large production clients. You can also determine the size and the storage requirement of your clients with reports RSTABLESIZE or RSSPACECHECK (see also note 118823).

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?

The start conditions of a job can be time based or event based.
Time based:
Immediate
At date/time On a chosen workday (defined as a certain workday per month)

All time-based start conditions can be periodic. That is, a job can be performed at regular, defined time intervals. Days that are not workdays can be treated as exceptions.

Event based:
After event (optional parameters can be used to further specify events) These can be periodic. That is, the job can be triggered every time the event occurs.
After job (this can depend on the status of the previous job)
At change of operation mode (for example, between day and night)

To monitor jobs, call transaction SM37.

From the job overview, you can navigate to various detailed job-related views:
The job log enables you to monitor the progress of a job.
The spool list contains the output of ABAP programs, if any.
Job details include the job definition, execution time, and background work process number.

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.

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..

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.

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.

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

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

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

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.

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

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.

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.