intercube accelerators

Hi all,

Please don't shoot me but I have the task of rebuilding the rules for a V11 model which was previously fully accelerated. It has complex rules and the dimensionality of the cube is updated.

None of the accelerators now compile, if you go into them and syntax check them, but they do show as OK.

Looking at them, I don't feel that the intercube ones were written as the syntax would require.

I believe that the target cube syntax should be in the format:

CUBE{dim1!dim1,dim2!dim2) where the cubes match or source cube dimension!targetcube dimension where they do not and an element name where the dimension does not exist in the source cube.

There was a document written about 20 years ago, by Phil Bichard, but I can't find it. Does anyone have a copy or can anyone advise whether what I have written is correct or what should it be today.

Thanks in advance

Mike

Find more posts tagged with

Infor EPM Discussions

Comments

martin-reischl

Hi Mike,

I don't have the document you mention but according to the training material I wrote about the same time you mention, the syntax for "dimension mapping" is

CUBE[target_dimension!source_dimension]

So if you have a target cube TFINANCE with a dimension DACCOUNT, and you take over values from a cube TSALES with a dimension DSALESACCOUNT, the rule might run:

[{{SalesAccounts}}] = B: DB('TSALES', !DYEAR, !DMONTH, !DSCENARIO, 'All Customers', 'All Products', !DACCOUNT);

Now you would use this as an accelerator in the TFINANCE cube:

TSALES['All Customers', 'All Products'] > TFINANCE[DACCOUNT!DSALESACCOUNT];

Best Regards

Martin

Mike Potashnick

Thanks Martin,

That does confirm my understanding.

Do you have any idea whether using cube names or dimensions, with spaces in the name would give a problem?

so I have got 'Client Variable'['PFM'] > 'Income detail'[dim1!dim1....] but a lot of the dimension names contain a space, so !'Client Status'.

I just can't get the accelerators to compile successfully!!

Regards

Mike

martin-reischl

Hi Mike,

I'm sorry but I'm out of my depth here. I never used technical dimension or cube names with spaces. If it does not work with single quotes, my only other ideas are using double quotes, and reporting this as an issue to support.

Best Regards

Martin

Nick Gladkov

Mike, maybe use it as an opportunity to remove accelerators completely? We do have great tools for analysis of the performance and best practices around writing rules in a better way, I would highly recommend to follow that practice as soon Accelerators will go away anyways and this works should be done (again)

Mike Potashnick

Nick,

That's why I said.. "Don't shoot me!". Because of the problems I have already encountered in rewriting the accelerators for the changed cube structures, I have refactored 1 rule already using Boolean logic. If I could get access to the performance analysis tool set that would greatly help, and sharing the tools will help all of us. The knowledge that accelerators will go away soon makes a difference which I will share with "our" customer.

mike

depm-638-Writeback On YTD cells.mp4

Matthias Englert

Hi Mike,

I didn't check things in detail here but using the function ElementInHierarchy('<TargetDim>', !'<SourceDim>') might help to validate references when element-names are identical but come from different dimensions.

regards

Matthias

Mike Potashnick

Thanks Matthias, In this case the same dimensions are being used, so this shouldn't be a problem. Interestingly, I have always used the de.index <> 0 function to test whether whether an element exists in another dimension.

Regards

Mike

mark-raynham

Hi Nick,

I must have missed this news about accelerators being removed eventually so when is this expected to happen?

I have a lot of clients who use accelerators and enjoy the speed and functionality of their model which in my view is only possible due to accelerators so, like Mike, I need to start giving these clients a "heads-up".

Thanks,

Mark

Nick Gladkov

Mark, you didn't miss it - we are preparing the communication and current plan is to give customers around 2 years for such move. Do you think such time would be sufficient?

mark-raynham

I would think 2 years is sufficient especially, for on premise clients, they won't necessarily have to upgrade to the version without accelerators straight away.

It gives partners and clients plenty of time to assess and implement necessary changes.

Whilst there will be a lot of initial pain, I'm pleased to hear that accelerators are going!

Copyright © 2025 Infor. All rights reserved.