The Problem: It was for one of the training sessions, I was expected to conduct, I was preparing a data flow for showing the data load from flat file up to the cube, routing the flow through DSO. I was creating the flow on my company’s Training Server, which pointless to say is not very closely monitored and is connected to many source systems, which are added and removed frequently.
So, I created the entire flow using a flat file data source and a standard DSO. As it happens, on executing the info-package, the data got loaded into the PSA. From there, it was designed to load Data, on to the DSO through DTP, by manual execution solely for demonstration purpose.
But whenever I executed the DTP, it gave me ITAB_DUPLICATE_KEY dump with a short text of “A row with the same key already exists” (See Figure-1 ABAP Dump).
Figure 1 -ABAP Dump
All the settings were perfectly fine, it was for the very first time I was loading the data. Still, I checked and rechecked it, and after checking it for the umpteen times I was baffled and totally perplexed. I was under the assumption that there is a row in DSO table which already has the same key, which I was not able to find or locate.
I went to the extent of manually checking all the activation queue, under New data, but nothing was there. The only thing that showed the way forward was the ISOSMAP table which was figuring in the dump and it led me to SAP Note 613449.
The Cause: Using a BW client, having many different source systems attached, which get added and removed on a frequent basis, is fraught with perils of unused objects getting left behind because of one reason or another, creating a duplicate entry in RSISOSMAP table and making system inconsistent. Normally they will have same transfer structure and same data source, but coming from two different source systems, hence creating duplicity and this is primarily responsible for the dump ITAB_DUPLICATE_KEY.
Solution: Fortunately SAP has provided a solution in terms of a report Program RSAR_RSISOSMAP_REPAIR to amend and remove duplicity from table RSISOSMAP. So we go to ABAP Editor: Initial Screen and enter the program name as shown in the :
FIGURE 2- ABAP Editor: Initial Screen
figure 2 – ABAP Editor:Initial Screen and execute it.
It immediately takes us to the next screen providing a selection for Repair Mode. We will select that option as shown in Figure-3 (Selection for Repair mode). Once we execute it, after selecting the repair mode option,
it shows us the report with duplicate entries for same data source (under the heading OLTPSOURCE) but from different Source Systems (under the heading LOGSYS) having duplicate Transfer Structure (Under the heading TRANSTRU) as can be seen in the Fig-4 (Report RSISOMAP)
Figure 4 – Report RSISOSMAP
Now, all that we have to do is, remove the unwanted entry for the source system which we are not using, like in my case Source System 100. So now, we go to Table RSISOSMAP by executing Tcode SE16. See Figure-5 Data Browser: Initial Screen and explore that particular table
Figure 5 – Data Browser: Initial Screen
On the selection screen for table RSISOSMAP we will enter the Data-source name which is occurring in duplicity as evident from the report and execute it. See Figure-6
Figure 6 – Selection screen for Table RSISOSMAP
Now we will delete the entry for the source system that is redundant or not wanted and all our problems will be resolved.
Figure 7 – Duplicate entries Table RSISOSMAP