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.
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.
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.
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.
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.
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...
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.
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).