Design Studio 1.5: View on Variable Unmerge Scenario
A view on the variable un-merge scenario. Some entry points for you to get started. This is a blog of the series "Design Studio 1.5, View on..." - here the function "Variable Unmerge". For more topics see Design Studio 1.5: What's New in? A (technical) View.
The starting point.
Design Studio in previous release can handle many data sources and those again have potentially variables (BEx Variables, do not mix with term "Global Script Variables"). A variable can be input enabled or not, in case it is input enabled it can be maintained by the user. Until release 1.4 it was only possible to merge the variables.
What means "variable merge".
When variables are merged, the application is creating only one variable container which is holding the values of all variables. The values for a variable with the same technical name are always same, even those are coming from different queries. Here how this looks like:
Pic.1. Variable container for merged scenario
Having example as above, the variable container contains 3 variables from 2 data sources. And those variables will be always synchronized between APPLICATION data sources, BICS data layer and OLAP processor in SAP BW. This means, every change in any variable value requires update of all data sources. This is taking processing time, especially when data sources will be loaded in the script.
General States of Data Source.
As I have heard many questions on when the data source is executed - here an overview of "states" which can be taken by a data source.
There is actually no "executed" state, a data source can be un-assigned, assigned (initialized), in "variable set" state, in "variable submit" state and "result set requested". The picture below is showing the workflow.
Pic. 2. States of a Data Source
For this blog, important is the point "Event onVariabledInitialization()", as this is the place where you can react on the variables before user will see prompt dialog.
How to activate this scenario? There is a new property in the application - "Merge Prompts" which is set to "true" by default. You need to place it on "false". The application will reload in designer. You can still define which prompts the user should see, the option for "Prompt Settings" is still working as in merged scenario - you can change the sequence or remove some variables from the dialog.
Pic 2a. Option for (Un-) Merge Prompts
What is now changed in variable unmerge scenario? First, the user (by default) is facing the variables for every data source separately. In our case, it would mean that the prompt will show now not only 3 variables (2 from DS_1 and 1 additional from DS_2) but all 4 variables separately.
Pic. 3. Different Prompts in both scenarios (example)
What you can see now in the prompt dialog, the variables are bound to one data source only, and therefore have a prefix (by default it is the technical data source name) which can be adjusted in the data source properties (property "Text"):
Pic. 4. Custom Data Source Prefix
With this prefix additional options are possible, like "simulation of merge scenarios" even the unmerge is active (separate topic, see Design Studio 1.5: View on Variable "synchronized" Unmerge Scenario).
Effects on Data Source processing.
There are some positive effects on execution of applications with many (> 1) data sources - especially when not all data sources are instantiated immediately, but set to the "load in script" mode. The biggest effect is that the already instantiated data sources are no touch and the result set is not reloaded until variables from those data sources are not changed. This can save a lot of time in scenarios with background processing when new data sources are loaded one by one.
Setting of Variables (New Functions).
With release 1.5 you can find the known methods "setVariableValue" and "setVariableValueExt" (which were always available on APPLICATION level) also on data source level, e.g. DS_1.setVariableValueExt()... This is how you can control changes in variables for single data sources.
Reaction on Variable Changes (New Event).
There is a new event introduced on APPLICATION level - "On Before Prompts Submit". This event allows you to react on changed variables and e.g. change some of those shortly before the prompts get submitted. This can be used for the "simulated merge scenario".
Pic. 5. New Event "On Before Prompts Submit"
The event is located here in the Data Source state model - this event is triggered on application level and is data source independent!
Question: When is this Event triggered exactly?
Answer: This event is executed only when you press "OK" on the prompt dialog. It is placed to be able to react on the prompt dialog.
Question: What could be the procedure to distribute variable values from one DS to others?
Answer: My sugestion is:
- create a global script function which is implementing the distribution
- call this function from prompt dialog
- every time, you change variables in runtime using scripts, call the function as well
Question: can I make the variables distribution in "onVariableInitialization()" in case I set some default values to avoid prompt?
Answer: yes, you should - other case you can get the prompt.
Pic. 7. States of a Data Source with new Event
Why we need Variable Unmerge Scenario?
This scenario is required for use of parallel query execution. Even you want to merge thee variables, technically you need to use unmerge and with additional synchronization scripts you can achieve a "simulated merge". But in order to activate the parallel query execution, you have to run the application in unmerge scenario.
Potential Scenarios with Variable Unmerge.
Besides the effects on performance, and as prerequisite for on query parallel execution - you can also use variable unmerge scenarios for execution of the same query in a "comparison mode" - with different values of the same variable.
Perhaps not all aspects are covered yet, in case of questions, feel free to ask.