TRDIR Different in DEV / PROD

[hardyp180]

We have installed the free product SALT from Revelation Software Conceptes which attempst to tell us what objects are different between development test and production e.g. nothing should be in production that is not also in DEV.

My problem is not with SALT it is with our system where the entries for objects in tables like TRDIR are different between development and production, but the underlying Z objects are identical.

Does anyone knw how the TRDIR entries get populated? Is there a way to manually force a regeneration?

Cheersy Cheers

Paul

[former_member183804]

Hello Paul,

there are rules how transportable development objects (tadir) and source code artifacts (trdir) are related.

• Only few tadir object types (PROG, INTF, ..) have always identical trdir entries.
• Some tadir object types (CLAS, FUGR, ..) may have same or similiar entries.
• Some tadir object types (WDYN, ..) would have the same name only by chance.

Without knowing these rules in detail, one should not make detailed assumptions on the state.

Best Regards

  Klaus

[hardyp180]

Greetings,

So, is it normal for the TADIR or TRDIR entry to be different for a specific Z object in different systems e.g. in development there is a TRDIR entry for a Z object, it gets transported to production, in production the Z object is there and works fine, but there is no TRDIR entry.

Does that indicate a problem in my SAP system, or is this normal?

Cheersy Cheers

Paul

[former_member183804]

Hello Paul,

the TADIR is the object catalogue for transportable transport objects. In case two systems have a common transport route (e.g. dev=>test=>prod) the tadir entries shall be identical. Exceptions known to me are delays (transport not arrived) and local repairs.

The content of the program source reposistory TRDIR requires no 1:1 mapping for all of its content.

Dependend on the type of the TADIR object there are mapping rules / interpretation that expressed in code. A precise judgement for consistency needs to be aware of the mapping rules, just considering the repository is a prognosis at best.

Take for instance the implemented methods of a global class. Each method implementation is stored in a separate include beginning with the name of the class pool and with a postfix like ===CM001. The three letters at the end are most often identical but they do not need to be. Just comparing repository content is limited to count to number of such includes to check if the implemented methods relate require to use the according API.

Tschau

  Klaus

[kakshat]

Hi Klaus,

I am curious about what you said about the names of the method implementation Includes. I wonder if they can really differ between two systems if they have been transported from one system to the other. I thought when we transport a development object from one system to an exact copy (with the same name) of it is created in the target system. Isn't that the case?

[former_member183804]

Hello Kumar,

I am no expert on this but to my knowledge the name is derived from the sequence methods have been created in a particular system. If the class / methods have been transported all times there shall be no difference. In case one applies notes and local repairs the numbering scheme differs possibly.

But a difference in the numbering scheme does not hurt as it is part of the mapping logic.

The identiy of includes is an assumption that works often but there is much more complexity in real live.

Regards

[hardyp180]

I just want to restate what I am encountering.

We have Z objects transported from development to production via the normal transport mechanism. There is no external SAP system involved here, the objects are created in development and then transported to test and production.

Aftewards, although the Z items are identical in every system the TADIR and TRDIR entries for said objects are not. Sometimes there is not even a TRDIR entry for the object in production.

Is this normal, or is this a bug in our SAP system?

Cheersy Cheers

Paul

[former_member183804]

Hello Paul,

to my guts feeling the liklihood for a bug is low as long there is no indication of a functional flaw.

To have more than a feeling you need to dive in technical details. Group the differences by object type (TADIR-OBJECT).

Then do spot checks:

• does concrete object work in the businiess scenario?
  • yes => likely issue (check more objects of same type)
  • no => check trdir again, different content?
    • yes => most likely delayed / on-the-fly generation(/mapping)
    • no => maybe mapping rules in place, are the names containing GUID running number?
      • yes => most likely mapping mechanísm
      • no => Possibly inconsistency in development system? (interview author, .... )
        • yes => resolve inconsistency in dev. system
        • no => I have no clue

Regards

   Klaus

[Former Member]

This message was moderated.