Guidewire Application Events Service

Enabling event-driven integrations in Guidewire Cloud

By: Mark Bolger (Architect)

Guidewire’s Application Events Service is a key part of the new integration framework on Guidewire Cloud. Based upon an event-driven architecture and built on Apache Kafka, the Application Events Service fundamentally transforms the way insurers enable integration between their core systems and third-party products, applications, and components. While the Guidewire platform has long focused on driving integrations from events in the InsuranceSuite core, the Application Events Service takes this further by using cloud-native services and service distribution. This approach maximizes performance, scalability, and reliability, while also improving business agility and data sharing both inside and outside the enterprise.

Background: InsuranceSuite Event Messaging

Historically, the Guidewire InsuranceSuite platform has used an event-driven pattern of integration with a feature called event messaging. As transactions are committed in the core system (such as creating or altering data entities, or firing custom business events), a set of rules examine the changes to determine whether a message is sent to one of the pre-configured destinations. These destinations are registered with a transport layer, which handles sending the message to wherever it needs to go, along with acknowledging that the message was successfully delivered. These transports leverage the platform’s toolset to get the required data out or in, including via REST API clients or messaging protocols such as JMS.

A destination is similar to a Kafka topic, denoting a set of logically related messages, but not necessarily ensuring their order. Order is incredibly important for transactions in a system of record such as InsuranceSuite, so destinations also have a feature called safe ordering that leverages the platform’s knowledge of core business entities to ensure that messages for any destination are placed in virtual queues corresponding to those entities. With this safe ordering enabled, no message for a given core entity (such as a claim or account) is sent if the message before it has not yet been acknowledged. This persistence allows developers using InsuranceSuite to create robust integrations without fear of data loss in transit.

At a high level, the steps look like this:

• An event occurs in InsuranceSuite (such as ClaimOpened).
• The event fired business rules are run for the event against each destination.
• The business rules decide whether the event is of interest to the destination.
• A message is created for the destination and related to the event. In this case, the claim that was opened.
• The message transport picks up the message, sending it and acknowledging that it was sent successfully.

This integration capabilities reside wholly inside InsuranceSuite, using optimized database tables and related services to guarantee successful event handing as described above.

Introducing Guidewire Application Events

Well, the above sounds great. What could we possibly improve?

Although the InsuranceSuite event messaging system works well, the architecture of Guidewire Cloud allows us to decouple and distribute the high-level steps listed above. The new Application Events Service both splits the lifecycle of the transport layer from the core application and standardizes the data that InsuranceSuite produces. This results in improved scalability, resiliency, and agility for the integrations a customer enables. Most importantly, it faithfully delivers the same event-based integration capabilities and guarantees that were previously available in InsuranceSuite:

• Custom events can be created to enable new use cases.
• Order is maintained transparently for events associated with InsuranceSuite core entities.
• Events are persistent, and any downtime does not affect the guaranteed delivery of events.
• Destinations are isolated from each other, processing their own events and creating distinct messages for each integrated system.

How It Works

We started by implementing the Application Event Service to use the same event definition approach as the InsuranceSuite event messaging that preceded it. Any custom events a developer might have added to InsuranceSuite generate application events the same way as before. Integrations can more readily be migrated by starting with the event firing logic that was previously expressed within InsuranceSuite business rules.

Instead of checking applicability against a set of business rules, the Application Events Service writes every event to an external event broker along with the entity that the event relates to. The data for the event is defined in terms of a what we call an integration view, which combines a schema and a set of mapping functions that produce the concrete data entity that matches the schema. Using the robust P&C data models made accessible through the InsuranceSuite Cloud APIs, the Application Event Service matches the entity on which an event occurred with the broadly applicable integration view for that entity. This initial event stream contains everything we need to integrate with other systems, but it isn’t yet in a form that is usable for that purpose.

Here’s an example of how the data looks for a claims exposure event created within Guidewire ClaimCenter:

In the above example, as an exposure is added and then later updated, snapshots of the exposure (created by the integration view) are sent in the order they were created to the event broker. This sending of the event snapshots is done safely by committing the message contents to the application’s database along with the changes themselves. If the changes fail to save, then the events and snapshots are not sent; but if the commit succeeds, then the event is processed and sent by an internal worker.

NOTE: In a future blog post we’ll discuss how events produced by the Guidewire Application Event Service allow downstream systems to act as middleware, easily enabling support for other event sources beyond the Guidewire core.

While the above data is now complete for the specific event, it includes only data directly related to the entity the event was “on.” Event transports have broad access to the InsuranceSuite data model through the entity a message relates to. Transports use this access to build complex messages before sending them to specific integration endpoints. Enabling a similar scope of data access in the Application Events Service requires that we extend the pipeline with a capability we call the snapshotter. The snapshotter takes each event it receives and uses it to build on the last event received for the same core entity, creating a snapshot of the core entity’s data at the time of the event. In other words, it uses event sourcing to build point-in-time payloads of complete, denormalized business entities.

Using a simple example, let’s say there are two insurance claims, claim “1” and claim “2”, where “1” and “2” are the IDs by which events for those claims are partitioned. Each claim will have three related events occur: ClaimOpened, ExposureAdded, and ExposureUpdated. The event data representing this scenario is shown in the diagram below:

The Application Event Service pipeline parallelizes the steps taken on claims “1” and “2” (identified by the “Root ID”), while still ensuring that each event for those claims is processed completely and successfully in order. Once InsuranceSuite writes these events in the log, the snapshotter takes the following additional steps:

• Reads the ClaimOpened event and its corresponding claim data, finding a claim ID of “1.”
• Looks up the previous snapshot for claim “1.”
• Assuming the claim exists, it updates the claim’s data fields with those in the event.
• Stores a new snapshot with the update as the latest snapshot for claim “1.”
• Stores the new snapshot reference and event into the event log.

The steps executed for claim “2” would be similar, though any new events such as IncidentAdded would add new data rather than updating the existing data fields of a particular entity.

You can see how this would work if we expand our example. This diagram shows the resulting state, with each snapshot containing all the data required to enable integration work scopes:

The final step in the process is the most interesting, as the output of the snapshotter is another event log. This log correlates the event to a full claim snapshot, instead of just the data the event may have altered. This data is also moved out of the event log itself into a separate storage service. The data representations of entire core system objects can get very large, so the Application Event Service uses AWS’s S3 and DynamoDB offerings for persistent event data storage with minimal latency.

From Internal to External Integration

The Guidewire Application Events Service sets the stage for enabling a wide range of integration scenarios by providing an ordered stream of core application events to systems within Guidewire Cloud. This stream and the corresponding snapshot data are secured and help standardize and simplify the integration needs of our customers while doing the same for Guidewire internal development teams.

In our next blog post we’ll explore two other aspects of the unified integration framework being delivered as part of Guidewire Cloud. This includes an Integration Gateway and Streaming API service that enable external integrations through both low-code development as well as business-driven (no-code) configuration. These systems correspond to the transport layer for moving data out of Guidewire Cloud in reliable, secure, and flexible ways.

“The preceding is the confidential information of Guidewire Software, and is intended to only outline potential innovations from Guidewire Products & Engineering. It is being provided for information purposes only, and it does not constitute a binding agreement or contractual obligation of any sort with the recipient, nor is it a commitment to deliver any existing or future software or functionality. The development, release, and timing of any features, capabilities, or functionality described in the preceding remains at the sole discretion of Guidewire.”