In the world of so many cool applications, features and functionalities, “Jailbreaking” has become a standard practice for opening up possibilities in our electronics. Popular techniques are available for adding apps to Apple IOS and Android devices as well as media through Kodi in our Amazon Fire devices. While this process can give us what we crave moment to moment, it can also have unintended effects on our devices. We can lose functionality in other applications, limit upgrade options, or disable certain apps permanently.
There is a certain correlation between “jailbreaking” and customizing a Laboratory Information Management Systems (LIMS). Most modern LIMS offer an Application Programming Interface (API) with which system customizations may be accomplished. For example, the STARLIMS™ system is very flexible in that most of the core product’s API is available to view or change as a developer, enabling organizations to easily modify applications or create whole new applications. While this provides awesome possibilities for customizing STARLIMS to meet your laboratory’s needs, certain customizations and modifications can be risky for the current or future functioning of your STARLIMS system. Modifications to the core STARLIMS scripts can change functionality everywhere that code is used, sometimes even where you wouldn’t expect, trust us, we’ve seen it. There is also a chance that a future upgrade will overwrite the modified scripts or won’t be compatible.
The good news is, there are ways to avoid these potential hazards and be successful with your customization of STARLIMS. In this blog, we will share with you how.
Making customizations that touch core functionality in STARLIMS can be problematic if not done properly. Let’s look at this example scenario. An implemented STARLIMS system had very small changes made to the core STARLIMS scripts for specific processes in the sample workflow. Coincidentally, “bugs” started to pop up around the same time that the changes to the core scripts were implemented. Examination of the modifications, and tracing the usage through the system, will reveal that one of the modified scripts was being used by over 15 different applications and several processes! Although the customization was small, it hadn’t taken into account all of the logic created for each process, so its effect on the system was more widespread than anticipated. The fix for a situation like this can be very minimal, but the effects the customization had on the system are broad. New and deeper regression testing of all the potentially affected applications will need to be done. To avoid this pitfall and ensure successful customization, a simple copy of the script and small change in the form to call it may have resulted in the correct behavior.
Knowing or learning the scripts that are part of the customization is crucial when making changes to existing scripts in the STARLIMS system. This practice should be used when doing form development or modifications as well. Sometimes there are modules or functionalities that can help manage the use of a form built into the STARLIMS system. An example of this is the “Modes of Operation” functionality. This allows developers to change how a form looks or can be used for different types of applications. It is configurable and allows certain controls to become visible or disabled based on the application type or user role. When building a new application this can be helpful if you consider this up front and develop accordingly. If modifying an application that uses modes of operation, it is important to make concessions in your code for the modes and your components. Using functionality like this can keep your customizations safe.
There are other ways to create customizations for STARLIMS workflows that have less of an impact on the overall system. For instance, some projects use STARLIMS ELN for all sample workflow processing after the initial sample login. The ELN module allows the User Interface (UI) to be presented in a spreadsheet format and driven through the testing process. Scripts are created or copied and used in the ELN interface. This allows for simple changes to the UI to be accomplished without impacting other core applications.
Another option for customizing STARLIMS is using the STARLIMS Services Module. The services module allows for configuration to be done for processing a sample workflow. Each “step” in the workflow uses a custom or shared form. There are several generic scripts that are used to push samples through the workflow and custom scripts can be called, copied or created for specific tasks. While the customizations described require maintenance and structured development, the effects on the system are more isolated and less likely to cause ripple effects.
Perhaps this all seems like a headache, but it doesn’t have to be. There are ways to navigate these modifications around the core product, and techniques to help manage the customized code to prevent problems down the road. Organization and prior implementation experience are key to implementing customized code in STARLIMS. It is also important to make sure that a separate space for the new code is created and that the scripts from the core are copied prior to modification. There are also several ways to lower the impact of new or modified code on the system using wrapper scripts or client scripts, making it possible to get what you want out of STARLIMS without any unintended consequences.
Have you made use of the STARLIMS customization techniques and methods described above? If so, share with us in the comments below which technique and the success you had.