Skip to main content

Output Processors

Output Processors are the exit points of a Workflow, determining how and where processed data leaves the pipeline.

Overview

In layline.io, Output Processors serve as the final step in your Workflow. They receive processed messages from Flow Processors and deliver them to their final destinations. While Sinks define where data goes (the connection endpoint), Output Processors define how data is sent (the delivery mechanism and format).

This relationship mirrors the input side: just as Input Processors work with Sources to bring data in, Output Processors work with Sinks to send data out. A single Sink can be reused across multiple Output Processors, each configured for different message types or delivery patterns.

Available Output Processors

File & Stream Output

AssetDescription
Output StreamWrite data to stream-based Sinks (File System, S3, FTP, WebSocket, etc.) with support for compression, format serialization, and batch control. Use when outputting to file systems, cloud storage, or streaming endpoints.
Output FrameSend data as discrete datagrams to frame-based Sinks (Kafka, Kinesis, SQS, SNS, EventBridge). Use when publishing to message queues, event buses, or streaming platforms that handle individual messages.

Utility Output

AssetDescription
Output Dev NullDiscard messages without sending them anywhere. Use for testing workflows without producing output, handling dead-letter scenarios, or measuring throughput without I/O overhead.

How to Choose an Output Processor

If you need to...Use this processor
Write files to disk, S3, FTP, or cloud storageOutput Stream
Publish to Kafka topicsOutput Frame
Send messages to SQS queuesOutput Frame
Push events to Kinesis or EventBridgeOutput Frame
Publish SNS notificationsOutput Frame
Test workflows without actual outputOutput Dev Null
Discard messages that don't need processingOutput Dev Null

Common Patterns

Error Handling

Output Processors support configurable failure handling when a Sink is unreachable or returns an error:

  • Discard Message — Skip the failed message and continue processing subsequent messages
  • Rollback Stream — Roll back the entire transaction and retry from the beginning
  • Retry with Backoff — Automatically retry failed deliveries with exponential backoff

Configure these behaviors in the Output Processor's Failure Handling section.

Retry Logic

All Output Processors include built-in retry mechanisms:

  • Configure maximum retry attempts for transient failures
  • Set retry intervals to control backoff behavior
  • Define timeout values for slow destinations
  • Use circuit breaker patterns to prevent overwhelming failing endpoints

Output Batching

Optimize throughput by batching messages:

  • Output Stream supports batching multiple records into a single file or stream operation
  • Output Frame can batch messages for queue and topic destinations
  • Configure batch size limits and flush intervals to balance latency vs. throughput

Format Serialization

Output Processors that write to file-based Sinks (Output Stream) require a Format asset:

  • The Format defines how messages are serialized (JSON, XML, CSV, etc.)
  • Multiple Output Processors can use the same Sink with different Formats
  • Formats ensure data consistency and validation before writing

Transaction Boundaries

Output Processors participate in Workflow transaction management:

  • Messages are committed to Sinks as part of the Workflow's transaction
  • Failed outputs can trigger rollback of the entire processing batch
  • Use Input Frame Committer for precise control over when offsets are committed relative to output

See Also

  • Sinks — Reusable destination endpoints that Output Processors write to
  • Input Processors — Entry points to Workflows (the counterpart to Output Processors)
  • Flow Processors — Transform and route data between input and output
  • Formats — Define how data is structured when written by Output Processors