Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

Table of Contents
outlinetrue
indent10px
stylenone

Incorrect values for referenced InfoObjects 

...

Some Object settings can’t be imported or exported using the Migration Booster. A list of these particular settings is shown below:

InfoObject - Key Figure

  • Stock Coverage (Tab Type/Unit)

  • Stock Coverage (whole Tab)

  • Person Responsible (Tab Type/Unit)

  • Key Figure with High Precision (Tab „Additional Properties“)

InfoObject – Characteristic

  • Lowercase Letters (General Tab)

  • High Cardinality (General Tab)

  • Person Responsible (General Tab)

  • Characteristic is Document Property (General Tab)

  • Constant (General Tab)

  • OBN Portal Sys Alias (Business Explorer Tab)

  • Base Unit of Measure (Business Explorer Tab)

  • Units of Meas. f. Char. (Business Explorer Tab)

  • Settings for Query Restriction > Query Definition (Business Explorer Tab) Query Execution Filter Val. Selection 

  • Display (Business Explorer Tab) à may not be transferred completely or correct if the Source Object comes from an older SAP Content

  • Supports XXL Attributes (Master Data/Texts Tab)

  • Master Data InfoSource / Data Target / InfoProvider (Master Data/Texts Tab)

  • Master Data Read Access (Master Data/Texts Tab)

  • External SAP HANA View (Master Data/Texts Tab)

  • Miscellaneous (Master Data/Texts Tab)

  • Hierarchy (whole Tab)

Data Store Object (DSO)

  • Indexes (already in Planning)

  • Planning Mode

  • External SAP HANA View

  • Allow Duplicate Data Records

  • Check Delta Consistency

  • Extended Table

  • Unique Data Records

  • Set Quality Status to ‘OK‘ Automatically

InfoCube

  • Supported InfoCube-Types:

    • Standard

    • Real-time InfoCube

    • VirtualProvider

  • External SAP HANA view

  • Auditable

  • Settings for VirtualProvider need to be maintained in the target system

  • Settings:

  • Name of Delta Cache Class

  • Do Not Transform Selection Conditions

  • Supports Navigation Attributes

  • Derive Selection Conditions from Attribute 

  • Non-Cumulative Values for SAP BW Releases <= 7.30

Advanced Data Store Object (ADSO)

A reliable export of ADSOs is supported starting from the BW-Release 7.50 SP06. The following settings are currently not supported:

  • Only In- and Export possible

  • Properties of Fields

    • Conversion Exit

    • Use Navigation Attribute in Extraction

  • SAP HANA Dynamic Tiering

  • Partitions

  • Hash-Partitions

  • Indexes

  • Inventory

Import DSO as ADSO

Master Data Check

When importing DSOs (might also occur with InfoCubes) as ADSO, the Docu Performer might display a successful export even if the ADSO in the target system isn’t active. The following list states constellations having the described issue:

  • DSO has “never create SIDs” as setting

  • All Characteristics in the ADSO (not Key Figures or Entities) have “No Master data check/ No reporting” as setting for the Master Data Check.

  • This leads to an error message in the BW Modeling Tools (tested with BW-Release 7.50 SP06)

  • Solution: Change Master Data Check to a different setting. Usually changing only one setting for a Characteristic is enough for the activation.

Image Removed

...

Importing an InfoCube as ADSO can lead to a failed activation during the Export. A solution is given by changing the Master Data Check of the relevant InfoObject to “Master Data Check while loading/ activating” or “Master Data Check when loading/ activating and SID storage at DataStore”.Image Removed

...

Image Removed

MultiProvider and CompositeProvider

...

For the migration from BW to BW/4HANA there is a concept of Compatibility Views. They can be used for migration e.g. of DSOs to ADSOs. The concept is that a view with the name of the old DSO table (e.g. /BIC/AMY_DSO00) is created. That view selects on the new ADSO table (e.g. /BIC/AMY_ADSO1). With  With this concept, you do not have to change your code where you do lookups or other reads on tables of your old InfoProviders. We  We do not support this concept and we think that also the code should be migrated. These  This leads to advantages like clear names of DDIC views and it is sustainable.

With the Docu Performer, you can do an ABAP Scan to identify the places where an InfoProvider table is used in the code. These  These places should be adjusted manually.

Queries

Modeling does not support the generation of Hierarchies.
So before copying a Query with the Docu Performer, you should create corresponding Hierarchies in target systems.