Transport query analysis

[Former Member]

Subject Matter.

The situation is familiar for any SAP consultant—transport queries are transferred to the target system with errors caused by violations of integrity of the transferred object. For example, a transferred program uses new tables (or new versions of older tables) but the target system does not “know” them, as these created/modified tables were not transferred and are absent from the query transferred with the program.

Such situations are fraught with problems: not only headaches and delays, but also more present the possibility of strategically important risks and losses.

Such risks are especially noticeable when the authors of these changes (programmers employed by the Contractor) are unable, that is to say, do not have the authority to independently transfer changes into the Customer’s target system. As a result of existing regulations, they are forced to contact the Customer’s basic consultants about these questions. Thus, a strict system of control of transferring changes is put into effect.

This situation is fraught with problems related to the loss of time and money (extension of deadlines and, as a result, terms of payment for completed work), but also can put a company’s reputation at risk. For example, unfriendly employees of the Customer have a reason to call into question the level of qualification of the Contractor’s programmers—they’re so stupid that they cannot even complete a simple transfer query! Yet the terms of the contract promised only highly qualified programmers.

As anyone familiar with the situation knows that even the most professional and experienced programmer is defenceless against such errors. There is always a risk—as a result of haste or carelessness, or because of more objective reasons e.g. the changes were made a long time ago, or due to complex interdependencies. Standard SAP tools do not offer sufficient protection.

All of this can eventually lead to real financial losses. Thus, the subject matter of this article goes beyond the scope of programmers.

However, by approaching the issue in a slightly more creative manner, it can be feasible to create tools that can help manage these risks.

The general concept of realization.

In order to analyse the integrity of queries, we must perform the following steps:

1. 1.)    Select all objects contained in the transfer query and its subqueries.
2. 2.)    Chain select all functions that are used directly or indirectly within this query and its subqueries. The topic of mutual use of functions is too vast to cover in this article. So we will limit ourselves to questions related to the use of programming functions, i.e. ABAP-code functions: АВАР-reports, АВАР-includes, classes. We will not analyse the use of data elements in table fields, domains in data elements, etc. Likewise we will also limit the types of functions used: only АВАР-includes and global types: glossary entries (database tables, structures, types of tables, pools and their components, data elements), АВАР-classes (with their components). Of course this is a limitation, but when you implement your tool and begin using it, you will see that even this limited variant “closes” 80-90% of problems. And even if this tool’s possibilities don’t cover your needs, with little effort will be able to easily build up a circle of analysed dependencies in its “image and likeness”.
3. 3.)   For those functions used that are not present in the transport query, we should a remote version comparison between systems (we will test for differences. Of course, we will compare the source system and the target system.
4. 4.)    If the function differs between systems and is absent in the transport query, we should signal the problem.

Implementation.

The analyser is carried out like a regular executed ABAP-report.

При For the conclusion of the analysis we will not use sophisticated UI elements like ALV. For our purposes, a conventional listing conclusion is sufficient.

I will deliberately be using the old-fashioned ABAP-code style (using HEADER-LINE and so on) in the interest of brevity and clarity (and in order to remove inessential structures necessary to maintain ABAP-code in a modern style). For unassisted implementation, I recommend following SAP’s recommendations related to the outdated constructions.

1. The only input parameters we need are the query number and the name of SAP system whose compatibility we want to check. One could take the name of the target SAP system from the attributes of the query, were it not for the usual the three-levelled SAP system landscape (“Development”à”Test”à”Product”). Often it is necessary to determine the integrity of the query at all transfer stages.

PARAMETERS: p_trkorr TYPE e070-trkorr    OBLIGATORY MEMORY ID trkorr " What we transfer

          , p_system TYPE e070-tarsystem OBLIGATORY MEMORY ID tarsys " Where we transfer it

          .

Chain select all functions, contained in the transferred query and its subqueries.

The transport query’s header and the hierarchy of its subqueries are kept in table E070. The number of the query/task is in field E070-TRKORR. The number of the higher query for the task (subquery) is in field E071-STRKORR.

Objects contained in the queries/tasks are kept in table E071.

Objects can be directly linked either to the “main” query or to the subqueries (tasks).

*We will form RANGES from the number of the query and will receive a list of all objects contained in the query, in the field E071- TRKORR.

DATA: ltr_korr TYPE RANGE OF e070-trkorr WITH HEADER LINE,

      BEGIN OF ltd_objk OCCURS 0,

        object TYPE e071-object,

        obj_name TYPE e071-obj_name,

      END OF ltd_objk.

ltr_korr-sign = 'I' .

ltr_korr-option = 'EQ' .

SELECT trkorr INTO ltr_korr-low

  FROM e070

WHERE trkorr EQ p_trkorr

    OR strkorr EQ p_trkorr .

  APPEND ltr_korr .

ENDSELECT .

SELECT DISTINCT

        object

        obj_name INTO TABLE ltd_objk

  FROM e071

WHERE

       trkorr IN ltr_korr

   AND pgmid    IN ('LIMU', 'R3TR')

ORDER BY OBJECT .

In Table LTD_OBJK we now have a list of all objects included in the query and its subqueries.

In this article we are limiting ourselves to the following object types:

1. 1.) АВАР-programs;
2. 2.) АВАР-code includes;
3. 3.)    Structures of global glossaries: database tables, structures, types of tables and data elements, as well as their components.
4. 4.)    Global АВАР-classes (built in SE24), and their methods;

Field value OBJECT	Object Type
PROG	АВАР-programs and АВАР-includes
TABL	Definition of tables and structures of data glossaries
TYPE	Pools (groups) of types
FUGR	Groups of functions
CLAS	АВАР-class
METH	Separate method of АВАР-class

Chain select all objects directly or indirectly used as objects within the query or its subqueries.

Insofar as we are limiting ourselves in this article only to objects used as ABAP programs (and are not considering other uses, for example, of data elements in tables), we need the data sources from which we can receive information about the use of objects as ABAP programs.

SAP offers a good tool for this task: “Usage journal.”

Data on the use of objects as programs are stores in *CROSS* tables.

Table Name	Purpose
WBCROSSI	Use of АВАР includes in programs.
WBCROSSGT	Use of global types in programs, including use of components of tables and structures. Including the use of ABAP classes, their fields and methods.
CROSS	Use of functional modules in programs. In this table, we will also find information about the use of pools (groups) of types. In addition, this table contains data about the use of various other objects types, e.g. messages, but we will not consider them in this article.

WBCROSSGT is the most interesting and varied of these tables.

In SAP, the concept of “global type” is quite broad: glossary objects, tables, structures, data elements and their components. АВАР classes are also global types.

Every line of АВАР code with access to a global type or its component is given in a line of WBCROSSGT.

АВАР Code	OTYPE	WBCROSSGT- NAME
IF sy-subrc = 0 .	SY	SY\DA:SUBRC
DATA: BEGIN OF ltd_objk OCCURS 0,         object TYPE e071-object,         obj_name TYPE e071-obj_name,       END OF ltd_objk.	TY	E071\TY:OBJECT
		E071\TY:OBJ_NAME
CALL METHOD o_grid-> set_table_for_first_display	ME	CL_GUI_ALV_GRID\ME:SET_TABLE_FOR_FIRST_DISPLAY

The field WBCROSSGT- INCLUDE contains the names of includes and programs, which refer to the global type or its component. Please note: it is not the name of the main program that is prescribed, but rather the name of the direct piece of the referring ABAP code.

Thus we can get a list of all global types involved directly or indirectly in the work of the ABAP programs, if we (beforehand) make a list of all includes involved in the program’s operations.

We simultaneously receive information about the usage of functional modules.

*We perform a search of all includes involved in program operations.

  DATA: BEGIN OF ltb_crossi OCCURS 0,

          name TYPE wbcrossi-include,

        END OF ltb_crossi,

        ltd_wbcrossi TYPE TABLE OF wbcrossi WITH HEADER LINE .

  LOOP AT ltd_objk .

    ltb_crossi-name = ltd_objk-obj_name .

    COLLECT ltb_crossi .

  ENDLOOP .

  SELECT DISTINCT * INTO TABLE ltd_wbcrossi

    FROM wbcrossi

         FOR ALL ENTRIES IN ltb_crossi

   WHERE

         include EQ ltb_crossi-name

      OR master EQ ltb_crossi-name .

* For all includes located, we perform a search of all global types used in these includes.

  DATA: ltd_wbcrossgt TYPE TABLE OF wbcrossi WITH HEADER LINE .

  SELECT * INTO TABLE ltd_wbcrossgt

    FROM wbcrossgt

                   FOR ALL ENTRIES IN ltd_wbcrossi

   WHERE include EQ ltd_wbcrossi-include .

* For all includes located we performa search of all functional modules involved.

  DATA: ltd_cross TYPE TABLE OF cross WITH HEADER LINE .

  SELECT * INTO TABLE ltd_cross

    FROM cross

                   FOR ALL ENTRIES IN ltd_wbcrossi

   WHERE include EQ ltd_wbcrossi-include .

Intermediate Results

We have received lists of the following:

1. 1.)    All objects included in the analysed query and its subqueries (tasks);
2. 2.)    Objects connected to the objects being developed.

Next, we must be guided by the following logic:

1. 1.)    If the object is located in that same query, all is well—its current version will be transferred with the objects using it;
2. 2.)    If the object is not found in that query, we must check if it should be, so that the transfer query goes smoothly. It’s obvious that if the given object’s version is identical in both systems, it won’t be necessary to transfer it.
3. 3.)    If the object used is absent in the query and its versions differ between systems, we must warn about the presence of potential problems in the transfer of such a query. It is necessary to either include such objects in the query or transfer them into the target system in advance.

Comparing object version between systems.

There is a standard way to accomplish this task in SAP: the version control system with remote inter-system version comparison.

It is possible to check for differences between versions by calling FM.

SVRS_CHECK_VERSION_REMOTE_INT

Completion of parameters:

Parameter	Description
E071_ENTRY	The parameter with the structure of table E071, but only fiels  PGMI, OBJE, OBJ_NAME have real meaning. We can get the field values by making a selection from E071 by object name (we complete these fields in any query in which it is present.
DESTINATION	The name of the RFC connection for communication with a remote system. This RFC connection is created automatically when you configure the transport system. His name is composed according to the rule ‘TMSADM@’ + SystemName + ‘.’ + DomainTransferName . The transfer domain name can be found by the name of the target system using the FM call system TMS_CI_GET_SYSTEMLIST Or one can use use FM call SVRS_GET_RFC_DESTINATION to receive the completed RFC address.
Result	If no differences are found, FM will work without error. If differences are found, EXCEPTION will appear NOT_EQUAL  – if versions are not identical NO_VERSION – if the object has not yet transferred into the target system.

However, this FM has a strange feature: in theory, the message EXCEPTION NO_VERSION will appear if the object is absent from the target system. Nonethless, it will work without error, as if the object was present in the target system and no differences had been found.

Therefore, before calling SVRS_CHECK_VERSION_REMOTE_INT we will first call FM FIND_OBJECT_40, which will check for the presence of the existence of the object in the target system:

CALL FUNCTION 'FIND_OBJECT_40'

EXPORTING

   DESTINATION                 = ‘TMSADM@’ + SystemName + ‘.’ + DomainTransferName

   OBJNAME                     = Technical name of the objext

   OBJTYPE                     = Type of object from field E071-OBJECT (FUNC, METH, etc.)

IMPORTING

   OBJECT_NOT_FOUND            = Flag: object not found in target system

Afterward, if OBJECT_NOT_FOUND is in fact empty, we will call SVRS_CHECK_VERSION_REMOTE_INT.

Victor Amosoff, ABAPFactory.com