SAP Backgroud Job

Background jobs, which are primarily used to run programs that need to process large amounts of data without requiring interaction. Personally, it is not difficult to create, configure, and monitor background jobs easily. Background Job management is the most difficult solution to trade-offs, system load regulation. Out-of-control background work often brings catastrophic performance problems to the system, and also leads to the risk of rights management, resulting in a loss of benefits and potentially confusing processes. So personally, it should be carefully analyzed first before creating a recurring background job. For example, a report that is clearly biased towards OLAP type, if it can be implemented with BI, why persist in the production system to run a long period of background work. This is highly likely to be a serious recurring performance issue. Again, for example, the user is authorized to create background jobs, resulting in background jobs out of control, when the business is busy, because a large number of background jobs caused by the entire system, will cause real economic losses. For example, the background work arrangement unreasonable, energy resources and important background work directly or indirectly arranged to the same time period, then will inevitably affect the operation of the process.

Explain the SAP background job in detail. SAP's background job can be started in a timed manner, or it can be triggered by an event. The background job contains one or more steps, each of which contains the calling program, the external shell command and the external program, as well as the caller and the variable, and the printing parameters can be defined. Background job name often need to follow a certain naming rules, used to clarify the background of the importance of the job, how to start, the role and so on. We often use SM36 to create background jobs, (or SM36 to view SAP standard background jobs), to monitor and manage background jobs through SM37.

Background jobs are scheduled, released, Ready, Active, finished, canceled six states. You can also specify which server groups to execute (the server group that the background job executes can be configured with Sm61). The job of the scheduled state is created but not yet release, and the job of this state does not run. The job of the released state is started when the start condition is met, and ready is when the start condition is met, the system begins to assign the job, but has not yet allocated an intermediate state of the appropriate background process, and active represents the job is running, in other words, Its corresponding background process is running the job of a step program; Finished represents the job and all the step is completed successfully. Canceled on behalf of the job in a step to run the process of abnormally aborted.

SAP job information exists in a series of table tbtc*. Sometimes, a job corresponding to the process is aborted, but the status information in the table is still not updated, the job is the active state, and the actual process is not running, then we only need check status, you can manually fix the status information inside the table.

If you want to analyze the job cancel reason, you should check job log, often job to run is the ABAP program, so the job cancel is often accompanied by the dump generated, this time, double-click the job log entries, you can jump to the corresponding dump. In addition, sometimes the job cancel that is caused by the process being aborted is not written to the log and needs to be analyzed in conjunction with System log. The job log is stored in the \usr\sap\sid\sys\global log file <client Nr>joblog, and in some specific cases the log file access problem causes all job Cancel to occur on Di, It is said that it may be NFS instability, which I am not sure.

The trigger EVENT is basically a function module bp_event_raise or Sapevt.exe.