}bedrock.cube.data.copy - does not work if Element not exist in main hierarchy

[buzasjozsef]

Hi,

I faced an issue with }bedrock.cube.data.copy and }bedrock.cube.data.copy.intercube process. The copy is not working, if the elements are not exists in the "main" (hier name = dim name) hierarchy, but exists in the dimension. I think the main issue, is the process uses only DIMIX, that can give not proper results.

Screenshots I've made a small demo process to show it:

Message Log:

The results are the same, but with different error messages, if I add the elements in the following way: HierName:ElementName

To Reproduce Steps to reproduce the behavior:

1. Create a dimension with more than one hierarchy.
2. Add two N elements to the new hierarchy, but do not add them to the main hierarchy
3. Assig the Dimension to a cube.
4. Run the }bedrock.cube.data.copy process.

Expected behavior The process copy the values,

Screenshots If applicable, add screenshots to help explain your problem.

Version

• OS: Windows Server 2016
  • TM1 Build Number: 11.8.00200.24

Other The process, if you would like to copy+paste it: pCube = 'POSITION_MAINTENANCE'; pDim = 'organization'; pHier = 'bp_sim';

pVersion = 'bp_sim';

sOldID = '111033';

sNewID = '111037';

sOldDIMIX = DIMIX(pDim, sOldID); sNewDIMIX = DIMIX(pDim, sNewID);

sDimix = 'Dimix OLD: ' | NumberToString(sOldDIMIX) | ' Dimix NEW: ' | NumberToString(sNewDIMIX); LogOutput('INFO', sDimix);

sOldDimExist = DimensionElementExists(pDim, sOldID); sNewDimExist = DimensionElementExists(pDim, sNewID);

sDimEx = 'DimensionElementExists OLD: ' | NumberToString(sOldDimExist) | ' DimensionElementExists NEW: ' | NumberToString(sNewDimExist); LogOutput('INFO', sDimEx);

sOldHierExist = HierarchyElementExists(pDim, pHier, sOldID); sNewHierExist = HierarchyElementExists(pDim, pHier, sNewID);

sDimEx = 'HierarchyElementExists OLD: ' | NumberToString(sOldHierExist) | ' HierarchyElementExists NEW: ' | NumberToString(sNewHierExist); LogOutput('INFO', sDimEx);

pFilter='version¦'| pVersion | ' & period¦2020_11+2020_12'; pMappingToNewDims ='organization¦'|sOldID |'->'|sNewID;

ExecuteProcess( '}bedrock.cube.data.copy', 
    'pLogOutput', 1,
    'pCube', pCube, 
    'pFilter', pFilter,
    'pEleMapping', pMappingToNewDims, 
    'pMappingDelim', '->',
    'pDimDelim', '&', 
    'pEleStartDelim', '¦', 
    'pEleDelim', '+',
    'pSuppressConsol', 1, 'pSuppressRules', 1,
    'pZeroTarget', 1, 'pZeroSource', 1
);

[lotsaram]

Hi @buzasjozsef This is actually expected behaviour since the processing view used by TI is a "traditional" view not a MDX view and traditional views only have access to the same named hierarchy.
If you want to process data for elements that exist in an alternate hierarchy but NOT in the same named hierarchy then you need to use an MDX view.
The immediate workaround is to ensure the element exists in the same named hierarchy if you want to use it in a bedrock filter. However it would be a legitimate enhancement request that bedrock 4 also be able to handle MDX views for data processing. For technical implementation I think this would be pretty easy as the existing pFilter parameter could be used and we could just do a scan to see if "SELECT" and "ON COLUMNS" or "ON 0" is in the filter and if true then use MDX view else us the current logic. (This wasn't done originally since it is only in quite recent versiosn of PA that MDX views started to work correctly). If you want to raise the ER please create a new issue.