Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Monitoring Tools

Objectives

After completing this lesson, you will be able to:

List selected monitoring tools and explain their use
Explain the content of the transport directory
Troubleshoot typical import errors

Monitoring Tools

The Transport Management System (TMS) provides various tools with which you can monitor transport activities in your transport domain.

Monitoring Tools

The tools can be accessed as follows (some of them are shown in the figure above):

In transaction STMS, choose Overview → Systems from the menu and mark one or more SAP systems:
- RFC connection test: To check RFC destinations for all or just one system within the transport domain in both directions, choose SAP System → Check → Connection Test.
- Transport directory check: To verify the availability of the transport directories for all or just one system within the transport domain, choose SAP System → Check Directory → Transport Directory.
- Transport control program check: To check the transport control program tp for all or just one specific SAP system within the transport domain, choose SAP → System → Check → Transport Tool.
In transaction STMS choose Overview → Imports from the menu and double-click the SAP system in question:
- Import history: To display the import history, choose the menu path Goto → Import History.
  Note
  The import history is collected from the log file ALOG and is kept in the tables TPALOG and TPALOGHDR. For details, see SAP Note 375230 – TMS: incomplete import history.
- Import monitor: The transport control program tp stores status information in the database before and after each import step. This status information is read and displayed by the import monitor which can be accessed by choosing the menu path Goto → Import Monitor.
- Import queue consistency check: To check if the data files and cofiles of transport requests in an import queue exist in buffers of the transport directory and can be read, choose the menu path Queue → Check → Consistency.

Transaction /SDF/TRCHECK or report /SDF/CMO_TR_CHECK provides various proactive checks for objects in transport requests. It predicts transport related errors before the requests are imported into a target system. Typical use cases are that developers check their transport request in the development system, before they release it and import it into the test system. Or a transport manager checks a number of transport requests in a test system, before they will be imported into the preproduction or production system. The checks are delivered with the ST-PI Plugin. For more information, see SAP Note 2475591 – Transport Check Report, which also lists required SAP Notes.

These checks are available:

Cross Reference: For all objects in the selected transport requests, the referenced objects are identified by a where-used-analysis. If the referenced objects are not included in the transport requests, we compare their versions between the reference and target system. If the versions are different or if the referenced objects do not exist in the target system, it will be highlighted as a potential error. In addition we show the last transport requests for the missing object versions. This check works for ABAP repository , data dictionary, customizing objects, SAP Notes and BW objects.
Sequence Check: The sequence check identifies other transport requests with identical objects which have been released in the analysis period, but have not yet been imported into the target system.
Cross Release Check: If the current system and the target system are on different support package levels, this check identifies critical objects in the selected transport request, which belong to inconsistent software components and should not be imported into the target system - for example SAP Notes. For customizing objects we compare in addition if the table structure is different in the reference system and target system.
Import Time in Source System: The import time of the selected transport requests in the source system is summed up. For this check the source system should be a test system in which the transport requests have already been imported.
Online Import Criticality: This check estimates the criticality of an import when the end users are working in the production system. As a prerequisite you must first collect the table call statistics and the report execution statistics in the production system for one week. The collection of the usage statistics must be triggered in the production system with the report /SDF/OI_ADMIN. You must first activate the Usage and Procedure Logging (UPL) in the production system. The report identifies the dependent objects of the transported objects and checks the usage profile of all objects. For tables, the number of table reads per hour, table writes per hour and the table size in KB is shown in the output. For reports, the number of report execution steps per hour based on the UPL data is shown. In addition, you can maintain a list of critical objects with regard to online import in table /SDF/OI_CRITOBJ in the production system. These objects are then also shown in the result.

Checking for Critical Objects

There are two options to check for critical objects:

Before the import of transport requests into the target system:: This option has to be performed manually and is only a display of the list of transport requests that contain critical objects.
During the release of the transport request:: This option is performed automatically, if tp parameter CHK_CRIOBJ_AT_EXPORT is set to W (warning) or E (error).

To check if the transport requests in an import queue contain critical objects that should not be imported into the target system, go to the Import Overview (transaction STMS, menu path Overview → Imports), double-click the system in question and choose Queue → Check → Critical Objects from the menu. The object lists of the transport requests are checked to see if they contain critical objects. The result is displayed in a hierarchical list. Transport requests containing critical objects are marked with the appropriate icon. The critical objects are highlighted in color.

Before performing this check, you must have maintained which objects are classified as critical. For this, you must be logged on to the transport domain controller system. The information about critical objects is distributed to the whole transport domain when you save your changes.

To display or maintain the critical transport objects defined for the transport domain, call transaction STMS on the transport domain controller system. Choose the menu path Overview → Imports and then the menu path Extras → Critical Transport Objects.

Note

You can also check requests for critical objects in the QA worklist. This supports the decisions you make on approving or rejecting transport requests.

If you want to check the whole QA worklist for critical objects, enter QA worklist and choose the menu path Worklist → Check → Critical Objects. You may need to confirm a dialog box. An overview of the transport requests with critical objects appears. If you only want to check certain transport requests for critical objects, you may filter them in the display.

Only objects of the form Object type = R3TR are checked as transport objects. Transport objects that start with LIMU are sub-objects of a repository object with an object directory entry. To check these, you must find out the object directory entry, and enter it in the table of critical objects.

Hint

Interesting objects to be classified as critical, would be, for example, R3TR XPRA (XPRAs) or R3TR TABL (table definitions) or R3TR TABU (table contents, for interesting tables).

Code Freezing and Testing

To ensure a stable test and development environment, use a development deadline to freeze work on objects in the development system until the completion of the quality assurance verification.

Follow this procedure during object development and testing:

Release the transport requests containing the developed objects.
Freeze development of the objects in the development system.
Import the objects and verify the changes in the quality assurance environment.
Sign off the changes.
If necessary, allow further development on the objects in the development system.

With the following tools, an administrator can force code freezing for an SAP system landscape. There are two main options:

Stop exports by creating a file T_OFF.<SID> in transport directory/usr/sap/trans/bin. The first line of this file will be displayed when you start a release of a transport request from the Transport Organizer.
Stop imports by creating a file NOIMPORT.<SID> in transport directory /usr/sap/trans/tmp. The contents of this file are not evaluated.

When an object has gone through the error fixing cycle, it is included in at least two different transport requests within the import queue of the production system: the original transport request and the transport request containing the fix. If you import the complete import queue, using Import all requests into the production system after sign-off, the object from the original transport request has no impact on your production environment.

Note

SAP recommends transporting all transport requests of a whole CTS project together in a single step when all objects are in an acceptable state rather than each single object as soon it is ready.

Transport Directory Naming Conventions

Because the transport control program tp runs on many different operating systems, restrictive naming conventions are required. Transport requests are always represented in the following format <source SID>K9<5 digits or characters>, where <source SID> is the SAP system in which the transport request was created, and K9 indicates a customer transport request. The five digits form a serial number, which can be expanded using characters.

The transport directory contains subdirectories, such as actlog, bin, buffer, coflies, data, log, sapnames, tmp, and EPS.

actlog

This subdirectory contains files for the tasks of the transport requests and the transport requests itself. A file is created for each transport request and for each task for which actions have taken place, and is updated when a new action takes place, for example, the creation or release of a transport request.

bin

This subdirectory contains the configuration files for the transport domain.

buffer

This subdirectory contains a transport buffer file <SID> for each SAP system. When a transport request is released, the transport buffer file of the target systems is updated.

cofiles

This subdirectory contains command files named K9<5 digits>.<source SID>. They contain, for example, a list of the performed import steps.

data

This subdirectory contains files named R9<5 digits >.<source SID> containing the exported objects.

log

This subdirectory contains all log files, such as ULOGs, ALOGs, SLOGs, and log files named

<source SID><action>9<5 digits>.<action SID> for each executed step (for example, with <action> = I for main import or A for activation) and
<action><date>.<action SID> for steps that are collectively executed, for example for step structure conversion (N) or step move nametabs (P).

sapnames

This subdirectory contains files named after the user's log on name (without any non-standard characters). A file is created for each SAP system user, who works with the CTS, and is updated when a transport request is released. Note that for repair-related transport requests, a file for the owner of the repaired objects is created as well. For more information, see SAP Note 2379949 – sapnames logging.

tmp

This subdirectory contains log files before they are moved to the log directory.

EPS

This subdirectory (Electronic Parcel Service) (among others) contains the subdirectories in and (optional) download, to which SAP Support Packages can be copied in order to apply them with the SAP Support Package Manager (transaction SPAM).

Troubleshooting Steps

Log Files

The various transport tools write a log for each transport action to the transport subdirectory tmp. After completion of this step, tp moves these logs from tmp to log. The log files are named <source SID><action>9<5 digits>.<target SID>, where <action> is represented by a single character and <5 digits> is taken from the corresponding transport request.

Each of those log file can be displayed from within in the SAP system. By expanding the log display, you can choose different detail-levels in the log file. The possible levels are as follows:

Performed actions and return code
Additional error messages
End-user logs
Details for developers and hotline

For long-running imports, it may be helpful to monitor the log files written at the operating system level. All logs in the transport environment are stored in the transport subdirectory log. These logs include logs created by tp (ULOG, SLOG and ALOG), and logs created by the various transport tools.

The current ULOG file records all tp commands that are free of syntax errors, and is named using the name convention ULOG<YY>_<Q> (YY is the year, Q is the quarter of the year). Each line in the ULOG file represents a tp command.

The SLOG file is used to monitor the transport activities of a specific SAP system. It contains a general overview of performed transports indicating the return code and thus the success of each transport. The name of the SLOG file can be set as tp parameter using the global tp parameter SYSLOG. The default setting is SLOG<YY><WW>.<SID> (YY is the year, WW the calendar week).

The ALOG file records the return code for all transport steps handled in the common transport directory. The name of the ALOG file can be set as tp parameter using the global tp parameter ALLLOG. The default value is ALOG<YY><WW>.<SID>.

Return Codes

tp receives return codes from all the transport tools involved in an import process. tp's own return code is interpreted as follows:

0 to 16 indicate the maximum value of all return codes from transport tools.
17 to 99 are values that are calculated from the return codes of the transport tools and a tp warning, for example, the transport buffer of the target system has no write permission.
100 to 199 indicates tp warnings. tp warnings mean that something went wrong and tp could not perform all the tasks. 100 to 149 are normal tp warnings, for example, RDDIMPDP cannot be triggered by sapevt. Return codes of 150 to 199 are rare and indicate incorrect operation by a user. For example, a return code of 152 is received if tp tries to import a transport request that is not included in the transport buffer.
200 or more indicates tp errors. For example, if a file could not be accessed as required by the import process, the return code is 212.

The accompanying text is more significant than the value of a return code. To display the text of a specific tp return code, use the tp command tp explainrc <value of return code>.

Note

For more information, see SAP Note 2878102 – Meaning of tp return code.

Troubleshooting

The first step in troubleshooting transport errors is to use the alert monitor, which records all TMS transport actions. The alert monitor is available in transaction STMS by choosing the menu path Monitor → TMS Alerts → TMS Alert Viewer. The information displays the date and time, the user name, the TMS status message, and the target SAP system. To display the full text of an error message, double-click the error message.

More detailed information can be seen in the SLOG file, which is used to monitor the transport activities of SAP systems and to determine the success of import requests.

If import failures are recorded in the SLOG file, drill down to the ALOG file and locate the import step that produced the return code listed in SLOG.

Use the ALOG file to identify the detailed log file, which is written for each step of a transport request. These log files can also be accessed from the Transport Management System (transaction STMS). To locate the log file for the transport request that produced an error, use the ALOG file.

All log files that are not dependent on specific transport requests, such as the log files for structure conversion and move nametabs can be accessed both from the operating system level in the transport directory and from the import queue of the SAP system in question (in transaction STMS) by selecting a transport request, choosing Logs and then expanding the folder Import steps not specific to transport request.

Additionally, you can check whether the import dispatcher RDDIMPDP is scheduled correctly and is event-triggered. Use the job overview SM37 to monitor the related background jobs (RDD*). Here, enter RDD* in the Job name field and an asterisk * both in the User Name and in the Or after event field.

Problems might result from:

Wrong versions of tp or R3trans
tp not running, as in UNIX (ps -ef | grep tp)
Permission or share problems with the common transport directory
No free disk space

When analyzing a problem, compare the logs and transport buffer entries with the entries in tables TRBAT and TRJOB (using transaction SE16). If required, insert the transport request or header in TRBAT and restart RDDIMPDP.

Hint

If a communication problem between tp and the SAP system is indicated, try to start sapevt at operating system level to trigger RDDIMPDP.

Note

Because sapevt communicates in an unauthorized way with the message server, the program may no longer function in general if secure message server communication is active. An exception is when sapevt is called on the application server using the operating system user that owns the SAP system. In this case, the parameter pf=<instance profile> must also be passed. For more information, see SAP Note 2000417 – Problems with SAPEVT as of kernel release 7.40.

Troubleshoot Import Errors

Business Example

When imports are successful, it is essential to analyze the import errors and solve the problem.

Task 1: Review the Log Files

Review the export and import files in the transport directory

Steps

You want to see transport logs generated by a transport request during export and import within your SAP system. To which SAP system (S4D, S4Q, ...) do you have to log on?
1. The systems S4D, S4Q, and S4P share the same transport directory and, therefore, are in the same transport group. This means that the SAP system from which you view the transport directory doesn't matter.
  Note
  If your transport domain contains multiple transport groups, you need to log on to an SAP system that accesses the transport directory where the log files reside. For example, in this course, the external SAP system PRD has its own transport directory.
Look at the files in the transport directory related to one of your released and exported transport requests. Use transaction AL11 to view files at file system level.
1. Log on to the development client in the development system S4D using the credentials provided by your instructor.
2. Start transaction AL11 and double-click the directory parameter DIR_TRANS. The following files are created or modified in the transport directory during the export process for transport requests.
  Note
  The solutions use the transport request named S4DK900815 as an example. Substitute the name of this request with your transport request.
  - The buffer subdirectory contains control information on which transport requests are to be imported into which SAP systems and the order in which imports should take place. Each buffer file is named with the <SID> of the corresponding SAP system. Depending on the transport actions during the class, you may see an entry in the buffer file of S4Q. If you're using transport target groups to import into multiple clients, there may be multiple entries, one for each client in the transport target group.
    Note
    Comment lines begin with a number sign (#). Comments are used for informational purposes only.
  - The cofiles subdirectory contains important control information on how to import and process transport requests. You can find the command file K900815.S4D in this subdirectory.
  - The data subdirectory contains data file R900815.S4D. This file stores all the data that was extracted from the development system based on the objects recorded in the transport request.
    Note
    The data files are not in character format; therefore, their contents cannot be seen using transaction AL11.
  - The log subdirectory contains transport logs, trace files, and statistics. The fourth letter of the file name starting with the SID of the development system specifies the step that was performed. The <SID> at the end of each filename specifies the SAP system on which the actions were performed. The following example log file is written during the export process of transport request S4DK900815:
    S4DE 900815.S4D : export log file
  - The sapnames subdirectory contains information for each SAP user who has released a transport request or who owns repository objects that have been exported in transport requests. Select the file that corresponds to your user ID (without any special characters).
Look at the files in the transport directory related to one of your imported transport request. Use transaction AL11 to view files at operating system level.
1. If you are not logged on already, log on to the development client in the development system S4D using the credentials provided by your instructor.
2. Start transaction AL11 and double-click the directory parameter DIR_TRANS. The following files are created or modified in the transport directory during the import process for transport requests.
  Note
  The solutions use the transport request named S4DK900815 as an example. Substitute this request with your transport request number.
  - The subdirectory buffer contains a buffer file for each SAP system (named with the corresponding <SID>). If you choose S4Q, you can see request S4DK900815 still listed, if the transport request was imported using the preliminary import functionality. After import into S4Q, an entry for the transport request appears also in the buffer file of system S4P.
    Note
    After the (final) import into the SAP system using the "fully loaded truck" (Import All Requests), the entry disappears from the buffer file.
  - The log subdirectory contains log files written during both the export and import process. Examples of log files that may be written during the import process of transport request S4DK900815 include:
    - S4DH 900815.S4Q – dictionary import log file
    - S4DA 900815.S4Q – dictionary activation log file
    - S4DI 900815.S4Q – main import log file
    - S4DV 900815.S4Q – versioning log file
    - S4DR 900815.S4Q – user-defined activities
    - S4DG 900815.S4Q – generation log file
  Note
  Each transport request requires different import phases, and log files are written only for the phases required by that transport request. Some import phases are generic and don't create individual log files for each transport request, but one log file for the import phase per day.

Task 2: Troubleshoot the First Import Problem

Steps

While the instructor imports the transport requests into the quality assurance system S4Q, monitor the import process.
1. Log on to SAP system S4Q, client 100 with the credentials provided by your instructor.
2. You can monitor the import process for example in one of the following ways:
  - Start transaction STMS, choose the menu path Overview → Imports, double-click the line for system S4Q and choose the menu path Goto → Import History. Scroll down to the end of the list (if necessary). Now, you can directly see the return code of the transport requests in the import queue. By double-clicking the symbol for the return code, you can see the detailed log files for this transport request.
  - Start transaction STMS, choose the menu path Overview → Imports, double-click the line for system S4Q and choose Goto → Import Monitor from the menu. The Import Monitor shows the current import process. To follow the progress of the import, choose Refresh (you may need to expand the corresponding folder).
  - Start transaction STMS, choose the menu path Overview → Imports, double-click the line for system S4Q and choose Goto → tp System Log from the menu. Scroll down to the bottom of the SLOG listing. To follow the progress of the import, choose Refresh.
  - From this tp System Log: System S4Q screen, choose Goto → Transport Steps from the menu. Scroll down to the bottom of the ALOG listing. To follow the progress of the import, choose Refresh. By double-clicking the return code, you can see the detailed log files for this transport request.
The import monitor reports a return code 0008. What import phase and/or transport request has caused the import error?
1. To check whether there are obvious setup errors, start transaction STMS, choose Monitor → TMS Alerts → CCMS Alert Monitor and drill down to the S4Q branch of the tree. No configuration errors are recorded (folder Change & Transport System → S4Q → <domain name> → S4Q.<domain name> → S4Q.<domain name> - Configuration).
2. To determine the success of imports, in transaction STMS, choose the menu path Overview → Imports, double-click the line for system S4Q and choose Goto → tp System Log from the menu. You can see, as one of the last steps, an imp all (import all) or an imp subset, depending on the import strategy, that has ended with a return code 0008.
3. To view the action log file ALOG, choose the menu path Goto → Transport Steps. To locate the transport request or generic phase that has caused the return code 0008, scroll to the bottom of the listing and check the return codes of all individual transport steps. You can now detect the transport request that has caused problems, displaying a return code of 0008 (error) for step G (Generation of Programs and Dynpros).
How can you locate the log files for the transport request that has produced the import error?
1. Following the previous step, in the ALOG double-click the field containing the return code 0008.
  Hint
  You can also use a different approach. As long as the transport request is still in the import queue, you can directly reach the detailed log files by double-clicking the symbol for the return code of the transport request (make sure that any existing filter for a CTS project have been deleted). If they are no longer in the import queue because they have been imported successfully, you can find them in the Import history. You can reach the Import history from the import queue by choosing the menu path Goto → Import History.
2. Double-click the link to the log line Generation of Programs and Dynpros and expand the resulting log display (choose Expand All).
  The log displays that there Is a syntax error in program ZPGM3.
In real life, how would you correct this error?
1. To correct the error, you would first correct the syntax error in the development system from which the transport request was imported. Corrections should always be made in the development system.
2. Then you would use the program check to ensure that the program is correct. Record your changes in a transport request.
3. Finally, you would release and export the resulting new transport request in the development system. Then import the transport request with the corrected object into the target system.

Task 3: Troubleshoot the Second Import Problem

Steps

While the instructor imports the transport requests into the quality assurance system S4Q, monitor the import process.
1. If you have not yet already logged on, log on to the SAP system S4Q, client 100, with the credentials provided by your instructor.
2. You can monitor the import process for example in one of the following ways:
  - Start transaction STMS, choose the menu path Overview → Imports, double-click the line for system S4Q and choose the menu path Goto → Import History. Scroll down to the end of the list (if necessary). Now you can directly see the return code of the transport requests in the import queue. By double-clicking the symbol for the return code, you can see the detailed log files for this transport request.
  - Start transaction STMS, choose the menu path Overview → Imports, double-click on the line for system S4Q and choose Goto → Import Monitor from the menu. The Import Monitor shows the current import process. To follow the progress of the import, choose Refresh (you may need to expand the corresponding folder).
  - Start transaction STMS, choose Overview → Imports, double-click the line for system S4Q and choose Goto → tp System Log from the menu. Scroll down to the bottom of the SLOG listing. To follow the progress of the import, choose Refresh.
  - From this tp System Log: System S4Q screen, choose Goto → Transport Steps from the menu. Scroll down to the bottom of the ALOG listing. To follow the progress of the import, choose Refresh. By double-clicking the return code, you can see the detailed log files for this transport request.
The import monitor reports a return code of 0008. What import phase or transport request has caused the import error?
1. To determine the success of imports, in transaction STMS choose the menu path Overview → Imports, double-click on the line for system S4Q and choose Goto → tp System Log from the menu. You can see, as one of the last steps, an imp all (import all) or an imp subset, depending on the import strategy, that has ended with a return code 0008.
2. To view the action log file ALOG, choose the menu path Goto → Transport Steps. To locate the transport request or generic phase that has caused the return code 0008, scroll to the bottom of the listing and check the return codes of all individual transport steps. You can now detect the transport request that has caused problems, displaying a return code of 0008 (error) for A (ABAP Dictionary Activation).
How can you locate the log files for the transport requests that produced import errors? What are the errors that are reported?
1. Following the previous step, view the ALOG (or the return code in the import queue) and double-click the field containing the return code. On the resulting screen, double-click the log in line ABAP Dictionary Activation.
2. Choose Expand All to expand the log file completely.
3. Scroll down. The red lines indicate the root cause. During the ABAP Dictionary Activation step of the import process, the SAP system detected that either the field's component type of a table from the transport request or its underlying domain is either not active in the ABAP Dictionary in S4Q, or does not exist. Therefore, the runtime object (nametab) of the table could not be generated and the table has not been activated.
What has caused this error? How could it have been prevented?
1. This error probably occurred because the table and the corresponding component type (data element) were developed and transported in two different transport requests, and the data element was not imported in the same import step as the table that refers to the data element.
  Hint
  Such issues can occur if imports of single transport requests are triggered and the correct sequence is not considered.
2. To prevent such issues, developers should record all related objects in the same transport request to ensure proper activation. Transport requests should always be mapped to a CTS project. Using a CTS project makes it easier to see which transport requests belong together and, therefore, should be transported together.
In real life, how would you correct this error?
1. Import the transport request that contains the missing data element. Then import the transport requests that belong together, in on step into the subsequent SAP systems.
  Hint
  Use CTS projects in transport requests and the import of complete CTS projects to avoid these kinds of problems.

Next lesson