Support

May 28, 2016 | Author: Aravind Varma | Category: Types, Instruction manuals
Share Embed Donate


Short Description

Support for computer architecture and gui...

Description

SUPPORT R/3 Architecture:-

Presentation layer:It is used to present the user requests; GUI is installed to take the user i/p.  SAP designed SAP GUI to handle the requests that can be routed to various SAP components.  There are 3 types of GUI available. 1) SAP GUI for windows 2) SAP GUI for java. 3) SAP GUI for HTML.  SAP GUI for windows is used for windows O.S.  SAP GUI for JAVA is used to support all the operating systems that support JRE [java runtime environment].  SAP GUI for HTML is used to provide the SAP services over internet / intranet. SAP GUI has the following Advantages: It supports almost all the available languages in the world [we need to install additional languages on the server]. By default English and German are installed.  We can change color, fonts, themes t here by we can say that it is ergonomically designed.  Single GUI to support all the SAP components [SAP, CRM, SRM, XI, EP, BI] CRM -> Customer Relation ship management. SRM -> Supplier Relation ship management. SCM -> Supply chain management.

BI -> Business intelligence.  Function keys F1 provides field help and F4 provides list of possible values. E.g.: Currency and country. Provides to specify the name of the country and currency.  Frequently queued inputs are stored as parameters.  GUI supports all the operating systems and Databases.  SAP GUI has various versions. [46C, 600, 620, 640, 46D, 700, 710]  It has its own patch levels.  SAP GUI is downward compatible i.e., higher version of GUI can access lower versions.  SAP GUI is accessed over low speed connection when the n/w bandwidth is slow. Low speed connectivity disables OS suppress expensive GUI components like logs, pictures etc.  SAP GUI provides command window to execute the transactions directly. GUI also provides menus to access the functionality.  It is used to create favorites. Favorites are logon specific and they are displayed on any desktop for that user favorites are stored in DB. Installation of GUI:SAP provides presentation server DVD along with the SAP s/w.  We can download from WWW.SAP.COM

[It requires SAP partner / sap

customer, SAP certification SAP EMPID]  SAP provides installation tool SAPINST. SAP inst is used to install SAP components.  SAPGUI requires around 200MB of space to install on windows [It depends upon the type of components we choose.]  SAPGUI for HTML doesn’t require any space.  Navigate to presentation server DVD. Select setup.exe or SAPINST.exe [for windows] Use. /sapinst [on Non-windows or UNIX]  Double click on it [based on version] Specify the path c:\, d:\, d: -> windows. Specify the path /usr/opt -> UNIX.  Click on next to select the GUI components.

 Select the GUI components.  Click on install. Configuring SAP GUI:SAPGUI, SAP logon pad icons are installed on the user desktop. -> We need to configured various SAP components [SCM, SRM, CRM, BI etc] -> Click on SAPGUI icon.

-> Click on New to add the entries into SAPGUI.

-> Specify the details and click on Add to add the entry. Initialization files:1. Saplogon.ini. 2. SApmsg.ini 3. Saproute.ini 4. Sapdoccd.ini 5. Saprfc.ini Saplogon.ini:It consists the entries of all the components. It is initialized to display all the entries when user clicks on SAP GUI it maintains the details of each entry, if this file is lost all the entries are lost.

Sapmsg.ini:It is initialized when logon load balancing is configured. It is used to identify the last loaded server in the landscape. Saproute.ini:It is initialized to access the server across the routers [across the n/w] Sapdoccd.ini:It is initialized when SAP library is configured. Saprfc.ini:- It is initialized when to communicate b/w servers. All there initialization files are resides in C:\windows Sapmsg.ini:Sapmsg.ini contains the details of message server. Message server is the agent which is used to route the request to the least loaded server. Presentation Server: SAP GUI It is used to communicate with SAP systems. -> Click on SAPlogon.exe [windows] ->. /sap logon on [UNIX machines] to open up sapgui. -> This executable reads from SAPLOGON.INI and display the GUI along with entries. -> Entries area nothing but servers. -> In every company it is advised to create one saplogon.ini and populate it to users through a shared file server / mail. -> The naming conventions of the entries should be meaningful. Creating Entries:Logon to SAPGUI Click on new -> Select user specified system and specifies description [Application server.] -> Presentation server -> Application server –> DB server. -> System number is a 2 digit number varies from 00 – 97 -> System ID is three characters ID like [DEV, QAS, PRD, TES, MIG] -> Router string:- Provide the ID address of the router. Save the entries. -> The creation of the entries is only performed under -> The following circumstances:1) During Implementation 2) During upgrade. 3) During induction of new application server. Otherwise just distribute saplogon.ini as a basis consultant.

Installation of presentation server:- 1. Download the current version of GUI from www.service.sap.com or from SAP DVD kit. 2. Navigate to GUI folder and click on Setup.exe / sapinst.exe on windows ./setup on UNIX. 3. Click on next to display the available components. 4. Select the components and click on install. Installation Types:Now let us say I need to install on Scenario 1: 1 – 10 users. Copy the DVD into the files server and access the file server to install or use DVD to manually copy and install manually. Scenario 2: 10 – 100 users. Create a batch file pointing to file server and send the screen shot for self installation. Scenario 3: 100 – 1000 users. Use third party windows SMS or SAPGUI installation server. It automats the installation from a central shared system. Adoption:1. Command Window:It is used to take the transactions as input. It is the fastest and easiest way to navigate to the programs. 2. Menu based:It provides menus to access the functionality, but consumes dialog steps. [Dialog step means it is a keyboard enter or a mouse click or a screen change.] -> /n current screen to main menu. -> /n open the. -> /o opens the txn in another screen. -> /NEX exits the screen. -> /need pops up a message to logoff. The GUI screen provides various icons [Create, change, Display, delete, lock, unlock, copy, save, print, back (moved to old screen) transport, search, create session] -> Make use of legends, which gives description about status of icons. Note:- You can work simultaneously on 6 windows at a time.

Handling End user Front end problems:- [GUI problems] -> Host name not known / host system is not reachable [cannot ping to the system]. -> Partner not reached “WSAE connect Refused” checks the hostname and port number. Probably ports might be blocked at firewall / proxy. -> User complains the GUI request is timed out and could not connect to the system. -> Identify the detailed error, check n/w band width, n/w connectivity and select the option low speed connections. -> User is able to connect to GUI, but GUI displays special characters like [! @ # $ % ^ &] check the -> Could not display the logged on language…. Select the language [select the check box internationalization]. -> GUI could not open up to logon check for virus. If required we may need to reinstall GUI. -> How do you install GUI from off shore to onsite? -> Use remote desktop, Net meeting, team viewer, go to my pc, pcay where tools to install GUI remotely. Problems with SAPGUI:-> Patch levels difference: a) Application server has updated at o/s level executable b) Database at o/s level executables, DB patch. c) R/3 system patches / support packages. -> Unable to add entries. a) No write permissions on SAP GUI folder. [SAPlogon.ini] b) Option is set to not editable or user uses logon pad. -> GUI installation files corrupted. [Re-install GUI]. -> Menu functions or menus are not available. a) Check authorization. 1) Patch level differences. Q: - The system is working fine until yesterday, but I am unable to logon today? A: - These can be patch level differences at presentation server, application server [o/s, executables (kernel) and database (o/s executables (kernel)) and R/3 patch level update. 2) Unable to add entries in the SAPGUI. No write permissions on GUI folder or user is provided with SAP logon pad or the option is set to non-editable mode in GUI.

-> We do not want the end users to changes the entries on their own, if there is any changes in the application server names, port numbers, we will notify (populate) the respective saplogon.ini. -> Update GUI patch level check GUI version. 3) Libraries are missing. If you uninstall any services in the user front-end the SAPGUI required Dll’s might be un-installed or it can be due to virus. Re-install GUI by taking he backup of SAPlogon.ini. 4) Menus are not available. Check the Authorizations [permissions for the users]. 5) GUI display special characters It can be due to virus, lower patch levels, and update the patch level. 6) I couldn’t login to Chinese, Korean etc languages even though languages are installed. Check the option internationalization in the 118N but in older version, you need to select the character set [Chinese / Korean / Japanese etc] 7) Could not connect to GUI with error Network failure, connection broken, partner could not be reached. Check the N/W connectivity using the command ping you are disconnected from the n/w, or your servers are not reachable. 8) Load-program-not found... [Syntax error]. The program that allows you to log on is having problem with syntax. Identify the error and error code and apply the relevant patch if it could not be resolved write to SAP with high priority. 9) GUI is not compatible to access the SAP component. GUI is down words compatible, i.e. higher version can access lower version components. I.e. GUI 7.10 can access 7.00, 640, 620 components unless there is a bug in the specific release. 10) We cannot get screen painter, business explorer, business analyzer…. These are selected during installation reinstall the GUI by selecting the missing components. Some components depend on Microsoft office (Excel) so we may need to update Microsoft office. Q: - I could not login to the system? A: - Check if the client exists. -> Go to SCC4 and check the availability.

-> It exists but the entry might be deleted. 2) Check the username exists -> Go to SU01 and check for the username. -> User exists but user is inactive or locked due to admin reasons, locked due to incorrect logins, user account validity is expired. (Contract users). 3) Password mismatch. 4) The logged on language is not installed. -> We can set various parameters for users and passwords that is a part of security. Application Server:-

-> Application server is used to handle the user requests. -> Application server has its dispatcher to mange the system, [keeps the requests in queue, assign the processes etc]. Dispatcher:There will be only one dispatcher for each instance; dispatcher has its own post [3200]. -> It is used to handle the user requests and assign them to freely available resources based on FIFO [first in first out]. -> Dispatcher manages all the work processes and keeps their status [waiting, running etc] Work process:It is process which actually interprets the user requests using its task handler [TSKH]. Task handler consists of three interpreters:1) Screen Interpreter:- It is used to interpret the screens that are in the user requests and convert then to understand format [identify the user request what screen it is like purchase order creation, display, delete, modify]

2) ABAP interpreter:- It is used to interpret the user inputs based on the logic [if, else conditions]. And helps to define the SQL statements. Ex: Reads the user inputs and based on the inputs process them. -> User login to us site, state: Washington It helped to finalize the inputs to define SQL Select * from population where country = “US” and State=”Washington” and year=’1947’ and gender = ‘male’, age>18; 3) SAL Interpreter:It interprets the SQL commands and define the SQL statements that needs to be sent to database. -> The SQL statement that is defined is based on OPEN SQL. -> Open SQL is the database language used by SAP. -> In order to convert open SQL to native SQL, we need native DB client installed on application server. -> Native SQL is the language used by the database. Oracle -> PL / SQL SQL Server -> Transactional SQL [T-SQL]. SAP -> open SQL. Advantages of Native SQL:-> It communicates with database without any DB client there by avoiding conversion from open SQL to Native SQL. Disadvantage:-> Loss of independency as it is particular to one database. -> Each statement hits the database because the frequently used data is not stored in Native SQL. -> Open SQL: It is independent of database, and it costly for the first Time and later it is stored in buffers which will reduce the response time drastically. Buffers:This is a temporary memory area where the frequently accessed data is stored. -> There are various buffer elements which will be discussed during fine tuning of the system. DB Client:This is used to communicate with the database using there own protocols. Oracle DB client -> Oracle database server. SQL client -> Microsoft SQL server.

Workflow-1:1) User sends requests using SAPGUI. 2) The request is sent from presentation server using DIAG protocol. [DIAG stands for Dynamic information Action Gateway]. 3) Dispatcher receives the request and keeps them in queue. 4) Dispatcher allocates WP based on free resources and on FIFO. 5) Work process contains task handler to interpret the user request.[The interpretation of logon screen that contains user id, password, client, logon language]. 6) Based on ABAP, screen, SQL interpretation the request is [SQL] compiled to sent to database as the database communicates only in native SQL. 7) DB client connects to the database and handover the requests. 8) The user request is handled by the database processes and the response is sent to the R/3 process. 9) R/3 process identifies the frequently accessed data and stores a copy in R3 buffers. [This data is available to all the users]. Ex. Logon screen home page, SAP menu, logos, 10) R3 work process stores user related information in the USERCONTEXT. User context: It is a temporary work area where user related information is stored. [The information can be user authorizations, parameters, earlier access screens…… etc.] -> The process of copying user related information to user contest is referred as roll-out. -> It will not the content that is buffered in R/3 buffers. It will just point to it. 11) The response is send to the user. 12) User gets the logon home page. Workflow-2: 1) The user wants to crate sales order and executes transaction VA01. 2) The request processes by dispatcher and work process handles it. 3) Work process goes to the user context [Roll buffer or user buffer which is specific to user] and rolls the user related information into task handler. 4) Task handler interprets the user request and it needs sales order screen. 5) It checks in the user buffer and it is available the response it sent to the user [it avoids open to native SQL conversion and database traffic.] 6) The work process Rolls-out by storing the screen [pointing to R/3 buffer]. Workflow – 3:. 1) User fills the details of the sales order / purchase order and submits the request.

2) Request is handled by dispatcher and the work process rolls-in user related information in to task handler to create sales order / PO. 3) Now the buffers are not used because we are going to update the database. 4) Once the record is created or updated, a copy is stored in R/3 buffer again. Dialog Step:The dialog step is nothing but a screen change or act based on keyboard input or mouse click. Types of processes:- DVEBMGS 1) Dialog process:- It is the only process that is used to communicate with users. -> Dispatcher assigns user requests to dialog process only. -> There should be at least 2 dialog processes only. -> Users directly cannot interact with any other processes except dialog. -> As the dialog process is serving end-users the run time should be restricted the maximum run time to execute a task by dialog process is 600 sec. -> The average dialog response time is measured as 600 milli sec to 1200 mille sec. 2) Background process:It is used to run the expensive programs, reports in the background mode [in the non-interactive mode]. -> There is no time limit to execute these jobs. Ex. Payroll run, dunning reports, monthly reports. It will generate pay slip based on other wise it will converted in to PDF format and sent it to all the employees in the company] 3) Update process:Dialog process updates the records in the database temporary tables. -> As per the logical unit of work, if all the txn are committed then update process update the database from temporary tables. 4) Spool Process:It is used to print the documents, it is initialized by either dialog or background work process. These processes write the prints request into Tense. [Temporary Sequential objects]. -> Spool process reads Temse and converts them into printer specific requests. 5) Gateway Process:It is the process which is used to allow the communication b/w systems. It has it own port [3200]. 6) Message server:- It is used to manage all the dispatchers [application servers, instances]

-> When log-on load balancing is configured it is used to identify the least loaded dispatcher and route the user request to the dispatcher. -> Message server assists in getting the locks [While updating the record] from the Enqueu process, it he request is coming from dialog instance. 7) Enque Process:It is used to lock and unlock the records while updating a record. -> It ensures the transaction consistency. SUPPORT It is used to support the runtime environment for SAP systems and it is advantages in the following areas:1) Proactive Monitoring:-> Check the CPU’s, disks, clustering, SAN, backup, log files etc. -> Check the database fill level, file size fill level. -> Check the response time of the dialog process. -> Monitor the status of each process. Note:-> We define proactive checklist to be monitored periodically [hourly, by hourly, daily once or twice] -> This has to be initiated by the consultant to avoid and prevent the bottle neck on the system. 2) Reactive support:Users submit the requests to the SAP basis team in the following ways where the consultant needs to react based on the criticality of the request. a) Telephone requests [provides IVR is available]. b) Fax c) Email d) More familiarized ticketing tool. Ticketing tool:It is based on CRM, where the user submits request and gets a token ID/ticket/case ID/request ID/TT number [Trouble ticket] based on the type of CRM used. 1) Siebel CRM 2) SAP CRM 3) Microsoft navision. 4) Remedy 5) Synergy

6) Clarify 7) HP open view 8) Peregrine. Ticketing tool is and unique ID to identify end-user problems. Priorities:1) Low 2) Medium 3) High. 4) Very high. 1) Low [Normal]:-> End user problem. -> It is only related to that desktop. Ex. User cannot login, GUI issues, probably a new user joined in the company requires end user training. 2) Medium:-> User cannot create documents [Do, Invoice, billing delivery] Ex. Authorization issues [user does not have roles] access to printer. 3) High:-> Business is affected. [Also called as dollar problem] -> Could not print documents to a printer [sales order, purchase order] -> A group of users could not login. Ex: vendor is waiting for a purchase order to supply goods. -> If PO is not delivered goods are not supplied by effects production->sales->Marketing. 4) Very High:-> Dialog instances are down. -> Most of the business is affected. [It can be due to accidental errors, h/w errors] -> Performance effected. 5) Disaster:- The complete system is down. SLA [Service level Agreement]:It is and agreement made b/w customer and the support partner. -> Except some sensitive issues and financial values the remaining, SLA is open to all the consultants. -> SLA can be of the following types:1) Ticket based That is the company pays to the partner based on number of tickets. -. Customer fix minimum no of tickets i.e. 1000 tickets per month each ticket cost varies from 15$ to 30$. 2) Lum sum Amount:-

-> A fixed Amount to provide the support services. -> We will include in scope and out scope tasks. In scope activities:- Supporting the system regularly - Monitoring - Supporting end user related activities - GUI installation, GUI patching - Printer related issues Out scope activities:- Support packages and patches - Kernel upgrade - Backup restore - Installation and post installation activities. - Connectivity to external devices. [Printer, fax, barcode machine etc) - The out scope tasks needs evaluation there by charged accordingly. Ex: Support package [100$] -> System copy [restore] [150$ - 300$] -> Installation [750$ to 1000$] ->depending upon the component probably a new component like CRM may costs thousands of dollars. 3) Time and material [T & M]:This is used for out scope activities and fixed bit or fixed amount contracts. -> It is calculated based on no of hours / man days incurred on a particular task. Ex: Applying support stack in a 3 system landscape 1. We need to check dependencies. 2. Apply in the sequence [development, quality, production]. 3. We need to provide at least one week for testing the support stack in each system. SLA Timings:- It is calculated based o n type of support [24*7*365]. Priority/severity Response time

Closer time

Ist

Escalation IInd III

CSE

Low

36 hours

72 hours

12

18

24

30

Medium

12 hours

36 hours

4

6

8

10

High

4 hours

8 hours

1

2

3

3

Very High

1 hours

4 hours

1

1

1

1

Disaster

15 min

1 hours

15min 15

15

15 min

Response time:- We need to respond to the customer request or the ticket saying that “We are going to work on the ticket” and assigns yourself to the ticket. Closer time:- Once the ticket is assigned to the user [consultant] we need to ensure that it is closed with in time. -> Response time is calculated based time on date and time of request / ticket and date and time of response. -> Closure time is also calculated as similar to response time. Status of Tickets:1) New:- When the ticket is created by customer the status of the consultant in the team. 2) Assigned:- The ticket is assigned by the team leader to one of the consultant in the team. 3) WIP [work in progress]:- Consultant is working on the ticket. 4) Hold / pending:- The ticket is waiting or approval from the customer [It is not considered for SLA and escalation] 5) Temp fix:- The issue is resolved temporarily Ex: The user could not print the document ask the user to change the printer or ask the user to use the common queues. KOSK – common queue. 6) Finished:- The consultant change the status to finished if the work is completed. 7) Closed:- Customer closes the ticket. Note:- The status changes are notified through email to the customer and PDL [public distribution list]. Types of Supports:1) On-site support. 2) Off shore support 3) Right shore support. On-sit support:- The consultants works with the customer directory or works at data centre. Off shore support:- The consultants works from off shore

Ex: HP, Sinsenatec. -> HP provides off shore services from their Bangalore office. -> Sony provides off shore services from their Bangalore office. But servers are located in Japan. Right shore support:- The consultants are available on shore and available to work either off shore or on-site.

Main line 1. ISDN line [dedicated line] 2. VPN [virtual private Network] 3. Internet Pc any where Go to my pc Team viewer RSA cards -. Random password. 1. Go to office 2. Logon to your system. 3. Check the connectivity If [VPN], ISDN [not required] connect to customer site. 4. a) Check tickets / Inbox. b) Handover from your colleague. 5. Check list. Check list:- It contains the list of activities which needs to perform pro-actively and ensure that system health is maintained as per threshold values.

-> It depends upon company to company and in the schedule [every 1 hour for production system, every 4 hours for pre-production system, weekly once for development system. The following activities are checked:1. CPU utilization. 2. File system fill level [May effects logon problems] 3. Database fills level 4. Work process utilization 5. Users logon report 6. Critical users that who are causing bottle necks problems by using expensive programs, reports, txn, etc. 7. Memory utilization [consider various parts of memory]. 8. Buffer utilization. 9. Backup schedules and monitoring the success or failure of backup. 10. Monitoring the background jobs [house keeping jobs]. 11. Monitoring the interface jobs [data transfer from one system to another system i.e. SAP to SAP, SAP to Non-SAP] 12. Monitor logs at OS level, D/B level and R/3 level. Dialog processing:It is used to process the user requests and initiate background, update, spool processes. On behalf of users because it is only the process that communicates interactively with the user. -> Each instance requires at least 2 dialog work process. Instance:- It is a logical entity that is installed on an application server which has its own dispatcher, work process, memory, buffers etc. -> It is possible to have more than one instance on a single application server provided they are differentiated by a 2 digit instance number. -> Instance number varies from 00 – 97 [98, 99 are reserved for roxting purpose]. -> Dialog process are configured by using parameter Rdisp/WP – NO-dia. -> Each WP requires around 75 to 150 MB of memory on an average. Dialog work process Multiplexing:The dialog work process is not restricted to user but internal server n no of users similarly user is not restricted to a work process but in turn served by multiple work process to complete the transaction. -> The process of serving multiple users without restricting to a user is called as Multiplexing.

-> Each dialog process executes the part of transaction only. -> In order to execute the part of txn, it should be completed with in 600 sec. If not he job is timed out. -> The time out parameter is defined by rdisp/max-wp run-time=600 sec. -> It is a dynamic parameter which can be modified based on the customer requirement. Ex: Pay roll run, monthly sales reports, dunning reports etc. -> The time should not be more than 1800 sec. I.e. 1800/600 = 30 minutes. -> Each dialog work process is used to serve 5 to 10 users and each WP requires around 75 – 150 MB of memory. NOTE:The sum of dialog WP should be more than sum of non dialog WP. -> The dialog WP are monitored using the txn SM50 using executable demon or SM66. -> Dialog process initiates background, update and spool processes. -> It updates temporary tables so that the above processes are executed by reading the “Temp” tables. Monitoring of dialog work process / work process:-> Go to SM 50 or SM 66 txn to monitor the work process. -> It is a regular activity to monitor the processes SM 50 – locally and SM 66 – Globally. -> It is used to monitor the status of WP. * NO: - The WP number (serial number) * Type: - Type of the WP (Dialog, update, Btc, spool) * PID: - Process ID at os level. -> use task manager to check the WP ID [windows]. -> Use ps –ef grep|| dw* [UNIX] STATUS:- The status of the work process. Waiting:- It is waiting to handle the request. Running:- Currently executing the user request. Stopped:- Work process is stopped. Holding:- It is processing the request but hold due to the response from the target system. Terminated:- The process is terminated the status only determines whether [terminated / working] the actual reason for the status is displayed in reason field. Reason:- The reason for the status of work process there are various reason field. 1) Sleep:- The w/p is waiting for a response from the target system. 2) RFC + CPIC:- Waiting for response from extern or system.

3) PRIV:- [private mode] W/P is restricted by the user. 4) Enq.vb.ms.spo:- Waiting for the respective process to process the request. 5)

START:- Start the work process after termination end. We need to specify this option if automatic start after an error is required if it is set number we can root cause the error.

6) ERR:- The number of times work process terminated / C.P.U:- It displays the time [The amount of time taken by the work process utilizes the C.P.U resources. TIME:- The total time of the work process in executing the dialog step. Report:- The name of the report executed by work process. Client:- The client number USER:- The client name who is executing task. ACTION:- The type of active [read, insert, sequential read direct read] TABLE:- The name of the table. What to monitor:

We need to monitor the status of the w/p and ensure that the work processes are in waiting state.



We need to alarm the status is hold/running/stopped with reason private, sleep, etc..



We have the option of killing the work process with core and without core.



We use excel sheet to maintain the system health check.



SM66 it is similar to SM50 but display all the work process globally. It also display’s the memory utilization of the work processes.

Analysis: Go to SM50 or SM66 Select the w/p that is continuously running and double check on it to find the details of the w/p. It clearly demonstrates the SQL statements and the nature of work [insert, read, direct read, physical read, sequential read] Find the expensive w/p [which consumes more time then the threshold value] 600 seconds. Select the processes goes to user info and get the contact details. Call the user to know the significance of the task that is being executed, and if it is the major bottleneck kill the process with [log file] or without core. If you cannot login to the system, use dpmon and identify the name of the user [for communication] and kill the w/p. It is better to kill any user work process instead of restart. Disadvantage of Dialog w/p:

Each w/p execute a part of the transaction. That is complete transaction cannot be handle by a dialog w/p. Any transaction that consumes more than 600 sec is timed out. NOTE:- Above two are advantages in dialog perspective to facilitate the problem is user can not execute long running, time consuming expensive program.

Background W/P [BTCH]:It is used to run the long running, time consuming programs in the background mode during half peak hours without any user interaction. Ex:- Pay role run: Pay role runs in the background and generates page structure, print pay slips [Email pay slips to all the employees]. During reports are the account receivable month and reports, quarter reports, yearly reports. Background process executes the job completely by dedicating to the user request till the completion of the job. It will not out the user request. There are background jobs which runs for days background job are configured by parameter rdisp/wp – No – BTC. There should be at least two background w/p in the SAP system. Background job mechanism:1 User schedules a pay role run using dialog process to run in the background mode during half peak hours with variant. Variant:- It is predefined value which will be populated on the screen during run time. It is also referred as program selection criteria. That is required to run the program. Ex:- Pay role run requires the month, pay role duration. [daily, weekly, fort night, monthly] These variants are stored in table TVARV [table variants] Variants are defined in transaction SA38 or SE38. Go to SA38 specify the program or report name execute to display the selection screen provide the I/P’s and choose the option go to variants and save as variant. When the job is schedule it is stored in the table TBTCT [table background time] and TBTCS A background scheduler SAP MSSY runs periodically for every 60 sec in the dialog mode The time is specified in the parameter. Rdisp / btc time = 60 sec The scheduler reads the background tables and runs them or queue them. Statuses:1. New [schedule]:- The job is defined but the time is not specified.

2. Release:- The job is specified to run at a specified time. 3. Ready:- The schedule time is execute of and the job is ready to be picked up by the scheduler. 4. Active:- The job is being to be executed or the job is running. This task can be displayed in SM50, SM66 and SM37 to know the process of the job. 5. Finished:- We can assume that job is completed successfully. We need to evaluate thoroughly because finished status may also result in abnormal terminations, memory issues, space fill levels etc.. 6. Cancelled:- The background job is cancelled. Dispatcher monitor:When you cannot login to the system use “DPMON” at o/s level to monitor the status of the w/p Use option ‘K’ kill the process based on the time. “DPMON” is an executable in \usr\SAP\SID\sys\exe\run in earlier versions. \usr\SAP\SID\sys\exe\UC\nt 138C in current Netweaver version. On UNIX you need to login as adm to work with dpmon. Defining background jobs:Background jobs are defined in transaction SM36 or in SA38 or SE38. SM36 has various options to define a job. 1 Go to SM36 Specify the job name: [Job class a,b,c. there are three types of job classes.] a. Class A:- It is used to schedule high priority job. These jobs will be executed by class A background w/p only [class A is defined in operation mode] Transaction “RZ03”, RZ04, SM63. b. Class B:- It is used to schedule medium priority jobs that runs periodically Ex:- System housekeeping, performance, statistics jobs. These are executed before the class C jobs are executed. c. It is used to schedule low priority jobs this is the default class. Status:- It is scheduled until you define time. Execute target serve:- To execute the specify the name of the server to execute the job. RFC server groups are used [RZ12] to determine the least loaded background server. Spool lost recipients:- It is used to schedule the output to the printer, Fax, Email, PDL. Start Condition:Immediate: It will be scheduled immediately Date and time:- Specify the date and time to execute.

After job:- The job will be scheduled to run based on success or failure of a predecease in order to schedule the background jobs with various conditions it is not possible using ‘SM36’ SAP recommends and certifies the following tools. 1. Maestro 2. Tidal 3. SAP job scheduler. These tools schedule the jobs with various conditions. But the jobs still can be monitored in SM37. Each company provides training on the above tools. After event:- Events are the programs that are triggered at o/s level by using an executable SAPEVT. It is used to trigger the transports, archiving, data transfer and other financial related jobs. Events are maintained in transaction SM62. SAP defined their own variants which are triggered in the above scenarios. Ex:- While reporting a transport request. SAP_TRIGGER_RDDIMPOP SAP_IMPORT_START SAP_IMPORT_STOP At operation mode:- Operation mode is used to convert the dialog to background and background to dialog dynamically without restarting the system. The job will be triggered during the operation mode. Factory calendar:- Job can be executed either being of the month or end of the month. Job steps:- The job can be defined by using 1. ABAP program 2. External command 3. External program. 1 ABAP program:- Specify an ABAP program with variant. 2 External command:- External commands are defined in SM69 and executed in SM49. These are the commands. Which are executed in o/s level? Ex: Backup, Ping, Listener, Router, TP, SAPDBA 3 External program:- It is used to trigger the executable SAPXPG. SAPXPG is used to trigger the external programs. Background job monitoring:-

-

Go to SM37 to monitor the background job

-

Select the job

-

Click on job log to display the job steps

-

SM37 is used to display background jobs based on job name, username, status, start condition, ABAP program name.

-

Select based on date time and status ready, active, finished and cancelled.

-

Double click on the job to identify the problem if job is failed. If the status is ready for longer time.

-

Check SM50 and SM66 for free background w/p’ s. If the process are freee check for the free dialog w/p. If dialog w/p is free than check background scheduler time.

Analyze the finished and cancelled status:1. File system problems: File could not opened File with old data File is opened but not in the desired format File is filtered or corrupted. 2. The target system is not available; it is available but not enough resources to handle the source request. 3. User ID and password required to communicate the systems. 4. Check if the user ID is active. If active check for password expiring or password locked due to incorrect logon’s or requires a password change for every 30 days. 5. The target system is not allowing any connections due to ports blocked. 6. The program is using expensive reports that require more memory an timed out due to lack of memory. [Increase memory]. 7. The program is terminated with PXA_NO_FREE_SPACE. This is program buffer error. 8. It is terminated with error ora – 1653. Ora – 1653 table space overflow. Resolution:- Add data file or resize data file. 9. Error message ora – 1631, ora – 1632 max extends reached. 10. Ora – 255, 272 Archive struck Resolution:- Increase space in ORA ARCH. 11. Unable to het lock on the record to update dead lock issue. 12. Lock table overflow.

Pausing the BTC job:- Use BTCTRNS1 and BTCTRNS2 to pause and un pause the background job. However we delay the schedule by using parameter rdisp /btc time to maximum. Scheduling background jobs or Housekeeping background jobs -

Go to SM36

-

Set standard background jobs and schedule them to run with default time 1 RSBTCDEL: It is used to delete the background jobs based on job name, user name, and status, older than 10 days. 2 RSSNAPDEL: It is used to delete old ABAP dumps. 3 RSBDCREO: It is used delete old Batch o/p files. 4 RSPO41: Used to delete old spool files. 5 RSM13002: used to delete old update requests and other jobs related to performance and statistics to calculate the work load on the system.

UPDATE W/P Logical unit of work:It is a transaction where it consists of one or more tasks. If any one of the task is failed the LUW is failed. If both tasks are successful then LUW is successful. That is LUW either commits or roll back. It was not be in hanging state. Transaction:- A transaction consists of one or more LUW’s which are committed or rolled back together SAP Transaction:It consists of one or more transaction that can be committed together or rolled back. An SAP transaction is handled by one or more dialog process. The dialog process is a speedy process and needs to commit transaction with in 600 sec. If it commits the transactions in to database main table. The transaction cannot be reverted. That is why SAP uses update mechanism. For the transactions that have more than one LUW there are three types of updates. 1. Local update:- It updates directly on the database some standard job’s uses this mechanism. 2. Asynchronous update:- The dialog process updates the temporary tables with out getting any confirmation from the system. It update’s the temp table’s which can be reverted back. 3. Synchronous update:- Update process read’s the temp tables and update’s the database synchronously. Update mechanism:-

1. User login to the system using dialog process 2. User submit’s request to create sales order, purchase order which consists of more than one dialog step. Ex: A sales order consist of more than 8 dialog step’s that means 8 dialog w/ps are required to complete the transaction. 3. User submits the part of the transaction [dialog step]. As we are going to update user need to lock the record. So that it is not modified by other user. Dialog process communicates with the ENQUE process and obtains a lock on the record that is going to be updates. ENQUE process assigns the locks [SM12] for the entire SAP transaction from the main memory of the ENQUE instance. Dialog process updates the temporary tables asynchronously. Upon commit the transaction no or ID from the number rename buffers [SNRO] issued to user and updated in the temp tables. Update process in herit the locks from the dialog process and foes to the database. Update process now lock the record’s at database level table by table and update synchronously. The database locks are displayed in transaction ‘DB01’. Types of UPDATE work process:There are two types of updates w/p SAP defined three V1, V2, V3 [V3 reserved] V1 and V2 V1 – It is used to handle high priority updates or critical updates V2 – It is used to handle non critical updates. It is recommended to configure at least on ‘V1’ update for SAP system. If V2 is not configured ‘V1’ handles V2 updates. Updates are defined by parameter. 1 V1 – R disp /WP – No – VB 2 V2 – R disp /WP – No – VB2 A thumb rule for each five dialog w/p three should be at least one update w/p. Temporary tables:- These are stored in the database [SE12] 1 VB HDR [update herder]:It consists of the header information like Enque, update program and Transaction. 2 VB MOD:-

Update function module to update database function module specify the logic to update the tables. [One module can update few hundred tables.] 3 VB DATA:The data to be updated 4 VB ERROR:- Update error information. Update Re organization:- Set the parameter R disp / vbreorg = 1 To re organized that is to delete incomplete update request at the start of server. We can also scheduled RSN13002 background job to delete the incomplete update request. Rdisp / Vb _ delete _ after _ execution To delete update after execution SAP recommend using the above background job instead of setting up the parameter. Update Monitoring: [SM 13] Update are monitored in transaction SM13 Updates status are 1 INIT: The update is being initialized update database. 2 RUN: The update running [updating the database] 3 Auto:- If the update is deactivated if the updates are thrown into error states upon activation the update is started with status “Auto” [The updates are automatically initialized] 4 ERR: The update is thrown into error. ST 07: Is used to display the most servers’ total number of users’ w/p’s, total number of users, buffer utilization, memory utilization, component wise users, servers, and w/p. UPDATE MONITORING: Go to sm13 and check the status of the updates we need to check the updates that are thrown into the errors or running. Double click the record and check the low it is not committed on the database due to the following reasons: 1. Programmatically error. 2. Deadlocks (The lock required by one by one user is held by another user vice versa)in this scenario none of the user can commit the transaction we need to release the lock of either one of the user by ending their sessions. 3. There is no enough space in the database (ora 1653,1654,ora16-31,32).

4. A particular module is in the unit stage and locks are released with error message we could not be updates or restart is not possible. Analyze the module which is not updated and refer technical team 5. Lock table overflow. UPDATE DEACTIVATION: When ever there is a problem in the system the updates are automatically deactivated by using the parameter R disp \ VB – stop – active. Reset to 1 Ex: Table space overflow, max extension reached archive struck. During deactivation an email will be sent to the user provided that parameter R disp \ vb mail is set. Go to SM14 and to deactivate update mechanism manually. The active updates will be running or error status Up on activation the updates are moved into auto status If the update does not happened. Go to SM13. Check the information. If update restart is possible select the record repeat update. If the error is due to update deactivation. Go to SM37 update all records. While repeating the update ensure that transaction Consistencies are maintained. If necessary communicate with SAP. ENQUE PROCESS Enque process:- It is used to lock and unlock the records while updating a record. Enque process is configured mostly on the central instance along with message server. In most of the companies these will be only one Enque but depending up on the update frequency we can increase the no of Enque by using parameter Rdisp / WP – No – ENQ Provided the lock table is shared by all the w/p. The lock table is configured by parameter ENQUEUE / Table – size = 4 MB. Which can be increase up to 100 MB? Lock table memory of the Enqueu instance [central instance] Enqueu process is used to logically lock the record at application server lever for an SAP transaction. These are also referred as SAP locks. This locks the complete SAP transaction. It is different from database locks. Database locks are used while updating permanent tables by the update process, which course inherited from the dialog w/p. ENQUE WORK FLOW:-

User request to update an invoice, PO, sales order.

-

Dialog process communicates with Enque process to issue lock on the record.

-

Enqueu process issues the lock based on availability in the lock table and if no lock is issued on the table.

-

Enqueu process should provide the lock with in the 5 mill sec. If the request is coming from dialog instance. The dialog process communicates with message server, message server communicates with Enqueu to lock the record [that needs to be updated] and issue the lock and wise versa.

-

The communication that is Enqueu time should not go beyond.

ENQUE MONITORING:-

Go to SM12 specify the user ID, client and executes to display the lock tables and their arguments. We need to monitor the locks that are older than 12 hrs and include them in the check list.

Process of releasing locks:1. User complaints that he could not update the request due to the record lock y Enqueu process. 2. Go to SM12 and check the lock weather it exits is not. If it exits inform the user that the record is locked by the user who has locked the record. 3. Lock exists but it older than 12 hrs. 4. User again comes back to the update problem saying that we locked user is not in the office and while communicating over mobile we conformed that we did not hold any locks write a mail to the manager. 5. Write a mail to reporting manager, company and table locked user saying that we are releasing the lock or ending the particular session. Get the response from the reporting manager and end the user session and release the lock. Note:- Do not release the locks on verbal approval ensure that you have black and white document. ENQUE PROBLEMS 1. Dead lock situation during dead lock the locks will be pending more than 12 hrs has to be deleted [Depending up on the SOP (standard operation procedure)]. 2. Unable to get the lock even though the records not locked by any other user [SMR] and the Enqueu time is shooting up that is going more than 5 milliseconds and more than 100 milliseconds. In dialog instance. This could be due to Enqueu process over loading. In this scenario increase the no of w/p ENQUE TABLE OVER FLOW;The size of the Enqueu table is 4 MB. If need to increased the Enqueu table size.

Note:- There will be only one Enqueu which is instead on central instance. Along with message server. There will be only one lock table for each instance. SPOOL PROCESS It is only the process which is used to o/p the documents to printer email, fax etc... Spool process is initialized by either dialog or background w/p. Spool mechanism:- Dialog or BKC don’t print directly to the printer. But interm the generates spool requests. Which are later printed by spool process? Work flow:-

1. User uses dialog process to print a document or to print documents [sales order, purchase order, invoices for the week, pay roles of the employees] 2. The dialog or the background generates spool requests which can be stored either at o/s or data base. 3. The storage location can be referred as temse or temporary sequential file. 4. The storage location is determined by a parameter rspo / store – location = G/DB G of o/s level DB for data base. -

G means global which resides in \usr\SAP\\sys\global

-

If it is db it is stored in two tables TST01 and TST03.

-

TST01: consist spool information like name of the author who made the print requests, no of copies, name of the printer etc.

-

TST03: It is consist of Temse data that needs to be printed.

-

The spd requests are read by spool process and convert them into o/p requests.

O/p requests are nothing but the printer specific request. -

The o/p requests are printed either locally or remotely

Storing the Temse at o/s level [G]:- When you have small no of requests ‘G’ is recommended. If the request size is increases it is very difficult to identify them because we don’t have indexes and primary key and foreign key relationships to avoid duplicates. We need to take special care to backup the requests at o/s level. Strong the temse at DB level:- It is used for log no of spool requests. It takes the advantage of database features like indexing, primary key and foreign key relationships. As the tables are included in the database no special case is required to do. Default is database. Access methods:It specifies the process of converting the spool requests into o/p requests either locally or globally., There are two types of methods 1. Local access method 2. Remote access method. 1 Local Access method:It is used by spool process to convert the spool request into o/p request. When the spool requests and then o/p spool resides on the same server. Access method ‘C’ it is used on windows and works with Windows NT print manager. Access method ‘L’ it is used on UNIX o/s. Access method ‘F’ It is used for front end printing that is the printer is connected to presentation server. Front end printing has the disadvantages. a. The printer is specific to the user b. It cannot be used c. The spool process is restricted to the user and can be used only when print request is completed. NOTE:- It is recommended to configure maximum spool process that can use front end printing using parameter. Rdisp / WP – No- spo – Fro – Max = 2/3 The above number can be changed based on available spool process. 2 Remote Access method:If the spool process and the o/w spool resides on two different server remote access method is used. Access method ‘U’ It uses UNIX Berkeley protocol to print the documents on UNIX environment.

Access method S [SAP]: It is an SAP property protocol to print the documents on WINDOW’S may need NOTE: We to initialize SAP LPD [Line printer] on windows on environments to print the documents. NOTE: In the remote access method a spool server [print server] is used to mange all the printers on UNIX environments use command ‘LP’ [line print] or LP STAT [Printing status of the application server]. SPOOL ADMINISTRATION:Use T – code ‘SPAD’ to define printers [o/p devices] spool servers. Spool servers: The server which consist at least one spool w/p is referred as spool server. It is also referred as real spool server. Logical spool server: The server which does not exists physically but used for load balancing or for fail over. Each logical server is mapped to one or more real spool servers. Definition: 1. Go to ‘SPAD’ 2. Click on spool server. 3. Click on change Icon. 4. Click on create. 5. Specify the server name. 6. Specify the server class [Test,, production] 7. Specify the logical server to define a server that does not exist. 8. Specify load balancing if this server is a part of a group. 9. Specify alternate server for fail over. 10. Save the logical spool server save.

Definition of an o/p device: An o/p device is a printer [barcode printer, Scanner, label printer], an archiving device to o/p the document’s

1. Click on o/p devices 2. Click on create. 3. Specify the name of the printer. NOTE:- Name of the printer should be define the accordingly naming convections to identify the printer uniquely in the company. 4. Specify the device type. Device type specifies the type of printer, manufacture, model no, if the device type is not available write to SAP to send the device types. Device type is a small program which provides interface to the printer. 5. Go to ‘SPAD’ – Device type – Import – specify the file name and execute the import. Assigned the spool server so that the spool server assign’s the process to the printer. The spool server can be logical or real [physical]. If it is logical it can communicate with one or more real spool servers [dunning load balancing or fail over]. Device class;- It specify the standard printer, Fax, archiving etc. Authorization Group:It is used to provide security to the printer and ensure that only the people with this authorization group can print documents. Specify the model --------Location ---------Message -----------Select the option – to lock printer in SAP system click on TAB “Access method” Select C or L ro F for local access method. Select U or S for remote access method along with printer name and host name. Check the box do not query host spooler for o/s status. If it is not checked w/p goes to host spooler and request the status periodically. Tab o/p attributes:- To specify the printer customizing. Tray into:- Specify the no of trays in the printer. SPOOL Monitoring:- [SP01] -

Spool request and o/p request are monitored in transaction SP01.

-

Go to Transaction SP01 specify user name, date and time to display a spool request and their status.

-

Note:- Spool request are related to SAP and they are stored in “Temse” until we delete or reorganize the ‘Temse’.

-

We need to monitor the status of spool request.

1. -: not yet send to host system [n o/p request exists]. 2. + Spool request is being generated. 3. Waiting: It is waiting to be processed by the spool process. 4. In proc: The spool w/p is formatting the o/p 5. Printing: The host spool is printing the request the status cannot be printing for more than a 1 min because the spool process will be blocked. If it is printing the status is completed. If not throws in to error. 6. Compl: The o/p request printed successfully. If the spool system doesn’t receive any info from host spool the status is marked as Compl. Note:- It is possible to have more than o/p request for a single transaction. Each o/p request can have various statuses which can be monitored by the tab o/p. 7. Problem: The print is generated but with minor problems due to incorrect character set, page setting, page out etc. 8. Error: The request is not printed at all. It can be due to a network issue [printer not available, printer is not defined. Printer is out of network. 9. Archive: The spool request will be deleted from the temse periodically. In order to keep a copy, it is advice to archive the spool requests to a separate storage location. SPOOL Problems: 1. User complains that he cannot print the documents. The error could be temse overflow. In an SAP system the max: permitted spool numbers are 99000 which are defined by parameter. 2. Rspo / spool_ID/max-number = 99000 i.e. the temse cannot store not more than 99000 entries. 3. Spool congestion occurs with spool requests status waiting. There couldn’t be enough spool processes or the existing processes are busy or hold by front end printers Analysis:- If the spool process couldn’t print use SP01 to evaluate or ask the user to use SP02 to evaluate their own spool requests. If the user couldn’t print, he can reprint to the same printer or redirect to any other printer by changing the print priority to very high. However we can forward the o/p request to the other users in the system. Re-organization:The Temse has to be reorganized from time to time so that Temse doesn’t go beyond 99000. Go to SPAD select option Admin select the option delete old spool

requests. Alternatively periodically to delete the jobs based on age, client etc. Depending upon the spool frequency we may need to schedule periodically. [Daily or weekly] Spool consistency check:Go to SPAD go to admin, check the option consistency check of spool data or use the report RSP01043 / RSP00043 to check the consistency. Monitoring Temse:Go to SP12 to monitor and administer Temse. It is used to check the memory allocation of the Temse objects. Message server:It is used to manage all the dispatcher in the SAP system. It is used to direct the user requests to the least loaded server when logon load balancing is configured. It is also used to communicate with Enqueu to obtain the locks for the dialog process of the other instances. Message server is the 1st process to be started to start SA system. If this is not started SAP system is not reachable. Msg server is monitored in Transaction SMMS. Msg sever couldn’t be started if ports [3600] series is blocked. If there is a change in host name, hardware [32-bit], change in network card, IP address, SID the Msg server doesn’t start. Gate way services;It is used to provide the entry to the system. It is used to communicate b/w the system using RFC, TCP/IP, and HTTP etc. Gate way is monitored in Transaction SMGW. Go to transaction SMGW to display the connections to the gateway. Click on Go to configure gateway. Gateway will be timed out if max. Gate ways are opened which is configured by parameter. R disp / max – gateways = 100 We can increase this value to 500. We can also trace the gateway connections. Go to – Trace – gateway To reset the trace, increase or decrease the trace levels. From Netweaver on wards, in order to avoid gateway congestion we can install gateway separately. There will be 1 gateway for each SAP instance. ICM [Internet Communication Manager] It is introduced in SAP web application server that is from 4.7 onwards. ICM is used to provide internet services to the SAPP system. I.e. SAP can be accessed over the internet for the predefined web-dynpro content. It is accessed over port 8000. ICM is monitored by using Transaction SMICM. There will be only 1 ICM process for each

instance. If the page can’t be displayed with in 60 sec. If will be timed out. This is defined by parameter. ICM/Keep – alive-timeout = 60 When the ICM is implemented we need to specify the host name along with domain i.e. the host name should consist of 2 dots and defined by parameter. ICM/host – name – full – Willsys 07. SAPERD.NET [Fqdn: Fully qualified domain name] ICM traces can be increased based on the requirement [use the option go to]. If the ICM congestion occurs increase the value of threads by using parameter. ICM / Min – threads = 10 ICM / Max – threads = 50 ICM / Min – spare – threads = 3 DATA TRANSFETR It is used to transfer the data from SAP to SAP systems. And SAP to non – SAP systems. Data transfer is required in the following circumstances. 1. To transfer the legacy data from non – SAP systems to sap systems. Ex: Customer is having a JAVA based, Siebel based or any other system. In order to replace the system with SAP we need to transfer the data from traditional system to SAP system. If the amount of details small we can user data entry operators to keying in the data but if the data is large volume let us say few thousands of customers, vendors, suppliers, employers, partners. 2. Periodic data transfer during parallel run [both SAP system and non – SAP system runs in parallel. As the SAP system is leading system we need to transfer the data from non – sap to sap periodically. 3. To reduce the license cost by using the 3rd party interfaces. 4. Business to business [B to B], B to C [Business to customer] E commerce applications gets the information during B to B and B to C. Ex: HP, SONY, Kodak [SAP systems] communicate with distributers, whole sellers, retailers, like metro, digital shops, carry for circuit city. B to C customer login to the website and order the goods over the web. The order is transferred in to SAP system and an available or deliver date is provided to the user. Business analysis / Data ware housing solutions;In order to analyze the data we need to get information from various system. Ex: SAP BW server communicates with ERP, SRM, SCM etc. In order to transfer the data we need to communicate between the systems using RFC.

RFC: Remote function call Used to call the system remotely using host name, instance number, or IP address, user name, password etc. There are various types of RFC’s used 1. Synchronous RFC [SRFC] 2. Asynchronous RFC [ARFC] 3. TRFC [Transactional RFC] 4. Queued RFC [QRFC] Synchronous RFC [SRFC]:It is used to communicate with the target system synchronously and ensure that the task I completed and gets the acknowledgement by using this method the resource is blocked at the target system. Waiting to be served by the target system. If the target system is not available or the resources are not available on the target system the w/p goes in to sleep mode, RFC+CPIC mode. CPIC:- Common programming interface for communication it is a SAP proprietary protocol. This is used for communication between systems. ARFC:- It is used to communicate with the target system and does not guarantee any acknowledgement. It will not wait for target system or resources or response from the target system. Transactional RFC:- It is an extension of ARFC. The source system resource communicated with target system. If it available delivers the message. If not the transaction ID is generated which is display in SM58. The background job RSARFCSE runs in the background for every 60 sec and ensures the message is delivered to the target system without any failures. TRFC is reliable communication between the systems. Ex: Central user administration parent client create the users and transmits to the child client based on availability. QRFC:- It is similar to TRFC but ensures that the jobs are queued and serves based on first in first out [FIFO] EOIO: Exactly once in order. QRFC’s are monitored in SM01 [out bound queue] SM02 [In bound queue] SMQR is a QRFC monitor, Defining RFC connection:Go to SM59 to define RFC connection. 1. Click on create

2. Specify the name [it should able to identify the target system] 3. Specify the type of connection [R/3 for BW, CRM, SRM, SCM, for three tire architecture systems] Choose 3 for 3 tire Choose 2 for client server architecture system Choose T or TCP/IP systems Choose H for HTTP based connection [web] T is used for email, JAVA, Fax systems, 4. Provide description [this connection is used to connect to active directory server, exchange, Fax server] 5. Specify hostname, IP address, instance number etc 6. If T is used TCP specify program ID, for JAVA base system 7. Specify gateway host name and gateway instance. Host name: Willsys, Gateway instance: SAP GW 00 8. Specify client number, user id, password and logon language. 9. Save the connection 10. Test the connection 11. Test remote connection 12. Test authorization. Note: The user should be a communication or system user so that user cannot logon to the target system interactively. DATA TRANSFER METHODS 1. LSMW: [legacy system migration workbench] T-code: LSMW to perform one time data time data transfer from legacy system to SAP system. Process:- Identify the legacy data to be transferred. Let us say employee master, material master, customer master etc. Pursing, placing, truncating/choosing based on ETL standards [extraction, transformation and loading] Identify the mapping program and run it. 2. Periodic data transfer:It is used to load the data periodically from various backend systems. The schedule can be hourly, daily two times or four times, daily, weekly. It is used during. 1 Parallel run 2 Business to business [B to B]

3 B to C SM35:The data is always entered through SAP screens only. Either it is a dialog or background. In dialog inputs are interactive where as in background we use variants. VA01: Sales order MM01: material In SM35 to check for the incorrect sessions. All the background jog problems are application to batch input processing. Customizing Batch i/p: 1 Call transaction method 2 BDC session method 1 Call transaction method:- It is used to call the transaction and pass the values in the background. While using call transaction method Ws-upload. Ws – download are used to upload the files. These are replaced by GUI down to load the application in to SAP application server. Call transaction is used for only one time and error handling has to be preformed explicitly. 2 BDC sessions: It is an advanced version of cal transaction. Where the data transfer is scheduled in terms of sessions. We use open-form, close – form, Read – form, Write – form. These sessions are stored and executed periodically. It has predefined error message and the session can be executed by correcting the error message. It is used for periodic data transfer. Communication mechanism between SAP to SAP system;ALE:- [Application linking Enabling]: It is used to transfer data between two loosely coupled systems that is SAP to SAP – based on logical system names. Each client needs to be assigned with a logical system name in transaction SALE. Go to SALE Define logical system Click on new entries CLNT Name of the system three digit Client number. Logical system name is used to identify the client uniquely in the landscape.

Define the sending system and receiving system. Go to BD64 and define the model view And add BAPI BAPI:- Business application programming interface to determine the data transfer between sending and receiving system. BAPI are predefined in the Sap system they are based on interface and method Ex: of ALE is central user administration. Communication Mechanism [B/W SAP – non SAP] In ode rot communicate b/w sap to non sap systems we need to use EDI [Electronic data interchange] EDI is the mechanism used to transfer the data from SAP to non SAP systems using IDOC. IDOC is an intermediate document which is in the understandable format of both the sender and receiver. IDOC is defined by functional and Technical consultants. IDOC are checked and maintained in T code IDOC. SMQ1 is used to monitor the outbound queues. It is used to monitor the data that needs to send to a receiver. SMQ2 is used to monitor the inbound queues. It is used to monitor the data that needs to receive from a sender. WE21 is used to find the ports that are used for IDOC processing. WE05 is used to monitor the IDOC based on IDOC number and status, partner, partner type and partner port. Go to WE05 and select the date and display all the IDOC’s. Look for the status and action on the type of status: 0 – 49 are outbound errors [SMQ1] 50 and above are inbound errors SMQ2 01:- IDOC generated 02:- Error is passing data to port. Check the port in WE21 03:- Data passed to port ok. 07:- Error during syntax check 09:- Error during inter change. Frequently occurred error is 51: document not posted. Based on the type of error we may need to inform. Business process owners / functional consultants. External connections:SCOT is used to define the external connections like pager, Fax, SMTP etc. Go to SCOT click on create / copy to define new connections. Specify new node and description

Specify RFC or HTTP. RFC is used for fax, mail, exchange etc. HTTP is used for Sms messages. Specify RFC connection [if choose RFC] Select the address area [email, internet, paging, printer etc.] Specify the o/p format [text, html and PDF] Specify the duration for repeat send and save [Most of them are pre configured we may need to reconfigure or create new connection] Basis Role:- Monitor the status of the Msg [completed / errors/ in transit/ waiting] Error: error couldn’t send due to interface problem. In transit:- These are processing. Waiting:- Waiting to be processed. User complains that the Msg are waiting since long time or spending long time in transit. Check the interface [Pager, Fax, SMTP and SMS etc]. Monitoring the Messages [SOST]:G to SOST and specify the send data and display the msgs of the request. It displays the requests that are waiting, Incorrect. If the Msg couldn’t be transmitted [either email, fax, etc..]. Select the request send request an repeat send. We can also display the document along with transmission history. Managing Instances:- Instance has its own memory, buffers, processes, db client to maintain the instance based on the available resources we need to use their profiles. Each instance has its own profiles. Start up profile:- This profile is used to start the instance. It is in the naming conversion start – debmgs instance # host name [central instance] similarly start – dol – host name [dialog instance]. It consists of parameters to start the D/B, Msg server and dispatcher. It resides in usr\sap\SID\sys\profiles directory. Note: - Don’t modify start up profile under any circumstances. Default profile:- It is used to set the profiles for all the instances i.e. it provides global values to all the instances. It is represented by default. Pfl. Note: - Changes are made / allowed so that, they effect in all the instances. There will be only 1 default profile in the entire R/3 system. Instance profile:- It is used to control the behavior of the instance, work process, buffers, memory parameters etc. It is represented b SID – debmgs instance # host name [central instance] similarly SID – dol – hostname [dialog instance] Profile Parameter Documentation:

Go to “RZ11” to display the documentation of the parameters. it also displays on option value change to change the dynamic parameters. Dynamic Parameters: These parameters are changed dynamically without restarting the system. These are modified in the RZ 11. Changes are temporarily and lost when the system is restarted. E.g.: Changing the time schedulers like R disp / btc – time. Static parameters:These parameters require restarting the system when changes are made. Parameters such as no of w/p, changing buffer values, change in memory parameters and security parameters. These changes are permanent. Profile Mechanism:- When the system is installed, the profiles are located in usr/sap/SID/sys/profiles. SAP system always starts by reading the profile from the o/s level. The profiles can be edited at o/s level but they are not checked for consistency. That is why Sap recommends importing the profiles into D/B using RZ10 and maintaining them. Go to RZ10 and utilities and import profiles of active server. The profiles are modified in the D/B, save and activated so that the profiles at o/s level are modified. The existing profile is renamed to - .bak and a new profile with modified parameters is created. Profile management

\usr\sap\SID\sys\profile

1. Import using RZ10 2. Profiles are available in database 3. Go to RZ10 to maintain

4. Change / Create a parameter 5. Copy/save 6. Activate to copy the change to o/s level 7. Existing profile is renamed as “.BAK” and a new profile is created. 8. The changes are effective and read while restarting the system. Parameters are stored in table “TPFYPROPTY” Go to TPFYPROPTY or RZ11 to identify the dynamic parameters Profile administration:Go to RZ10 or profile administration There are three options 1) Administrative functions 2) Basic maintenance 3) Extended maintenance Administrative functions:- It displays path of all the profiles and mostly changes are not required using this options. Unless there is a change in file system. Basis Maintenance:- It is used to change the parameters without any technical names or parameter names. It is a user friendly option where we can toggle between lesser than and greater than options. This is used to change the available parameter that is existing. It is mostly used for w/p, buffers, memory. Extended Maintenance:- It is used by exports and based on parameter names. Go to Rz10 Select Extended maintenance Select profile Click on change to display the parameters in the edit mode Click on create specify the parameter name and value Click on copy Go back [where we can see the created parameter] Save, save Activate the profile. NOTE:- Activate the profile after changing the all values do not try to activate the profile more than once before to restating the server. Alternatively we can make the backup of the profiles directory. If backup of the profiles directory. If the system could not be started we can use the .BAK parameter [delete the .bak] and the current profile parameter to start the system.

Operation modes:- Operation modes are used to convert the dialog process to background w/p and vice versa without restarting the systems. During off peak hours dialog process are not in use and the resources allocated to them are not useful similarly background processes. During peak hours we need more dialog w/p to serve the users. So we can convert background to dialog. Process of defining operation modes:1. Go to RZ 10 to import profiles. 2. Go to RZ 04 check and define the instance 3. Define the instance in RZ04 4. Define the operation mode [peak/off peak day/night mode] 5. Define the instance with hostname / startup profile / instance profile. 6. Assign modes to the instance and define the work process. 7. Go to SM63 to specify the time for night mode and day mode. 8. Select the time interval and assign the modes. 9. The interval is of one hour durations which can be further reduced to 30, 15 minutes interval. 10. Save the changes. Note:- During the switch operation mode change it is recorded in SM1 which is a daily monitoring activity] Go to RZ03 to dynamically switch between operation modes Go to control – switch operation mode Switch all servers or specific server and click on ok. Note;- Do not give authorizations or access to RZ03 because the instance can be shutdown. Using SAP GUI. Note:-If the work processes are performing certain tasks during the switch, it waits till the work process are freed and perform the switch. Log on Load Balancing:When one or more dialog instances are deployed in order to use the resources effectively log on load balancing is configured. Concept:1. Effective usage of resources that is w/p 2. Effective utilization of buffers 3. Log on load balancing and fail over 4. Identify the no of instances that are defined in the R/3 system. 5. Define logon groups in SMLG based on modules for effective utilization.

6. For each log on group we can assign as many instances as possible. Go to user GUI Select the logon group Specify message sever and SID Select the logon group [groups defined on SMLG are displayed] Save. Log on process:1. User select the group and login to that group 2. Sapmsg.ini is used to identify the message server with port number and service in [SAPMS3600 / TCP in services file.] 3. Message maintains the list of favorite server and router the request to that instance. 4. Instance dispatcher handles the request. This is used for dialog processes only. RFC server groups:These are used to load balance between background processes / instances. Go to RZ12 Specify the server group and assign the instance and one server group can have any number of back ground instances. These server groups are used while defining background jobs. When a request is coming from a source system, the target server group provides the process from the least loaded system. Let us say Peak mode dia – 25 – btc : 10 Off peak mode Dia – 7 – btc : 28 In order to switch to dialog we require at least 18 free dialog w/p In order to switch to btc we required at least 18 free btc w/p If 17 w/p are available, switch waits for more dialogs. SYSTEM MONITORING: [Health check] 1. Check all the servers are up and running use ping command following by IP address/host name. 1 Login to desktop using user ID, Password and domain. 2 Based on connectivity we may need to use VPN with secured access key. 3 Open the check list. 2. Check all the active instances of SAP system

SM51: -

It is used to monitor all the active instances of the SAP system.

-

It describes the type of instance [central or dialog] along with types and no of processes. Double click on it to display the transaction. SM50 of that respective instance.

-

It displays the status of each instance.

-

It displays the release notes along with OS, DB and R/3 versions along with patch levels.

-

It is also used to navigate to various other transactions like system logs, users on this instance, Directories [AL11/ST11] etc.

Note:- Do not give authorization to this transaction, because it is used to call various transactions. SM50: To monitor the work processes. SM37: To monitor Back ground w/p ST22: ABAP dumps are monitored in ST22, Whenever an SAP program could not be executed due to some of the following reasons the program is dump with reason for dump. 1 Time out error: The program consumed more than 600 sec, so it is timed out. So schedule it as the BTC job. 2 START_CALL_SICK: In consistency found between kernels based on the o/p in SICK, we may need to patch OS, DB or R/3. 3 MESSAGE_TYPE_X not found: It is GUI problem uninstall and reinstall GUI or patch GUI. 4 PXA_NO_FREE_SPACE; Buffer over flow Increase the program buffer size using ABAP/buffer size to 600,000 KB 5 Work process in PRIV mode: Work process is restricted to the user, based on the requirement we may need to kill the process. Table space overflows [ORA-1653, 1654] Max extents reached [ORA – 1631, 1632] Archive struck [ORA – 255, 272] Program Bugs/ : We may need to apply patches, notes or packages. ST22:- It describes the nature of the problem along with what happened when, how, why along with program name and program code line which is dumps. It will also specify the measures to resolve the issue. The dump also results in system log.

System logs: [SM21]: System logs are used to display the important events in the system. It may be a message, warnings, problem, and error. Each of the messages is displayed with date, time type of process, client, user, Transaction code, message number and message text. All the above dump problems users in the system log. Ex: Work process start up, shutdown. Enqueu table overflow. Operation mode switch. Update deactivation, Temse overflow. W/p failures like sleep mode, private mode. SM04: It is used to display the list of users on the specific instance along with Transactions, no of sessions and the memory consumed by the user. It is used kill the user session while releasing locks. We can also log off the user completely. AL08: It is used to display the users of all the instances. It is only a display we cannot kill either the session or logoff the user. Dialog step:- It is a screen change [part of a transaction] goes to the database, database buffers, R/3 buffers. Each dialog step has to be served with in 600 milliseconds. It is also referred as average response time of a dialog step. The average response time can go up to 1200 milliseconds, If it goes beyond we need to evaluate the complete response time. GUI time or Front end time: The time taken by the user request to reach the dispatcher is termed as GUI time or Front end time. It should not go beyond 200 milliseconds. If the user request goes beyond the threshold value it is treated as expensive and we consider the following. 1 The network communication b/w GUI and dispatcher is congested. If this is a common problem we can increase the network bandwidth. 2 Message server is busy in identifying the least loaded server. If this is a regular problem to a particular group of user then assign them application server instead of group. 3 Use GUI low speed connections while communicating over slow bandwidths. Wait time [Queue time]: It is the time taken by the user request to be served by the dispatcher or it is the amount of time the user request sits in the Queue. The wait time should not be more than 50 milliseconds or 10% of the response time. If wait time is expensive we can conclude the following; 1 There are no free WPS or the WPS are not configured at the ratio of 1:5 2 The work processes are held due to sleep, CPIC+RFC, PRIV mode.

Resolution: We may need to increase the WPS or we may need to kill processes based on FIFO. Roll – in time / Roll – out time [Roll time]: The time taken by w/p to role the user related into task handler. The roll in time and roll out should not go beyond 50 milliseconds. If it goes beyond 50 milliseconds. We can consider role time as expensive. If the role time is expensive delete the unwanted roles, parameters and ask the user to fine tune the i/p’s [Don’t give * which fetches changes huge amounts of data]. 4 Processing Time:- The amount of time taken to process the user request by the w/p [screen, ABAP, SQL interpretation]. It also includes as expensive if it is more than twice the amount of CPU time. If processing time is expensive it is due expensive ABAP, screen and SQL statements. 5 CPU time:- It is the amount of time taken by the work process in utilizing CPU resources. It is considered as expensive if it is more than. [CPU time < 40% [response time – wait time]]. If CPU time goes beyond threshold value we can consider the ABAP programs are expensive. It can be due to in efficient code, expensive looping. Time tunes the program using SE30 [runtime analysis of ABAP program]. Load and generation time:- It is used to load and generate the programs and screens for the users to send as response. It should not go beyond 200 milliseconds. If it is expensive consider increasing the size of buffers. Enqueu time:- The time taken by the w/p to communicate with Enqueu and obtain the lock [on central instance 1-5 milliseconds, on time is expensive consider increasing Enqueu w/p etc. RFC + CPIC time:- It is used to communicate with external systems using RFC. SAP didn’t provide any threshold values for RFC connections. If depends upon the customers. D/B Time:- It s the amount of time taken by the w/p to get the response from the D/B. It is treated as expensive when it goes beyond 40% of response time – wait time. [Similar to CPU time]. It is expensive due to the following reasons. 1 Expensive SQO statements [fine tuning using ST05]. 2 D/B buffer size is not enough [increase DB – cache size in the profile in it .ora] 3 D/B statistics is not updated [use DB13 to schedule D/B statistics]. 4 Missing indexes [Identify them in DB02 and recreate them.] Response time:- It is the sum of all the above times except GUI time or CPU time.

Note: GUI time is not considered because the request is not reached the dispatcher. CPU time is not considered because it is calculated as part of the processing time.

Physical memory:- The memory that is installed on its system or the memory that is assigned to the instance defined by the parameter. Physical memory size. Ex: Let us say, if 8 GB memory is installed. We can consider 72 to 80% of 8 GB as physical memory. 2 Let us say, 80 GB is installed from which we can define 10 instances of 8 GB each or 5 instance of 16 GB each. Virtual memory:- In order to provide temporary work area physical memory is not sufficient to hold large data sets [Data information]. So it uses the space on the disk. The space allocated to hold the data temporarily by memory is referred as virtual memory. On windows 32 bit machines, 4 GB is max. On 64 bit we can allocate based on requirement. On UNIX we can allocate 20 GB as swap space during installation. Shared memory:- The memory is used by all the executable is termed as a shared memory, including o/s executable, R/3 executables. Extended memory:- The memory is used by all the R/3 w/p’s. It is defined by parameter Ztta/roll_Extension. This memory is allocated when the local memory is exhausted. Extended memory is defined by parameter em/initial – size – MB and each block size is defined by parameter em/block size – KB. Local memory:- The memory allocated for each w/p define the parameter Z tta / roll – area Heap memory or private memory:- This memory is allocated when all the other memory are exhausted. It is a private memory allocated to a w/p and the w/p continuous to run beyond 600 sec. That is process will not be timed out. Memory work flow:1 User requests a transaction [to create PO, SO, invoice etc.]

2 Work process is allocated to serve the request. 3 W/p requires certain amount of memory to roll the user contact. 4 Initially a part of roll area that is 1 KB is allocated to w/p defined by parameter Z tta / roll –first. 5 In most of the scenarios this memory is not sufficient to roll the user context. 6 W/p starts using extended memory in terms of 1 MB block which is defined by parameter em /block size – KB = 1024 and it uses up to the value defined by the parameter. Z tta / roll – extension = Max 2 GB 7 If the extended memory is not enough it uses the remaining part of th memory that is available in Z tta / roll – area – Z ttz / roll – first. 8 If the role area is not sufficient the w/p starts using heap memory and the w/p goes in to private mode. If the w/p goes in to private mode it can use memory up to the value defined by the parameter ABAP / Heap – area – Dia 9 The w/p is restricted to the user request and ca only released the entire memory is exhausted or the task is completed. 10 When the w/p is in private mode the w/p is bynded to user request and cannot be timed out it will goes beyond 600 sec. 11 When more no of w/p goes into private mode hour glass situation occurs in this situation we may need to use DPMON to kill the work process. We can restrict the maximum w/p that can go in to private mode by using parameter rdisp / WP priv – max – No we can also configure parameter. HANDLING HOUR GLASS: 1. If the instance is blocked login through other dialog instance and we use SM66 to terminate the w/p. 2. If we have O/S permission we can use DPMON and kill the w/p. WORK LOAD ANALYSIS: Go to ST03 to identify the workload based on user , work flow, transaction etc. ST03 provides 3 modes for display are: 1. Expert Mode 2. Administration Mode 3. Service Engineer Mode ALLOCATION OF MEMORY TO BACKGROUND W/P: 1. ZTTA/ROLL_FIRST

2. ZTTA/ROLL_AREA 3. ABAP/HEAP_AREA_DIA or ABAP/HEAP_AREA_NON DIA 4.ZTTA/ROLL_EXTENSION BUFFERS: The frequently used content and rarely changed content is eligible for buffering. It is instance specific and use to improve the performance of the system. Buffers are monitored in transactions “ST02” buffers resides in the memory and they are lost once the system is restarted. Buffer Management: Buffers are organized in term of directories and the directories users’ space. These are various types of buffers which are used to store the content based on content type. Go to “ST02” to display the buffer content allocated space, free space, free space percentage, directories size, free directories, swaps etc, and the various content that are buffered is table names, definition, program, screen, common user attribute, calendar, tables etc. Each buffer content has its own parameter to define the space and directories. Double click on the parameter to display buffer hit ratio, amount of swaps and configured parameters. BUFFER HIT RATIO: It IS USE TO IDENTIFY THE UTILISATION OF BUFFERS AND IT SHOULD NOT GO BELOW 94%. TUNNABLE PARAMETRS: Buffer plays a important role in the fine tuning system. As part of monitoring swaps with the threshold value needs to be captured and monitored periodically. Eg: Program buffer has 25000swaps marked red in with huge database is access. Analysis: Check the free for percentage directories utilization check the directories percentage. If any of them goes below the threshold value. Consider increasing their value with respective

parameters

for

the

ZCSA/TABLE_BUFFER_AREA.

programs

ABAP/BUFFER

SIZE.

For

tables

We may need to increase either directories (or)

space. The Reasons For Swaps: 1. Either the directory or the space is not enough.

2. After applying support packages and patches or mass transport to production because invalidate the buffer content. 3. The instances are not configured properly or load balancing is not configured based on modules or based on instances and users. NOTE: When the system is restarted the buffers are built and users experience high response time in order to measure the response time wait for at least 20000 requests to built the buffers. TABLE BUFFERING: THERE ARE 4 types of table type buffering are: 1. No Buffering. 2. Full Buffering. 3. Single record Buffering 4. Generic Buffering. 1. No Buffering: The table Which are relatively large and frequently updated is not eligible for buffering . Ex: Mara, V bank, EKPO, BSEG. 2. Full Buffering: The table which are relatively small are rarely updated is eligible for full buffering. Ex: T000, TBDLS. 3. Single Record Buffering: The tables which are considerably small are buffered by using their key. Eg: USR02 4. Generic Buffering: The buffering is performed based on group of fields. Ex: T001 (Company Codes) Buffering For Tables: When the table is defined SAP categories whether table can be buffered or not it provides various options: 1. Buffering not allowed. 2. Buffering allowed. 3. Buffering allowed but switched off (Customer can only change this.)Especially when we are working on development system buffering is not required. BUFFER SYNCHRONISATION:

When more than one instance is configured we need to set the buffer synchronization option if not users get the invalid data as response or the request cannot make use of buffers. BUFFER WORK FLOW: 1. User goes to the database and fetches content into the R/3 buffers in various instances. 2. User on one of the instance modifies the data but the same data is available to users on the other instance. 3. Now the modified content be synchronized with other instance needs to inform the user that content is updated and advised to invalidate the buffer content. 4. When the data is fetched into buffers it logs into the table DD log 5. When from the user is fetching the content from the buffer it will check the time stamp record. There is a difference in the time stamp user gets data from database. On the other hand there is a parameter RDISP/BUFF REF TIME is 60sec to 3hours. 6.Inorder to set the parameter we need to activate buffering by using parameter RDISP/BUFF REF MODE set to send on, execute if we do not want the buffer synchronization send off, exe off.

It is possible to allow 5000 to 1000 per day 50 do not panic when you see swaps in ‘ST02’. Buffers are displayed. Buffer: B.H.R | allocated | free | free % | allocated | free | free | swaps 94% In this swaps need to be monitored.

SE13: Technical settings of tables Buffering allowed / not allowed/ allowed but switched off no buffering / 100% / all buffering / single / generic Note:- On a central instance configure rdisp/ buffer mode as send off No buffering / 100%/all buffering/single/generic Note;- On a central instance configure rdisp / buffer mode as send off, exe off configure to send on exe auto if more than one instance is complicated. Setting the parameter to off we will dramatically increase the performance. Tracing:- [ST01 system trace] or [ST05 SQL trace] It is used to trace the following ST01: 1. Authorization Trace:- It is used to trace missing authorization [it will be default in security] 2. Kernel Trace:- It is used to identify the functionality of kernel when it is being executed. It will specifies if any executable is out dated and based on that we may need to update them. ST05:- 1 SQL Trace: - It is used to identify the expensive SQL statements with estimated cost. Go to ST05 and activate the trace for the logged in user. We can also activate the trace with filter to specify user and program / transaction name. ABAP development team can write the SQL statement to fine the SQL execution plan. 2 Enqueu Trace:- It is used to find the causes of expensive Enqueu time. 3 RFC Trace:- It is used to fine the causes of RFC+CPI time buffer trace is used when more swaps are recorded. 4 Buffer Trace ST01:- It is used friendly to work with all traces and with all combinations. ST06:- It is used to identify the utilization of CPU and memory resources. Go to ST06 and ensure that CPU idle time should not be less than 30% If it goes down below 30% click on detail analysis men and select to CPU. To identify the top CPU services or users. Count specifies the number of CPU and utilization for 1 st, 5th and 15th min is displayed. Identify the top CPU users and services and fine tune the program used by tem using SE30. It also displays the physical memory available and free memory along with swap space. We can also stop and start SAP OS collector from ST06. Go to detailed analysis men use LAN check by PING to presentation servers and database servers.

ST07:- It is used to identify the no of applications and total, no of users, total no of w/p throughout the system along with the load on the applications with users and processes using that application. It is use to find the load on the applications and determine which application is it mostly used for getting the requirement for log on load balancing and it is also used to determine the buffers used, the response time of the system and DB memory and DB access. ST11:- It is used to display the log files from E: usr/SAP/SID/DEVBMGS/work CCMS [Computing Center Monitoring System] It is used to monitor the system based on alerts threshold values. It is also called as alert monitor it is a single window where the complete system can be monitored and alerted for change management. We can use SAP predefine monitors or we can create and adapt our own monitors. Go to RZ20 Extras Activate maintenance function on create or copy the monitor from the standard template. RZ20 consists of monitor sets, monitors, and monitor tree elements [MTE] MTE are assigned with properties and methods Go to RZ21 to define and assign properties and methods How the information is passed to RZ20? The methods run the various jobs periodically and update CCMS. The method can get the information from transaction, report or using a functional module. Properties are defined to collect the information based on time interval and change the traffic light from White – yellow – red – green The threshold values are defined to change the above colors based on output. Let us say the system should check DB02 and report missing indexes. The background job monitors DB02 and if there are any missing indexes it displays in red color, similarly, backup fails, background job fails, update fails, and lock mechanism failure etc are monitored and displayed through CCMS. It is an alert monitor to display the errors on windows. This reduces the task of check list, but there should be someone to monitor this CCMS. MTE properties to specify traffic lights based on the output from methods. Methods are assigned with reports, transactions, and Function modules to run in the background in non dialog mode and get the information into CCMS.

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF