cancel
Showing results for 
Search instead for 
Did you mean: 

BPC 10 NW -RUNLOGIC BADI doesn't work

former_member216978
Participant
0 Kudos

Dear Experts,

The RUNLOGIC keyword BADI doesn't work anymore in BPC 10 as some methods  and  classes have been changed by SAP in BPC 10 NW.

Anybody having any luck so far....how to hanle RuNLOGIC keyword in BPC 10 NW??

Regards,

Rakesh

Accepted Solutions (1)

Accepted Solutions (1)

former_member200327
Active Contributor
0 Kudos

Hi Rakesh,

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.

Regards,

Gersh

former_member216978
Participant
0 Kudos

Hi Gersh,

First thanks a lot for your prompt response.

I had used ur old version in BPC  7.5 NW and it was highly helpful the same way like BPC MS runlogic keyword.

I sent you an email at better.bpcat gmail.

Regards,

Rakesh Kumar

former_member216978
Participant
0 Kudos

Thanks a ton Gersh!

RUNLOGIC_PH works perfectly for me both for cross model updates and parallelization.

Regards,

Rakesh Kumar

Former Member
0 Kudos

Dear Gersh!

I am also very interested of the new version of RUNLOGIC BADI.

I have sent yor email to gmail.com with this request.

Thanks in advance.

former_member186498
Active Contributor
0 Kudos

Hi Konstantin,

you will found it  here http://scn.sap.com/docs/DOC-4258

Kind regards

     Roberto

former_member200327
Active Contributor
0 Kudos

This is the first "official" version of the BADI that works in v.7.5 only.

There is now version that works in 7.5 as well as in 10.0 and has extended functionality. Unfortunately "How To ... Guide" is still WIP.

Gersh

former_member186498
Active Contributor
0 Kudos

oops sorry,

then can you send me please the unofficial new version too?

Kind regards

     Roberto

former_member200327
Active Contributor
0 Kudos

Sure, just tell me where at the email above.

Gersh

former_member186498
Active Contributor
0 Kudos

Hi Gersh,

you will found the email in my profile.

Thanks

     Roberto

former_member200327
Active Contributor
0 Kudos

Hi Roberto,

If I would be able to find your email in your profile or your vcard I won't ask you to provide it.

Gersh

former_member186498
Active Contributor
0 Kudos

Hi Gersh,

I setted it visible but maybe it doesn't work.

so please roberto.vidotti@unipolassicurazioni.it

Thanks

     Roberto

Former Member
0 Kudos

Please send EPM 10 NW RUNLOGIC transport or code to me as well.  Thanks!

jonathan.essig@optimalsol.com

Former Member
0 Kudos

Please send me the 10.0 Runlogic to jason.vaughn@baldor.abb.com

Thanks

Jason Vaughn

Former Member
0 Kudos

Hi Gersh.

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
10.0.

My email is : lassetrolle@gmail.com

Thanks in advance, and have a nice day.

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi Rakesh,

Can please send the detail document to my mail id: Saireddy.Kalagotla@gmail.com

former_member186338
Active Contributor
0 Kudos

Hi Saireddy,

You are talking about this document: How To Implement the RUNLOGIC_PH Keyword in SAP... | SCN

Vadim

Former Member
0 Kudos

Thanks for update

Former Member
0 Kudos

Hi Gersh,

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.

*START_BADI RUNLOGIC_PH

QUERY=OFF

WRITE=ON

LOGIC=CLR.LGF

APPSET=XXX

APP=CONSOLIDATIONS_APP (target app)

DEBUG=OFF

*END_BADI

*START_BADI RUNLOGIC_PH

QUERY=OFF

WRITE=ON

LOGIC=SEND_DATA.LGF

APPSET=XXX

APP=LOAD_APP (executing app)

DEBUG=OFF

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.

former_member200327
Active Contributor
0 Kudos

Hi Zoheb,

There is an issue with RUNLOGIC (or BPC logs) in case of more than one RUNLOGIC call in a script: it shows only the last log.

Can you please check the data if really script hasn't been changed?

Regards,

Gersh

Former Member
0 Kudos

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.

Former Member
0 Kudos

Hello Gersh,

We have BPC for Netweaver 7.53 will the new version of the transport request work for us?

Kind Regards

former_member200327
Active Contributor
0 Kudos

Hi David,

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.

Regards,

Gersh

Former Member
0 Kudos

Thanks Gersh,

We applied the transport request ignoring the difference in release without problem, but in SE20 we see there are 2 methods in status red, is it ok to ignore them?

Regards

former_member200327
Active Contributor
0 Kudos

Red in that screen means that method is Private. It doesn't mean any error.

former_member216978
Participant
0 Kudos

Hi Gersh,

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" " "

   "CL_UJK_WRITE==================CP" bzw.

"CL_UJK_WRITE==================CM009"

   "WRITE"

....................the section having problem

61   CALL METHOD cl_ujk_model=>get_structure

62     EXPORTING

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

68     RECEIVING

69       rr_data            = lr_wr_data.

70

71   ASSIGN lr_wr_data->* TO <lt_wb_rec>.

72

>>   <lt_wb_rec> = et_data.

74

75   CALL METHOD cl_ujk_write=>filter_td

76     EXPORTING

77       i_appset_id = i_appset_id

78       i_appl_id   = l_appl_id

79     CHANGING

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

Regards,

Rakesh Kumar

former_member200327
Active Contributor
0 Kudos

Hi Rakesh,

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.

Regards,

Gersh

former_member216978
Participant
0 Kudos

Thanks Gersh,

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.

Regards,

Rakesh Kumar

former_member200327
Active Contributor
0 Kudos

Hi Rakesh,

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.

Regards,

Gersh

former_member216978
Participant
0 Kudos

Hi Gersh,

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.

Regards,

Rakesh Kumar

former_member200327
Active Contributor
0 Kudos

Hi Rakesh,

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:).

Regards,

Gersh

former_member186338
Active Contributor
0 Kudos

Dear Gersh,

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:

*START_BADI RUNLOGIC

WRITE=ON

QUERY=OFF

LOGIC=CALLINGSCRIPT.LGF

APP=SOMEAPP

DIMENSION SOMEDIM1=MEMBER1

DIMENSION SOMEDIM2 = MEMBER2

VARIABLE VAR1=MEMBER3 // or %SOMEMEMBERSET%, or $SOMEVAR$, or 1.12345

VARIABLE VAR2=MEMBER4

DEBUG=OFF

*END_BADI

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'
EXPORTING
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
IMPORTING
ET_LGX                  
= lt_lgx
E_FM_ERROR_MESSAGE      
= ls_err_message
ET_LOG                  
= lt_log.

In PROCESS_PARAMETERS:

******************************************************************************
* VALUE
******************************************************************************
clear ls_param.
clear gs_badi_param.
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.
ELSE.
CONCATENATE gs_badi_param-parameter ';' ls_param-hashkey '=' ls_param-hashvalue INTO gs_badi_param-parameter.
ENDIF.
endloop.
gs_badi_param
-equal = '='.
gs_badi_param
-splitter = ';'.

MOVE gs_badi_param TO is_badi_param.

B.R. Vadim Kalinin

former_member200327
Active Contributor
0 Kudos

Hi Vadim,

$...$ 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.

Regards,

Gersh

former_member186338
Active Contributor
0 Kudos

Hi Gersh,

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

WRITE=OFF

QUERY=OFF

STARTMONTH=$STARTMONTH$  //DM Variable

ENDMONTH=$ENDMONTH$ //DM Variable

MONTHSBETWEEN=MONTHSSET //Result variable

DEBUG=OFF

*END_BADI

*XDIM_MEMBERSET TIME = $MONTHSSET$

...

B.R. Vadim