I’d like to share more details about how our primary BI pricing metrics work.
For the past few years we have been focusing on the Named User and Concurrent Session metrics.
Customer with older CPU based licenses can continue to purchase ‘more of the same’, however we do not support new innovations like SAP Lumira Server for BI Platform data discovery tools on that pricing metric.
With that, let’s break down how the Named User and Concurrent Session metrics work.
Please note that this blog is a distillation of the key aspects found in contract documents, user guides, and 'under the hood' software behaviour.
This blog is not a document of record and does not override or replace any contracts. Current standard SAP contract language can be found at sap.com/agreements. For on-premise deployments you will want the document called 'Software Use Rights'
Named User license represent individuals. They identify a single person, and provide guaranteed access to the software.
They are typically used for power users, administrators, and executives that require guaranteed access to the BI Platform. A login by a Named User will never be refused by the system. Contrast this with Concurrent Sessions below.
Named user licenses are not to be shared between people.
Custom programs (either written by the customer or by a third party) can login to the BI Platform using a Named User license only if that program ‘passes through’ the identity of the user and logs in to the BI Platform using the credentials of the individual that is using the program.
‘Headless’ applications that are not used by individuals should use a concurrent session license to connect.
The Named User license also provides access to all desktop software.
A Named User license for a single individual can be created on any number of deployments. So if your organization has 5 BI deployments, a single individual with a named user license can be configured to login to any of those 5 separate deployments.
Concurrent sessions represent a single logon to the BI Platform by anyone. Logons using the concurrent session metric are limited by availability of a free session in the session pool.
For example, a customer can license 100 concurrent sessions and share those sessions among 1,000 users. There’s no system imposed limit on the number of users that can be configured to use a concurrent session license.
When one of these 1,000 users attempts to login, the system first checks to see if there is a free session in the session pool. If there is, the login is successful. If not, the login attempt is denied. This flowchart shows what happens on login for both named users and concurrent sessions:
The concurrent session metric is ideal for casual users (either internal or external to the organization).
A customer that licenses 100 concurrent sessions can spread those 100 sessions around any number of deployments, but the sum of all concurrent sessions on all deployments must not exceed the license entitlement.
The concurrent session metric is not supported for most desktop software, with the exception of SAP BusinessObjects Analysis edition for Office.
The reason for this limitation is that the desktop software can be used disconnected from the BI Platform server. It is the BI Platform server that counts and releases sessions.
So what constitutes a ‘session’? The rule of thumb is that every logon to the BI Platform is a session. So the following actions would consume a session:
The following actions would not consume a session:
IMPORTANT: One user can create multiple sessions! This is why it’s called a concurrent session license and not a concurrent user license.
By default, a Concurrent Session license times out after 20 minutes of inactivity.
Concurrent sessions are only managed by the BI Platform. Software that runs on SAP HANA or SAP NetWeaver can only support the named user metric because these platforms cannot count and release concurrent sessions.
This table shows which clients support named users and which clients support concurrent session.
To estimate the number of concurrent sessions you may need, we recommend the following steps:
Software from partners like EV Technologies and GB&Smith can help with this process, and also identify content that is not used and can be retired.
If you don’t have auditing turned on and want a rough ‘rule of thumb’ then we recommend a 20% concurrency rate to be conservative and account for peak usage. This means take the total user audience and divide by 5 to get the estimated number of concurrent sessions.
There are 2 places to track concurrent session consumption in the CMC:
In CMC > Sessions you will see a list of users and the number of sessions they have created:
In CMC > Monitoring > Servers > CentralManagementServer you will see a real time chart of session consumption over time:
Make sure to click on the “Number of Sessions Established by Concurrent Users” in the left hand list.
Each user in the BI Platform is identified as being either a named user or concurrent session user. The following screen shots are from BI 4.1.
When adding a Named User, the number of users is checked against the number of named users encoded in your systems keycode.
If you have a 1 named user license for example and attempt to add a second named user, that will be rejected by the system as shown below:
When adding a concurrent session user, you can add as many users as you wish. 26 users or more can share a session pool of 25 sessions:
A blog on BI Metrics wouldn’t be complete if we didn’t cover the new Public Document metric.
This metric is for organizations that want to put BI content on the public internet. This is a document based license. Any supported BI Platform document can be counted against the number of licensed public documents.
No security must be put on this document. It must be ‘Google-able’.
If you need security on your documents (ie for customer or partner access) then use the NUL or CSBL metric.
Public documents must reside in a separate deployment from named users or concurrent sessions. We can support this from a single physical installation using the multi-tenncy technique described below.
We support combining Named Users and Concurrent sessions on the same deployment. This allows a single deployment to address the needs of users who need guaranteed access (like power users, administrators and managers) and casual users who may logon once a month.
We cannot support multiple license models running on the same deployment for audit reasons. Combining CPU metrics with CSBL metrics is never allowed.
We encounter many customers who have converted from a CPU metric to a CSBL metric but have forgotten to remove the old CPU keycode. This causes issues during audits so please remember to remove your CPU keycode after transitioning to a CSBL model.
If you wish to deploy different license models on the same physical installation, that is possible using the multi-tenancy feature of the BI Platform. Each tenant may have a different license model. However content and users must be separately administered for each tenant.
If you’re on an old CPU based license model, we can provide SAP Lumira Server for BI Platform to you but only with a Named User metric. We do not support the CPU metric with SAP Lumira Server for BI Platform.
While I look forward to answering any further questions you may have, I can’t comment on customer-specific scenarios on a public blog like this. If you have questions about the details on your specific contract please reach out to your SAP account executive or partner.
For the past few years we have been focusing on the Named User and Concurrent Session metrics.
Customer with older CPU based licenses can continue to purchase ‘more of the same’, however we do not support new innovations like SAP Lumira Server for BI Platform data discovery tools on that pricing metric.
With that, let’s break down how the Named User and Concurrent Session metrics work.
Please note that this blog is a distillation of the key aspects found in contract documents, user guides, and 'under the hood' software behaviour.
This blog is not a document of record and does not override or replace any contracts. Current standard SAP contract language can be found at sap.com/agreements. For on-premise deployments you will want the document called 'Software Use Rights'
Named Users
Named User license represent individuals. They identify a single person, and provide guaranteed access to the software.
They are typically used for power users, administrators, and executives that require guaranteed access to the BI Platform. A login by a Named User will never be refused by the system. Contrast this with Concurrent Sessions below.
Named user licenses are not to be shared between people.
Custom programs (either written by the customer or by a third party) can login to the BI Platform using a Named User license only if that program ‘passes through’ the identity of the user and logs in to the BI Platform using the credentials of the individual that is using the program.
‘Headless’ applications that are not used by individuals should use a concurrent session license to connect.
The Named User license also provides access to all desktop software.
A Named User license for a single individual can be created on any number of deployments. So if your organization has 5 BI deployments, a single individual with a named user license can be configured to login to any of those 5 separate deployments.
Concurrent Sessions
Concurrent sessions represent a single logon to the BI Platform by anyone. Logons using the concurrent session metric are limited by availability of a free session in the session pool.
For example, a customer can license 100 concurrent sessions and share those sessions among 1,000 users. There’s no system imposed limit on the number of users that can be configured to use a concurrent session license.
When one of these 1,000 users attempts to login, the system first checks to see if there is a free session in the session pool. If there is, the login is successful. If not, the login attempt is denied. This flowchart shows what happens on login for both named users and concurrent sessions:
The concurrent session metric is ideal for casual users (either internal or external to the organization).
A customer that licenses 100 concurrent sessions can spread those 100 sessions around any number of deployments, but the sum of all concurrent sessions on all deployments must not exceed the license entitlement.
The concurrent session metric is not supported for most desktop software, with the exception of SAP BusinessObjects Analysis edition for Office.
The reason for this limitation is that the desktop software can be used disconnected from the BI Platform server. It is the BI Platform server that counts and releases sessions.
So what constitutes a ‘session’? The rule of thumb is that every logon to the BI Platform is a session. So the following actions would consume a session:
- Logging on to the BI Launchpad.
- Logging on to the CMC
- Logging on to the BI Platform from within any desktop tool (Crystal Reports, Web Intelligence Rich Client, Dahsboards designer, Design Studio client, etc…)
- Logging on to Mobile BI
- Logging on to Live Office
- Accessing an OpenDoc link for the first time (when there is no existing session token in the browser).
- Logging on to the BI Launchpad from Internet Explorer, then logging on to the BI Launchpad a second time from Chrome would consume 2 sessions – not one.
The following actions would not consume a session:
- Opening multiple tabs within the same BI Launchpad session to view different documents.
- Following OpenDoc links from one document to the next if a BI Platform session is already established.
IMPORTANT: One user can create multiple sessions! This is why it’s called a concurrent session license and not a concurrent user license.
By default, a Concurrent Session license times out after 20 minutes of inactivity.
Concurrent sessions are only managed by the BI Platform. Software that runs on SAP HANA or SAP NetWeaver can only support the named user metric because these platforms cannot count and release concurrent sessions.
Comparing Named Users and Concurrent Sessions
This table shows which clients support named users and which clients support concurrent session.
Estimating Concurrent Sessions
To estimate the number of concurrent sessions you may need, we recommend the following steps:
- Turn on the auditing feature of the BI Platform if it is not already on.
- Use the auditing reports to identify the peak periods where you have the maximum number of connections to the system. This would be your total session consumption.
- Reduce the session consumption for users that would have a named user license and have guaranteed access.
- Adjust that session estimate to account for growth in the user base.
- Adjust that session estimate for users that can create multiple sessions (ie Administrators that use both the CMC and Universe Designer).
Software from partners like EV Technologies and GB&Smith can help with this process, and also identify content that is not used and can be retired.
If you don’t have auditing turned on and want a rough ‘rule of thumb’ then we recommend a 20% concurrency rate to be conservative and account for peak usage. This means take the total user audience and divide by 5 to get the estimated number of concurrent sessions.
Tracking Concurrent Session Consumption
There are 2 places to track concurrent session consumption in the CMC:
- CMC > Sessions
- CMC > Monitoring > Servers > CentralManagementServer
In CMC > Sessions you will see a list of users and the number of sessions they have created:
In CMC > Monitoring > Servers > CentralManagementServer you will see a real time chart of session consumption over time:
Make sure to click on the “Number of Sessions Established by Concurrent Users” in the left hand list.
User Configuration
Each user in the BI Platform is identified as being either a named user or concurrent session user. The following screen shots are from BI 4.1.
When adding a Named User, the number of users is checked against the number of named users encoded in your systems keycode.
If you have a 1 named user license for example and attempt to add a second named user, that will be rejected by the system as shown below:
When adding a concurrent session user, you can add as many users as you wish. 26 users or more can share a session pool of 25 sessions:
Public Documents
A blog on BI Metrics wouldn’t be complete if we didn’t cover the new Public Document metric.
This metric is for organizations that want to put BI content on the public internet. This is a document based license. Any supported BI Platform document can be counted against the number of licensed public documents.
No security must be put on this document. It must be ‘Google-able’.
If you need security on your documents (ie for customer or partner access) then use the NUL or CSBL metric.
Public documents must reside in a separate deployment from named users or concurrent sessions. We can support this from a single physical installation using the multi-tenncy technique described below.
Other Interesting Factoids
We support combining Named Users and Concurrent sessions on the same deployment. This allows a single deployment to address the needs of users who need guaranteed access (like power users, administrators and managers) and casual users who may logon once a month.
We cannot support multiple license models running on the same deployment for audit reasons. Combining CPU metrics with CSBL metrics is never allowed.
We encounter many customers who have converted from a CPU metric to a CSBL metric but have forgotten to remove the old CPU keycode. This causes issues during audits so please remember to remove your CPU keycode after transitioning to a CSBL model.
If you wish to deploy different license models on the same physical installation, that is possible using the multi-tenancy feature of the BI Platform. Each tenant may have a different license model. However content and users must be separately administered for each tenant.
If you’re on an old CPU based license model, we can provide SAP Lumira Server for BI Platform to you but only with a Named User metric. We do not support the CPU metric with SAP Lumira Server for BI Platform.
Wrapping Up
While I look forward to answering any further questions you may have, I can’t comment on customer-specific scenarios on a public blog like this. If you have questions about the details on your specific contract please reach out to your SAP account executive or partner.
- SAP Managed Tags:
22 Comments
