Using SAP Lumira on Universes? Guide for BI4.1 administrators
The purpose of this blog is to explain the different BOE services that are utilized when using Lumira to acquire data from a universe. Before we get into the details of using Lumira in the BI platform, let’s start with a brief introduction to the different type of Connectivity Services you will find in a BI4.x system.
BI4.x comes with three different Connectivity Services that can be utilized:
- ConnectionServer – This is the 64 bit Connection Server.
- ConnectionServer32 – This is the 32 bit connection server and used in certain workflows when the underlying database only supports 32 bit connectivity. Since this is 32 bit process, it’s limited in terms of how much memory(<2 GB)) it can consume.
- Adaptive Connectivity Service – This is a Java based connection server primarily used when using JDBC data sources. The Adaptive Connectivity Service is hosted in the Adaptive Processing Server, which is a container process that contains several different services.
In my screenshot below, you can see the default ConnectionServer and ConnectionServer32 processes. I’ve also create a new Adaptive Processing Server(named APS_Connectivity) that contains only the Adaptive Connectivity Service.
Now that we have a basic understanding of the different connectivity services in BI4.x system, let’s look at how these services are leveraged when using Lumira on top of Universes. For Business Objects administrators it’s important to understand what BOE processes are utilized when using Lumira to acquire data using a universe and also when these documents are refreshed from the BI platform.
UNX universe built using JDBC connectivity
An example of this type of universe would be a universe built on SAP HANA. In Information Design Tool we can define a relational JDBC connection to HANA and build a universe on either on Analytical Views or Calculation Views.
When using Lumira to connect to HANA based universe using this connectivity type, you will leverage the Adaptive Connectivity Service. You can see the workflow that we follow in the picture below. Essentially we follow these rules when acquiring data in this scenario:
- The DSL bridge library is invoked on the Lumira Desktop to load the universe and generate the SQL statement. When the Lumira document refresh happens from the BI platform, it’s the Lumira Server(running in BI4.x system) that invokes the DSL Bridge libraries to generate the SQL statement.
- In both cases, the generated SQL will be sent to to the Adaptive Connectivity Service(running in the BI4.x system) to fetch the data from the database.
Unx Universe using non-JDBC connectivity
Things get bit more interesting when you have a universe built on other relational sources such as Sybase, SQl Server, Oracle etc. using ODBC or the native client connectivity offered by the database vendors. In this case we follow these rules:
- Lumira desktop or Lumira Server will invoke the DSL bridge libraries to load the universe and generate the SQL statement.
- The generated SQL statement is sent to the ConnectionServer. We first try to utilize the 64 bit Connection Server process if it is running in the BOE system.
- If 64bit connectivity defined in the BOE platform, the Connection Server will fetch the data from the database to populate the Lumira document
- If the Connection Server process is enabled but 64 database connectivity is not configured, we will generate an error message during the acquisition in the desktop or during refresh from BI Launchpad
- If the Connection Server process is NOT running, we then check to see if Connection Server 32 bit process is running and enabled.
- If 32 bit connectivity to the underlying data source is defined correctly, the data is fetched from the database through the Connection Server 32 process otherwise an error will be generated.
The workflows that I’ve described are simplified to highlight the connectivity services that are utilized. I would encourage you to review the various process flows documented for Lumira for a complete picture of other services that are also involved during processing of Lumira documents. The process flows can be found here:
The workflow above would be very similar if you were using a universe built on a 32 bit database. Take for example, the standard efashion universe(.unv) that comes with BI4.x installation. This universe is built on MS Access mdb file that is 32 bit database file. You can convert this universe to .unx format and acquire data from this universe in Lumira using the Universe Query Panel extension. The only change to workflow above would be that we go directly to the 32 bit connection server and leverage the 32 bit database connectivity to acquire data. The 64 bit connection server would not be used in this scenario.
Considerations for scaling and troubleshooting
Knowing that we leverage these connectivity services heavily it’s important to scale the connectivity services accordingly. If you plan to use universes built on JDBC datasources with Lumira, it would be prudent to split the Adaptive Connectivity Service and have one or more Adaptive Processing Servers(APS) dedicated to running this service. You may also need to tweak the Java heap setting of the APS so that the process does not run out of memory. The heap setting can be modified by increasing the -Xmx settings in the command line parameters of the APS that is hosting the Adaptive Connectivity Service.
For non-JDBC universes, you may need to have more than one Connection Server process running, especially if several concurrent users will acquire data using Lumira desktop or refresh Lumira documents through BI launchpad.
If you get errors during refresh workflows, tracing can be enabled on the various connectivity services to identify the cause of the failure. To enable tracing, modify the properties of the service in the Central Management Console(CMC) and set the Log Level to High. By default, the traces will be stored under:
<Install directory>\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\logging
Closing remarks and tips when using Lumira on universes
- Install and leverage the Universe Query Panel Extension in Lumira. Avoid using the out of the box universe connector that comes with Lumira. The workflows that I described in my blog are only relevant when using the Universe Query Panel Extension in Lumira to connect to a universe. Also note that the DSL bridge library is now invoked by the Lumira process directly so we no longer leverage the DSL bridge service hosted on the Adaptive Processing Server.
- Ensure that 64 bit Connection Server is running and 64 bit database connectivity defined correctly for the databases that support such connectivity. This will ensure we don’t have to rely on 32 bit connection server to fetch data. Since 32 bit connection server is a 32 bit process it will not be to scale to leverage larger memory footprint if required.
- Closely monitor the CPU/Memory on the connection servers as these processes should NOT be running at peak memory and CPU. Add more connectivity services on different nodes if this is observed.
- Follow best practices to configure Adaptive Processing Server to split the Adaptive Processing Servers for production usage. For Lumira workflows, you may have one or more APS only hosting the Adaptive Connectivity Service.
- Leverage the BI Sizing Guide and Lumira Sizing guide to size your environment to support the Lumira workflows.
Nice blog, but could you please let me know where the CMS would come into picture here for Unx Universe using non-JDBC connectivity?