In yesterday’s blog posting, I mentioned that I don’t intend to start a 3rd-party knowledge base of any laboratory informatics software product. Additionally, I don’t have the time to start helping the world with these products, either, as I’m just one person and have to prioritize my time to help my customers and people I know first and foremost. I owe that to my customers, who are paying for it, and loyal cronies, who also help me when I need it. I meant it and I’m sticking to it. With that said, there’s one type of search that occasionally brings people to my blog and something I happen to know that even some of the senior implementers have some problems with. The issue is to understand the difference between LabWare’s Event Triggers, Automation Scripts and Status Rules. I know from working with people that it’s confusing and frustrating to those trying to understand all of this. However, if you’re going to program in LIMS Basic and to work within the entire system (as opposed to just creating various templates and calculations who don’t need to know any of this) then you need to understand these as they’re powerful and can be difficult to use if you don’t understand them.
My experience comes from this: I’ve been working with the LabWare LIMS Automation Scripts for the standard system modules and for the Status Rules since they were in Alpha development (yes, that’s pre-Beta testing) and many of the others since they were in Beta, plus many that I’ve used upon release. I’ve been working with Event Triggers for as long as I remember working with this system, probably as far back as 1996. What I’m saying is that I’ve been using them for a REALLY, REALLY, REALLY long time, possibly since around 1998 or so. I’ve been using them longer since even all but maybe one or two of LabWare’s own consultants whose customers also got some of these pre-released, at the time.
These are, well, events. No, not like your birthday. Well, actually, that’s not a bad analogy. Your birth, your graduation, these are all life events. In the LabWare LIMS, an Event Trigger is an event in the life of whatever the Event Trigger is for. So, a sample’s Event Trigger is something that happens in the life of a sample. For example, it gets logged-in, it gets received – these are all events in the life of a sample. So, if you look at the list of events for each item that has Event Triggers (such as a test or a stability study), any code you enter will happen when this event happens. LIMS Basic put into the Default will fire for all of that object that doesn’t have template-specific code, or you can create code for specific templates. These are probably the easiest of the three to use and understand because they not only seem logical if you look at the list of things you can do but they pretty much work about the same way.
Automation Scripts are opportunities to place LIMS Basic in various modules in the LIMS. They’re available for most/all of the standard system modules, such as project manager or batch manager, and come with some of the add-on modules, as well, such as stability manager. These fire at various states within that module. So, most modules have a “hook” to put code when the window opens, when you open a record within the window, when you’re about to save the record, when you save the record, and other various opportunities to place your LIMS Basic.
These get tricky because when a person learns to use the Automation Scripts for one module they think they now know how to program all Automation Scripts, which isn’t the case. Each set of Automation Scripts has a different list of events to use and each set will work somewhat differently. For example, if you were to write scripts for Project Manager you would use a different technique than if you write them for Batch Manager because the two modules work entirely differently. The other tricky bit is that there are a lot of know-it-alls out there who will snub you when you try to ask for help, telling you these are all alike. Those people are in that category that they’ve done one set (a little knowledge is a dangerous thing), never done it but read about it (ignore these people, too), or just playing one-upsmanship with you like competing consultants like to do (ignore these head games).
Status Rules are events that happen when something is changing status. Be aware that a Status Rule applies to all objects so you’ll almost always have to put specific code in to handle the various objects. For example, when you add code for samples, you’ll put in an IF statement to check that it’s a sample object and then write the code, accordingly. When you’re setting something with regard to whether the user is “allowed” to do something, remember that this applies to a single object and, when you’re in grid mode, it works somewhat differently.
Notice that Event Triggers and Automation Scripts are all called “events.” That’s the worst bit about this, because people initially confuse “events” as those things only happening in an Event Trigger. So, even when we talk about them, it can be confusing. Also, some things fall under multiple categories. For example, stability studies have Event Triggers and Stability Manager has Automation Scripts. They’re not the same and you’ll have to plan this out to determine which type of event is the right one for what you’re doing.
There are lot of programming tips that can be applied to these, including good programming practices, but that could fill a book and I won’t even attempt it, here.