Configuring State Persistence in IBM App Connect Enterprise (ACE)

Introduction

In modern integration environments, reliability and resiliency are critical. Systems must continue processing events correctly even after restarts, failures, or redeployments.

In IBM App Connect Enterprise (ACE), State Persistence enables message flows to store operational state externally so that processing can resume from the same point after a restart or failure. This capability is especially important in containerized environments.

What is State Persistence?

State Persistence enables ACE input and event nodes in a message flow to persist their processing state, such as the last polling time, stream position, or last processed event timestamp. By storing this state externally, the message flow can resume processing from the same point after an integration server restart or failure. This ensures continuity of event processing and helps prevent missed or duplicate events during unexpected outages or planned restarts.

Why State Persistence?

Consider a GitHub Input node configured to poll a repository for new issues every minute. Suppose the integration server unexpectedly crashes at 10:05 AM. During the downtime, 3 new GitHub issues are created. Without State Persistence, the GitHub Input node has no record of the last successfully processed event and cannot resume from its previous checkpoint. As a result, the issues created while the server was offline may be missed after the server restarts.

With State Persistence enabled, ACE persists the polling checkpoint in an external store. When the integration server restarts, the GitHub Input node restores this checkpoint and resumes processing from where it left off, ensuring that the issues created during the downtime are processed without loss.

Implementing State Persistence with GitHub Input Node

In this example we will demonstrate State Persistence, we will use a simple message flow that polls GitHub for newly created issues every minute and writes each event to a trace file.The flow consists of GitHub Input node and a Trace node

Configure the Trace node to write incoming event payloads to a file. Next, use Connector Discovery to configure the GitHub Input node by selecting Issues as the object and New Issues as the action. Provide the required GitHub credentials, choose the target organization and repository, and set the polling interval to 1 minute.

Our sample flow is ready for configuring State Persistence.

The remaining sections focus on enabling State Persistence for this flow and validating how it allows the GitHub Input node to resume processing after an integration server restart.

Configure State Persistence Policy

Select the GitHub Input node and navigate to Properties > Advanced. In the State Persistence Policy field, click Browse > Create Policy, then create a new policy with StatePP as the Policy Project and persist as the Policy Name.

The policy editor opens with the StatePersistence template. This policy determines where the input node stores its runtime state, such as polling checkpoints and other processing metadata.

Under Persistence type, select one of the following providers:

• REDIS – Stores state in an external Redis instance. This is the recommended option for containerized and cloud-native deployments, as the persisted state remains available even if an integration server or pod is restarted. Multiple integration server instances can also access the same persisted state.
• FILE – Stores state locally on the file system. This option is suitable for development and standalone environments but does not preserve state if the local storage is lost.

For this example, select REDIS as the persistence provider.

Since this example uses Redis as the persistence provider, create a RedisConnection policy to define the connection details for the Redis instance. Create a new Policy Project named RedisPP, then create a RedisConnection policy named persist. If Redis is running locally, the default configuration can be used (Host: localhost, Port: 6379). Save the policy before proceeding to the next step.

Return to the StatePersistence policy and specify the fully qualified name of the Redis connection policy as {RedisPP}:persist.

Finally, create and start a Local Integration Server using the default settings. Once the server is running, deploy the required artifacts: RedisPP, StatePP, githubPP, and the TestingStatePersistenceGithub application. After deployment completes successfully, the environment is ready to validate State Persistence.

Testing State Persistence

To validate the configuration, create a new GitHub issue in the configured repository and verify that the event is written to the configured trace file that confirms the event was processed.

Next, confirm that the polling checkpoint has been persisted by inspecting the corresponding keys in Redis.

Once verified, stop the integration server and clear the contents of the trace file.

( This ensures that any entries generated after the server restarts correspond only to events processed during the recovery phase. )

While the integration server is stopped, create a new GitHub issue in the configured repository. Since the GitHub Input node is no longer polling, the event is not processed immediately. This simulates events arriving during an unexpected outage.

Restart the integration server. During startup, the GitHub Input node retrieves its previously stored checkpoint from Redis through the configured State Persistence policy. It resumes polling from that checkpoint instead of starting from scratch.

Expected Result:

After restart, the GitHub Input node processes the issue that was created while the server was offline. This demonstrates that the connector resumed from the last persisted checkpoint rather than treating the restart as a fresh deployment.

Without State Persistence, the node would not have a persisted checkpoint available. Depending on the connector behaviour, events created during the downtime could be missed or previously processed events could be re-read. State Persistence eliminates this risk by maintaining the polling state outside the integration server.

Summary :

In this blog we:

• created a GitHub Input message flow
• configured a State Persistence policy
• stored checkpoints in Redis
• verified that processing resumed correctly after restarting the integration server

State Persistence enables input nodes to preserve operational state outside the integration server, allowing applications to recover gracefully from restarts, failures, and container rescheduling without losing or reprocessing events. This makes it particularly valuable for cloud-native deployments where integration servers are expected to be restarted or replaced over time.

In the next part of this series, we'll explore Scheduler State Persistence and see how the Scheduler node can recover from downtime using different recovery strategies through the missedEventMode property.
for more information visit Building Resilient Scheduler-Based Integrations: State Persistence in IBM App Connect Enterprise