Intrexx Process Looping
Have you ever encountered an issue in Intrexx where most of your backend logic relies on event listeners, such as record insertion, updating, or deleting?
It's a valid approach, but sometimes you may find yourself restricted to calling backend processes via Generic Actions triggered with an AJAX call. In such cases, you might wonder how to send data to those event listeners without duplicating all the functionality in a single Groovy Script Action.
In short, a small Groovy snippet can trigger Global Timers with optional parameters. You can then use the timer filter to access the parameters sent:
import de.uplanet.lucy.server.scheduler.JobStarter
JobStarter.startJob("<Timer-GUID>", [testParam: true, greeting: 'Hello world!'])
We scoured everywhere for a solution to this obstacle. Fortunately, we found the above snippet in a section called Start processes, where the headline "Starting timers via Groovy and passing parameters" starts, from the official Intrexx Help Center, Tips & Tricks chapter.
It details how to start timer jobs using the JobStarter class and the startJob method. The first parameter is the timer GUID, and the second optional parameter is an object array. You can send Booleans, Strings, Integers, etc., which are later accessed via the Shared State (Processing context) functionality g_sharedState.myVar
.
We needed to trigger our structured event listener workflow based on a couple of IDs in our use case. Were there other options than this one? Of course, but from all the solutions we found, none seemed as reliable and performant!
What we ended up doing was concatenating our IDs with "||" so they're interpreted as the SQL keyword "OR":
def idArray = ["123", "222", "331", "213"]
def idStringConcatenated = ""
idArray.each { currentID ->
idStringConcatenated += "$currentID||"
}
// Expected output of idStringConcatenated
// 123||222||331|213||
// For our case, having the last "||" bit with no following value does not matter
Finally, once we finished our data processing, we added the following line:
JobStarter.startJob("123123123", [idsToLoopThrough: idStringConcatenated])
Make sure this snippet is outside of any loops! Otherwise, unintended behavior, such as repeatedly triggering the timer, might occur!
Moving to our Global Timer, we set the targeted Data Group along with the rest of the settings, but the most crucial part is the filter! Here, we added a filter to check for IDs in our string coming from the Shared State (Processing context).
Finally, the process should look like this: