Forum Discussion

Montreux's avatar
Montreux
Contributor
1 day ago
Solved

Import with Vertical Extensibility or Extensible Dimensions

Hi,

I can’t get my data import to work with vertical extensibility, and I’d like to understand how this situation is supposed to be handled.

In short, the import validation fails on accounts that are extended for an entity. The entity belongs to a cube that is vertically extended from the primary workflow cube.

 

Detailed situation

I have extended dimensions and two cubes that use those dimensions.

  • CubeParent contains a parent entity with dimensions applied. The parent entity resides in the parent entity dimension.
  • CubeChild has dimensions that are extended from the parent’s dimensions. The child entity resides in the child entity dimension.

As a result, each cube has its own unique entity dimension containing its respective entity.

Additional configuration details:

  • CubeChild has Is Top Level Cube For Workflow set to False.
  • CubeParent is the top-level cube and has the Workflow Profile created from it.
  • The child entity has been added as a child of the parent entity in the parent’s entity dimension (see screenshot).

     

  • CubeParent has the Cube References tab configured correctly.

Data import issue

I have configured a data source that reads from a CSV file. The data source successfully loads the CSV into the staging area. However, the transformation step fails.

The failure occurs only for the child entity’s extended account, not accounts in the ParentCube account dimension.

The transformation rules when created are associated with a cube.  If the cube is not that of the workflow profile the transformation rule does not appear in the import configuration step.

Question

How should data be imported for an entity that exists in a workflow that has different dimensional detail than the cube it belongs to because it is using vertical extensibility?  


Data Integration
Import
Transformation
  • Montreux's avatar
    Montreux
    7 hours ago

    I got it now.  Thanks a lot for your comments here.  I was missing something.

    Workflow Profiles in given "Cube Root Workflow Profile" can be set to different cubes when the Workflow Profile is created.  The apps I've worked on in the past had the default cube be the same as the cube root's workflow profile's cube.  

     

     

4 Replies

  • Montreux's avatar
    Montreux
    Contributor
    7 hours ago

    I got it now.  Thanks a lot for your comments here.  I was missing something.

    Workflow Profiles in given "Cube Root Workflow Profile" can be set to different cubes when the Workflow Profile is created.  The apps I've worked on in the past had the default cube be the same as the cube root's workflow profile's cube.  

     

     

  • Montreux's avatar
    Montreux
    Contributor
    13 hours ago

    Thanks for the reply!  I understand the reason the import needs the WF cube; it needs to know its dimensions for mapping.

    However, vertical extensibility (vertically extended) entities can no longer have their cubes referenced in the parent cube when Is Top Level Cube For Workflow is set to True. I get this message in the Cube References dialog when I try to select the ChildCube1 when it is a top level cube.

    So, if I want to import, the child cube must be a top level.  If I want vertical extensibility, the child cube is not top level.  How do I reconcile these two requirements? 

    (I am assuming that to make vertical extensibility work correctly the child cube needs to be referenced in the top parent cube.)

     

     

    • rhankey's avatar
      rhankey
      Contributor III
      9 hours ago

      You might have some other settings not set correctly.  We have no issues setting the extended base-level cubes to IsTopLevelCubeForWorkflow=False that automatically consolidate into the parent cube.  Only the parent cube is set to True.

  • rhankey's avatar
    rhankey
    Contributor III
    1 day ago

    The Workflow to which the Import is attached needs to have Cube=CubeChild.  So does the Data Source and the Transformation Rules.

    Put differently, should you have 3 different base cubes, each with different extensibility, you will need 3 different Workflows, Data Sources and Transformation Rules - one set for each base cube.