“I love witnessing the moment clients realize they can use Exago BI on their own data,” says Bill Piacitelli, Senior Manager of Solutions Sales at Exago.
“It’s not like we keep it a secret or anything — it’s just that during the evaluation process, SaaS companies are understandably focused on making sure the embedded business intelligence tool they pick is right for their clients. It’s usually not until after deployment that they become interested in using it in-house, and when they realize they can, it’s like they found a hundred-dollar bill in their pants pocket.”Leveraging BI in-house can be a great way to extract added value from a solution intended for resale, and in many cases, that means connecting to data from business software platforms like Salesforce, HubSpot, JIRA, and Freshdesk. Many software companies handle integration by building platform-specific connectors, but since it’s impossible to build a connector for each and every business application on the market, this method necessarily limits users’ options.
Exago BI avoids this pitfall by keeping its connector settings database-specific rather than platform-specific. While the connection will require a bit more setup as a result, not being restricted to a small subset of solution vendors dramatically improves your chances of achieving a connection in the first place.
There are five means of connecting Exago BI to data being generated by a business software platform, and we’ll review them in order of most-to-least performant.
Method 1: Local Hosting
If it’s possible to host the business software application data on a local server, then connecting to it is as simple as supplying a connection string. Exago BI connects to MSSQL, MySQL, ODBC, Oracle, DB2, and Informix sources, and accessing an on-premises data source neither stresses the network nor requires that joins be made on the server, making it the most performant option.
Method 2: Direct Database Connection
If the business software application data must be cloud-hosted, get in touch with its support team to find out whether they could provide you with a connection string to the database housing your information. If they can, simply supply the string as you would when adding any other data source. This does require data to be passed over the network, however.
Method 3: Open API
If you have access to the business software application’s API, you can write an assembly that will call the API to retrieve the data and format it for reporting purposes. Exago BI can then be connected to the assembly. With this configuration, every report execution must pass through the network, so its performance will depend on your network speeds and the volume of data being returned. Joins between data objects would also have to happen on the server, further slowing execution.
To improve performance, you could instead write a program that calls the API and stores the retrieved data in a local database, updating the tables at regular intervals. This of course introduces data latency, but some companies might consider this a small price to pay for an unburdened network and quicker execution times.
Method 4: Data Exports
This method can either be more or less performant than using a proprietary web service, depending on how it’s deployed. In the event that the business software provider supplies no other means of retrieving data other than file exports to CSV, XLS, XML or other formats, a low-tech solution would require human intervention. An employee would have to manually export those data files and add them to Exago BI as sources.
Alternatively, a developer could write a program to automate the process, but this would still require all joins to happen in memory on the server, slowing performance. In a file-exports scenario, the best option would be to transfer the downloaded data to a local database and connect Exago BI to that. In any case, the data export method will result in some degree of data latency.
Method 5: Proprietary Web Service Connection
In some cases, business software applications will allow clients to retrieve data through a proprietary web service, which Exago BI can connect to given the appropriate connection string. While it’s simple to set up, it can be taxing on the network, and joins must happen on the server, making it the least performant option.
Because Exago BI is designed to integrate into an application and adopt that application’s authentication protocol, leveraging Exago BI internally, no matter the method, would require a sysadmin to settle on a means of controlling user access. One method might be to use Windows Authorization to enforce that users supply their network credentials to gain access to the application. Another possibility is to configure IIS to either include or exclude certain IP addresses or (groups of IP addresses) from reaching the application page. Given adequate resources, your development team could even opt to write an authentication wrapper expressly for Exago. Exago clients are advised to take whatever measures they feel will keep their data safe.
Today, Exago employees use the application to connect to Zendesk and JIRA via Method #3 and Salesforce via Method #4, using database storage in both cases. Having that data ready at hand has enabled all departments to track KPIs, improve operational efficiency, and keep the rest of the company apprised of their progress.