IS-U data export (extraction) for EMIGALL

[Former Member]

Hi everybody,

I found few documentation/step-by-step/manuals about tr. EMIGALL (thanks to authors, especially to Fritz), but there is describet just import of data which is, I think, intuitive. But I need to help with data-export from source IS-U system - is there any easy way how to do this (see closer explanation bottom) and, of course, is there any guide/manual describing process?

My probles is that I have one IS-U with data and second, blank IS-U without data. I want to migrate data from first system to second, and I would like to use tr. EMIGALL. There is no connection between those systems (not event in the same network and building VPN between them is not an option), so only possibility is to use files (on source system export into file, and then on target system use import in EMIGALL). On both systems I have administrator privileges and I am allowed to do what I need.

[Former Member]

Hi Peter

There was/is a tool to migrate from the SAP IS-U predecessor RIVA (R/2 based utilities) to IS-U.

I am not aware of any standard tools to migrate IS-U to IS-U. From rumors I've heard there're tools supporting similar requirements, for example to create test systems that have a subset of the production system, not sure if they're file-based though. Maybe you should contact SAP directly.

In case you there aren't any tools or they don't meet your requirements:

From a development point of view you should look into the service function modules providing object data - doing the opposite of the service function modules used in EMIGALL creating the data - for example:

ISU_S_CONNOBJ_CREATE => ISU_S_CONNOBJ_PROVIDE

ISU_S_PREMISE_CREATE => ISU_S_PREMISE_PROVIDE

Put a framework around it that uses the data to create the files based on the EMIGALL customising.

Yep

Jürgen

[Former Member]

Thanks sattlerj for response, it seems that you are right (or at leasts this is the only answer I get also from other sources) - there is simply no standard extraction tool provided by SAP

[friedrich_keller]

Hello Peter,

Yes, there is no tool available for a data extraction from an IS-U system.

But you have to see it also from another prospective: Why should SAP deliver such a tool? To help customers changing to another SW solution? I don't think this is really something that is desirable in particular not for SAP. On the other hand only very few customers require an IS-U to IS-U migration. Again a reason not to invest into development due to a lack of demand.

Finally, SAP's SLO service allows a technical table-to-table data migration from one IS-U system to a second one. This tool is mostly used to decouple IS-U system due to deregulation requirements or company acquisitions.

Bottom line is: there is no complementary tool available for an IS-U data extraction. You will need to develop own custom-specific programs for data extraction.

You may investigate the report REMIG_FILE_CREATE that may support this endavor in at least helping you to create binary import files. A documentation "Guideline Simple Data Transformation" can be found at http://service.sap.com/utilities -> Technical Information Center -> Data Migration.

Kind regards,

Fritz

[Astrid_Gambill]

SAP does have a tool called TDMS (Test Data Management System) which is designed for copying datasets from system to system, and from what we're heard it is working for IS-U data.

[friedrich_keller]

Hello Astrid,

Yes you are correct. But please bear in mind that the main purpose of TDMS is to "copy" an extract of the data of a production system to a smaller system - otherwise you would do a homogenous system copy. In addition and to the best of my knowledge about TDMS for Utilities, no fully consistent excerpt is created. The aim is to extract consistent data from the biggest database tables while smaller tables are copied entirely.

Cheers,

Fritz

[Former Member]

Fritz/Everyone,

We are facing data extraction issue in BW.

We initially migrated data through Emigall, run initialized extraction, data extracted to BW successfully.

After 3 months, more migration took place through Emigall (as a part of Roll Out) but now we are unable to fetch the Master Data created as a result of Mass Migration through Emigall.

Our Data Team has no idea whatsoever about BW and its related objects in Emigall,

Please suggest what to do? I have investigated on forums, and I found that Emigall doesnot fill all requires structures due to which it is happening.

[Former Member]

Hi Umair

It would have been better to open a new thread, as people don't tend to look much into already answered threads.

Problems like this one should have been addressed in the data migration strategy document (Blue Print Phase) and not after the first go-live. This would have given you enough time and thought about a practical solution, including time to develop the process and thorough testing. Anyway...

Problem

The data migration tool does not populate the BI delta queues for performance reasons, therefore you can't do a "standard" delta load for the newly migrated data. Here the code example for Installation:

FUNCTION isu_db_eanl_update.
...
  CALL FUNCTION 'ISU_MIG_STATUS'
    IMPORTING
      y_active = mig_active.
  IF NOT mig_active IS INITIAL.
    RETURN.
  ENDIF.
...
* Update to BW Delta Queue of Installationdata (12.03.2007 Tributh)
  CALL FUNCTION 'ISU_BW_INSTALLA_DELTA_WRITE'
    EXPORTING
      x_upd_mode      = x_upd_mode
      x_eanl          = x_eanl
    TABLES
      xt_eanlh_delete = xt_eanlh_delete
      xt_eanlh_update = xt_eanlh_update
      xt_eanlh_insert = xt_eanlh_insert.

ENDFUNCTION.

As the Active flag is used pretty much everywhere in the IS-U code, so there's no way you can simply turn the active flag off to create the delta queue information.

Solution

In one of my previous project we had exactly the same scenario: Phased migration approach plus load into BI for each partial migration.

My solution for this problem was:

Create a program that saves all the latest/highest number of all number range intervalls for all the objects you have to transfer into BI. You run this program before you start the migration into IS-U and you run it afterwards. This determines the range of numbers you have to transfer into BI. You either down-upload those ranges to BI or have a fancy RFC call to populate a custom table there.

Within BI you create a full load data source that extracts all the objects according to the ranges you've transfered from your IS-U system.

This solution worked very well for us (17 million customer accounts plus related data spread over 13 or 14 migration events).

Yep

Jürgen