Forwarders
What is a Forwarder?
A Forwarder in Factry Historian defines which data should be sent to a Sink, and how that data should be structured. Where Sinks handle where data goes (e.g. MQTT broker), Forwarders handle what data is included and how it is formatted.
Think of a forwarder as the logic layer between your data and the output destination.
Why does it matter?
Not every external system needs every piece of data. With Forwarders, you can:
- Select specific Measurements, Calculations, Asset Properties or Events to be included
- Format data (e.g. as JSON, in the case of a generic MQTT sink), see generic MQTT
- Split different data streams across multiple sinks with different rules
- Control the structure of outgoing messages
This makes it possible to build targeted, efficient, and decoupled integrations without duplicating configuration or exposing your entire Historian.
How does it fit in the system?
Forwarders are attached to a Sink, and define:
- What data should be sent (using Labels, Asset Properties, or Events)
- What format the output should follow (plain JSON or Sparkplug B)
- How frequently the configuration should be reloaded
The Sink simply sends what the Forwarder tells it to, in the form defined by the Forwarder.
Example
You have two MQTT Sinks:
- A local broker for exposing data locally
- A corporate broker for KPIs and energy tracking
You configure two Forwarders:
Forwarder A (connected to local Sink):
- Selects all Asset Properties under Line1.
- Uses a JSON format deemed fitting for the site's use cases.
Forwarder B (connected to corporate Sink):
- Selects only OEE and energy KPIs for all lines in the site
- Formats them using the JSON structure defined by the corporate guidelines
- Only sends Event data
This allows the same system to support both high-resolution data egress and low-resolution corporate integration, using tailored outputs from the same source data.
When you use it
You use Forwarders to configure what data leaves the Historian over MQTT:
- When you have multiple Sinks that need different subsets of data
- When you need to control structure and formatting for outgoing messages
- When you want to reuse the same Sink with different categories of data sent to different topics
Common misconceptions
- Forwarders do not send data on their own; they work through Sinks.
- You can have multiple Forwarders per Sink, each with different settings.
- Forwarders do not modify the original time-series data, only what is published.
Best practices
- Use clear naming for Forwarders.
- Avoid overlapping rules unless needed. One Forwarder per purpose is easier to maintain.
- Verify your JSON message structure with other stakeholders in the organization, to confirm compliance with their use cases.
- Test outputs thoroughly before going live with third-party integrations.
More information
- Creating a forwarderCreating a forwarder