Published version works for version 7.5 only. I have a newer version that works in 7.5 as well is in 10.0. Unfortunately How To Guide is not updated yet. Please send me your email at better.bpc at gmail.com and I'll send you that version with a list of new features.
you will found it here http://scn.sap.com/docs/DOC-4258
I can see that you have a solution for implementing BADI script logic / Run
Logic for BPC nw 10.0 that i would very much appriciate to get, since we have
an BADI implementation for 7.5 that does not work anymore due to upgrade to BPC
My email is : firstname.lastname@example.org
Thanks in advance, and have a nice day.
The new version of RUNLOGIC is quite good but I am facing some issues.
--The RUNLOGIC works fine perfectly as before for the same app where the script logic is hosted.
The problem is cross application writing.E.g. CONSOLIDATION -->RATES
When I debug the program I see the program works fine and generates records for RATES first time perfectly then again it runs the same code again this time the data of consolidation is entered to ET_DATA.
Now when ET_DATA is assigned for writing it gives assignment error .
"OBJECTS_TABLES_NOT_COMPATIBLE" " "
....................the section having problem
61 CALL METHOD cl_ujk_model=>get_structure
63 i_appset_id = i_appset_id
64 i_appl_id = l_appl_id
65 i_type = 'T'
66 if_with_measure = abap_true
67 * IF_WITH_SIGNEDDATA = ABAP_TRUE
69 rr_data = lr_wr_data.
71 ASSIGN lr_wr_data->* TO <lt_wb_rec>.
>> <lt_wb_rec> = et_data.
75 CALL METHOD cl_ujk_write=>filter_td
77 i_appset_id = i_appset_id
78 i_appl_id = l_appl_id
80 ct_data = <lt_wb_rec>.
I read one of your threads where you have mentioned to exclude the data of consolidation/Source App by using filter XDIM etc .That did the trick.It excluded the data of Consolidation APP and finally records of RATES (when ET_DATA was empty then structure of Rates was read ) were generated and were written .(basically I was copying ACTUAL to FORECAST in rates app ).
-->Still its not always possible and may pose problem as managing that would not be possible always.Are you working on this aspect as well?
-->I think another irritating thing with RUNLOGIC is you have to mention all the dimensions of source APP ,even though we are already passing the name of Target APP .If this could be handled then would be really good and kind of very helpful though not necessary
I'm not sure where you took that code you've posted, but it's not from RUNLOGIC.
I do not recall advising to exclude data using XDIM; could you please remind me in what context it was?
I'm not sure why you think that you have to mention ALL Dimensions of source APP in RUNLOGIC. You have to pass only those Dimensions that are different between Applications or where you want to use a specific scoping.
Now, it looks like you are using BADI in the script you calling. Do you call WRITE-BACK from your BADI or you using WRITE=ON in the call?
Also, when you call RUNLOGIC parameter QUERY should be OFF.
Yes you are right its the standard code which is called while using RUNLOGIC BADI.
I have used Query = OFF and WRITE=ON now.It has perfectly worked for me now.
When I used Query = ON it gives dump.Which I mentioned to you.
thanks a ton.
I had worked out of an alternative which worked earlier was actually I created a dummy member in one of dimension(present in CONSOLIDATION app and not in RATES).I did XDIM_MEMBERSET dim = dummy member.This actually cleared the consolidation data (I guess it works same as Query = OFF).
What I am doing with RuNLOGIC is when I am in CONSOLIDATION APP I am trying to update 2012.JAN data ACTUAL -->to 2013.JAN FORECAST (ofcourse there is some more logic) for RATES application.Basically cross application script logic running function.
Anyways thanks for your help.
P.S. : KEEP QUERY = OFF always to use RUNLOGIC for cross app / model scenarios.
One clarification: use QUERY = OFF ALWAYS when calling RUNLOGIC, not only for cross AppSet/App scenarios. If you have QUERY = ON data for your total scoping will be retrieved from your source Application; this data is not used anywhere, so it's a loss of time and space.
Another clarification (not related to use of RUNLOGIC): if you calling your own BADI that writes data back into the App use WRITE = OFF in that call or empty CT_DATA before exiting the BADI. If you don't follow this and write back to same App it will be just a waste of time, if you write data to a different App - it will e an error.
If you are just trying to copy from one Category to anther why are you using BADI? Regular script logic handles it efficiently enough.
Thanks for your informative post and indeed it will be definite help to many others apart from me.
As regards to BADI BPC NW script logic has lot of limitations which i can list may be SAP can introduce some keywords for them :
1.GET supported in MS but not in NW ,quite handy and useful though
2.# Temp tables concept that we use in MS is not supported with normal script logic
3.Concatenation is supported with clumsy for next there are some more ...
4.How do I write from CONSOLIDATION app to RATES app (cross APP scenario)??
Nevertheless,I always prefer script logic whereever possibe as for 5 lines of script logic sometimes I have to write 100 lines in ABAP.Not only that maintenance of script logic is much much easier than BADI and effort is also lesser.
Thanks for your help again.
You can post your suggestions in "idea place". I know that SAP checks it regularly and those that have many votes are considered for implementation.
Instead of MS version GET there is tuple, that provides most of the functionality GET does.
To write from one App to another use DESTINATION_APP.
I agree completely with you on script versus BADI. I recommend writing BADI only in cases where script functionality is no there. If performance is not there user parallelization:).
Me and Konstantin Kruzhkov managed to enhance the RUNLOGIC BADI functionality to provide the ability to pass $$ parameters to the calling script. It's useful in cases when it's required to pass more then one member per dimension (ex. source and destination) or to pass non member parameter.
We added the new keyword to the BADI input parameters: VARIABLE with the syntax similar to DIMENSION. This method is more flexible then passing the original DM $$ parameters to the calling script. The new syntax looks like:
DIMENSION SOMEDIM2 = MEMBER2
VARIABLE VAR1=MEMBER3 // or %SOMEMEMBERSET%, or $SOMEVAR$, or 1.12345
In the calling script VAR1 and VAR2 can be used as $$ DM variables:
*XDIM_MEMBERSET SOMEDIM3 = $VAR1$
*XDIM_MEMBERSET SOMEDIM3 = $VAR2$
Changes in BADI code:
CALL FUNCTION 'UJK_SCRIPT_LOGIC_EXECUTE'
I_APPSET = P_NEW_APPSET_ID
I_APPLICATION = P_NEW_APPL_ID
I_USER = l_user
I_LOGIC = lt_th_lgx
I_FILE_TYPE = 'LGF'
IT_CV = PTH_DIM_LIST
I_MODULE = 'DM'
I_LGF = l_docname
I_MODE = l_run_mode
IS_BADI_PARAM = lt_badi_param
ET_LGX = lt_lgx
E_FM_ERROR_MESSAGE = ls_err_message
ET_LOG = lt_log.
loop at it_param into ls_param where hashkey CS 'VARIABLE'.
REPLACE FIRST OCCURRENCE OF 'VARIABLE' IN ls_param-hashkey WITH space.
condense ls_param-hashkey no-gaps.
condense ls_param-hashvalue no-gaps.
translate ls_param-hashvalue to upper case.
IF gs_badi_param-parameter IS INITIAL.
CONCATENATE ls_param-hashkey '=' ls_param-hashvalue INTO gs_badi_param-parameter.
CONCATENATE gs_badi_param-parameter ';' ls_param-hashkey '=' ls_param-hashvalue INTO gs_badi_param-parameter.
gs_badi_param-equal = '='.
gs_badi_param-splitter = ';'.
MOVE gs_badi_param TO is_badi_param.
B.R. Vadim Kalinin
$...$ variables are already working in the version I sent to Konstantin. An I tried to explain this in the email I sent him.
This option wasn't there in the published version, but since BPC 7.5 SP08 this feature is available. You don't have to do anything in your START_BADI RUNLOGIC_PH; just use $...$ variable in the script that is called from RUNLOGIC and variable will be substituted from your DM Package.
We analyzed the code of the latest version of RUNLOGIC BADI sent to Konstantin but decided to have more flexibility in passing of $...$ parameters. With our code it's possible to hard-code the variable in the caller script (without DM prompt for this variable) and to pass it to the calling script. In some cases it's useful to reduce number of scripts (the same script can be launched directly by DM or can be run by RUNLOGIC from another script with the fixed set of parameters).
By the way, is it possible to change $...$ variable dynamically in BADI during the script execution? It depends on how Script interpreter works (is it reading the $...$ variables only at the beginning of script execution or...?)
If it's possible the following scenario can be implemented to get months between two months (STARTMONTH, ENDMONTH) passed as DM parameters:
//BADI will select months between start and end month and put the result set into variable defined in the MONTHSBETWEEN line*START_BADI MONTHBETWEEN
STARTMONTH=$STARTMONTH$ //DM Variable
ENDMONTH=$ENDMONTH$ //DM Variable
MONTHSBETWEEN=MONTHSSET //Result variable
*XDIM_MEMBERSET TIME = $MONTHSSET$
Original version should work in NW 7.53 and BPC 7.5. It won't work in BPC 10.0.
STMS might ask you to acknowledge that you transporting between different NW versions since transport was created in NW 7.01, but this should be okay.
If you need additional functionality I can send you newer version of that BADI for 7.5 or for 10.0.
First off, excellent thread, long awaited for RUNLOGIC_PH users. Would you mind if I tagged my issue on to the bottom of this?
Here's my situation. We're using RUNLOGIC_PH in 2 cases.
1. Execute below logic to run clear package in CONSOLIDATIONS app followed by destination app logic from LOAD app. This is executed from the LOAD app and works fine in DEV environment.
APP=CONSOLIDATIONS_APP (target app)
APP=LOAD_APP (executing app)
2. Execute similar logic as above but from CONSOLIDATIONS app to first clear data in INTCO app (target) and then destination app from CONSOLIDATIONS (executing) app to INCTO app.
This has worked fine previously in sandbox, but does not execute anything in our DEV box. Package returns as a success but does not execute the script logics. The individual script logics when executed from their respective apps also work fine.
Could really use your help on this inconsistency on why the same runlogic would work when moving from LOAD app to CONSOLIDATIONS but not from CONSOLIDATIONS to INTCO.
Thanks for the quick reply Gersh.
I checked and the data doesn't change. It doesn't seem to be executing either of the scripts - neither the clear script in the target nor the destination app script.
I also followed your thought and commented out the first RUNLOGIC call which runs the clear package in the target app but it still does not execute the second call (destination app). The reason we're using two RUNLOGIC calls is because we need to execute one package that will both clear data in the target as well as run destination app from the executing app. It was found that RUNLOGIC code followed by just the *DESTINATION app code wasn't executing.