The EMIGALL projects can be compared in Mass Processing to check if the Rules and other aspects match up with source system.

The Transaction for that is EMIGCOM.

As evident from the screen we can do a single object comparison as well as mass comparisons. The design of the T-Code is RFC based so the RFC connection to the system has to be preconfigured. For mass comparisons (Project Based) select the radio button as shown above and execute (F8).

A sub-screen comes up as shown below:

Enter the comparison Company Object and the remote system (destination system) to which we have to do the comparison with.

This generates a report that summarizes the status of each object after the comparison is done.

We can then double click and check individual objects with differences (Marked by Red status). Each Object comparison summary is given under the following categories given in the below screen shot.

The comparison is categorised into:

  • Dates and Events
  • Autodata and Field Rules

The Dates and Events category does a detailed comparison of all the events and Object Definition parameters. We can see the field level comparison details as well when we click the individual categories.

The first is the Migration Object Definition. This deals with the very basic Object definition details.

The Migration Object definition is the comparison of the object definition

The next is the Data for Disconnection Status node. This node details the disconnection status details:

The Service module interface details are also visible after the comparison. This gives a comparison of all the service module related comparison.

Also the same is applicable for the Events as well.

Even the basic detail of the event is visible:

Next we move to the comparison of the Auto-data Structures, its fields and their related comparisons from rules to attributes.

The summary is given and we can easily point out the Auto-data structures that do not match up in two systems. Now this comparison is not only that of the basic structure but also of their attributes like what rule is applied, what processing types and other attributes as well.

So let us consider the VKP Auto-data structure and go into the details of why it’s not ok. Opening that node gives us a ready indication that it’s an issue with the Field Rules.

Now opening this node gives us a detailed look into each field and its related attributes and rules.

Now we see that filed CMPGRP is not ok. Opening that node further gives us an insight into the missing ABAP instructions

On choosing the view () option we see the difference. It takes us to the split screen editor and we see the missing code

Now we shall see what other forms of comparison it summarizes. The scenarios of field PAYDATE and field PAYDATEALT are taken as example.

In case of field PAYDATE we see the ABAP Instructions (meaning code snippet) is OK but it still has error. If we check the detailed view () we shall see that there is a difference in the processing type one is Type 4 (i.e. Rule) and the other is Type 3 (Transfer) hence the comparison gives error.

Now let’s analyze the other field PAYDATEALT. We see that in this case there is no difference in processing types, but still there is an issue with it.

We notice the difference in Generate category this is ‘X’ in one and null in other. This actually indicates that the field in included for migration in one system and excluded in other.

This relates back to the Control Data section of field maintenance in EMIGALL.

Another scenario that we can encounter is the use of Alternate Field Length mismatch. A field of MENGE is considered below.

When we check the details we can see the mismatch.

This relates back to the below settings used in Field maintenance screen.

Another scenario that we can encounter is that the rule is there but there is a difference in the rule and the rest if the attributes are OK. This is indicated by at summary level Compare Autodata and Field Rules and by symbol at the rule level.

When we see the detailed view () it displays the code mismatch in split screen editor.

Also the T-code has provision to choose what nodes we want to see in the comparison report. The object view has the options of Individual & Standard.

The Individual option allows us to set filter to see only the nodes we want where as the Standard one displays all. The complete list of comparison parameters are given below.

There is also a provision to display non-generated fields via the menu option.

This will display the comparison of non-generated fields for that Object.

This will help us to compare objects during the migration to check them quickly for any anomalies.



To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply