How to Solve Self-Service BI Integration Conflicts

Software integrationIndependent software vendors expect big challenges integrating a third-party self-service business intelligence platform with their application, but that doesn’t have to be the case.

Challenges do exist for a successful integration. Software developers can help make it work by collaborating with the BI vendor.

First, no catchall solution exists for BI integration. Everybody has their own set of conventions when they write code or develop an application. Every application has its own architectural patterns and/or ways it does something. And Izenda is not likely to match any of them.

We have our own standard set of conventions. We try to adapt to our customer’s conventions to integrate our self-service BI platform. We need to mimic the way they do things to make the integration a success.

Conflicts almost always arise from the differences in patterns and conventions. The solutions to these problems come when Izenda’s integration team adapts to the customer’s methods. It’s a challenge to try to shift the way you think to make sense to someone else who doesn’t think that way, but our application integrators have extensive experience adapting to many different conventions and rules.

Izenda encourages companies planning to integrate Izenda’s self-service BI platform to follow these best practices for success:

Set up a dev environment to help integration, allowing Izenda support techs and engineers access to assist in the process. They’ll need website and code access. Do this in a replicated environment that follows the same conventions as the production environment. Izenda’s support techs and engineers need the ability to reproduce any issues discovered in the development process. They can’t solve an issue if they can’t reproduce it.

All too often, our team encounters issues that aren’t reproducible in a vanilla instance of Izenda. This can happen when a customer puts something outside of the InitializeReporting () method, which requires them to go in and find where that lies in the code. Izenda’s support team needs to review the actual custom code in the application and have the ability to test changes to that code.

Issues Izenda can’t reproduce in the dev environment may occur because of load balancing, the way the customer’s application stores sessions or other variables. Izenda doesn’t have the resources to replicate every possible production environment or application that integrates our self-service BI platform. Our integration team will need access to a replicated environment to solve these issues. Many software developers have a mirror image as a QA environment. The customer can give Izenda access to it. Or they can make a copy of it so our integration engineers can make changes and not affect the QA environment.

Sometimes third-party tool conflicts with Bootstrap, jQuery and others can occur, but Izenda created workarounds for some of those conflicts already. We end conflicts with our jQuery by changing the ‘$’ alias to ‘jq$’ in our usage of jQuery.

Izenda works around conflicts with Bootstrap using namespacing if our clients call their own modified Bootstrap classes on Izenda pages. An integration can’t scrap our Bootstrap because the platform will be loading our CSS pages, so the solution is to add a “namespace” to the Bootstrap classes Izenda uses.

Another potential for conflict involves log4net. Izenda uses it for logging in our dll. Some actions happen inside our dll that don’t occur in the web application or the frontend. If the application Izenda integrates into uses a different version of log4net, a conflict can occur. But again, Izenda has developed workarounds to end any conflict.

Izenda’s integration specialists work with each customer to make integration quick and painless.