Customers who need to regularly pull data out of Barium Live in order to visualize or analyze that data using a BI platform (or Excel, or some other analytics software external to Barium Live) need a way to do the actual pulling of data into an appropriate destination repository used by the BI application. The purpose of this document is to lay out the general options available in Barium Live to accomplish this.
NOTE: These approaches are particularly well suited for situations where the solution not yet contains any legacy data that needs to be part of the BI analysis - i e when new applications are being delivered.
OPTION 1: PUBLISH AND SUBSCRIBE TO UPDATES USING BIA OR OTHER EXISTING MIDDLEWARE
The suggested approach to systematically pull data is the following. This approach is particularly well suited when the data repository is managed on-prem and lacks publicly available endpoints (for instance, a local data warehouse or database). It requires either the use of BIA, or other middleware that can assume responsibility for subscribing to information.
In Barium Live:
1. Add the Send Application Message business component in the space configuration
2. Configure a queue to which to send messages from the process application.
3. Add appropriate message intermediates to the process application, in order for relevant data to be published to the queue.
Note: If >10 values e.g form values or other values from each instance are to be pushed with each message, consider only pushing the relevant instance id into the queue due to issues with maintenance and configuration with large data sets. Instead have the middleware asynchronously fetch values using the API into the destination repository.
On the customer site:
1. Determine how to pull data from the queue, which is available through the Barium Live ApplicationMessages API method. Choose between querying the queue using Barium Integration Agent (BIA), or using third party integration middleware provided by the customer.
2. Determine and configure the frequency of pulls, e.g. daily/weekly/monthly.
3. Output data to a storage format so that it is made available to the BI software.
OPTION 2: OUTGOING INTEGRATION TO POPULATE EXTERNAL DATA SOURCE
This approach is particularly well suited when the data repository is managed in an online service with publicly available endpoints. In addition, this approach allows for almost instantaneous updates of the data repository.
Note: Requires the use of Execute Script Service, which for the time being is only available to Barium’s delivery team.
In Barium Live:
Configure Script Service tasks in the producing application to send relevant data to external repository/service.