Designing event-driven TRIRIGA integrations that teams can operate

A downstream application does not always need another complete extract. Sometimes it needs to know that a particular business change has happened: a record has reached an agreed state, relevant information has been updated, or a process is ready for its next handover.

That is the starting point for an event-driven integration. Instead of making a consumer repeatedly ask whether something has changed, the integration identifies a relevant change and sends information that the consumer can act on. The design question is not simply how to transmit a message, it should also cover what the message means and what should happen if the receiving application cannot act on it.

ExpressEvent is the event-processing part of ExpressConnect for IBM TRIRIGA and IBM Maximo Real Estate and Facilities (MREF). Its framework includes gathering data, filtering, transformation and transmission, with an embedded WebSocket server and webhook delivery. Those capabilities provide the building blocks; the business and operational decisions still belong to the integration design.

Define a business event, not just a record update#

Consider an illustrative process in which an approved location change should reach a downstream facilities application. A record might be saved while someone is still correcting its details. Sending every save could ask the receiving application to act before the source process is ready.

Define the condition that makes the change meaningful. It might depend on the record's state, a relevant field change or another agreed business condition. Then describe the expected action in the destination. This prevents the event name from becoming a vague label that different teams interpret differently.

ExpressEvent supports filtering, including field-level filtering. You can use that capability to assess which changes matter to the consumer. The exact trigger, subscription and data selection need to be configured and tested for the intended process.

Give each stage a clear job#

The gathering stage should collect the information needed for the handover. Filtering should decide whether that information meets the agreed conditions. Transformation should shape it for the receiving application. Transmission should deliver it through the selected transport.

Separating these responsibilities makes the design easier to discuss. If the destination rejects a location identifier, the team can ask whether the wrong value was gathered or the mapping was incorrect. If irrelevant updates arrive, the filter and trigger deserve attention.

Keep the payload purposeful. Include the business identifier the consumer needs, the information required for the action, and whatever context the agreed contract uses to interpret the change. One should avoid including a complete business record merely because the gathering stage can access it.

Choose the transport for the consumer#

A webhook delivers a request to a configured receiving endpoint. It can suit an application that already exposes a service for incoming notifications. The design needs to cover that endpoint's authentication, network access, accepted payload and response behavior.

A WebSocket provides a persistent connection and can support interaction with connected clients. ExpressEvent includes a bi-directional WebSocket server. Evaluate this option when a maintained connection fits the consuming application, and account for what happens when that client disconnects or reconnects.

Neither transport alone establishes the business outcome. A request reaching an endpoint is different from the destination accepting and applying a record. Agree which response or subsequent check demonstrates completion, and make that distinction visible in operational guidance.

Decide how failure and repetition are handled#

During design, assume that the destination can be unavailable, a payload can be rejected and a consumer can see the same business change again. Then decide how the receiving application should behave in each case. These are acceptance requirements to verify in the deployed integration, not delivery guarantees inferred from ExpressEvent's transport support.

For repeated processing, assess an idempotent consumer: one that can recognize an already-applied business change and avoid applying it again. Where ordering matters, define how the consumer detects or handles an older update arriving after a newer one. Choose identifiers and comparison rules deliberately rather than relying on the arrival sequence.

Also agree who can retry failed work and when a failure needs business intervention. A temporary service outage and an invalid business value may need different responses. Repeatedly resending a rejected value is not a substitute for correcting it, for example, network failures can be retried, however, there is no point sending a payload with error again.

Keep a way to check the resulting state#

Event-driven delivery can be paired with an API read or a reconciliation process. For example, a consumer may use an agreed API operation to check source state, while an operational check compares records that should have reached the destination. Whether this is necessary depends on the process and the consequences of a missed or delayed update.

Use representative data to test the whole path. Change a qualifying record, verify the gathered and transformed payload, inspect the destination result, and repeat the exercise with a non-qualifying change. Then test a disconnected consumer and a rejected payload. Make a note of the behavior provided by the deployed configuration and that requires application logic.

Make the operating agreement part of the design#

A useful event specification names the trigger, payload, destination, access requirements, success condition and recovery owner. It should also explain what information support staff need to investigate a problem without exposing unnecessary business data or credentials.

That specification gives an ExpressConnect technical session a concrete focus. Bring a business change that matters to your organization, describe the action another system should take, and work through the event path and its failure cases. The goal is to make the process easy to understand, not just when the demo goes well, but also when things go wrong, so people can see what happened and why.