Message_Type_X while running the infopackage

Introduction

Attempts to create/run infopackage data load terminated in Short Dump – Message Type X.  This Infopackage was working fine, until we had the Source system Upgrade.

Scenario: -

  The IP was working fine before the source system upgrade. After the system upgrade we were unable to create/run new infopackages for the datasource. We were  getting the following dump

The Step By Step procedure to analyze:-

1.    Check if the RFC connection between the source system and the BW system are working fine.

   2.     Check if the initialization request in BW and Source system in the following tables are the same.

System	Table Name
BW System	RSSDLINIT
Source system	ROOSPRMSC

   3. Check in both the tables for the respective DataSource, the request numbers are same or not.

   4.  Mismatch between the request number means inconsistency in the initialization request. This is the root cause of the problem.

Solution:-

1. )    RFC connection check in both source system and the BW system.  T-code SM59, select “Abap connection”.

Find your source/BW system and double click on that

Once you double click on the source/BW system, check for connection test and the remote connection.

Once you click on the connection test you must see

This signifies the connection between the two system are ok (Note: - This needs to be checked in both Source system and the BW system.)

   2. )    Once the RFC connection check is done we check if the initialization request in BW and Source system tables were same.

BW table: RSSDLINIT

T-Code - SE11

Give the Source system logical Name in the above screen.

Source system table: ROOSPRMSCT-Code - SE11

Give the BW system logical system name in the above screen.

We can spot from the above two tables that for the datasource DS_SCPCR_DATA the request numbers are different. This inconsistency in the initialization request led to creation of a delta queue in Source system which was not at all related to BW.

   3. )  Delete the wrongly pointing delta queue from RSA7 for this data source to refresh the entries in the Source system table ROOSPRMSC. (Note doing this  may result in the data loss. This should be done only after taking the proper approval from the business.)

    4.) Once the deletion of the wrongly pointing delta queue from RSA7 for the data source is done, delete the initialization request from the info package – Init options in BW end to refresh the BW table RSDDLINIT.

     5.)    Note: We had tried the same steps previously hoping that this would refresh the delta queue in the Source system end but it had not refreshed the delta queue.

Forced the delta queue updation by running the program RSSM_OLTP_INIT_DELTA_UPDATE in the BW system .

Upon Delta queue updation   created the initialization infopackage on this data source and ran it. Now the request number in the BW and the SRM tables matched.

6.) Once the above steps are followed , we can see the following

And now the IP's will run perfectly fine .