Options
All
  • Public
  • Public/Protected
  • All
Menu

Interface EnrichOptions<T, U>

These options for an RStreamsSdk.enrich pipeline step. This reads events from one queue and writes them to another queue. Put another way, an enrich pipeline operations reads events from an inQueue and then writes them to an outQueue, allowing for side effects or transformation in the process.

see

RStreamsSdk.enrich

see

RStreamsSdk.enrichEvents

Type parameters

  • T

    The type of the event read from the source inQueue

  • U

    The type of the event that will be written to the destination outQueue

Hierarchy

  • EnrichOptions

Index

Properties

batch?: number | BatchOptions

This governs micro-batching events that have been received from the source inQueue before they are sent to your transform function, allowing that function to receive events in batches instead of one at a time. This can be useful when your transform function will reach out and hit an external resource such as a database. Hitting a database for every single event that flows through a pipe can be very detrimental to performance. So, it's common to micro-batch say 100 or 1000 or so and then construct a single query to a database to read/write all data as a single DB operation.

If this is a number, it's just the number of events to micro-batch up.

config?: ReadOptions

Fine-grained control of reading from the source inQueue

id: string

The name of the bot that this code is acting as. The SDK will use it to query to the bot Dynamo DB table to pull checkpoints and to checkpoint for you.

inQueue: string

The source queue from which events will be read

outQueue: string

The destination queue into which events will be written

start?: string

The event ID of the starting position to read from with in the queue. It is common to not provide this because each queue is stateful in that it remembers the last read position of a bot. Then, as bots read they make a call back to the RStreams Bus to update the read position.

Usually, the SDK just handles this for you. So, if the start isn't provided, the SDK will just use the bot's last read position as the starting point. So, as bots are invoked, read some events and do some processing, they automatically update back how far they've read to and then the bot shuts down after a period of time. When the bot starts back up to read again, it knows where it last read from and just continues.

see

Fundamentals: Event ID

transform: ProcessFunction<T, U>

The SDK will invoke this function after reading events from the inQueue and will take the result of this function to send to the destination outQueue.

Generated using TypeDoc