Limitations and known Issues

Incorrect values for referenced InfoObjects 

When exporting referenced InfoObjects, the Business Explorer Parameter value "Display/ Text Type" will not use the one set in the Docu Performer, even if it is changed separately from the referenced InfoObject. The Function Module “BAPI_IOBJ_CREATE” seems to strictly assign the “Key” values. (internal note: JIRA 3831)

Unsupported Settings/Properties

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.

Open

Open

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

MultiProvider and CompositeProvider

CompositeProvider and MultiProvider can be imported as CompositeProvider.

As PartProvider we support only InfoCubes, DSO, and ADSOs. All other entities are not supported

Compatibility Views

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 this concept, you do not have to change your code where you do lookups or other reads on tables of your old InfoProviders. We do not support this concept and we think that also the code should be migrated. 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 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.