Thursday, 24 January 2013

Some knowledge on sap workprocess



1. DIALOG WORK PROCESS

Parameters
rdisp/max_wprun_time=600 to 1800sec
rdisp/wp_no_dia

Monitoring Dialog Work Process

SM50-Local Instance (Central Instance):- To display the list of process configured on that instance.
SM66-Global Instance (Including Central Instance and Dialog Instances)

Dialog Process Screen
No, Type, PID, Status (Running, Waiting, Holding, Terminated/Stopped, Ended), Reason (Sleep, Private, Enque mode), Start, Err, Semaphore, CPU, Time, Report, Client, Users, Action, Table.

Using DPMON we can monitor the status of Work Process at OS Level

2. BACKGROUND PROCESS

Background Job Classes
  1. ClassA- High Priority
  2. ClassB- Medium Priority
  3. ClassC- Low Priority

SM36- We can Define Background Jobs
SA38- We can create variant.

Variants are stored in Table TVARV.

Job Status
1. Scheduled, 2. Released, 3. Ready, 4. Active, 5. Finished, 6. Canceled.

Background Job Steps
  1. ABAP Program
  2. External Program
  3. External Commands
Using above Programs we can define Background jobs

Background Job Mechanism
When the dialog user defines to run a job in the background it is entered into the tables TBTCT and TBTCS

TBTCS (Background processing time schedule table)
TBTCT (Compare value for batch job selection)

Background job scheduler runs for every 60sec or the time specified by the parameter rdisp/btctme=60sec
rdisp/wp_no_btc

Monitoring

SM37- We can monitor Background jobs
SM62- It’s used to display SAP events which will be triggered in the Background by using SAPEVT.
SM69, SM49-External Commands
SM64- To trigger the event in the Background

3. UPDATE PROCESS

SAP TRANSACTION: - It consists of multiple transactions which are handled by different Dialog work process these are updated in Temporary tables. Update process reads the Temporary tables to update the Database based on Transaction Id.
Each Transaction is Logical Unit of Work (LUW).

LUW: - It’s a Transaction which can be committed or rolled back

Types of Updates
  1. Local Update
  2. Asynchronous Update
  3. Synchronous Update

Types of Update Process
  1. V1 Update- High Priority
  2. V2 Update- Low Priority
  3. V3 Update- SAP Reserved
There should be at least one V1 update process defined for every 5 Dialog process

Dialog Process updates each dialog step tasks in temporary tables. These are VB* tables and each of them
VBHDR (Header):- It stores header information
VBMOD (Modules):- These are used to update the transaction.
VBDATA: - The exact data to be updated.
VBERR (Error):- The errors that are occur during the update.

Transaction Id is generated from “NRIV” table (Number Range Intervals)
Monitoring
SM13-We can monitor Update process
SM14- We can activate and deactivate Update process
Update Status
Init, Run, Auto, Error (Ora1631, 1632, 1653, 1654, 255, 275, 1555, Deadlock, Number Range Problem, Support Packages or Notes)

Using following Transactions we can get the granular information about Update Failure
SM21, SM37, ST22, SM13, SM50, SM66


Update Parameters

  1. rdisp/vb_stop_active= 0 or 1:- Set to “0” so that update can be deactivated. If the value is set to be “1”update can’t be deactivated
  2. rdisp/vbdelete:- This parameter delete the old update requests based on number of days. Default 50 days (which are older than 50 days it will delete).
  3. rdisp/vbmail:- It’s used to send an email if update throws an error. This can be viewed in “SBWP” (SAP Business Work Place). Based on user
  4. rdisp/vbname:- Name of the server where updates are processed.
  5. rdisp/vbreorg=0 or 1:- Use to delete the incomplete the update request “0” for Not Delete, “1” for Delete
  6. rdisp/vb_delete_after_execution:- It’s used to delete the update request soon after the execution of update. Set it to “1” for delete record and “2” for not deleting
  7. rdisp/wp_no_vb

4. ENQUEUE PROCESS

It’s used to communicate to obtain a lock while updating a record.

Enqueue time will be 1m/s to 5m/s for Central Instance and 100m/s for Dialog Instance

SM12:- Monitoring Enqueue locks. It displays lock arguments based on Table name, Client and User name (Lock arguments Time and Table)

Enque Problems

  1. Lock Table overflow
enque/table_size=4 MB By Default ( We can increase up to 100 MB)
  1. Enque Time Increase
rdisp/wp_no_enq ( Increase enqueue work process from 0 to 100)
  1. Dead Locks
SM12:- Releasing locks
SM04:- for ending the user session.


5. SPOOL PROCESS

It is only process which is used to output the documents to the printers, fax, Email, etc.
TemSe: - (Temporary Sequential objects) it’s nothing but spool request. It will store spool request up to 32,000 to 99, 000.
rspo/spool_id/max_number=32000 to 99000
rdisp/wp_no_spo

Parameter
rspo/store_location =g or db (To store the  spool request at OS level or Database level)
g= OS Level (TemSe Resides in Global Directory) Spool size is small (Around 300MB) Path= \usr\sap\<SID>\SYS\global

db=Database level (TemSe resides in these tables TST01, TST03)

TST01:- It stores the objects and details of spool requests (Author name, No of Copies, Name of Printer etc)
TST03:- Spool Data to be printed

Spool process reads TemSe to generate out put requests. Out put request depends upon the Access Methods
  1. Local Access Method:- Spool process and Host spool resides on the same system (C for windows, L for Unix )
  2. Remote Access Method: Spool process and Host spool resides on two different machines (S for windows, U for Unix)
  3. Front End Printing:- Printers are directly connected to end user systems (F for all)
rdisp/wp_no_spo_fro_max=2 (if 10 spool work process are available 2 will be set for front end printing)

Spool Server: - The server with at least one spool process is called as spool server. It can be Logical (For Fail over and Load balancing of Printers) or Real servers.

SPAD: - For defining the Printer (Output device) and the Spool Server (Logical or Real).

Monitoring
SP01:- It displays the list of spool request (Based on Username and Date Time)
Status (-, +, Waiting, In Process, Printing, Completed, Problem and Error)
SP02:- It displays Individual users spool requests
SPIC: - Spool installation Check use to check spool devices and pending requests
SP12:- TemSe Administration to check memory allocation objects and performs the TemSe consistency check

No comments:

Post a Comment