*DIM_NONAGGR - UJ_STATIC_CHECK:Error found in the System /UJHANA_ERROR001

[collepicolo]

Hi -

This week the *DIM_NONAGGR engine started failing in our production system. The same logic that we are using in production works in our quality and development system. The problem doesn't seem related to transactional or master data, we are experience the same problem in different models and environments. We can't find any SAP note that would fix this error in our current Support Package 14 in BW 750. We opened a ticket with SAP but we are not getting much of assistance at this moment, so any help would be very welcome.

We have the ACCELERATOR_ON marked with X in all the models. We have the ENABLE_HANA_MDX on in our environment level. We don't have the ENABLE_NATIVE_HANA_MODEL because we have write-back BAdI.

Below a screenshot of the error in UJKT:

Data Region

PROG_ID=ASI_001463
VER=WORKING_FCST
DEPTID=NO_DEPTID

Script

//==Variables=============================================================================
//Select Plan ID's
*SELECT(%PLAN_ID_ALL%,PLAN_ID,PROG_ID,ID=%PROG_ID_SET% AND TYPE=O,P,M AND ID<>ASI_NO_PROG_ID AND COMP_CODE=0611)
*SELECT(%PLAN_ID%,ID,PROG_ID,ID=%PLAN_ID_ALL% AND COMP_CODE=0611)  //yields unique occurrence from above select
*SELECT(%PID%,ID,PROG_ID,PLAN_ID=%PLAN_ID% AND CALC=N AND COMP_CODE=0611 AND PLAN_ID<>"")

// Pushdown
*SELECT(%GPID%,ID,PROG_ID,ID=%PID%,sortby=ID)
*SELECT(%GPID_PLAN_ID%,PLAN_ID,PROG_ID,ID=%PID%,sortby=ID)

//***************************************************************************************
*XDIM_MEMBERSET TIME=TNONE
*XDIM_MEMBERSET DATASOURCE=BOB_INP
*XDIM_MEMBERSET UNIT=USD
*XDIM_MEMBERSET P_ACCT=CQUAD
*XDIM_MEMBERSET DEPTID=NO_DEPTID
 
*RUNALLOCATION
*DIM_NONAGGR PROG_ID WHAT=%GPID_PLAN_ID%; WHERE=%GPID% 
*DIM DATASOURCE WHAT=BOB_INP; WHERE=INP 
*DIM UNIT WHAT=USD; WHERE=<<<
 
*ENDALLOCATION

This is the error log in SLG1:

*EDIT 1

SAP Components:

component.jpg

****FINISH EDIT 1

*EDIT 2

Dimension PROG_ID Screenshots, focusing on only one program to make it simple to follow, the *DIM_NONAGGR fail even for only one program selected such as the ASI_001463:

PLAN_ID

COMPANY CODE

TYPE

****FINISH EDIT 2

If we run the allocation without the *DIM_NONAGGR it executes without the error.

Any suggestions about something that we are missing that could fix the *DIM_NONAGGR?

Ideally we would like to use the *DIM_NONAGGR but if we can't how would we write this same piece using *FOR and *NEXT probably? We have several other parts using it, all are failing if we can get an example of how to re-write it using other structure we could replicate in other scripts.

Thank you

[former_member186338]

Sorry, but what do you want to achieve with this strange logic?

[collepicolo]

Thank you for your prompt reply. No need to be sorry asking a question that may be helpful but you probably should be sorry by labeling it "strange". Allow me first answering your question with another one, why would you focus in talking about the logic rather of the software issue? I would advice having a read to the note 1903167 if you don't know about the *DIM_NONAGGR.

[former_member186338]

Sorry, but I am aware about "*DIM_NONAGGR" since it was introduced 🙂 Just look on my profile!

I want to understand the required calculation logic! Please read my old blog: https://blogs.sap.com/2014/01/31/how-to-ask-questions-about-script-logic-issues/

Not sure that the logic in your script is the best one!

[collepicolo]

I read your blog, added a component screenshot to the original post.

Dimensions that we have in this model:

DATASOURCE - Audit Type

DEPTID - User Defined

PROG_ID - Entity Type

P_ACCT - Account Type

TIME - Time Type

UNIT - Currency Type

VER - Category Type

Model relevant for this discussion:

PLAN_PROG - Financial Type / Periodic

The other models are also not having the same issue in production. We believe that something was corrupted in the *DIM_NONAGGR engine.

Logic Trigger:

Launched in the default.lgf and via package by user need

Logic Purpose:

Allocate the value from the data from the PROG_ID that is identified in as a property in other PROG_ID members. You can trace this looking the select statements. The following *FOR/*NEXT may work but I didn't test all the permutations to make sure that the relation 1:1 will be respected and we will lose time replacing everything and testing:

*XDIM_MEMBERSET TIME=TNONE

*XDIM_MEMBERSET DATASOURCE=BOB_INP

*XDIM_MEMBERSET UNIT=USD

*XDIM_MEMBERSET P_ACCT=CQUAD

*XDIM_MEMBERSET DEPTID=NO_DEPTID

*FOR %LPID%=%GPID_PLAN_ID% And %MPID%=%GPID%

*RUNALLOCATION

*DIM PROG_ID WHAT=%LPID%; WHERE=% MPID%

*DIM DATASOURCE WHAT=BOB_INP; WHERE=INP

*ENDALLOCATION

*NEXT

It worth emphasis that using the *FOR / *NEXT is the last resort that we would like to adopt since the *DIM_NONAGGR was previously working and take advantage of the HANA capabilities. If this run right will be very slow giving the amount of programs that we have in the master data to execute.

Please let me know if you need additional information.

Thanks

[former_member186338]

Can you provide details about PROG_ID dimension? Please post a screenshot of dimension administration screen (with PLAN_ID property visible).

P.S. "Launched in the default.lgf and via package by user need"

In default.lgf??? Looks strange - default.lgf requires different logic approach. Please read:

https://blogs.sap.com/2014/06/09/how-to-write-defaultlgf/

[collepicolo]

Added to the original post. Not sure how much this would add to the discussion, remember that the regular run allocation is running. The error only happens with the *DIM_NONAGGR so not sure how exactly the master data or transactional data could be affecting something.

[former_member186338]

OK, now I understand the results of the script execution. But what is the business logic behind?

*DIM_NONAGGR PROG_ID WHAT=ASI_001463,ASI_001463,ASI_001463; WHERE=A26011,A36119,ASI_001463

Very strange to my mind...

Why not:

*DIM PROG_ID WHAT=ASI_001463; WHERE=A26011,A36119,ASI_001463

?

[collepicolo]

Just to close the loop, to have this resolved we have to run the program UJHANA_MANAGE_TRACE and press deactivate. After that the *DIM_NONAGGR will return to work as always.

*Vadim, if you would like to reproduce the issue on your side try to activate the trace, check the table is populate and run a simple *DIM_NONAGGR in any model/environment that you have.

Thanks

[collepicolo]

Good news, after debugging we were able to find the problem cause. It seems somehow one table got populated with an entry that shouldn't be there. We don't know yet what made this to happen, we are going to communicate this to SAP and see if they can help from this point.

[former_member186338]

Can you explain how it's related to your issue?

[former_member186338]

By the way, I have found interesting note:

https://launchpad.support.sap.com/#/notes/0002641351

with the reference to:

https://launchpad.support.sap.com/#/notes/1960281

Try your script with the line:

*ACCELERATOR=OFF

[collepicolo]

I added the *FACTOR=1 and it didn't work. Making the accelerator off doesn't work, I get another error and according note 1903167 this should be on to have the *DIM_NONAGGR working.

[former_member186338]

collepicolo

1. "and according note 1903167 this should be on to have the *DIM_NONAGGR working." - incorrect statement!

From the note:

"An new keyword *DIM_NONAGGR is introduced for more efficient allocation scripting which will further help to improve performance. This keyword can be used for both HANA and non-HANA system."

2. In your screenshot I see some strange mismatch between lgx and log:

Recommended - remove all SELECT statements from the test script and use fixed lists in WHAT and WHERE

Also, don't remove FACTOR - bad practice, at some SP you will get strange result without it. It's a documented part of RUNALLOCATION syntax.

Test script:

*XDIM_MEMBERSET TIME=TNONE
*XDIM_MEMBERSET DATASOURCE=BOB_INP
*XDIM_MEMBERSET UNIT=USD
*XDIM_MEMBERSET P_ACCT=CQUAD
*XDIM_MEMBERSET DEPTID=NO_DEPTID
 
*RUNALLOCATION
*FACTOR=1
*ACCELERATOR=OFF // test with ON and OFF
*DIM_NONAGGR PROG_ID WHAT=ASI_001463,ASI_001463,ASI_001463; WHERE=A26011,A36119,ASI_001463 
*DIM DATASOURCE WHAT=BOB_INP; WHERE=INP 
//*DIM UNIT WHAT=USD; WHERE=<<< - useless line, already scoped!
*ENDALLOCATION

P.S. And reload transaction UJKT!

[collepicolo]

Here is the result:

I think there was some cache in UJKT on my last execution, anyways, still doesn't working.

This statement in the note is a bit misleading: "Pre-requisite, Environment level setting 'ACCELERATOR_ON' is set to 'X' in IMG."

Other thing, I know that I mentioned this a couple of time but why would we need to change the logic if it works in different systems? Also, the *DIM_NONAGGR doesn't work in different models and environments in this system. I wonder where could I check if the pre-requirements and/or entries are all setup accordingly to have it working properly.

[former_member186338]

collepicolo

OK, strange - member count is the same!

Let's test simple one:

*XDIM_MEMBERSET TIME=TNONE
*XDIM_MEMBERSET DATASOURCE=BOB_INP
*XDIM_MEMBERSET UNIT=USD
*XDIM_MEMBERSET P_ACCT=CQUAD
*XDIM_MEMBERSET DEPTID=NO_DEPTID
*RUNALLOCATION
*FACTOR=1
*ACCELERATOR=OFF 
*DIM_NONAGGR PROG_ID WHAT=A26011,A36119; WHERE=A26011,A36119 
*DIM DATASOURCE WHAT=BOB_INP; WHERE=INP 
*ENDALLOCATION

Unfortunately, I don't have the system with your configuration, Have to ask you to perform tests.

And test also with

*ACCELERATOR=ON

to see the difference

[former_member186338]

May be that starting from some SP RUNALLOCATION with *DIM_NONAGGR didn't like same ID's in WHAT!

Can you test something like:

*DIM_NONAGGR PROG_ID WHAT=ASI_001463,ASI_001463;WHERE=A26011,A36119

And without same ID's:

*DIM_NONAGGR PROG_ID WHAT=A26011,A36119;WHERE=A26011,A36119

[collepicolo]

*DIM_NONAGGR PROG_ID WHAT=ASI_001463,ASI_001463;WHERE=A26011,A36119

*DIM_NONAGGR PROG_ID WHAT=A26011,A36119;WHERE=A26011,A36119

It didn't like either. Do we have some tables that I could check if the ENABLE_HANA_MDX is really active or any other one like that?

[former_member186338]

collepicolo

By the way, in your script the line:

*FACTOR=1

is missing.

Not sure it can affect the code execution, but better to add it.