SAP Library - Find your answers

BTCTRNS1 - Suspend all Released Jobs
Released Jobs will have the status Released/Susp. in transaction SM37.

BTCTRNS2 - Reverse Suspend for all Released Jobs

e-Mail The Back Ground Jobs

How to setup a background job after its completes and sends an e-mail to the external outlook?

In the client already using SAP SBWP and we are sending the e-mails to the external id, and a background job is running for every 5 minutes .

How to trigger it to the external mail?

What is the general procedure what you do if the task has been given to you after the background job is run it should send an e-mail to the external e-mail.

First you need to create a distribution list via tcode SBWP. In the distribution list, write the external email address. Choose the recepient type into "Internet Address".

In SM37, if you double click on the job, you will see there a "Spool List" button.
Click on that spool list button, then key in the newly created distribution list in the recipient field.

When you set the job up you can specify an external email in the spool list recipient section.
It should look something like the below. There will be some mail side setup required depending on your environment and what is possible.

One the job process is completed, the email will be send out to the recipient.

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

How to setup a background job after its completes and sends an e-mail to the external outlook?

In the client already using SAP SBWP and we are sending the e-mails to the external id, and a background job is running for every 5 minutes .

How to trigger it to the external mail?

What is the general procedure what you do if the task has been given to you after the background job is run it should send an e-mail to the external e-mail.

First you need to create a distribution list via tcode SBWP. In the distribution list, write the external email address. Choose the recepient type into "Internet Address".

In SM37, if you double click on the job, you will see there a "Spool List" button.
Click on that spool list button, then key in the newly created distribution list in the recipient field.

When you set the job up you can specify an external email in the spool list recipient section.
It should look something like the below. There will be some mail side setup required depending on your environment and what is possible.

One the job process is completed, the email will be send out to the recipient.

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.

Keyword: BASIS
Title : Introduction to Background Jobs

Keyword: BASIS
Title : Defining Background Jobs

Suspend/UnSuspend Released ABAP Jobs

BTCTRNS1 - Suspend all Released Jobs
Released Jobs will have the status Released/Susp. in transaction SM37.

Keyword: BASIS
Title : Creating Background Jobs - Job Steps

We cannot stop the active background job, however we can pause the active jobs. Goto SA38 and run the report "BTCTRNS1" to suspend/deschedule all the scheduled jobs,ie Move Jobs with Status "Rescheduled due to Upgrade",use program BTCTRNS2 Release jobs with status "Descheduled due to upgrade".

Symptom

Corrective action

Increase the swap space or decrease the R/3 Extended Memory.

If necessary, increase the roll area.

Check if the maximum process size (operating system parameter) is sufficient.

See: Swap Space Bottleneck During R/3 Operation

Background Jobs:

Background processing is used to: Reduce the load on the dialog processor, as the dialog wp duration is limited.

You can define and schedule background jobs in two ways from the Job Overview:

• Directly from Transaction SM36.
  
• The Job Wizard : To use the Job Wizard, start from Transaction SM36, there you'll find Job Wizard

1. Call Transaction SM36.
2. Assign a job name. Decide on a name for the job you are defining and enter it in the Job Name field.
3. Set the job’s Priority or Job Class

• High priority: Class A
  
• Medium Priority: Class B
  
• Low priority: Class C

• For the system to use system load balancing to automatically select the most efficient application server to use at the moment, leave this field empty.
• To use a particular application server to run the job, enter a specific target server.

4. If spool requests generated by this job are to be sent to someone as email, specify the email address. Choose the Spool list recipient button.
5. Define when the job is to start by choosing Start Condition and completing the appropriate selections. If the job is to repeat, or be periodic, check the box at the bottom of this screen.
6. Define the by choosing Step, then specify the ABAP program,external command or external programe to be used for each step.
7. Save the fully defined job to submit it to the background processing system.

There are 6 status for background jobs


Scheduled - The job has been created, but it has not yet been assigned a starting time.
Released - The job has been created and it has been assigned a starting time.
Ready - The job is ready to be processed.
Active - The job is being processed.
Finished - The job has finished successfully.
Cancelled - The job did not finish successfully.

To check one's own Background Job's go to the TCode "SMX"