Script Logic choice SQL or MDX in NW release?

Hi experts,
I have encountered some opposite arguments in forum. Please can you clarify NW release script logic choice should be as MS release?
In [Script Logic BPC MS (SQL) vs. NW (ABAP); Tim Klem states
- "Write the logic using BPC SQL script logic syntax (not MDX) for performance reasons" but this opinion based on MS version. How about NW release is it really smarter to select SQL Script rather than MDX.
There is another statement in [Re: BPC 7 NW; Deppak mentions that:
- "In BPC 5.1 the script formula approach suggests to use SQL based logic instead of MDX.
Whereas in Teched,08, I learnt that MDX & ABAP (using BADIs) would be used for it. Thats why I am slightly confused...."
But second statement is far beyond NW relase date and I am sure this is not true but I would like you to confirm that.
If you were a project responsible and want that all scripts will be held in one language, what would you choose??
Thanks in advance,
ergin ozturk

Hi Ergin,
I can understand your approach not to use ABAP hence you miss the skills witin your project team.
However, you (or you client) has chosen the NetWeaver version for whatever reason. I'm sure a thorough decisions process has lead to this decision. In choosing the NetWeaver version with SAP BI you will sooner or later come to the point that you will have to use ABAP if you like it or not. Especially when you start using further capabilities within NetWeaver and the BI solutions. So from my point of view ABAP knowledge is an essential skill you need in a project based on SAP NetWeaver anyway.
Additionally I heared some statements that MDX is causing some performance issues on the NetWeaver version. This may have been fixed in the meantime with some SPs.
As the SQL within the NetWeaver verison does not have the full functionality than it has in MS Version SQL is not an option for me.
I do also not see the cost impact hence someone need to do the support anyway. In case of MDX you need an MDX developer, in case of ABAP and ABAP developer. Or a technical BPC consultant able to do the development (which I would recommend you should have in your project team anyway).
So coming back to your original question, I would recommend to do as much as possible using ABAP BADIs.
Cheers,
Steffen

Similar Messages

Referring to SQL comment table in Script Logic

Dear all,
If i have the following combination of dimensions, i.e. "DimA, DimB and DimC", and they will point to a comment in the comment table in SQL, how do i grab the [Comment] from the comment table to be used in my script logic.
I was adviced to use *select statement, but i can't seem to get it to work.
Any help is much appreciated.
Cheers,
Lip Chean

Hi,
*Select allows you to retrieve a list of elements from a dimension or table and save it in a user-defined variable for later use anywhere else in the logic.
For example, with this instruction:
*SELECT(%REPORTING_CURRENCIES%, u201CIDu201D, u201CCURRENCYu201D, u201C[GROUP] = 'REP'u201D)
In this case, you retrieve the ID of all members in the CURRENCY dimension where the property GROUP has the value REP. Running this example fills the variable %REPORTING_CURRENCIES% with the list of reporting currencies defined in the current application.
Important information
xxx The SELECT statement generates a SQL query, and NOT an MDX query. This implies that it can be executed against any SQL table existing in the application set database, and not just against the properties of a dimension in the cube. The prefix "mbr" is automatically added to any name entered in the table parameter. Otherwise, the name of the table is taken as is. If
you want to select a list of elements from a dimension using an MDX query use *MEMBERSET statement.
xxx In case any parameter contains embedded commas the entire parameter must be enclosed in an extra set of double quotes.
xxx The *SELECT statement is executed at the time the logic is validated, and the expanded result is written in the LGX file. This means that if the related dimension is modified, it may be necessary to re-validate the logic.
xxx Statements returning no members do not necessarily cause the validation of the logic to fail. In this case a warning is entered in the validation log.
xxx These instructions are not specific to a given logic section, but they can be written once anywhere in the logic and used across multiple commit sections.
Hope this helps.
Badrish

Script Logic: Using a property in MDX *REC statement (BPC NW)

Hi,
Is it possible to use a Property in an MDX statement without using *LOOKUP() function? I have script successfully working but it takes 15 minutes to execute and would like to speed it up.
I understand that [DIMENSION].[MEMBER].Property is not valid syntax, and do not believe NW has any other functions to resolve the issue, except *LOOKUP which takes a long time.
Specific Example is below:
I have a piece of script that successfully splits JV Expense by customers. A Profit Share planning driver determines the percentage that each customer is entitled to. Typically this will be 100%, but could be 50% between two customers.
The PROFIT SHARE planning drivers records, and PARTNER_INCOME transactional records are below:
ACCOUNT
ENTITY
PARTNER
SIGNED DATA
PROFIT_SHARE
UK_001
PARTNER_A
0.5
PROFIT_SHARE
UK_001
PARTNER_B
0.5
PROFIT_SHARE
UK_002_PLANNING_DRIVERS
PARTNER_B
1.00
PARTNER_INCOME
UK_001
NO_PARTNER
$5,000
PARTNER_INCOME
UK_002
NO_PARTNER
$5,000
UK_001 has two partners that are each entitled to 50% of the $5,000 NET PROFIT.
For UK_002, one one single Partner is entitled to 100% of the $5,000 NET PROFIT.
Using script logic, you can scope the Profit Share account (PROFIT_SHARE) - , and use a *REC statement to multiply this by the driver. It would look like:
*XDIM_MEMBERSET ACCOUNT = PROFIT_SHARE
*WHEN ACCOUNT
IS *
*REC (EXPRESSION = %VALUE% * ([ACCOUNT].[PROFIT_SHARE],[PARTNER].[NO_PARTNER]), ACCOUNT = PARTNER_PROFIT_SHARE)
*ENDWHEN
This wouldn't be a problem if the Planning Driver is always stored on the same Entity that the Income is stored on, but for UK_002, the planning driver is stored on another Entity - which is stored in a the PLAN_DRIVER_REF property of the entity. It should use UK_002_PLAN_DRIVERS
ID (Entity)
PLAN_DRIVER_REF
UK_001
UK_002
UK_002_PLAN_DRIVERS
UK_002_PLANNING_DRIVERS
In this scenario, we need to switch out the Entity used in the MDX, however I do not believe you can use a property in MDX - can anyone confirm?
I have currently implemented the *LOOKUP functionality to loop through, changing each *LOOKUP partner for each loop.
Lookup:
*LOOKUP PLANNING_JV_US
*FOR %LOOP_ASLS% = %ASL_LOOKUP_LOOP_VARIABLE%
*DIM LOOK_%LOOP_PARTNERS%:ACCOUNT = "PROFIT_SHARE"
*DIM LOOK_%LOOP_PARTNERS%:PARTNER= %LOOP_PARTNERS%
*NEXT
*DIM ENTITY = ENTITY.PLAN_DRIVER_REF                   //   Use PLAN_DRIVER_REF Property of Entity
*ENDLOOKUP
Scope and *REC:
*XDIM_MEMBERSET ACCOUNT = PROFIT_SHARE
*WHEN ACCOUNT
IS *
*FOR %LOOP_PARTNERS% = %PARTNER_LOOKUP_LOOP_VARIABLE%      // 1000 Partners
*REC(EXPRESSION = %VALUE% * LOOKUP(LOOK_%LOOP_PARTNERS%), PARTNER= %LOOP_PARTNERS%, ACCOUNT = TCOJVSHAR_CALC, AUDIT_ID = PP_EXPENSE_BY_PARTNER)
*NEXT
*ENDWHEN
The problem with the above, is that because the Lookup is being generated for every single Partner, there are significant numbers of loops.
Does anyone know of another way this can be implemented in Script Logic? Otherwise we'll need to explore BAdI route.
Thanks,
Nick

Hi Nick,
Use property in LOOKUP - will dramatically speed up the calculation without FOR/NEXT.
Vadim

SQL functions in Script Logic

I want to build a script logic but the dimensions that I am testing do not have the fields I want in the format I want. In my case I would like to test the "Start" property in the Employee dimension. The property represents the employee start date but is a var char in the format dd.mm.yyyy rather thna a date field. I want to test whether it is five years prior to the date being processed.
My time dimension has a year property and a monthnum property. Each of these are varchar. I can write SQL that would convert these to a date and compare them with the start property on the employee dimension.
Can I do iinsert SQL functions in the When statement. An example would be
*When convert(datetime, substring(employee.start,4,2) + '/' + substring(employee.start,1,2) + '/' + substring(employee.start,7,4))
Can I use SQL functions in the Is statement? An example would be
*Is <DateAdd(YY,-5 , convert(datetime, Time.Monthnum + '/01/'' + time.year)
Finally when I use such techniques and look at the log by using "show log" in the logic debugger I see no reference to the SQL I used. It is as if the generated SQL has not made use of my functions. Instead all I seee are the extract statements from the three fact tables. Is this normal? Is there a way to see what SQL is really being generated and run?
At the moment it seems my only option is to make changes, try running it and hope I get an output. If no records are written I can't be sure whether it is because embedding SQL function is not supported or because I have made some other error.

No, the "BPC SQL" script logic doesn't allow for this extensive use of real SQL within the scripting syntax. As a concept, it's best to think of "BPC SQL" script logic as, "this unique BPC logic syntax will generate real SQL code when it's executed."
There's very little real SQL that you can use within the syntax itself, and definitely not within the WHEN or IF statements. Nothing like cast, convert, substring, etc. (Except you CAN use these, a little bit, in a *SELECT statement. But I don't see how that will solve your current problem.)
Plus, when you consider how the logic engine processes a set of data, it's helpful to think of it in terms of selects & reading through a recordset. So in that regard, a SQL background can be helpful, in understanding the concepts. (Sort of helpful, except when it confuses you, or frustrates you since you don't have all the power you want.)
Anyway, to solve your problem, you might be able to restate the problem, and then use something like this code, which is valid syntax:
*WHEN TIME.TIMEID
*IS >= VERSION.FirstPlanMonthTimeID
In this case, FirstPlanMonthTimeID is set up in the version dimension as, for example, 20090400 (representing 2009.APR). This timeID is set by BPC automatically when processing the time dimension, and I need to ensure that my Version property value is set to match it.
A key point is that in BPC fact tables, the time dimension is stored as TIMEID (not ID, unlike all the other dimensions), and can be used for comparative evaluation in script logic WHEN/IF. The comparison property needs to be stored as an 8-digit integer value. If your time dimension has days in it (along with months), check the TIMEID after processing, and you should see the pattern for assigning values to TIMEID for days and months, etc.
Normally, TIMEID is assigned pretty sensible and stable values. If it doesn't meet your logic requirements, you can create another property (be careful of USERTIMEID, since that has a specific purpose in the system which I've never fully understood) and assign that whatever (integer) values make sense.

Evaluation of SignedData in Script Logic v7.5 SQL

Hello everyone,
I'm noticing a problem in script logic at a client trying to upgrade to version 7.5 SQL. This client has used its logic for around 5 years now through versions 4 and 5 but is now having a problem moving to version 7.5 and using this logic.
It appears that evaluation of signeddata doesn't work in version 7.5 in SQL. For example, a statement like:
*WHEN ACCOUNT
*IS 1000
*WHEN SIGNEDDATA
*IS <>0
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Doesn't appear to be working. It's also possible that a reference to the TIMEID property is not working in something like:
*WHEN ACCONT
*IS 1000
*WHEN SIGNEDDATA
*IS >TIME.TIMEID
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Does anyone have any experience using SIGNEDDATA references in logic in version 7.5?
Thank you,
Grant

Hello everyone,
I'm noticing a problem in script logic at a client trying to upgrade to version 7.5 SQL. This client has used its logic for around 5 years now through versions 4 and 5 but is now having a problem moving to version 7.5 and using this logic.
It appears that evaluation of signeddata doesn't work in version 7.5 in SQL. For example, a statement like:
*WHEN ACCOUNT
*IS 1000
*WHEN SIGNEDDATA
*IS <>0
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Doesn't appear to be working. It's also possible that a reference to the TIMEID property is not working in something like:
*WHEN ACCONT
*IS 1000
*WHEN SIGNEDDATA
*IS >TIME.TIMEID
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Does anyone have any experience using SIGNEDDATA references in logic in version 7.5?
Thank you,
Grant

Calc Previous YTD periods in SQL script logic

Hi, experts!
I need help in writing SQL script logic. I want to calculate such logic
(Account = Acc3, TIME = 2009.FEB ) = (Account = Acc1, SUM(TIME = (2009.JAN; 2009.FEB))) - (Account = Acc2, SUM(TIME = (2009.JAN)))
(Account = Acc3, TIME = 2009.MAR ) = (Account = Acc1, SUM(TIME = (2009.JAN; 2009.FEB; 2009.MAR))) - (Account = Acc2, SUM(TIME = (2009.JAN; 2009.FEB)))
..... and so on
Thanks all for help.

Hi Petar,
Thanks for your advice.
Legalapp in my Apshell do not have any account transformation rules. But looking at the account transformation table, I can see it requires dimension type datasrc and subtable for datasource and flow fields. But currently my application is similar to the Finance application from Apshell and do not have these dimension types.
Still I created a rule in account transformation table by having these fields blank and the validation was successful. Then I used SPRUNCALCACCOUNT in default.LGL file to trigger this rule but I don't see this working.
Can you help me on below questions:
1. Is it necessary to have datasrc and subtable dimensions to create account transformation rule?
2. Will SPRUNCALCACCOUNT write the values to WB table or should I use COMMIT or any other command along with his to have the values written?
3. Is there any way/place where I can get the examples of Account Transformation rules ?
Thanks
Sharath

Math power function in script logic

Hello all!
Can anybody help me how I can do math "power" function in BPC 5.1 Script Logic?
Thanks

Let's say you have a source account FOO and you want to calculate FOO to the 5th power, posting the result to FOOFIVE.
In BPC SQL scripting, there are no mathematical functions to play with (powers, roots, sine, cosine, etc.) except for add, subtract, multiply and divide -- plus you can round results in your Factor or Expression. So that means, we must use multiplication.
You could certainly do this using a bunch of intermediate accounts, one each for foo squared, foo cubed, foo to the 4th, and foo to the 5th. That would require *GO in between each *WHEN/REC block, and could be slow.
I haven't tried this, but I think this should work, all in one statement:
*XDIM_ACCOUNT = FOO
*WHEN *
*IS *
REC(Factor=GET(Account="FOO")GET(Account="FOO")GET(Account="FOO")GET(Account="FOO")*GET(Account="FOO"),Account=FOOFIVE)
*ENDWHEN
If you want FOO to the 50th power, copy & paste.
If you want square root of FOO, that could be a real challenge. I think to use straight BPC SQL logic it wouldn't be possible. I would probably write a stored procedure using SQL's SQRT(), and call that from the BPC logic file. Likewise for any other geometric functions, complex algebra, etc.
There also may be a way to calculate powers in MDX -- that's more mathematically straightforward -- but as a BPC on MS person, I really never ever use MDX due to performance.
Regards,
Tim

SAP BPC 5.1 Script Logic Issue

Hi Guys,
I have a problem with Inventory Days script logic at the moment. Basically what the logic should do is:
1. Copy the required data across to a calculation category (SQL)
2. Calculate the last 12 months Cost of Sales for every entity in the selection for 3 years (MDX)
3. Use the Cost of Sales number and multiply it with the inventory days number (SQL)
The calc works fine for some of my smaller brands (200 - 500 entities), but when i run the logic for my big brand (2000 entities) the last step doesn't calculate correctly. I have done the following to try and fix the problem.
1. Every step has it's own COMMIT
2. I clear the data before writing anything
3. I use XDIM_MAXMEMBERS Entity = 500
Any ideas why the logic is acting like this? I don't know if I am allowed to post my code here, but if it will help i will
Regards,
Andries van den Berg

Hi,
I only sent you the step that is giving me a problem at the moment. I broke the logic up into different packages to check where the problem lies and narrowed it down to this one.
It seems like the code didn't copy across correctly, it is supposed to be when EXTRAP.BRAND "<>" "". I'll just paste the code again, just so that we are all on the same page.
Regarding the FAC2, the client was running the code a lot of times and the WB table was getting huge. So, i started posting the records to the FAC2 table and processing it in the SSIS package. And i did confirm that they are posting there.
I just tried to run the script for half of the entities and it didn't work. I then tried to run is for 25 entities and it worked. Could the *XDIM_MaxMembers Entity = 50 be giving me the problem? This is all i get over and over in the formula log:
RPTCURRENCY,ACCOUNT,CATEGORY,DATASRC,ENTITY,INTCO,TIME,SIGNEDDATA
LC,80500,BUDGET,INPUT,P71559,NON_INTERCO,2010.AUG, 0
The other thing that bugs me is that i have similar script that never gives me issues for the same client.
Regards,
AvdB
//Step 4 -- Calculate the Inventory per month for all the entities selected
*SELECT(%BUDGET_YEAR1%,"[BUDGET_YEAR1]","CATEGORY","[ID]='BUDGET'")
*SELECT(%BUDGET_TIME_SET1%,"[ID]","TIME","[YEAR]=%BUDGET_YEAR1% AND [CALC] = 'N'")
*SELECT(%BUDGET_YEAR2%,"[BUDGET_YEAR2]","CATEGORY","[ID]='BUDGET'")
*SELECT(%BUDGET_TIME_SET2%,"[ID]","TIME","[YEAR]=%BUDGET_YEAR2% AND [CALC] = 'N'")
*SELECT(%BUDGET_YEAR3%,"[BUDGET_YEAR3]","CATEGORY","[ID]='BUDGET'")
*SELECT(%BUDGET_TIME_SET3%,"[ID]","TIME","[YEAR]=%BUDGET_YEAR3% AND [CALC] = 'N'")
*XDIM_Memberset Time = %BUDGET_TIME_SET1%,%BUDGET_TIME_SET2%,%BUDGET_TIME_SET3%
*XDIM_Memberset Category = TOPDOWN, BUDGET
*XDIM_Memberset Entity = %Entity_Set%
*XDIM_MaxMembers Entity = 50
*XDIM_ADDMemberset ENTITY = CLKS,MUS,BS // Add global entities
*XDIM_Memberset ACCOUNT = Last12FSCoS,Last12DispCoS, InventoryFSDays, InventoryDispDays //Add the caculated CoS account from the previous step and the Global Driver for days
*WHEN ENTITY.EXTRAP_BRAND
*IS <> ""
*WHEN CATEGORY
*IS TOPDOWN
*REC(EXPRESSION=(GET(ACCOUNT="Last12FSCoS",CATEGORY="TOPDOWN")*GET(ACCOUNT="InventoryFSDays",ENTITY=ENTITY.EXTRAP_BRAND,CATEGORY="BUDGET")/365)*-1,NOADD,ACCOUNT="80500",CATEGORY="BUDGET")
*REC(EXPRESSION=(GET(ACCOUNT="Last12DispCoS",CATEGORY="TOPDOWN")*GET(ACCOUNT="InventoryDispDays",ENTITY=ENTITY.EXTRAP_BRAND,CATEGORY="BUDGET")/365)*-1,NOADD,ACCOUNT="80510",CATEGORY="BUDGET")
*ENDWHEN
*ENDWHEN
*WRITE_TO_FAC2
*COMMIT

*Prior statement in script logic

Hi,
I'm getting started with script logic and I'm trying to create a record that will be the result of the current amount in a specific account minus the amount for the same account in the previous period.
I was thinking to use a "prior" statement, but not really sure how to do that. Do somebody could write me an example that would sbustract my current amount minus the amount from the previous period where the account is the same in a sql logic?
Thanks
Martin

Hi,
This should do the trick.
*INCLUDE SYSTEM_CONSTANTS.LGL
*XDIM_MEMBERSET TIMEDIM=PRIOR,%TIME_SET%
*XDIM_Member DataSrc=INput
*WHEN *
*IS *
*REC(EXPRESSION=GET(DATASRC="INPUTSAP",TIME=PRIOR)-GET(DATASRC="INPUTSAP"),NOADD,DATASRC="Movement")
*ENDWHEN
*commit
Cheers,
AvdB
Edited by: Gert Andries van den Berg on Aug 12, 2009 9:14 AM

Custom Measure in Script logic

Hi,
We have a custom measure created which is more or less the same as the YTD, but it starts not at the beginning of the year, but instead it starts at a given month.
The measure creation was ok and we can use it perfectly well in reports and input shedules and the cumulation of data is ok.
However, if we want to use this measure in a script logic it does not work.
- Validating the script in the admin console goes fine
- Executing the script gives the error:
- Root element is missing
- validating in UJKT gives the erro:
- UJK_VALIDATION_EXCEPTION:Invalid Measures value: "T_232"
The script we try to use is below. If we change the LTD (our custom measure) by YTD it works perfectly fine:
*XDIM_MEMBERSET BUILDSTATE=NABS
*XDIM_MEMBERSET BUSAREA=V1
*XDIM_MEMBERSET CATEGORY=FCSTCUR
*XDIM_MEMBERSET DATASRC=INPUT
*XDIM_MEMBERSET ENTITY=201
*XDIM_MEMBERSET MARKSEGM=NAMS
*XDIM_MEMBERSET ORIGIN=OBOOK
*XDIM_MEMBERSET PRODUCT=ELEVATORS
*XDIM_MEMBERSET PROFCENT=201251
*XDIM_MEMBERSET RPTCURRENCY=LC
*XDIM_MEMBERSET SALESORG=SO_201
*XDIM_MEMBERSET TECHPLATF=NATP
*XDIM_MEMBERSET TIME=2010.OCT
*XDIM_MEMBERSET TYPE=T_PLAN0
*XDIM_MEMBERSET NEBACCOUNT =BAS(T_232)
*XDIM_MEMBERSET MEASURES=PERIODIC
[NEBACCOUNT].[#A232]=([MEASURES].[LTD],[NEBACCOUNT].[T_232])
*COMMIT
Thanks for any input on this. We want to avoid going via a BADI!
Kind regards,
Christophe Posson

Hi Christophe,
I'm in a similar position to you and wish to avoid use of a BAdI if we can - despite the MDX parser engine being pretty pathetic at handling YTD or custom measures.
Did you get a resolution to this? If so, could you please share it with everyone?
As much information as possible would be apprecaited. Our next move is to contact SAP for confirmation that there is no possibility of using custom measures in Script Logic.
Many thanks,
Nick

Handling Ranges in Script Logic

Hi Experts
Is it possible to put logic to check a range of values in Script Logic.
For example, if I need to check if the value in Quantity Account is between 200 and 800, then only some Quantity Discount is calculated against this.
What command should one use for this
Any input would be very helpful.
Regards
Krishnendu

Hi Krishnendu,
I believe that you can use MDX or a BADI to do this. Using MDX, for example, the following should write 100 to the QUANT_DISC account in the event that QUANTITY is greater than 200 and less than 800:
[ACCOUNT].[QUANT_DISC] = IFF(([ACCOUNT].[QUANTITY]) > 200,IIF(([ACCOUNT].[QUANTITY])<800,100,0),0)
This is just example MDX code - you'll have to adapt and test yourself. I suggest using the script logic tester to speed the process. Performance may be less than ideal, and you can certainly implement this in a BADI in that event.
It would be nice if it were possible to do this using WHEN/IS statements in script logic, but at present conditional logic based on measure values is not supported in that context.
Ethan

Syntax in script logic

Hi Friends,
I have input schedule in below format.
Product   Rate/2011.INP Packing/2011.INP QTY/2011.APR AMOUNT/2011.APR QTY/2011.MAY AMOUNT/2011.MAY
PM         3                 3              3               27            4         36
PN        5            2          2          20     3 30
Here Amount= Rate*Packing*QTY. Pls correct below script logic and make it generic for all months.
*XDIMMEMBERSET TIME=2011.APR,2011.MAY,2011.INP
*XDIMMEMBERSET ACCT=QTY,RATE,PACK,AMOUNT
*WHEN ACCT
*IS QTY
*WHEN TIME
*IS 2011.APR,2011.MAY,2011.INP
*REC(EXPRESSION=%VALUE% * ([ACCT].[RATE],[TIME].[2011.INP])
                         * ([ACCT].[PACK],[TIME].[2011.INP]),
                             [ACCT]=AMOUNT,[TIME].[2011.APR])
*ENDWHEN
*ENDWHEN
*COMMIT
Thanks,
Naresh

Hi,
You can simply write this using MDX formula,
[ACCT].[#AMOUNT]=[ACCT].[PACK]*([ACCT].[RATE],[TIME].[2011.INP])*([ACCT].[QTY],[TIME].[2011.INP])
Run this code with required months from DM package it gets executed for defined time periods.
Hope this helps,
Regards,
G.Vijaya Kumar

Use BADI or LGF script logic? Which is good in performance

Hello,
I have a situation wherein a choice is to be made among the "BADI" or "script logic" having DESTINATION_APP which is along with WHEN clause.
Below is the code in which WHEN clause is used:
Code Starts****
XDIM_MEMBERSET CATEGORY=FC_CUR
*DESTINATION_APP=GROSSMARGIN
*SKIP_DIM =WEEK
*ADD_DIM PLAN_PARTNER = PP_NA, RPTCURRENCY = LC
*WHEN CATEGORY
    *IS "FC_CUR"
              *REC(EXPRESSION=%VALUE%)
*ENDWHEN
*****Code Ends****
The business requirement could be changing as we are at initial stage, wherein i may have to incorporate some data mapping logic which can also be handled through scripts instead of using BADI.
The major concern is if BADI would be most prefferable over script logic having WHEN clause to acheive the optimal performance considering large no. of records that needs to be written to the target APPLICATION
from the source application?
OR
The script with WHEN statement is fine if the data mapping is pretty simple and would not have much impact on performance compared to using of BADI even if the records to be moved is huge.

If data mapping is simple you can opt for script logic . If requirement is complex then you can go for BADI . You can check this [How-to|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/70187b3e-d5ce-2d10-d780-bb8b1a5b0bdc?QuickLink=index&overridelayout=true] 6 th page on performance considerations of BADI .
A well designed BADI implementation is faster than script logic

7.0NW: script logic to post data to another cube

Hi,
On the 7.0NW we have a FINANCE cube (8 dimensions) and a FINANCE_DETAIL (12 dimensions) cube. I was hoping that someone could advise on how to transport data using script logic from FINANCE_DETAIL to FINANCE, knwoing that the SQL logic for the MS-platform is no longer applicable (DESTINATION_APP statement) on the NW-platform.
Thx&Rgrds
Bjorn

BPC7Nw supports ABAP development through script logic. You can use the keyword 'call custom logic' to execute the BADI that you developed. With SP01, you can also pass parameters to this BADI. Here are step by step instructions to do the same.
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/20f4252d-98ca-2b10-e689-f85085ae2d12
Regards
Pravin

Script logic error - Invalid object name 'tblStatus'

Hi all,
Running BPC 5.1 SP5 on SQL 2005.
Has anyone ever seen this error message before? I only get the error message when choosing the run-time option in the package, to honor work status settings. This problem just appeared in the last few days, and I believe that a month or two ago, users were running the same logic (with the same yes-honor-work-status option selected).
We did recently upgrade from 5.1 SP3 to 5.1 SP5, and I'm wondering if this may be a cause? That's just a hypothesis though.
Invalid object name 'tblStatus'. in:
select distinct d.VERSION,d.ENTITY,d.TIMEID
from #RESULT_333729 d where signeddata<>0
and exists (select * from tblStatus s where [APP]='CONSOL' and d.VERSION=s.CATEGORY and d.ENTITY=s.ENTITY and d.TIMEID=s.TIME and [STATUS]>0)
I understand what it means, and of course there is no table in the appset database tblStatus. Work status locks are kept in tblConsolLock (where Consol is my app name). And in that table, the field name is StatusCode, not Status. So it appears that this is some vestige of code from an earlier version of BPC / O'soft.
This error occurs in a piece of script logic, that includes both basic SQL WHEN/IS/*REC's and also a *RUNALLOCATION. The error is thrown within the RUNALLOCATION code block. The complete run-up to the error message is shown below.
-- Calculate difference
insert into #DIFF_333729 ([ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION],signeddata)
select [ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION],amtWHERE as signeddata
from #WHERE2_333729
select [ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION],sum(signeddata) as signeddata
into #RESULT_333729 from #DIFF_333729
group by [ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION]
--Time to calculate and count differences (45459 found):2.5 sec.
select distinct d.VERSION,d.ENTITY,d.TIMEID
from #RESULT_333729 d where signeddata<>0
and exists (select * from tblStatus s where [APP]='CONSOL' and d.VERSION=s.CATEGORY and d.ENTITY=s.ENTITY and d.TIMEID=s.TIME and [STATUS]>0)
call 1 completed and data posted in 23.6 sec.
Run completed in 23.7 sec.
End time --->11:01:05 AM - Date:1/16/2009
Invalid object name 'tblStatus'. in:
select distinct d.VERSION,d.ENTITY,d.TIMEID
from #RESULT_333729 d where signeddata<>0
and exists (select * from tblStatus s where [APP]='CONSOL' and d.VERSION=s.CATEGORY and d.ENTITY=s.ENTITY and d.TIMEID=s.TIME and [STATUS]>0)
Here is the original script logic (from the LGX file -- the LGF file has a whole bunch of variables in it that would only confuse the matter more). It works just fine when the
*RUN_ALLOCATION @A_1||
USING/TOTAL|
ACCOUNT WHAT=659210,659310,659320,659410,659510,659610,659620,659630,659710,659810,659820,659910; WHERE=<<<; USING=PCAYTD510000; TOTAL=<<<|
PRODHIER WHAT=PRODHIERL1A;WHERE=[PRODHIERLEVEL]='5'; USING=<<<; TOTAL=<<<|
DATASRC WHAT=PCAASSESSSTAGE1,PCAASSESSSTAGE2; WHERE=PCAASSESSALLOC1; USING=INPUTCONSOL; TOTAL=<<<|
ENTITY WHAT=[COMPANYCODE]='7470' AND [PCAASSESSDRIVERBP]='PCAYTD510000' AND
([PCAASSESSMETHODBP] = 'ALLOCAUTO' OR [PCAASSESSMETHODBP] = 'ALLOCMANUAL');WHERE=<<<;USING=7470.BASE;TOTAL=<<<|
Anyone experience this same error message? I searched for SAP support notes and found nothing to do with tblStatus or similar.
Thanks for your help,
Tim

Hi Sorin,
Thanks, you've confirmed what I suspected.
Yes, we always process & save apps & dims on any upgrade.
We've reproduced the problem in all 3 of the environments with the customer's appset. I haven't yet reproduced in ApShell, but will do so & report it as a bug.
And just out of curiousity -- was the other message you saw here in this EPM forum? Before I posted my question, I searched both here, and in the support notes, for "tblStatus" and a few other terms about work status lock errors, etc., and came up with 0 results.
Thanks again,
Tim

Script Logic choice SQL or MDX in NW release?

Similar Messages

Maybe you are looking for