Build it Your Way: The Value of Extensibility in Third-Party Software

Many of us think of extensibility as roughly synonymous with customizability, but there’s more than a semantic distinction between terms, and understanding that distinction could be the difference between a successful software implementation and an underutilized one.

Whereas customizability measures the degree and ease with which users can modify existing features, extensibility measures the degree and ease with which they can add new ones. This may seem like a minor difference since changes are being made to the software in either case, but: you can’t customize a feature that isn’t there, and when the functionality you need does not yet exist within the application, extensibility becomes valuable indeed.

Of course, the value of an application’s extensibility features will depend entirely on what functions they allow your company to build upon. Since its users can already customize the UI and session state through CSS and the API, Exago’s extensibility features give them control over something else: the running state. Server and action events allow users to interrupt the running state to add intra-session changes of their own design, enabling them to redefine some of the application’s basic functions.


We Interrupt This Program to Bring You Something Completely Different

Server and action events (SAEs) are the meat-and-potatoes of Exago’s extensibility, and the only difference between them is how they are triggered. Action events are triggered by client-side user actions, things like clicking a button or loading a report or performing some other task in the UI. Server events, on the other hand, are triggered by an application process occurring server-side, like running a SQL query or loading a configuration file. These triggers, or events, are flagged by Exago developers as code injection points where application architects can take advantage of the program’s JIT compiler to make changes to the program’s running state. In other words, the application administrators get to decide for themselves what happens at these event points, and if what they want is to interrupt the default programming to bring end users something completely different, they can.


In practice, adding SAEs is a two-step process: identify and assign an event point or trigger, then compose your custom program in either C#, JavaScript, or Visual Basic. Alternatively, admins can build their program as a DLL, save the DLL as an assembly data source, and then set the assembly to run at the event point. While the two methods accomplish the same thing, the latter gives developers more finely tuned control as well as access to IDE tools.


“Built from the Ground Up with Extensibility in Mind”

If building and implementing SAEs sounds like work, that’s because it is. Designing server events requires time, development resources, and sometimes also guidance from the Exago Support Team; but, the freedom and flexibility it affords client companies can be invaluable.

The architecture firm Elemental embraced this same tradeoff when in 2010 a tsunami razed 80% of the buildings in Constitución, Chile. Elemental worked with the city on a housing project for the displaced and were challenged to come up with a design that a single mother could afford but which could house an extended family. Their solution: extensibility. Elemental proposed a community of houses split vertically down the middle with one half ready for move-in day and the other little more than a roof over the foundation. (Click here to see how they turned out.) This way, construction would be swift and inexpensive, and each family could expand on the house as needed and in their own time. Yes, it was more work, but it gave people the power to shape their environment to suit their needs.

Exago operates according to the same philosophy because the alternative to extensibility is waiting (and hoping) for enhancements. Tim Keogh is an Application Architect at Sageworks, a financial analysis software company, and helped implement Exago five years ago. While extensibility wasn’t a high priority for his team during the product evaluation period, its utility became clear later on. “It seems like Exago was built from the ground up with extensibility in mind,” he says. “With Exago, it’s very easy to do things like figure out what kind of SQL you’re running because of logging and extensibility features. If I’m using another BI solution, I might have to find a DBA to help me track the SQL that’s running and try to track that back to which report I’m running to determine if it optimized correctly, and I don’t want to have to go through all those hoops.”

In Keogh’s experience, not having access to extensibility features means “you have to submit enhancement requests, which usually don’t get turned around in a very quick manner.” Exago’s clients always have the option of submitting enhancement requests but are encouraged to develop SAEs as interim solutions whenever possible because global changes to the application require significantly more time to review and implement.


Case Studies

The following examples illustrate how companies have used SAEs to solve problems specific to their environment.


Case One Ben Jackson

Ben Jackson, Business Intelligence Analyst at Bond International



Bond International is a global provider of staffing and recruitment software with over 40 years of recruitment industry experience.



When users enter billing amounts incorrectly, they cancel out their mistakes by reentering the amount as a negative value, bringing the total to zero before finally entering the correct amount. Bond needed a way to identify and remove these zero-sum entries from reports so that they would not appear on client invoices.



Ben worked with Bond’s developers to create the SuppressTimecardBillingTransactions server event, which initiates after all data is retrieved and combined from all data sources. The server event code scours the data for zero-sum entries per invoice number, removes them, and returns the modified data to resume report execution.

60 lines of code, 2 weeks development time.



Request a feature enhancement or special build from Exago and wait for approval and implementation.


"Server events are a great way to help customers help themselves. If there’s an outlet you can give people to teach them how to fish and get them to fish on their own, it’s best to give them that option."


Case Two



This company, who chose to remain anonymous, is one of North America’s leading providers of medical insurance for cats and dogs, and its Data Management System is one of the many time-saving, cost-reducing software solutions it offers animal welfare organizations.



The application uses column tenanting to prevent cross-contamination of client data, and each object can have between 10k to 100k records. Reports containing three or more data objects were taking over ten minutes to run because the application was running a tenant check for each row of each data object. Changing this protocol would require altering the way the application built its SQL queries.



The company worked with Exago Support and Client Services to build a server event that uses unique key fields and joins to run column tenancy checks just once per report, rather than once per object.

34 lines of code, 10 hrs net development time.



Request a feature enhancement or special build from Exago and wait for approval and implementation.


"Before implementing this server event, a report with five or six large data objects in it was regularly hitting our ten-minute timeout limit. After implementing this server event, we got all data back within thirty seconds."


Building Together

One of the beautiful things about an extensible BI solution is that it fosters collaborative innovation between client and provider. Instead of simply requesting development from the provider, the client company can contribute to the programming process by building their own extensions and demonstrating their applicability, putting that feature on the fast track to global implementation should it be relevant to a wider audience.

ESM, a leading provider of spend management solutions, for example, used SAEs to always format certain data fields as currency upon report execution, and as of v2016.3.0, “currency” is available as a data type category in column metadata. Similarly, it was Logfire, a provider of warehouse management applications, who developed the event that inspired the schedule-to-repository enhancement, which enables scheduled reports to be stored in a directory rather than emailed.

Extensibility as a product design practice has the potential to accelerate innovation and build meaningful partnerships between participating businesses, all while getting the job done.


Quick Guide to Evaluating Extensibility

Since every solution has a different name for its extensibility features, below are some questions to ask during a product demonstration to determine whether the BI solution has an extensible running state or something equivalent to Exago SAEs. The questions all ask after the same functionality but are worded to accommodate different levels of technical proficiency, ordered from least to most technical.

- “Can I have a data field always formatted as currency, regardless of whether the user has applied that formatting and regardless of how the data is formatted in the database?”

- “Can I modify SQL during report execution?”

- “Can I make intrasession changes to the running state?”

To learn more about Exago’s server and action events, visit our Knowledge Base, or browse our Support Lab videos for related titles.



Authored by
Nicole Hitner
Content Strategist
comments powered by Disqus