bi content data flow migration - best practice - sap q&a · 1. business scenario migration of...
TRANSCRIPT
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/frameset.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/frameset.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