In this demo, I give examples of different ways to enrich a stream of events – and the types of event processing that this can enable.
I presented this in a webinar with Matt Sunley (replay recording available) yesterday. Matt started with some context, explaining how enriching events with data from external sources can enable event processing solutions that aren’t otherwise possible.
And then I ran through a demo, creating an event processing flow that included four types of enrichment.
IBM App Connect Enterprise (ACE) is a broker for developing and hosting high-throughput, high-scale integrations between a large number of applications and systems, including Apache Kafka.
In this post, I’ll describe how to use App Connect Enterprise to process Kafka messages that were serialized using Apache Avro schemas.
This is an update to an earlier version of this post, reflecting updates to the sample code.
Best practice when using Apache Kafka is to define Apache Avro schemas with a definition of the structure of your Kafka messages, and to store those schemas in a central registry that client applications can access at runtime.
If you want to use IBM App Connect Enterprise to develop and host integrations for processing those Kafka messages, you need App Connect to know how to:
This is the sixth in a series of blog posts sharing examples of ways to use Mirror Maker 2 with IBM Event Streams.
Mirror Maker 2 is a powerful and flexible tool for moving Kafka events between Kafka clusters.
For this sixth post, I’ll look at using Mirror Maker to migrate your Kafka cluster to a new region.
I’ve broken this down into multiple stages. For each stage, I’ll explain the intent and share a demo script I’ve created to let you try this for yourself.
This is the fifth in a series of blog posts sharing examples of ways to use Mirror Maker 2 with IBM Event Streams.
Mirror Maker 2 is a powerful and flexible tool for moving Kafka events between Kafka clusters.
For this fifth post, I’ll look at using Mirror Maker to maintain a backup of your Kafka events, and to be able to restore from that backup.
This is more complex than the previous posts as there are multiple stages involved. For each stage, I’ll explain the intent and share the demo script I’ve created to let you try this for yourself.
This is the fourth in a series of blog posts sharing examples of ways to use Mirror Maker 2 with IBM Event Streams.
Mirror Maker 2 is a powerful and flexible tool for moving Kafka events between Kafka clusters.
For this fourth post, I’ll look at using Mirror Maker to create an active/passive topology with a backup cluster ready to failover to.
This is the third in a series of blog posts sharing examples of ways to use Mirror Maker 2 with IBM Event Streams.
Mirror Maker 2 is a powerful and flexible tool for moving Kafka events between Kafka clusters, but sometimes I feel like this can be forgotten if we only talk about it in the context of disaster recovery.
In these posts, I want to inspire you to think about other ways you could use Mirror Maker 2. The best way to learn about what is possible is to play with it for yourself, so with these posts I’ll include a script to create a demonstration of the scenario.
For this third post, I’ll look at using Mirror Maker to create logical topics shared across multiple regions.
This is the second in a series of blog posts sharing examples of ways to use Mirror Maker 2 with IBM Event Streams.
Mirror Maker 2 is a powerful and flexible tool for moving Kafka events between Kafka clusters, but sometimes I feel like this can be forgotten if we only talk about it in the context of disaster recovery.
In these posts, I want to inspire you to think about other ways you could use Mirror Maker 2. The best way to learn about what is possible is to play with it for yourself, so with these posts I’ll include a script to create a demonstration of the scenario.
For this second post, I’ll look at using Mirror Maker to broadcast events to clusters in multiple regions.
Where the last post described a “fan in” scenario, this is effectively the opposite use case: a “fan out” scenario.
This is the first in a series of blog posts sharing examples of ways to use Mirror Maker 2 with IBM Event Streams.
Mirror Maker 2 is a powerful and flexible tool for moving Kafka events between Kafka clusters, but sometimes I feel like this can be forgotten if we only talk about it in the context of disaster recovery.
In these posts, I want to inspire you to think about other ways you could use Mirror Maker 2. The best way to learn about what is possible is to play with it for yourself, so with these posts I’ll include a script to create a demonstration of the scenario.
For this first post, I’ll look at using Mirror Maker to aggregate events across clusters in multiple regions.