Communication is key. Understanding relevant SAP terminology is the fundamental principle for conversing in the industry. Accurately transposing technical topics across functional and tech teams is the foundation for project success. The cruciality of precisely conveying the subject at hand should go without saying. However, many times tech and functional team members fall short on embodying this notion. And depending on the magnitude of the conversation, this could be just a small blimp or detrimental to the task at hand. Working in SAP for the past 5 years, I know how common it is to misrepresent a system issue or requirement due to the sheer complexity of the environment in play – which is no different in the SAP BPC arena. In an aim to educate and mitigate potential confusion, this blog will break down an SAP BPC version for NetWeaver (standard model) on HANA environment using the EPM Add-In as the frontend reporting tool, primarily from a reporting lens.
To set the stage, let’s start with the backend which, for this blog’s purpose, consists of the Application and DB layer.
Most commonly, the backend is referred to as both the application and the database. However, they’re independent of one another and to ensure precision in communication, they should be called out separately.
Within the application, we have the Product, NetWeaver and amongst others, the following installed software components: BW, CPMBPC & HANABPC. In the standard model of BPC, there is no modeling done within BW. The work takes place in the BPC Web Client which is then passed down to the data warehouse. The BPC component (CPMBPC) is compiled of a series of t-codes (all starting with UJ), tables, programs, etc. enabling SAP Business Planning and Consolidations to be possible. HANABPC is an additional component required and a pre-requisite to make your environment a BPC powered by HANA system. Once the HANABPC component is installed, you will need to run program BPC_HANA_MIGRATE_FROM_10 in SE38 and flip the value of parameter ENABLE_ACCELERATOR or ACCELERATOR_ON to “X” or “Y”, to enable a BPC powered by HANA system. Further HANA functionality can be leveraged once this step is complete - for example, passing the MDX parsing / execution down to HANA via the ENABLE_HANA_MDX parameter.
While the above is just an example of what one environment could look like, it’s vital to understand exactly how your system is configured to: communicate across functions and throughout organizational levels, efficiently troubleshoot, understand resource needs and to work with SAP on issues – to name a few reasons.
This blog won’t be going into much detail on the HANA DB (or the Web Client). The only aspect I want to reiterate to those who work in the industry, the HANA DB is where the data is originally stored and unless caching is in affect above the DB, each call will need to fetch data from HANA.
The EPM Add-In, in its core, is nothing more than an Excel Add-In. While it’s a client install like Analysis for Office, unlike AO, EPM doesn’t have a dedicated server or separate platform outside of the application and DB layer. It’s purely a stand-alone client tool. Users log-in via an HTTPS entry to initially connect to the application servers. If an individual decides to save an EPM report to the server, they will be saving to the File Store via the UJFS t-code, in the BPC component of NetWeaver. EPM reports and the tool itself should not be referred to as BPC, as that’s incorrect and will mislead colleagues & management.
While users connect to a given BPC model to leverage pre-defined logic to extract data, report developers have the opportunity to create additional formulas within the EPM Add-In called Local Members, which is not to get confused with Member Formulas. Local Members are created (and exist) within the report, where Member Formulas are created in the Web Client & exist on the backend. Both are leveraged for reporting & the decision between creating the two will be by a case-by-case basis, depending on the requirement.
One area I want to highlight where communication becomes overly important is when error messages pop-up within the EPM reporting tool. More often than not, these errors are stemmed from the backend and are a result of the application. In this case, the error should not be communicated as an EPM issue, but a backend issue which is impacting the frontend. True EPM errors are more often times than not, report development flaws. And if you want to get really specific, you can take it one click down and call-out MS Excel issues which would be the Add-In getting disabled.
Now, let’s bring what we’ve learned together and discuss the end-to-end report workflow & different scenarios.
At a high level, when a report is refreshed (in a load balancer environment), the Web Dispatcher, which is located in a demilitarized zone outside of NetWeaver, will communicate to the message server within the central service to conclude which application server is available to handle the request. From there, the Web Dispatcher will pass the call down to the Internet Communication Manager (ICM), via gateway, which will ultimately allow for a dialog work process to be created. The dialog process will perform the corresponding steps in the application, and will eventually be passed down to HANA DB, which will follow similar server steps to fetch the appropriate data. The call is completed when it’s sent back to the EPM Add-In for final construction, before the report is rendered on your machine. And by final construction, I mean formatting, excel logic or any built-in VBA code within the workbook.
For those new to the end-to-end report refresh process, I’ve complied the below diagram to illustrate (once again, more at a high level). Visual enhancements are slotted for the next release.
End-to-End Report Refresh Workflow
There are many complexities to the application and the DB, and then on top of that, you have EPM Add-In in the mix. While I’m just touching on high level concepts at the different layers, there’s going to be scenarios where an end-to-end analysis needs to be undertaken to ascertain root cause, or to tune the system. To get a better understanding of these complexities, I’ll briefly highlight two end-to-end scenarios that if not properly understood and accurately communicated; will leave you and your colleagues scratching your heads.
The EPM Add-In, Application and HANA DB all have (multiple) timeout parameters and each has its own caching. You’ll have to understand how (and why) your environment is configured to weed out fallacious theories. Without this institutional knowledge, the wheels start to churn.
Now that we’ve covered key concepts and broken down an example of an SAP BPC Version for NetWeaver (standard model) on HANA Environment (primarily from a reporting lens); you’ll be better suited to articulate within the organization.