In PerformancePoint Server 2007 Planning, you build centralised business rules in a new language called PerformancePoint Expression Language (PEL). PEL is very MDX-like and relatively straight-forward to pick up, if you are even a little familiar with MDX.
The beauty of PEL is that it can generate either MDX or T-SQL scripts from the same PEL Expression. This allows the developer/analyst to target either the cube itself, using MDX Script, or the fact table, using T-SQL, depending on which implementation approach is more suitable for the type of calculation and from a performance perspective.
Within the Business Rules Editor workspace you can easily select the implementation (SQL or MdxQuery) from the Rules Detail property list
With the Rule saved (it does not have to be deployed) you use the rule context menu to debug the rule.
If you come from a development background like me, you may expect a little more to happen than what actually does happen !
Depending on what implementation you have selected, and whether or not your PEL is valid, either the MDX or the T-SQL is generated from the PEL and displayed in a window. It’s important to realise that the PEL expression has not been run. It is for information purposes only.
From this point you can eye-ball the resultant query to help determine your issue or, as I tend to do, cut and paste into a New Query window inside SQL Server Management Studio. The resultant T-SQL tends to be extremely verbose so actually debugging the problem using T-SQL will be rare !
If there is a problem with the actual PEL itself, the reason, in the form of a (normally) reasonably helpful error message is displayed in the window, instead of the resultant MDX/T-SQL.
I was initially a little disappointed with the built-in debugging facilities, but considering the target audience of the Planning Business Modeler, full integration with SSMS or Visual Studio was never going to be a consideration. But, to be fair, it is probably just enough; the debugger is primarily aimed at ensuring your PEL is correct, it stops somewhat short of helping you debug the actual business logic but this can be handled if you cut, paste and hack the resultant MDX or T-SQL into another tool and even that becomes less and less necessary as you develop your PEL writing skills.
Introduction to Data Wrangler in Microsoft Fabric
What is Data Wrangler? A key selling point of Microsoft Fabric is the Data Science
Jul
Autogen Power BI Model in Tabular Editor
In the realm of business intelligence, Power BI has emerged as a powerful tool for
Jul
Microsoft Healthcare Accelerator for Fabric
Microsoft released the Healthcare Data Solutions in Microsoft Fabric in Q1 2024. It was introduced
Jul
Unlock the Power of Colour: Make Your Power BI Reports Pop
Colour is a powerful visual tool that can enhance the appeal and readability of your
Jul
Python vs. PySpark: Navigating Data Analytics in Databricks – Part 2
Part 2: Exploring Advanced Functionalities in Databricks Welcome back to our Databricks journey! In this
May
GPT-4 with Vision vs Custom Vision in Anomaly Detection
Businesses today are generating data at an unprecedented rate. Automated processing of data is essential
May
Exploring DALL·E Capabilities
What is DALL·E? DALL·E is text-to-image generation system developed by OpenAI using deep learning methodologies.
May
Using Copilot Studio to Develop a HR Policy Bot
The next addition to Microsoft’s generative AI and large language model tools is Microsoft Copilot
Apr