By default, and it can't be changed, the SQL and File rules are run/processed one-at-a-time.
So, if you have for example, a SQL rule that triggers a batch/XML that runs for one hour, no additional rules will process until that batch is complete.
What-the-heck? I know, right. Well, this is by design to ensure a previously triggered event does not "step on" a later event. In a perfect world, you could add dependencies to rules like "make sure process X isn't running" or "make sure process X runs first". This just adds to the complexity of running and watching SQL and File rules, and we're trying to keep Event Server's "decision making" as simple as possible (or no more complex than it already is).
So, what's the workaround to trigger multiple SQL and File rules and processes at once? Use a "dummy" Superbatch that runs immediately and triggers a longer running "real" batch.
What's a SuperBatch?
What's a "dummy" SuperBatch?
The "dummy" refers to a job or batch that's not really outputting any real work. In the System Reports that we make available
, there is a Batch Message Report. Follow these instructions to make a "dummy" SuperBatch.
- Create a new batch
- Add/use the Batch Message Report
- Edit Parameters and set the message parameter to "Dummy" or if you want to make it informational "Whatever Process SuperBatch Has Triggered"
- By default, it outputs to File, that's fine... just set the option to cancel output if zero records (this report ALWAYS returns zero records --- there is no datasource)
- OK window and save batch --- name it something relevent like "Whatever Process SuperBatch Trigger"
- Note, now the INI button is enabled to customize the batch; click the INI button
- Configure your SuperBatch "if good run" triggered batch --- the batch you want this dummy process to always trigger
- Save and exit, and you are done!
You can test this batch manually, and you'll see it runs immediately, creates no output, and simulates the trigger of your next batch (a manually run SuperBatch only displays what would trigger --- it does not actually trigger it until it's non-manually run).
TIP: If you want to be notified when this process triggers... simply convert the job in the "dummy" batch to send an email or an SMS message... and uncheck the option to cancel if zero records. That way, everytime this process triggers, you'll be notified, and it still runs really quick.
And lastly, just to finish explaining how this works with your SQL or File rules in speeding up rules and triggers...
Instead of triggering a long running batch directly from the SQL or File rules, you configure the rule to trigger THIS "dummy" batch, which triggers the actual long running batch. The benefit is THIS "dummy" batch runs immediately, the rule is finished immediately, and the next rule can process immediately. You would configure these "dummy" batches for any rules that trigger batches that run a long time. If you do this for all long running rule batches, you'll have zero delays, because all rules would then run within a second or two.