The new SAP Design Studio 1.5 is packed with a lot of performance enhancements and new features. The most notable performance enhancement is the ability to load queries in parallel. In the earlier versions of SAP Design Studio, data sources of an application were executed in sequence thus resulting in longer initial load times. With SAP Design Studio 1.5, we now have an option to load queries in parallel by assigning them to different processing groups. One of the main advantages of this feature is that it reduces the initial load time of the application to a great extent. In addition, it also improves the application performance whenever the result sets of data sources are retrieved. However, this new feature processes queries as groups and involves some cost in terms of server resources/sessions.
When parallel query processing is enabled,
- Variable unmerge will be applied across processing groups. Queries that belong to different groups cannot share variables.
- Each Processing Group will consume one session in the backend system. For example, an application with 10 queries split in to 5 processing groups will use 5 sessions in the backend system.
- If Traces/Profiling is enabled, individual traces will be created for each processing group.
NOTE: This feature is available only in SAP BusinessObjects BI Platform.
Now let us take a look into the how-to(s) and the info(s) related to parallel query processing.
Steps to enable Parallel Processing
Create a sample application and add queries as desired. I have made use of 6 different BEx queries based on BW data source here (as seen in the screenshot). Each of these queries bring in retail data.
Select the first Data Source, navigate to its properties, and select the property “Processing Group” under “Data Binding”. Under this property, you can either enter a name of your choice to define a new processing group under that name, or you can use the dropdown to select an existing Processing Group (if you already have some defined in the application). Here, we will go ahead and create a new processing group.
Enter the name of the “Processing Group” in this column (I have named it as ‘ONE’ in this example).
Repeat Step 2 for the remaining Data Sources – you can either create a new Processing Group for each Data Source, or select one of the previously created groups as well. I have gone ahead and created a separate Processing Group for each of the Data Sources EXCEPT PQRY_03 and PQRY_04 – both of which have been assigned to the same Processing Group “THREE” (as seen in the screenshots below).
Now assign queries to new/existing processing groups as per performance requirements. As mentioned earlier, each processing group will consume one session on the backend server. So each processing group will execute with its own memory and CPU cycles.
Add New Entry
Select Existing Group
Sample Application with 5 Processing Groups – Note that PQRY_03 & PQRY_04 are under the same Processing Group
Now, select the application properties and disable “Variable Merge” by setting “Merge Prompts” to “False”. This will enable all the processing groups to execute in parallel. This is because queries that belong to different processing groups cannot share/merge variables.
Now the processing groups will execute in parallel and this improves the application performance by reducing the initial load time.
Note: If processing groups are used to enable parallel processing and variable unmerge is not enabled, then the application will use sequential load and the following error will be thrown.
As mentioned earlier, each processing group will use one session in the backend server. If parallel processing is not enabled, then only one backend session is used for the entire application irrespective of the number of queries.
When the sample application shown above is executed in sequential mode, only one session is consumed on the backend server. Below is a screenshot from the backed server, listing the session details of an application executed in sequential mode.
SM04 – Application executed in sequential mode
When the sample application shown above is executed in parallel mode, five sessions are consumed on the backend server and all of them are started at the same/closer timestamp.
SM04 – Application executed in parallel mode
When profiling is enabled for applications that use parallel query processing, separate traces are created for each processing group.
Profiling – Query Sequential Execution
Profiling – Query Parallel Execution of One
Profiling – Option to select Groups
Loading Data Sources on Demand:
We can all load these data sources on demand through scripting.With respect to processing group attributes of data sources, a method called loadDataSources() has been introduced in SAP Design Studio 1.5. Earlier we used loadDataSource() method to load a particular data source on-demand (sequential processing). But with the introduction of parallel query processing, we can now load data sources in parallel using APPLICATION.loadDataSources(). This method would be a lot faster compared to calling loadDataSource on each data source.
Query parallel processing seems to be a promising option; however it involves a lot of overheads in terms of server resources and sessions. There are a few factors to be considered while using parallel processing:
Proper sizing of backend server is recommended to handle the memory needs of parallel sessions and session cleanup should be done periodically to close active sessions.
SAP BusinessObjects should be sized effectively to handle parallel query loads in order to ensure that the performance gained on parallel load is not spent on rendering.
Use on Need
Parallel processing can be used when there is a critical need and can be avoided in scenarios where it is not required. This will conserve valuable server resources from being over-loaded.
I hope this blog helps in providing you an overview of this very useful new feature – Parallel Query Processing. Keep following us for more!
Subscribe to our Newsletter
Licensing SAP Business Objects BO BI.
Understanding Your Options.
How does SAP software licensing work again? Right: it is based on two licensing components: package licenses and named user licenses. SAP offer a down to earth, easy understandable licensing model for SAP Business Objects BO BI. No more CPU’s – bye bye cores! In general, if an individual uses SAP Business Objects BI (SAP BO BI) solutions in a display-only manner, a named user license is not required. In that case, only the package license is needed.
OK. Only a package license is required if display only is needed. But package licenses come with metrics. The package license for SAP BO BI is available through two metrics: “concurrent session” and “user”. These metrics are offered as options. You can decide which one (or both) to use.
“You have a certain flexibility when licensing SAP BO BI: you can choose the concurrent session metric, the user metric or a combination.”
SAP BO BI license types
When talking about SAP BO BI licensing, referral is often made to a parking lot with two types of parking spaces: the ones with a license plate and the ones without.
Parking spaces with a license plate can be compared to “user” licenses. The parking space is assigned to one car and only the car with the identical license plate is allowed to park there. No other car can use the spot. The parking space for that particular car is available 24/7.
The other parking spaces (without license plate attached) can be freely used by all other visitors. Only one rule applies: if the car park is full, no new car can enter (and it has to wait outside until another car leaves). This is exactly the way “concurrent sessions” work.
Easy and down to earth comprehensible: concurrent session (CS) licensing limits the system to a fixed number of concurrent sessions. If administrators set-up 1000 users in the Central Management Console (CMC) with connection type “concurrent session” but the system is limited to 250 user logons at the same time (250 CS), the next CS user (251rst) that attempts to log in, will receive an error message. Auwch! You see, CS licenses do not guarantee access to a system. Off course, when a user logs off, another user is allowed to consume that license. When purchasing these licenses, you should estimate (based on historical data, if possible) the amount of defined users that could log on to the system at the same time.
Three important remarks:
- One single user can consume multiple sessions if he uses multiple access points at the same time (like the BI Launchpad, BI Mobile or Live Office).
- CS licenses are specific to a single deployment. This means they can’t be shared across multiple deployments.
- Depending on when you purchased your SAP BO solution, you may not have access to CSs. In that case, you’ll need a conversion to the new licensing model that supports CSs.
“Concurrent session licenses do not guarantee access to a system.”
Within user licensing, each individual must be set up in the CMC to access the software with connection type “named user”. In this case, the individual is licensed. This type of licenses guarantee access. Just to be clear: individuals whose connection is covered by user licenses do not consume concurrent session licenses. User licenses are not specific to a single deployment. This means they can be shared across multiple deployments.
Needing more than display only?
All right. No problem: it can happen that some individuals require additional rights beyond display only (think about your administrators or query builders). In that case, SAP offers three named user licenses that may be licensed in addition to the package license:
“SAP Business Expert User”
“SAP Business Analytics Professional User”
“SAP Business Intelligence (BI) Limited User”
Take Away Message
Choose the most appropriate metric or a mixture of both. Divide your user group into users who would need 24/7 access and those who only need it frequently. Estimate, based on historical data, to determine the usage levels at any one moment. Define your needs carefully. Do not forget to check your license key! If you agree a limited number of Concurrent Sessions and Users but your license key received from SAP says ‘unlimited’, you should operate by the contract, even if the system appears to allow you more. Do not over buy. You can always buy more, based on your ongoing asessment of usage and demand.
Brecht Van Den Bogaert
Senior Consultant - SAP Access Controls and License Management at JNC Consultancy
Brecht Van den Bogaert is a Senior Consultant at JNC Consultancy. He started his career in financial auditing with EY, and before joining JNC spent over 2 years at Deloitte as Senior Consultant working across SAP Security, Authorisations, Access Management and GRC. Brecht also has significant experience within SAP system measurement and licensing. He specialises in designing and implementing scalable and transparent SAP authorizations concepts integrated with best practice principles of SAP License management. He has also gained experience on project management by working within SAP Project Management Office’s at former employers. Brecht holds a Master’s degree in Commercial Sciences and is a SAP Certified Technology Associate within the domain of SAP Authorizations and Audit for SAP NW 7.31.