8 Work with Connections and Datasources
Many operations call for connecting to source data external to the cube. Connections and Datasources, which you create and save as reusable objects in Oracle Essbase, provide a way to do this efficiently.
For example, you can set up a partition between a cube and RDBMS tables, share data between a cube and Oracle Database, develop security filters using variables to fetch members or user names from outside source data, and load data from REST API endpoints.
Many cube operations require connection information, such as login details, to access remote source data or hosts. You can define these as connections and Datasources once, and reuse them in various operations, so that you do not have to specify the details each time you perform a task.
You can implement saved connections and Datasources either globally or per application. These abstractions facilitate the following operations:
-
Loading dimensions and data
-
Importing cubes
-
Defining variable security filters
-
Connecting cubes using partitions, and accessing real-time data
-
Drilling through to remote sources of data
If you have network connectivity between an external source of data and Essbase, you can define connections and Datasources in Essbase to easily "pull" data from the external source. If you have no network connectivity between Essbase and the external source of data, then you should stream data loads or dimension builds using the CLI tool, first creating a local connection, and then issuing the dataload or dimbuild command with the stream option.
A connection stores information about an external server and the login credentials that are required to access it. By defining one connection that can be used by multiple processes and artifacts, you can simplify many aspects of your analytics. For example, when it’s time to change a system password, you only need to update one connection.
![Global Sources > Connections interface. The following connections have been created: 1) Name: Essbase2, Type: Essbase, Description: Connection to second Essbase instance. 2) Name: Oracle Database, Type: Oracle Database, Description: Connection to Oracle PDB .3) Name: UserDetails, Type: File, Description: CSV file of user details Global Sources > Connections interface. The following connections have been created: 1) Name: Essbase2, Type: Essbase, Description: Connection to second Essbase instance. 2) Name: Oracle Database, Type: Oracle Database, Description: Connection to Oracle PDB .3) Name: UserDetails, Type: File, Description: CSV file of user details](img/connections_multi_s.png)
A Datasource is another object that you can define once and reuse, to help you manage data flow into and out of your cubes. You can define a Datasource to represent any external source of data, whether a relational system, a table, a file, or another cube.
![Sources > Datasources interface in the Essbase web interface. The following global Datasources have been created: 1) Name: Essbase2_Datasource, Connection: Essbase 2; 2) Name: OracleDB_Datasource, Connection: Oracle Database; 3) Name: UserDetails_Datasource, Connection: UserDetails. Sources > Datasources interface in the Essbase web interface. The following global Datasources have been created: 1) Name: Essbase2_Datasource, Connection: Essbase 2; 2) Name: OracleDB_Datasource, Connection: Oracle Database; 3) Name: UserDetails_Datasource, Connection: UserDetails.](img/ds_multi_s.png)
You can define one connection and use it to access multiple Datasources. For example, consider an external Oracle Database server that has separate tables for products, resellers, and sales territories. You need only one connection to access Oracle Database, but you might want to create unique Datasources to access each of the tables.
One use case in which you might define multiple Datasources per connection is as follows: if you use separate load rules to build each dimension in a cube, each rules file can be set up to access the relevant table in Oracle Database. For example, assume your cube has a Market dimension, and you regularly build dimensions using a Dim_Market load rule to populate the Market dimension from a SALES_TERRITORIES table. Likewise, you use a Dim_Product load rule to populate the Product dimension from a PRODUCT table. Both load rules can use the same connection, but because they draw from separate tables, you defined two different Datasources.
Historically, you needed to hard code connection and source data details into Essbase artifacts such as rule files, location aliases, and partitions. While hard coded information is still supported in these artifacts, you can work more efficiently if you define connections and Datasources globally (or, at the application level).