Anexsys collectively has over a decade of experience in developing Relativity applications, and we’ve picked up a lot of tips and tricks along the way. We’ve learned some of our development lessons in interesting ways and have established a set of tools and practices that we use on a daily basis when developing our software.
Do put all your eggs in one basket: RTK. Manager Workspace
- This is a workspace that we create in every Relativity instance that has any of our software products installed. It allows us to create a ‘base’ for all our applications and have a centralised store for all our application data.
- This workspace contains all our queue tables for the work our agents do. By making our job and queue tables RDOs rather than SQL tables, we let front end users see the status of jobs in the queue without having to run SQL queries.
- By having a centralised workspace for these types of objects, we can also have an application installed in several different workspaces and only have to use one queue table.
A stitch in time saves 5000 lines of code: Custom Utilities Package
- We’ve written a custom utilities package which is a local NuGet package and is available to all our developers. NuGet is a package manager for Visual Studio and allows us to include a lot of code and functionality from the start. Our internal package is hosted on a network drive and makes sure that each developer has access to the most up-to-date version of the package.
- Through developing Relativity applications, we discovered this package contains a lot of the Relativity actions that we perform frequently – mostly likely repeatable code that we use in multiple projects. For example, this Relativity package has functions to:
- Get the version of Relativity we’re working with.
- Get the workspace ID of our RTK.Manager workspace, mentioned above.
- Add items to a job queue.
- Handle the configuration settings in the RTK.Manager workspace.
- The Utilities Package also handles licensing and configuration values for all our Relativity applications. We are able to fine-tune any instance-wide values, like the log level for a specific application, and prevents us from having to hard code any values in our software. It gives us peace of mind when deploying to other instances of Relativity that there is nothing hard coded that may break the application.
Recognise when history repeats itself: Logging
- Later versions of Relativity have logging functionality available through the APIs but occasionally we must develop and support software for older versions (the oldest version of Relativity we currently support is 8.2). For these older pieces of software, we must use our custom logging functionality.
- Again, we have an RDO in our RTK.Manager workspace which makes it easy for users to see each entry in the logs without having to run any SQL queries. We have functions in our Utilities Package that allow us to log to this RDO.
If at first you do succeed – test, test, test again: Testing
- Finally, we must perform thorough testing on our Relativity applications before they can be deployed to customers. We have found that the best way to do this is to abstract our business logic from our Relativity functionality as much as possible. We can then run unit tests on our business logic and use end-to-end testing for any Relativity interactions.
Anexsys’ experience in developing Relativity applications has given us a good grounding in the fundamentals and some useful tips and tricks for writing these types of software.
Whether you’ve never written anything more complex than a simple SQL script, or you’ve been writing software for Relativity since the first Event Handler Framework, we’d love to hear any lessons you’ve learned on your development journey. Get in touch!