Thursday, December 27, 2012
SPAM Steps
The SAP Patch Manager informs you of the status of the step currently being executed in the status bar. If you want to know which steps are executed for which scenario, run the program RSSPAM10.
The following list explains the steps executed by SPAM in the order in which they are performed.
PROLOGUE
In this step, the system checks if you are authorized to import Support Packages.
CHECK_REQUIREMENTS
In this step, various requirements are checked for importing a Support Package, for example, the transport control program tp logging on to your system.
DISASSEMBLE
In this step, files from the corresponding EPS parcels are disassembled, or unpacked, and stored in the directory.
ADD_TO_BUFFER
In this step, the queue is put into the transport buffer of your system.
TEST_IMPORT
In this step, the system checks if there are still objects in tasks that have not yet been released and are overwritten when the Support Package is imported.
IMPORT_OBJECT_LIST
In this step, the object lists for the Support Packages in the queue are imported into the system.
OBJECTS_LOCKED_?
In this step, the system checks if there are still objects in tasks that have not yet been released and are overwritten when the Support Package is imported.
SCHEDULE_RDDIMPDP
In this step, the transport daemon (program RDDIMPDP) is scheduled.
ADDON_CONFLICTS_?
In this step, the system checks if there are conflicts between objects in the queue and installed add-ons.
SPDD_SPAU_CHECK
In this step, the system checks if a modification adjustment is necessary (Transactions SPDD/SPAU).
DDIC_IMPORT
In this step, all the ABAP Dictionary objects of the queue are imported.
AUTO_MOD_SPDD
In this step, the system checks if modifications to the ABAP Dictionary objects can be adjusted automatically.
RUN_SPDD_?
In this step, you are asked to adjust your modifications to the ABAP Dictionary objects by calling Transaction SPDD.
IMPORT_PROPER
In this step, all the Repository objects and table entries are imported. Then actions such as distribution, conversion, activation and generation occur.
AUTO_MOD_SPAU
In this step, the system checks if modifications can be adjusted automatically.
RUN_SPAU_?
In this step, you are asked to adjust your modifications to the Repository objects by calling Transaction SPAU.
EPILOGUE
In this step, the import of the Support Package is ended. The system checks if the queue has been completely processed.
Wednesday, December 26, 2012
AS ABAP Work Process Overview
There are 5 types of Work Process:
Dialog Work Process (DIA): Every user request is processed by Dialog Work Process. Normal response time of a Dialog Work Process is 6 ms. Every instance should have a minimum of 2 Dialog Work Processes and can be increased to more as per requirement.
Background Work Process (BCK): All long running batch jobs and reports where user interaction is not required are taken care by Background Work Process. Every instance should have a minimum of 1 Background Work Processes and can be increased to more as per requirement.
Update Work Process (V1, V2): All udpate related request are taken care by Update Work process. This is of two types, Synchronous updates (V1) and Asynchronous updates (V2). Every instance should have a minimum of 1 Update Work Processes and can be increased to more as per requirement.
Enqueue Work Process (ENQ): Enqueue work process implements lock mechanism. When two users are trying to update same data in a table then Enqueue work process locks that table for other user and releases it when first user saves an commits it. Every instance should have 1 Enqueue Work Processes and cannot be increased.
Spool Work Process (SPO): All print related requests are handled by Spool Work process. Every instance should have a minimum of 1 Spool Work Processes and can be increased to more as per requirement.
Work Process Architechture:
Work processes execute the process logic of application programs. In addition to
internal memory, a work process has a task handler that coordinates the actions within
a work process, software processors and a database interface. The dynpro processor
executes the screen flow logic of the application program, calls processing logic
modules, and transfers field content to the processing logic. The actual processing
logic of ABAP application programs is executed by the ABAP interpreter. The
screen processor tells the ABAP processor which subprogram needs to be executed,
depending on the processing status of the screen flow logic.
The dialog work process selected by the dispatcher, performs a roll-in of the user
context first. That is, the data that contains the current processing status of a running
program as well as data that characterizes the user is made known to the work process.
The work process then processes the user request, which may involve, for example,
requesting data from the database or from the buffers in the shared memory. Once the
dialog work process has processed the dialog step, the work process returns the result,
rolls the user context back out to the shared memory, and is now available again
for a new user request from the request queue. The result is transferred to the SAP
GUI and the user sees the new screen.
Database Interface of AS ABAP:
Relational Database Management Systems (RDBMS) are generally used to manage
large sets of data. An RDBMS saves data and relationships between data in the form
of two-dimensional tables. These are known for their logical simplicity. Data, tables,
and table relationships are defined at database level in the database catalog (the data
dictionary) of the RDBMS.
Within the SAP programming language ABAP, you can use ABAP Open SQL (SQL =
Structured Query Language, database query language) to access the application data
in the database, regardless of the RDBMS used. The database interface, which is part
of every work process of AS ABAP, translates Open SQL statements from ABAP into
the corresponding SQL statements for the specific database used (Native SQL). This
allows ABAP programs to be database-independent.
When interpreting Open SQL statements, the SAP database interface checks the
syntax of these statements and ensures the optimal utilization of the local SAP buffers
in the shared memory of the application server. Data that is frequently required by
the applications is stored in these buffers so that the system does not have to access
the database server to read this data. In particular, all technical data, such as ABAP
programs, screens, and ABAP Dictionary information, as well as a number of business
administration parameters, usually remain unchanged in an operational system and
are therefore ideally suited to buffering.
Dialog Work Process (DIA): Every user request is processed by Dialog Work Process. Normal response time of a Dialog Work Process is 6 ms. Every instance should have a minimum of 2 Dialog Work Processes and can be increased to more as per requirement.
Background Work Process (BCK): All long running batch jobs and reports where user interaction is not required are taken care by Background Work Process. Every instance should have a minimum of 1 Background Work Processes and can be increased to more as per requirement.
Update Work Process (V1, V2): All udpate related request are taken care by Update Work process. This is of two types, Synchronous updates (V1) and Asynchronous updates (V2). Every instance should have a minimum of 1 Update Work Processes and can be increased to more as per requirement.
Enqueue Work Process (ENQ): Enqueue work process implements lock mechanism. When two users are trying to update same data in a table then Enqueue work process locks that table for other user and releases it when first user saves an commits it. Every instance should have 1 Enqueue Work Processes and cannot be increased.
Spool Work Process (SPO): All print related requests are handled by Spool Work process. Every instance should have a minimum of 1 Spool Work Processes and can be increased to more as per requirement.
Work Process Architechture:
Work processes execute the process logic of application programs. In addition to
internal memory, a work process has a task handler that coordinates the actions within
a work process, software processors and a database interface. The dynpro processor
executes the screen flow logic of the application program, calls processing logic
modules, and transfers field content to the processing logic. The actual processing
logic of ABAP application programs is executed by the ABAP interpreter. The
screen processor tells the ABAP processor which subprogram needs to be executed,
depending on the processing status of the screen flow logic.
The dialog work process selected by the dispatcher, performs a roll-in of the user
context first. That is, the data that contains the current processing status of a running
program as well as data that characterizes the user is made known to the work process.
The work process then processes the user request, which may involve, for example,
requesting data from the database or from the buffers in the shared memory. Once the
dialog work process has processed the dialog step, the work process returns the result,
rolls the user context back out to the shared memory, and is now available again
for a new user request from the request queue. The result is transferred to the SAP
GUI and the user sees the new screen.
Database Interface of AS ABAP:
Relational Database Management Systems (RDBMS) are generally used to manage
large sets of data. An RDBMS saves data and relationships between data in the form
of two-dimensional tables. These are known for their logical simplicity. Data, tables,
and table relationships are defined at database level in the database catalog (the data
dictionary) of the RDBMS.
Within the SAP programming language ABAP, you can use ABAP Open SQL (SQL =
Structured Query Language, database query language) to access the application data
in the database, regardless of the RDBMS used. The database interface, which is part
of every work process of AS ABAP, translates Open SQL statements from ABAP into
the corresponding SQL statements for the specific database used (Native SQL). This
allows ABAP programs to be database-independent.
When interpreting Open SQL statements, the SAP database interface checks the
syntax of these statements and ensures the optimal utilization of the local SAP buffers
in the shared memory of the application server. Data that is frequently required by
the applications is stored in these buffers so that the system does not have to access
the database server to read this data. In particular, all technical data, such as ABAP
programs, screens, and ABAP Dictionary information, as well as a number of business
administration parameters, usually remain unchanged in an operational system and
are therefore ideally suited to buffering.
Friday, December 7, 2012
Scheduling Standard Background Jobs
Scheduling Standard Background Job is one of the Post Install Activity.
Below are the steps to schedule Standard jobs:
Goto transaction SM36
Goto transaction SM36 and click on "standard jobs" pushbutton. This inturn displays standard jobs screen. Here select all the jobs and click on "default scheduling" push button to schedule all of them as per their default schedule.
Incase you would like to change the default schedule for each job, it can also be done by selecting each job and defining its start date/time and periodicity in the same screen.
What is the need of scheduling basis standard jobs ?
Standard jobs are the jobs that should run regularly in the SAP system. These jobs will perform housekeeping like deleting old spool requests (thus avoiding spool overflow), deleting old background jobs/logs/updates/batch input sessions/ABAP short dumps, collecting operating system/database level statistics (used for workload reporting) etc
What are the Standard jobs that should run in an SAP system & their significance ?
SAP_CCMS_MONI_BATCH_DP : Internally this job runs
RSAL_BATCH_TOOL_DISPATCHING report. This job dispatches monitoring architecture methods
SAP_COLLECTOR_FOR_JOBSTATISTIC : Internally this job runs RSBPCOLL report. This job generates run time statistics for background jobs
SAP_COLLECTOR_FOR_PERFMONITOR : Internally this job runs RSCOLL00 report. This job collects data for the performance monitor
SAP_COLLECTOR_FOR_NONE_R3_STAT : Internally this job runs RSN3_STAT_COLLECTOR report. This job will collect non-abap statistic data (Distributed Statistic Records - DSR)
SAP_REORG_ABAP_DUMPS : Internally this job runs RSSNAPDL report. This job cleans up old abap short dumps
SAP_REORG_BATCH_INPUT : Internally this job runs RSBDCREO report. This job cleans up old batch input sessions
SAP_REORG_JOBS : Internally this job runs RSBTCDEL report. This job cleans up old background jobs
SAP_REORG_JOBSTATIC : Internally this job runs RSBPSTDE report. This job cleans up old data from the run time statistics of the jobs
SAP_REORG_ORPHANED_JOBLOGS : Internally this job runs RSTS0024 report. This job cleans up orphaned job logs. The logs that cannot be deleted by RSBTCDEL report (i.e SAP_REORG_JOBS), remains as orphans which will be deleted by this job.
SAP_REORG_SPOOL : This job internally runs RSPO0041 report. This job deletes old spool data
SAP_REORG_XMILOG : This job internally runs RSXMILOGREORG. This job deletes XMI logs
SAP_SOAP_RUNTIME_MANAGEMENT : This job internally runs RSWSMANAGEMENT report. This job does the SOAP runtime monitoring
SAP_REORG_UPDATERECORDS : This job internally runs RSM13002 report and this deletes old update records
SAP_REORG_BATCH_INPUT : Internally this job runs RSBDCREO report. This job cleans up old batch input sessions
SAP_REORG_JOBS : Internally this job runs RSBTCDEL report. This job cleans up old background jobs
SAP_REORG_JOBSTATIC : Internally this job runs RSBPSTDE report. This job cleans up old data from the run time statistics of the jobs
SAP_REORG_ORPHANED_JOBLOGS : Internally this job runs RSTS0024 report. This job cleans up orphaned job logs. The logs that cannot be deleted by RSBTCDEL report (i.e SAP_REORG_JOBS), remains as orphans which will be deleted by this job.
SAP_REORG_SPOOL : This job internally runs RSPO0041 report. This job deletes old spool data
SAP_REORG_XMILOG : This job internally runs RSXMILOGREORG. This job deletes XMI logs
SAP_SOAP_RUNTIME_MANAGEMENT : This job internally runs RSWSMANAGEMENT report. This job does the SOAP runtime monitoring
SAP_REORG_UPDATERECORDS : This job internally runs RSM13002 report and this deletes old update records
Scheduling Background Job after Triggering an Event
Step1: Create event from transaction SM62.
Give event name and description and press save button
Step2: Create a program that triggers this event by calling the FM 'BP_EVENT_RAISE'.
*&---------------------------------------------------------------------*
*& Report Z_TRIGGER_EVENT *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*
REPORT Z_TRIGGER_EVENT .
CALL FUNCTION 'BP_EVENT_RAISE'
EXPORTING
eventid = 'Z_TRIGGER_JOB'
EXCEPTIONS
BAD_EVENTID = 1
EVENTID_DOES_NOT_EXIST = 2
EVENTID_MISSING = 3
RAISE_FAILED = 4
OTHERS = 5
.
IF sy-subrc <> 0.
Write: 'Event failed to trigger'.
else.
Write: 'Event triggered'.
ENDIF.
Step3: Configure the background job from transaction SM36.
In the initial screen give job name and job class and press "Start condition" button. 
In the popup screen press "After event" button and give the event name and then press save button.
Now go back to the initial screen and press "Step" button
Provide program and variant name and after providing all the values press save button.
In the initial screen press save button.
Step4: Now execute the program to trigger the event and as well check the background job.
Run transaction SM37
In the popup screen press "After event" button and give the event name and then press save button.
Now go back to the initial screen and press "Step" button
Provide program and variant name and after providing all the values press save button.
In the initial screen press save button.
Step4: Now execute the program to trigger the event and as well check the background job.
Run transaction SM37
Check the status of job created by the program.
Now check the spool to see the generated list
Wednesday, August 29, 2012
CCMS Alert Monitoring
The SAP Computing Center Management System (CCMS) provides a special alert monitor for SAP Exchange Infrastructure.
Suppose your landscape is very big and contains more than 50 servers, it would be tough to manually monitor all those systems. So, it is better to get CCMS configured in Solman system and all other satellite systems that are to be monitored.
You use this alert monitor to monitor the ABAP and Java components (including the Business Process Engine) of your Exchange Infrastructure centrally, and to identify different categories of system errors and application errors in the various interfaces and interface namespaces of the components involved.
The CCMS Alert Monitor has the following advantages:
● Automated, central monitoring that does not require any administration, except where alerts occur.
● Proactive monitoring by means of alerts that are triggered as soon as a particular threshold value is not reached, or is exceeded.
● Support for problem solving through predefined analysis functions, which you can use to remove the cause of an alert in a particular component.
To create the system group, there are two steps:
Go to CCMS Transaction RZ21
a. Choose Technical infrastructure---->Configure Central System---->Create Entry for Remote System from the menu and maintain all systems (components) of your Exchange Infrastructure.
b. Choose Technical infrastructure---->Configure Central System---->Maintain system groups and define the system group ExchangeInfrastructure_Systems comprising the systems created previously.
If you are setting up monitoring in a local system that is part of the system group, you can include it in the group by specifying the system ID.
Procedure of using an alert monitor:
1. Choose CCMS--->Control/Monitoring--->Alert monitor.
Alternatively, call Transaction RZ20. The system displays the CCMS Monitor Sets.
2. Expand the monitor sets by positioning the cursor on the CCMS Monitoring Templates and choosing Edit--->Expand tree.
SAP provides default monitor sets, the SAP CCMS Monitor Templates and the SAP CCMS Technical Expert Monitors. These monitor sets are always available to you.
3. Display the Entire System monitor in the SAP CCMS Monitor Templates monitors by positioning the cursor on it and choosing Monitor --->Start monitor.
* The monitor displays the tree as it was last used. The monitoring tree is a hierarchical display of the monitoring objects (system components) and monitoring attributes (types of information on objects) in the system. The Entire System monitoring tree shows all objects and attributes that are visible at the Expert level or for which there are alerts.
* In addition to the Entire System monitor, there are other predefined monitors for special purposes. For example, if you are the database administrator, you may wish to open the Database monitor instead of Entire System.
* One special monitor is the CCMS Selfmonitoring in the SAP CCMS Technical Expert Monitors. This monitor displays any problems with the alert monitor and the monitoring architecture itself. Check in this monitor to ensure that all data collection methods that the alert monitor starts are running normally.
4. Check the current state of your R/3 System.
* Set the monitor to show the current system status.
Display the Current system status if this is not displayed already.
The Current system status reflects the most recent performance values and status messages reported to the alert monitor. Older alerts that are still open (that is, not processed) are not reflected in the color-coding.
* Check the color-coding in the monitoring tree.
The colors of the nodes, or MTEs (Monitoring Tree Elements) in the tree have the following meaning:
Green: The component is running normally. Everything is ok.
Yellow: A warning or "yellow-alert" has been issued.
Red: A problem or critical condition has been reported, a "red alert."
Gray: No data is being supplied for an MTE. (Check the Self-monitoring monitor to see why the collection method for this MTE is not available.)
To display a legend of the colors and icons used in the alert monitor, choose Extras---->Legend.
* The alert monitor propagates the highest alert level up the monitoring tree. For example, if the MTE with the name of your R/3 System is green, that means that all components in the R/3 System's monitoring tree have the "green" status. There is no problem with the system.
* Double click on any MTE to start the analysis method associated with the MTE. The analysis method displays more detailed information on the current status of the MTE.
* Optionally, you can choose to automatically refresh the display. To do this, choose Extras---->Display options and switch to the General tab. In the Refresh display box, mark Yes, interval and enter the refresh interval. The suggested value is 300 seconds or longer. If the automatic refresh is deactivated, the alert monitor displays the data that was available when you started it.
5. Check to see what has happened recently in the system by choosing Open alerts.
Instead of showing the current status of the system, the color coding now shows where open alerts exist. Open alerts are those that have not yet been analyzed.
If you are just coming in to work or returning from lunch, you can use the Open alerts view to see if anything happened in the system while you were away. The monitor saves alerts for you to review even if the condition that caused the alert has since improved.
6. Respond to an alert.
If you see yellow or red entries in the monitoring tree, that means that a warning (yellow) or error (red) condition exists.
Proceed as follows:
* Ensure that you are displaying the Open alerts view.
The monitor now displays how many alerts there are for each MTE. It also shows the most serious of the alert messages that are waiting.
* Position the cursor on a yellow or red monitoring tree element and choose Display alerts.
The system opens the alert browser and displays the open alerts for that MTE. The alert browser includes all alerts in the branch of the tree that you have marked. Position the cursor "higher" up in the monitoring tree to display a broader range of alerts. If you position the cursor on an MTE at the lowest level, you display only alerts that pertain to that MTE.
* Analyze an alert.
Each line in the alert browser provides you with summary information on an alert, including the alert message.
The browser also offers two further sources of information. Mark an alert and choose:
* Start analysis method to start the problem analysis transaction or method that is associated with an alert. (Analysis methods are still being added to the system; not all monitoring tree elements have such methods as yet.)
For example, with buffer freespace problems, you can start the R/3 Buffer Tuning Summary from the alert monitor.
* Display details to display details on the monitoring tree element. These include the most current values or status messages, the alert thresholds, and the performance data for the last measurement period (only for performance monitoring tree elements). You can graph performance data by marking the appropriate row and choosing Display performance values graphically.
7. Has the alert been resolved? Then set it to Complete.
Once you have analyzed the problem and have either resolved it or can safely ignore it, you can set the problem to completed.
Mark the alert and choose Complete alert. The alert monitor deletes the alert from the open alerts.
Monday, August 13, 2012
Oracle Shutdown Stages:
There are 4 Oracle shutdown stages.
1. Shutdown Normal
2. Shutdown Immediate
3. Shutdown Transaction
4. Shutdown Abort
Shutdown Normal:
A normal shutdown of an Oracle database is actually rarely used. This is because the normal shutdown waits for everyone to complete their work and then logoff in an orderly fashion. When a normal shutdown occurs, the database is closed in a normal manner, and all changes made in the database are flushed to the database datafiles. This is known as a “clean shutdown”.
Here is an example of the use of the normal shutdown command.
SQL> shutdown
Shutdown Immediate:
Perhaps the best way to initially shutdown the database is the shutdown immediate command. This command will prevent any new logins, then rollback any uncommitted transactions, and then bring down the database. In the process of bringing down the database, Oracle will flush all the changes in memory out to the database datafiles too, just like a regular shutdown does. This makes database startup quicker.
Here is an example of shutting down a database with the shutdown immediate command:
SQL> shutdown immediate
Shutdown Transaction:
At this shutdown stage,
-No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
-After all transactions have completed, any client still connected to the instance is disconnected.
Here is an example using the shutdown abort command:
SQL> shutdown transaction
Shutdown Abort:
The shutdown abort command is pretty much a guaranteed way to get your database to shutdown. It’s a “hard crash” of the database, and this can result in a longer time to start the database back up.
A shutdown abort should not be your first shutdown method of choice, there may be times when you must force the database down.
At this stage,
-No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
-Current client SQL statements being processed by Oracle Database are immediately terminated.
-Uncommitted transactions are not rolled back.
-Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly disconnects all connected users.
-The next startup of the database will require instance recovery procedures.
Here is an example using the shutdown abort command:
SQL> shutdown abort
1. Shutdown Normal
2. Shutdown Immediate
3. Shutdown Transaction
4. Shutdown Abort
Shutdown Normal:
A normal shutdown of an Oracle database is actually rarely used. This is because the normal shutdown waits for everyone to complete their work and then logoff in an orderly fashion. When a normal shutdown occurs, the database is closed in a normal manner, and all changes made in the database are flushed to the database datafiles. This is known as a “clean shutdown”.
Here is an example of the use of the normal shutdown command.
SQL> shutdown
Shutdown Immediate:
Perhaps the best way to initially shutdown the database is the shutdown immediate command. This command will prevent any new logins, then rollback any uncommitted transactions, and then bring down the database. In the process of bringing down the database, Oracle will flush all the changes in memory out to the database datafiles too, just like a regular shutdown does. This makes database startup quicker.
Here is an example of shutting down a database with the shutdown immediate command:
SQL> shutdown immediate
Shutdown Transaction:
At this shutdown stage,
-No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
-After all transactions have completed, any client still connected to the instance is disconnected.
Here is an example using the shutdown abort command:
SQL> shutdown transaction
Shutdown Abort:
The shutdown abort command is pretty much a guaranteed way to get your database to shutdown. It’s a “hard crash” of the database, and this can result in a longer time to start the database back up.
A shutdown abort should not be your first shutdown method of choice, there may be times when you must force the database down.
At this stage,
-No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
-Current client SQL statements being processed by Oracle Database are immediately terminated.
-Uncommitted transactions are not rolled back.
-Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly disconnects all connected users.
-The next startup of the database will require instance recovery procedures.
Here is an example using the shutdown abort command:
SQL> shutdown abort
Oracle Startup Stages:
There are 3 Oracle startup stages.
1. NoMount
2. Mount
3. Open
The differences in the 3 startup stages for oracle db are as below.
NoMount Stage:
When DB is in the nomount stage, oracle first opens and reads the initialization parameter file "init.ora" for the DB configuration which includes various parameters required for initialization. Based on the parameters, the memory areas in database instance are allocated and db background processes are started. The instance then starts.
Mount Stage:
When DB is in this stage, it opens and reads the control file which contains the physical structure of db like the database datafiles etc.. It determines the location of the datafiles and the database is ready to be opened.
Open Stage:
When DB is in this stage, it opens the database, it tries to access all of the datafiles associated with the database. Once it has accessed the database datafiles, it makes sure that all of the database datafiles are consistent.
After that DB is into normal operations state.
1. NoMount
2. Mount
3. Open
The differences in the 3 startup stages for oracle db are as below.
NoMount Stage:
When DB is in the nomount stage, oracle first opens and reads the initialization parameter file "init.ora" for the DB configuration which includes various parameters required for initialization. Based on the parameters, the memory areas in database instance are allocated and db background processes are started. The instance then starts.
Mount Stage:
When DB is in this stage, it opens and reads the control file which contains the physical structure of db like the database datafiles etc.. It determines the location of the datafiles and the database is ready to be opened.
Open Stage:
When DB is in this stage, it opens the database, it tries to access all of the datafiles associated with the database. Once it has accessed the database datafiles, it makes sure that all of the database datafiles are consistent.
After that DB is into normal operations state.
Thursday, July 12, 2012
SAP Release Stategy
SAP offers 7+2 years of Maintainance strategy to its Customers.
SAP Software has three delivery Phases:
1. Restricted Shipment phase (2 Years)
2. Un-restricted shipment phase (5 Years)
3. Extended Maintainance (2 Years)
Restricted Shipment phase: This phase is also called as Ramp-up period. During this phase software is released to only limited circle of Customers. This phase is for 2 years.
Un-restricted shipment phase: This is the second phase of release. During this phase software is released to all the customers. This phase is for 5 years.
Extended Maintainance: After un-restricted shipment phase SAP will not release any upgradations to the software but it offers additional 2 years of Extended maintainance to its customers if they are willing to take it.
SAP Software has three delivery Phases:
1. Restricted Shipment phase (2 Years)
2. Un-restricted shipment phase (5 Years)
3. Extended Maintainance (2 Years)
Restricted Shipment phase: This phase is also called as Ramp-up period. During this phase software is released to only limited circle of Customers. This phase is for 2 years.
Un-restricted shipment phase: This is the second phase of release. During this phase software is released to all the customers. This phase is for 5 years.
Extended Maintainance: After un-restricted shipment phase SAP will not release any upgradations to the software but it offers additional 2 years of Extended maintainance to its customers if they are willing to take it.
Tuesday, June 26, 2012
Some useful table names for Basis:
TSTCT
List of Transaction Codes
TBTCT, TBTCO, TBTCP
Background Jobs data is stored in these tables
USR02
Logon data
USR04
User master authorization (one row per user)
UST04
User profiles (multiple rows per user)
USR10
Authorization profiles (i.e. SAP_ALL)
USR11
Text for authorization profiles
USR12
Authorization values
USR40
Table with list of password restrictions and prohibitions
AGR_USERS
List of roles assigned to Users
AGR_T-Codes
List of all T-Codes assigned to Users
E070, E070A, E070AS, E071
Transport data is stored within these tables
TST01
Table for TemSe
PAT01
Table for Support packages and updates
PAT03
Status of Support packages and updates
T000
List of all the Clients
SNAP
ABAP dumps are stored here
TPFYPROPTY
Table with list of all dynamically switchable parameter
List of Transaction Codes
TBTCT, TBTCO, TBTCP
Background Jobs data is stored in these tables
USR02
Logon data
USR04
User master authorization (one row per user)
UST04
User profiles (multiple rows per user)
USR10
Authorization profiles (i.e. SAP_ALL)
USR11
Text for authorization profiles
USR12
Authorization values
USR40
Table with list of password restrictions and prohibitions
AGR_USERS
List of roles assigned to Users
AGR_T-Codes
List of all T-Codes assigned to Users
E070, E070A, E070AS, E071
Transport data is stored within these tables
TST01
Table for TemSe
PAT01
Table for Support packages and updates
PAT03
Status of Support packages and updates
T000
List of all the Clients
SNAP
ABAP dumps are stored here
TPFYPROPTY
Table with list of all dynamically switchable parameter
Tuesday, June 19, 2012
Some Useful Basis T-codes
SU01 - User maintainance
SU3 - Logged in User maintainance
SU10 - Mass user maintainace
SM04 - Shows list of logged in users with T-codes executed on a server
AL08 - Shows list of logged in users globally in all the instances which are active
SM02 - To send system messages
SM36 - To create Background jobs
SM37 - To monitor Background jobs
SMX - To view the status of Background jobs
RZ04 - To create Operation Modes
RZ03 - To switch Operation Modes
SM63 - To define Time table for Operation Modes
SM21 - System log. Log for all the transactions are captured here
SM22 - To view ABAP run-time errors
PFCG - Roles and Profile Maintainance
STMS - To configure Transport Management System
STMS_IMPORT - To import a Transport request
SM59 - To create RFC's
SM58 - To create transactional RFC
SM21 - To create Queued RFC
RZ10 - To create/edit any paramenter
RZ11 - To view individual parameter by name
SA38 - To view list of all the parameters
SE38 - ABAP editor screen
SE16 - To view table entries
SE93 - To create/edit any T-Code
SCC4 - To create Client
SCCL - Local Client Copy
SCC7 - Client Import
SCC8 - Client Export
SCC9 - Remote Client Copy
SCC5 - To delete a Client
SCC3 - To view Client copy logs
PFUD - Mass User comparison
SU56 - To display user context data
SU53 - To display user authorization data
SUIM - To view user change history
ST01 - System trace
ST02 - Memory tune summary
ST03 - Workload Monitor
ST05 - Performance analysis
ST06 - Operating System Monitoring
ST22 - Workprocesses Trace, Message Service Trace and Dispatcher Trace
SE06 - To view system change options
SE11 - ABAP dictionary
SE80 - Object Navigator
SCOT - To configure SMTP
SOST - To monitor External send messages
SBWP - Business Workplace
SPAM - Support Packages Manager
SAINT - To install add-ons or plugins
SM50 - Workprocesses overview
SM51 - List of SAP Servers
SPAD - To add a printer
SP01 - Spool requests are displayed
SP02 - Output requests are displayed
SM12 - To check lock entries
SM13 - To view update requests
SM28 - To check for any errors after install
SICK - To check for any errors after install
SLICENSE - To install a permanent license
SNAP - ABAP dumps are stored
SE01 - To create a transport request
SE09 - To create a change request
SE10 - To create a change request
RZ70 - To connect ABAP to SLD
RZ20 - CCMS Monitoring
RZ21 - CCMS Remote Monitoring
SGEN - Load Generator
SMSY - To generate Solution Manager Key
What is a Transaction Code ?
Transaction Code:
It is a short cut Key attached to a screen. Instead of accessing a screen through SAP Easy Access menu we can navigate to particular screen by entering Transaction Code in Context field.
Subscribe to:
Posts (Atom)