You are on page 1of 17

BI Content Data Flow Migration

Best Practice





BI Content Data Flow Migration -
Best Practice







Topic Area:
Business Content and Extractors




Version 1.0
March 2012

i
© Copyright 2012 SAP AG. All rights reserved.
No part of this publication may be reproduced or
transmitted in any form or for any purpose without the
express permission of SAP AG. The information contained
herein may be changed without prior notice.
Some software products marketed by SAP AG and its
distributors contain proprietary software components of
other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are
registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5,
System p, System p5, System x, System z, System z10,
System z9, z10, z9, iSeries, pSeries, xSeries, zSeries,
eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400,
AS/400, S/390 Parallel Enterprise Server, PowerVM,
Power Architecture, POWER6+, POWER6, POWER5+,
POWER5, POWER, OpenPower, PowerPC, BatchPipes,
BladeCenter, System Storage, GPFS, HACMP, RETAIN,
DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex,
MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity,
Tivoli and Informix are trademarks or registered
trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the
U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are
either trademarks or registered trademarks of Adobe
Systems Incorporated in the United States and/or other
countries.
Oracle and Java are registered trademarks of Oracle.
UNIX, X/Open, OSF/1, and Motif are registered
trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame,
WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or
registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign,
SAP BusinessObjects Explorer, StreamWork, SAP HANA,
and other SAP products and services mentioned herein as
well as their respective logos are trademarks or registered
trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo,
BusinessObjects, Crystal Reports, Crystal Decisions, Web
Intelligence, Xcelsius, and other Business Objects products
and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of Business
Objects Software Ltd. Business Objects is an SAP company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services
mentioned herein as well as their respective logos are
trademarks or registered trademarks of Sybase, Inc. Sybase
is an SAP company.

All other product and service names mentioned are the
trademarks of their respective companies. Data contained
in this document serves informational purposes only.
National product specifications may vary.
These materials are subject to change without notice. These
materials are provided by SAP AG and its affiliated
companies ("SAP Group") for informational purposes only,
without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with
respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the
express warranty statements accompanying such products
and services, if any. Nothing herein should be construed as
constituting an additional warranty.
These materials are provided “as is” without a warranty of
any kind, either express or implied, including but not
limited to, the implied warranties of merchantability,
fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including
without limitation direct, special, indirect, or consequential
damages that may result from the use of these materials.
SAP does not warrant the accuracy or completeness of the
information, text, graphics, links or other items contained
within these materials. SAP has no control over the
information that you may access through the use of hot
links contained in these materials and does not endorse
your use of third party web pages nor provide any warranty
whatsoever relating to third party web pages.
SAP NetWeaver “How-to” Guides are intended to simplify
the product implementation. While specific product
features and procedures typically are explained in a
practical business context, it is not implied that those
features and procedures are the only approach in solving a
specific business problem using SAP NetWeaver. Should
you wish to receive additional information, clarification or
support, please refer to SAP Consulting.
Any software coding and/or code lines / strings (“Code”)
included in this documentation are only examples and are
not intended to be used in a productive system
environment. The Code is only intended better explain and
visualize the syntax and phrasing rules of certain coding.
SAP does not warrant the correctness and completeness of
the Code given herein, and SAP shall not be liable for errors
or damages caused by the usage of the Code, except if such
damages were caused by SAP intentionally or grossly
negligent.
Disclaimer
Some components of this product are based on Java™. Any
code change in these components may cause unpredictable
and severe malfunctions and is therefore expressively
prohibited, as is any decompilation of these components.
Any Java™ Source Code delivered with this product is only
to be used by SAP’s Support Services and may not be
modified or altered in any way.

ii

Document History
Document Version Description
1.00 First official release of this guide




iii

Typographic Conventions
Type Style Description
Example Text Words or characters quoted
from the screen. These
include field names, screen
titles, pushbuttons labels,
menu names, menu paths,
and menu options.
Cross-references to other
documentation
Example text Emphasized words or
phrases in body text, graphic
titles, and table titles
Example text File and directory names and
their paths, messages,
names of variables and
parameters, source text, and
names of installation,
upgrade and database tools.
Example text User entry texts. These are
words or characters that you
enter in the system exactly as
they appear in the
documentation.
<Example
text>
Variable user entry. Angle
brackets indicate that you
replace these words and
characters with appropriate
entries to make entries in the
system.
EXAMPLE TEXT Keys on the keyboard, for
example, F2 or ENTER.

Icons
Icon Description

Caution

Important

Note

Recommendation or Tip

Example





iv
Table of Contents
1. Business Scenario............................................................................................................... 1
2. Background Information ..................................................................................................... 1
3. Prerequisites ........................................................................................................................ 1
3.1 Know What Would Be Migrated .................................................................................... 2
4. Step-by-Step Procedure ...................................................................................................... 3
4.1 Getting Ready for Migration .......................................................................................... 3
4.2 Technical Migration Project .......................................................................................... 4
4.2.1 Creating a migration project ............................................................................. 5
4.2.2 Maintaining the migration project ..................................................................... 5
4.2.3 Execution of the migration project ................................................................... 6
4.3 Check Consistency of Transport Request. ................................................................... 9
5. Appendix ............................................................................................................................ 10
5.1 Appendix A – Tips & Tricks / FAQs ............................................................................ 10
5.2 Appendix B – Some More Useful Info ........................................................................ 11
5.3 Appendix C – Applications .......................................................................................... 12




Figure: Data Flow Migration 1 ................................................................................................................. 2

Figure: Initial Screen 1 ............................................................................................................................. 5

Figure: Change Object Selection 1 ......................................................................................................... 6
Figure: Change Object Selection 2 ......................................................................................................... 9
Figure: Change Object Selection 3 ......................................................................................................... 9

Figure: Display Object Selection 1 .......................................................................................................... 8
Figure: Display Object Selection 2 .......................................................................................................... 8







1. Business Scenario
Migration of customer owned BI Content or migration of SAP-delivered BI Content from SAP BW 3.x
to SAP BW 7.0 technology.



2. Background Information
Please note that this document is a Best Practice for the existing NetWeaver online documentation
that explains BI Content Data Flow Migration.

The data flow concept has been improved with SAP BW release 7.0, which has been available since
2005.
Based on our survey via DSAG and SDN, we received 168 anonymous responses with the following
message: Customers want the SAP-delivered BI Content to be in 7.x technology  details in SDN
portal.

The main motivations to migrate an existing data flow from BW 3.5 to BW 7.0 technology are
the following:
 Reduce Total Cost of Ownership (TCO) to a high extent.
 Prepare the Content to use Real-Time Data Acquisition (RDA) and
 Also prepare the content for the new era of BW that is SAP NetWeaver BW 7.3 powered by SAP
HANA.

Important
The migration tool (transaction RSMIGRATE) that is explained in this document is
available only in the landscape of SAP Netweaver 7.3x (example BI Content 7.36).
However, to migrate data flows in systems with SAP Netweaver 7.0x (such as BI Content
7.06), you can still migrate a given data flow in the old way via transaction RSA1.


3. Prerequisites
Existence of BI Content data flows in BW3.x technology as explained in Release Note / SAP Note.





3.1 Know What Would Be Migrated

Figure: Data Flow Migration 1


Data Flow between Two InfoProviders: Creating Transformations Using Update Rules.

Data Flow between InfoSource and InfoProvider: Creating Transformations Using Update
Rules

Data Flow between Data Source and InfoSource / InfoProvider: Creating Transformations
from Transfer Rules

For more details, see:
http://help.sap.com/saphelp_nw70ehp2/helpdata/en/43/f00e2696d24c5fe10000000a155369/frameset
.htm

1
2
3





4. Step-by-Step Procedure
Analyze the existing data flows in BI Content. Find out which data flows exist in BW 3.x technology
and BW 7.x technology.
The following steps shall be considered:
 Getting Ready for Migration
 Technical Migration Project
4.1 Getting Ready for Migration

...
...
1. System preparation:
a. BI Content system used for this project is a NetWeaver 7.3x system.
b. Connect relevant source system(s) to the content system.
i. Choose lowest source system release in development/maintenance:
Recommendation
It is always recommended to connect a development/maintenance system that is in the
lowest release and/or EHP.
2. Migration preparation:
If relevant, define the current existing scope of migration: ‘3.x data flow details per application
area’ (e.g., CRM, FIN etc.)
a. Check the validity of the data flows and confirm if they need to be migrated at all.
b. Also check if the data flow is cross-application-dependent, i.e. if the data flow uses an
InfoSource and/or a data source that is used across different application areas
Example
Financials-related DataSource 0CO_OM_OPA_6 is used in the data flows of Project
Systems & Healthcare
3. Content activation:
Based on the above two checks, the respective application area BI Content needs to be
installed and activated.
4. Data flow clustering:
Ranging from simplicity to complexity of the data flows, you can segregate your migration
projects with the following clustering:
a. EASY: Data flows with absolutely NO routine coding.
b. NORMAL: Data flows with routine coding which may require minor changes.
c. CRITICAL: Data flows with complex manual rework such as ReturnTables or
InverseRoutines etc.
d. X_DS (Cross-application-related DataSources /data flows)
Note
The above clustering is only a suggestion and not a must. For applications not wanting to
proceed with such clustering, the data flows can simply be put into one or more projects
(with a unique project name) depending on the number of data flows totally available for
migration.
5. Development packages:





Create a new development package if you want to save the objects generated by the migration
tool in the new package.
6. Transport request:
Transport requests to be created for transporting the migrated content to the landscape.
7. Migration projects creation:
a. Based on the data flow clusters (see check 4), migration projects are created using
transaction RSMIGRATE.
Note
Creating projects as per the clusters is NOT a must, but it would be helpful if the
developer does this segregation so that the complex data flows having coding can be
dealt with separately.
b. Details:
http://help.sap.com/saphelp_nw73/helpdata/en/8d/6b1b58cc1744e1bce7898a50e19368/f
rameset.htm

4.2 Technical Migration Project
...

Once all the analysis has been done and the user is ready to migrate a data flow, the technical
execution of the data flow can be undertaken.
The migration tool is explained in this section.
See also:
http://help.sap.com/saphelp_nw73/helpdata/en/8d/6b1b58cc1744e1bce7898a50e19368/frames
et.htm






4.2.1 Creating a migration project
1. Go to transaction RSMIGRATE and give your project a name.

Figure: Initial Screen 1
2. Use the button Add data flow ( ) to select a data flow based on one of the following types:
a. 3.x InfoSource (Flexible Update)
b. 3.x DataSource
c. 3.x InfSource (Direct Update)  usually these are InfoObjects
d. DataStore Object
e. InfoCube
Note
You can select and maintain several data flows in a single project which can all be migrated
together. Of course, the checkboxes for the relevant objects should be marked in the Project
maintenance screen (see Figure: Create Object Selection 2).

Figure: Create Object Selection 1
4.2.2 Maintaining the migration project
...
1. As shown in the screenshot (Figure: Create Object Selection 1) above, select the object that you
would like to be the starting point for your data flow selection.
2. Choose ‘Enter’.
3. Once the data flow is displayed, you can begin to select the BI Content objects for migration by
marking the relevant checkboxes






Figure: Create Object Selection 2
4. Save the project. A project can only be executed after it has been saved.

4.2.3 Execution of the migration project
...
1. Click the ‘Migration/Recovery’ button/icon to execute the project.
2. In the next popup, check mark the steps that you want to be executed, and click the button
‘Migrate/Recovery’.

Figure: Change Object Selection 1
Recommendation
If your 3.x data flows have any sort of coding in them, we strongly recommend that you select
only up to Step 5 “Adjust VirtualProvider(s)”.





Reason: The 3.x update rules & transfer rules would still be available then, thereby giving you a
chance to cross-check the consistency of the ABAP coding in the new generated transformation
object. This would not be possible if you proceed to steps 6 & 7, since step 6 converts the 3.x
Datasource to a 7.0 Datasource, and step 7 deletes the 3.x objects. See the picture (Figure:
Display Object Selection 2) below.
Note
As seen in the screenshot (Figure: Change Object Selection 1), these are the seven steps
involved during technical migration of a data flow:
Step Number Header Description
1 Copy InfoSource from
3.x InfoSources
In this step, the existing 3.x InfoSource is copied to a
(new) InfoSource or an existing (new) InfoSource is
used again. No objects are exported.
2 Copy Transformations
from
Transformation/Update
Rules
In this step, a transformation as a copy of the transfer
rules and a transformation as a copy of the update
rules are created. The field routines and formulas are
also duplicated for the transformations.
3 Create DTPs from
InfoPackages
In this step, a data transfer process is created for
every update target specified in the InfoPackage. The
current definition of the InfoPackage is exported
beforehand.
4 Adjust Process Chains
and Variants
In this step, InfoPackages in process chains are
replaced by the created data transfer processes:
In the process variants, all references to
InfoPackages are changed to references to data
transfer processes.
If InfoProviders are also supplied by the
InfoPackages in process chains, the relevant data
transfer processes are inserted into the process
chain. The data transfer processes replace the
HIERSAVE, PSAPROCESS and ODSPROCESS
processes. These processes are removed from the
process chain.
The current definition of the process chains and
process variants are exported before the adjustments
are made.
5 Adjust VirtualProvider In this step, an additional transformation between
new InfoSources and VirtualProviders is created and
a data transfer process for this source-target
combination is created. The source system
assignment in the VirtualProvider is removed.
6 Migrate DataSources
from 3.x DataSources
In this step, a DataSource is created and the 3.x
DataSource is replaced by this (new) DataSource.
This step corresponds to the manual migration step
for 3.x DataSources. The 3.x DataSources and the
transfer rules are exported with routines and formulas
beforehand.





7 Delete Obsolete 3.x
InfoSources and Update
Rules
Obsolete 3.x InfoSources and update rules are
deleted. They are exported before deletion is
performed.


3. Select the relevant ‘development package’ and/or ‘UserName’ for the newly generated objects.
Choose ‘Enter’.
4. An overview of the project status and status of the steps that you selected is seen at the top of
the project maintenance screen. See screenshot below.

Figure: Display Object Selection 1
Note
 If a generated transformation has any incompatible coding in its routines, then the
object is automatically set as ‘Inactive’. In this case, the developer has to correct
the coding and activate the transformation manually. After doing this, proceed with
the remaining steps. Refer also to SAP Notes: 1052648.
 Migration History: Provides a quick status of the seven migration steps. The icon
here is either green ( - Success), red ( - Error) or gray ( - In process).
5. This is how the project maintenance looks like when both 3.x and 7.x objects exist in parallel,
before proceeding to the final step.

Figure: Display Object Selection 2
Note
The DataSource is still seen in the 3.x-version as it would not be converted directly to a
7.x version until step 6 is executed. Also, the above 3x objects would be deleted in the
final step 7.





Note
In the above screenshot, a 3.x related content object can be identified by a small gray
box beside the technical object icon. Example: 3.x Update Rule:
corresponding 7.x Transformation is
. Similarly, for Info Sources, Transfer Rule,
DataSources.
6. Once all the seven steps have been executed successfully, click on the ‘transport migration
project’ icon (see Figure: Change Object Selection 2 and Figure: Change Object Selection 3) to
automatically check and place all the transportable objects into a transport request.

Figure: Change Object Selection 2

Figure: Change Object Selection 3
4.3 Check Consistency of Transport Request.
...
Use report RSO_TLOGO_CHECK_REQUEST (via transaction SE38) to check the consistency
of the transport request used.






5. Appendix
Below are some Tips&Tricks / FAQs plus some useful information.
5.1 Appendix A – Tips & Tricks / FAQs
Topic Description / Explanation
Migration Tool (transaction RSMIGRATE)
How to collect all the data
targets of a given Infosource /
DataSource?
Simply select either the Info Source or DataSource as the
starting-point when adding the data flow. See chapter
4.2.1
How can a migration project be
reset?
Click on the ‘Migration/Recovery’ button and unmark
(deselect) all the checkboxes, and click the button
‘Migration/Recovery’ as seen in the popup. This will reset
the migration project and the objects within back to its
original state.
Project cannot be edited. Check if the project has already been executed. If you
need to change the checkbox selection and/or add more
data flows to the project, you have to first reset the
project, see point 2 above.


ROUTINES
1 Routine Concept Details here.
2 Routine Coding Basic principle: Check the routing coding in the migrated
data flow, for example using the ‘dual control principle’´.
3 Usage of generated structure
types such as '/BIC/C*
 This syntax belongs to the Update Rule of the Data
Store Object '0RMA_DS10'.
Example 1
Data: LS_DATA_PACKAGE_STRUCTURE TYPE
/BIC/CS0RF_SKU_ATTR
Example 2
Reference to such generated structures in other parts
of ABAP coding such as function modules/
subroutines etc.
 The structure /BIC/CS0DF_IS_DFS_01 is used in
the program
RS_BCT_UPDATE_DFPS_IS01_DS10.
SOLUTION: See SAP Note 1052648 (topic: ‘usage of
generated structures’).





4 3.x Update Rule field routines
defined as ‘Return Table’
Coding of field routines using return tables should be
reworked in the end routine of the generated 7.x
transformation.
Tip
How to find routines using return table functionality?
Return tables are applicable only for the field routines
of Update Rules. So, to find which Update Rule and/or
its fields use the return table functionality, just go to
the table RSUPDDAT and set the filter on the field
ROUTMULTI = ‘X’. By doing this, you will get the list of
all the fields that are flagged with the return table
along with the corresponding Update Rule ID. Now,to
find the source and target objects for a given update
rule, simply use the table RSUPDINFO and search for
UPDID = <update rule id>.



5.2 Appendix B – Some More Useful Info

Sl. Nr. Scenario / Topic Description
1 Which data flows are
migrated for a given
application?
All the relevant or valid data flows on BW 3.x technology as
indicated by the respective application area are migrated to BW
7.0 technology.
2 Which releases are
affected?
See Release Note / SAP Note 1601140
3 Globalization Valid for all countries.
4 Advantages of migration. Enabling your data flow for the next generated BW which is SAP
NetWeaver BW 7.3 powered by SAP HANA. Also data flows on
BW 7.0 technology can be enabled for Real-Time Data
Acquisition (RDA).
Installing Migrated Content
5 What happens if a
customer has changed
his existing BW3.x data
flow locally before the
SAP-delivered migrated
content is installed?
In such cases, changes done in the 3.x data flow need to be
adapted again in the newly installed migrated data flow.

6 What happens to the
existing 3.x content
objects?
As explained in section 4.2.3 above, after the last step is
executed, the 3.x content objects are deleted and ‘D’ versions of
these objects are transported with a ‘delete’ flag.





7 Importing the Transport
Request:
What should be
considered for an
Installed Base Customer
(where 3.x data flows are
already ACTIVE) before
installing the migrated
content i.e. importing the
transport request which
has the new migrated
content?
As mentioned already, the transport request will have all the
migrated data flows on BW 7.0 technology, and those on BW3.x
technology will be set as deleted.
CAUTION
Importing the new transport request with the migrated content of
the existing 3.x data flows will automatically overwrite the SAP-
delivered content & shadow versions (if any) of the existing 3.x
data flow. This means the „A‟ (active) versions of the old data
flows would still exist.
CAUTION
Once the above step has been executed, there is NO way back
i.e. you cannot again re-install content in 3.x technology which
again means you cannot go back to the original state as it was
before importing the transport request.





5.3 Appendix C – Applications

The BI Content data flows were migrated for the following applications (LOBs & Industries):
LOBs:
 ERP (HCM, FIN, SD, MM, QM, PM, CS, PS, RE, Master Data)
 CRM, SRM, SCM
 Project & Portfolio Management
Industries:
 Retail
 Consumer Products
 Public Sector
 Utilities
 Healthcare
 Defense Forces & Public Security
 Apparel & Footwear Solutions