One of the most powerful, and underutilized, capabilities of OpCon thresholds is their ability to serve as a bridge between external systems and your OpCon job processing. Any system that can send an API call or drop a message file can update a threshold, and from there, OpCon can react automatically. This opens the door to event-driven automation that responds to real conditions in your environment.
How External Systems Can Update Thresholds
There are two primary ways external systems can update an OpCon threshold:
- API Call: Any system with network access to OpCon can send a direct API call to update a threshold value.
- Message In (File Drop): A system can write a message file to a watched location, and OpCon picks it up and processes the threshold update as an event.
Both approaches require no direct OpCon job involvement, the external system is reaching in and updating the state directly.
Use Case: File-Count-Based Job Triggering
Another practical scenario: transaction files arrive throughout the day, and you need a processing job to run after every 10th or 50th file arrives. Configure a file watcher that increments a threshold each time a file lands. Set a downstream job to trigger when the threshold reaches the target value (e.g., 10 or 50). After the job runs, reset the threshold to 0 and let counting resume. This pattern lets external file activity directly drive OpCon's job schedule without any polling or manual intervention.
Use Case: Goodnight Processing Milestone (OpCon User Tip)
An OpCon user shared this practical pattern: thresholds are used to signal when Goodnight processing is complete. When the threshold value rises above zero, OpCon knows that the core system's nightly processing has finished and that subsequent jobs, like downloading generated files, are safe to run. This replaces a complex dependency chain with a single, clear condition: 'Goodnight is done; proceed.'
Thresholds vs. Resources for External Integration
Both thresholds and resources can be updated by external events. The choice depends on what you're modeling. Use resources when the external system needs to control how many jobs run simultaneously (a concurrency gate). Use thresholds when the external system needs to signal that a condition has been met or a count reached (an event trigger). In many architectures, both will be in play.
Summary
Thresholds are OpCon's integration handshake with the outside world. By accepting updates from monitoring tools, file watchers, external APIs, and other systems, they transform OpCon from a self-contained scheduler into a responsive automation platform that reacts to what's actually happening in your environment. If you have processes that should run 'when X happens' rather than 'at Y time,' thresholds are the mechanism to make that happen.