Scheduler State Persistence in IBM App Connect Enterprise

Building on our previous post on State Persistence, this post focuses on how ACE handles scheduled events missed during downtime — and how you control recovery behaviour using missedEventMode.

When an integration server restarts, a Scheduler node without state persistence has no memory of its previous schedule. Events due during downtime are silently lost, and the schedule resumes as if starting fresh. For time-sensitive integrations — reconciliation jobs, compliance reports, batch exports — that gap requires manual intervention.

Understanding missedEventMode: Four Recovery Strategies

The missedEventMode property defines how the Scheduler node handles missed events when it discovers persisted state during startup. Think of it as a recovery policy that you choose based on your integration's business requirements.

Configuring missedEventMode in the Toolkit

The missedEventMode property is accessible in the Scheduler node properties panel in IBM App Connect Toolkit:

Mode 1 — None: Ignore missed events

Behaviour: The scheduler ignores all missed events and continues with the original schedule.

When to use: Ideal when your integration is truly time-sensitive and historical events have no value. If you're polling a real-time stock price API, you don't care about the price at 2:30 PM when it's now 2:45 PM — you only want the current price.

Key insight: This is the default mode when using discovery flows with a Scheduler node.

Mode 2 — Last: Catch up on the most recent missed event

Behaviour: The scheduler emits the last missed event immediately upon restart, then continues with the original schedule.

When to use: Works well when you need to acknowledge that downtime occurred, but don't need to process every missed event. If you're checking for configuration changes in a remote system, you only need to know the latest state.

Key insight: The emitted event carries special metadata — lastEventTime reflects the original scheduled time (2:40), while currentEventTime shows the actual execution time (2:45). Your flow logic can use this to handle recovery differently if needed.

Mode 3 — All: Catch up on every missed event

Behaviour: The scheduler emits every missed event immediately upon restart, then continues with the original schedule.

When to use: Essential when every scheduled execution represents a discrete unit of work that must be completed — for example a batch processing flow exporting data to a warehouse. If you miss two export windows, you need to run both to ensure data completeness.

Key insight: All missed events are emitted rapidly at restart time. Your flow should be designed to handle this burst of activity, especially if downstream systems have rate limits.

Mode 4 — Reset: Acknowledge and restart the schedule

Behaviour: The scheduler emits one missed event to acknowledge the gap, then restarts the schedule from the restart time.

When to use: Useful when you want to maintain a consistent interval going forward while still acknowledging that downtime occurred. If generating hourly reports and the server restarts at 2:45 PM, generate one catch-up report then continue with reports at 3:45, 4:45, etc.

Key insight: This mode changes the schedule's phase. An original schedule on the hour (1:00, 2:00, 3:00) resets at 2:45 PM to (2:45, 3:45, 4:45). Choose carefully if schedule alignment matters.

Comparing Recovery Modes

The runOnceOnCheck Behaviour

If runOnceOnCheck is enabled, it is ignored when the Scheduler node detects persisted state on startup. The node is resuming an existing schedule, not starting fresh — missedEventMode is the correct mechanism to control what happens next.

Conclusion

Scheduler state persistence represents a significant step forward in building resilient, production-ready integrations with IBM App Connect Enterprise. By giving you explicit control over recovery behaviour, it eliminates uncertainty and reduces operational overhead.

The next time you design a scheduler-based integration, take a moment to think about what should happen when the server restarts. With missedEventMode, you have the tools to implement exactly the recovery behaviour your business needs — whether you're building real-time data pipelines, batch processing workflows, or compliance reporting systems.

Have you implemented scheduler-based integrations in App Connect Enterprise? How do you currently handle restarts and missed events? Share your experiences and questions in the comments below.