Taming the Fox – Unified way
Last week SAP announced the general availability of SAP BPC10.1. Looking at the features and series of videos released by Pras, it makes lot of sense for SAP to take “best of both worlds” and come up with a product that caters to the requirements of both business and IT. The next obvious question that comes to our mind is “Will it make sense to migrate to 10.1 “? “What additional features that we get ? etc. In this blog, i try to answers the questions from developers point of view and will translate its benefit for business. This is my first in series of blogs, where i will compare some basic features offered in SAP BPC 10.1 Vs older Versions and why SAP BPC unified model is way forward for all future BPC NW implementations . To start with, i’m trying to compare features offered by script logic Vs FOX.
Script Logic for BPC classic models are used to manipulate transaction data in models and generate/change/delete records from Models. However, SAP BPC Script is not matured to handle complex calculations. There are many limitations in logic scripts. Although,SAP NW do have the option of outsourcing the whole logic to ABAP through BADI. However, this makes script as an interface between front end( Input forms, DM packages) and BADI. Truly, with customization using BADI the application becomes IT driven rather than business driven.
On the other hand with SAP BPC 10.1 unified model, FOX will come back. From its SEM-BPS days FOX has been very effective in manipulating transactions data. With advent of BI-IP, FOX was enhanced to add multiple features which not only handles complex scenarios but also reduces development time. There are scenarios where we need to call a Function Module to manipulate data, but those scenarios are rare. Most of the calculation can easily be handled with FOX without the need to call a function module.
The table below compares features of Script Vs Fox. As shown in table, it can be safely concluded that FOX scripting has many features which makes it superior as compared to BPC logic Scripts. For instance, complex mathematical operations, flexible loop and condition statements, messages etc. On the other hand, BPC logic scripts do provide features like standard functions allocation etc which are missing in FOX. There are some functionality that are missing in both FOX and script but would be nice to have like “Date” functions.
Based on above features, lets try to plot complexity Vs Flexibility graph. The graph compares the complexity Vs Flexibility matrix for each of the features listed in table. More features better the scripting language.If you look closely at the plot,you will realize that the number of features FOX offers is far more than that of script logic. In addition, the number of features in 2nd quadrant(high flexibility and low complexity) is more for fox as compared to script logic.
There are some features for FOX which needs to move from 4th quadrant( 14,15 ) into 2nd or 3rd quadrant.This will make FOX a great scripting language without dependence on Function Modules for complex scenarios.
Obviously it will make more sense from developers point of view to write logic in FOX rather than in scripts. But whats there for business ? They don’t care if the logic is written in script/ABAP/FOX until you hit performance. Performance wise, i’m not sure which once will be faster. I’m assuming same as both work on similar concept. However there are indirect cost that business has to understand. Addressing complex scenarios using BADI/ABAP increases time line as well complexity of the project. In addition,supporting the application with lots of customization in BADI/ABAP itself becomes a challenge thus increasing the resolution time.
At the end as far as scripting is concerned, going the unified way and using fox will be a win-win situation for both sides.
There are few considerations that can also be added to augment your argument. If one has to adapt to a language - FOX vs Script, FOX is much more easier to understand and learn. Certain syntax of Script are quite alien in nature and need proper syntax knowledge to understand.
Also, IP is now completely in ABAP layer of NW making it a much more strong contender as far as performance is concerned. This should benefit FOX too indirectly.
I agree. I think it is more because of the lack of debugger.We can still debug the UJKT program to understand the way script works( hard way). Normal breakpoints option with step wise execution would have made life easier for early adapters to learn and write better scripts.
just some remarks:
1 "...BPC logic scripts do provide features like standard functions allocation etc which are missing in FOX"
-> FOX was not designed to implement standard functions; BW-IP/PAK has standard functions for these kind of tasks that one can simply use, no script language is needed. This way it is also easier to optimize run time. But you can write an 'allocation' with FOX if you want ...
2. Point 19 DB Save
-> BPC and BW-IP/PAK (this applies also to BPC unified) have a different design for LUWs(logical unit of work): all BPC 'functions' write back to DB, next function reads from DB again. Thus DB save might be needed in a script. BW-IP/PAK has buffers in a user session (e.g. to support simulation without save). So BW-IP/PAK 'functions' read from the user session buffer and write back to the user session buffer. The buffer reads from DB if needed. 'DB Save' is an explicit command that should not be part of a script language (this is just a planning function type) since it invalidates the BW-IP/PAK LUW concept. BW-IP/PAK saves everything or nothing, the user session might contain data from many 'basic planning providers' (not just one InfoCube).
3. It deserves to be mentioned that HANA has FOX support, i.e. FOX can be pushed down to HANA
Those are excellent points.
For point 2 - DB save, having a planning buffer where you can simulate before saving is a definite advantage.
Just one thing to mention - if you use only SQL statements in script logic: WHEN/IS/REC/ENDWHEN and not MDX [#XXXX]=[YYY]... then COMMIT is useless, because write to DB happens automatically at the end of WHEN/ENDWHEN. And because SQL syntax is significantly faster then COMMIT is an obsolete statement.
P.S. The above is valid for BPC NW.
Nice blog Pratyush. Thanks for sharing these points. Not sure how SCRIPT LOGIC can handle keyfigure model in new Unified Model. Any thoughts on this ?
there is no SCRIPT LOGIC in the 'unified' model; you have to use FOX.
Maybe the difference of BPC classic and unified is not yet clear (cf. the existing blogs about this topic). The short version is that you are using different engines and also different data models. In 'unified' you are using BW-IP/PAK engine and 'native' BW data models. Thus all these copies of master data, transaction data as in BPC classic are not needed. In addition, 'unified' supports also some concepts from BPC classic like work status and BPFs.
Long time. You can think of unified model as BI-IP with additional features. All features of BI-IP( fox,bex queries, inverse formula's etc) + BPC( BPF,Work status etc)+ HANA( mandatory).
For existing BPC implementations( classic), it will smoothly migrate to 10.1
If you look at cost benefit analysis, it makes absolute sense for existing BI-IP or SEM BPS customer to move to unified model. However, it will be a tricky question for those who have already implemented BPC NW. Unified model do add extra features . But are these enough for extra cost ? That's will be a big question.
There is a basic difference in understanding between BPC Logic Scripts and FOX scripting.
BPC Logic scripts gets and manipulates data at a business perspective/layer, directly at the application layer. FOX scripting is done at a technical layer.
There is one more important difference. BPC Script logic is not an OOPS language. Its a procedural programming language.
BPC NW is restrictive than BPC MS in many ways because of the platform difference. Anybody can just compare the number of keywords available between these versions in help.sap.com.
In your comparison chart, you are missing a lot of XDIM statements for filtering and some other stuff too.
Technically, a comparison chart cannot work for comparing a OOPS language against a procedural programming language. The way of writing program itself will be different. It totally depends on the comfort of the coder.
We have done BPC projects with calculations completely based on Script Logics too. Yes, you heard it right, that too on BPC NW version. Everybody knows script logic is much more dynamic in BPC MS, no questions about it. We have done BPC projects with calculations completely based on BADI too.
At the end of the day, the customer does not look for what is happening under the hood. Whether the required solution works and is it quicker than the old solution they know about and whether they have more control of the end solution without needing the help from IT.
As always, SAP will definitely accommodate to customer's request. Up until now, BPC has enabled to reduce business user's dependency on IT department. Unified model is built on PAK, which needs some extra work from IT. Let's wait and see how the product evolves in future without removing the flexibility of business team having total control of EPM products. But as of now, Unified models require a lot of work to let the business user take complete control. Trust SAP to bring those in near future.
Thanks Kaarthic for your feedback.
Few Points to ponder,
This blog was written assuming BPC 10.0 NW version and not MS. We can definitely add another column BPC MS script and compare all 3 .However,with unified version on the horizon, there will not be significant investments in BPC MS. If you go by SAP, they are recommending to move from SAP BPC MS to BPC NW version.
Please look into my blog point 7 .
It does make sense to compare the two irrespective of the way they are getting executed. . As a consultant, we don't care how/where it is being executed; But we care about flexibility it provides. as a scripting language,it should have the flexibility to address all scenarios. I'm not stating FOX can handle all scenarios and the blog highlights those points too.
Depending on your scenarios, you can do "all script", "all BADI" way. Its the way you and business agree. but you have to consider, the goal of BPC is to reduce the IT cost/dependency. So if you are going by all BADI way then the purpose itself is defeated( and obviously you are adding extra time and money) . If you are saying all script, then ideally it should have all the features stated above. For instance, date functions( you cannot manipulate dates in BPC NW; you have to use BADI for this). Similarly other features as highlighted in my blog. so i feel customer do care about how you gonna implement. We have to translate it into cost-benefit terms for them to understand.
Yes, you are correct, BPC unified is still new. But it is the right step in that direction.
Thank you for concurring Pratyush.
Yes, BPC MS will be phased out since there is no point in keeping a version that is not running on SAP's technology. Everybody knew it from the day SAP bought Outlooksoft. 🙂
And not all features in MS can be brought in, due to platform differences.
Yes, BPC is a tool which will be used by the finance users and they will be happy to take full control of the solution instead of depending on IT. (The main reason why customers prefer BPC). Yes, Unified is new step in the right direction of utilizing the power of HANA in a better way, in which the business features will soon be added too like classic BPC, so that business can take full control.