Forwarders

what is a forwarder? a forwarder in factry historian defines which data should be sent to a sinks docid\ uhmcdtk0trx quipd8pey , 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 docid\ xqwlemdcnfff3 0h gmms , calculations docid\ opiodkgnngyjedx6zkg d , asset properties docid\ cr6hbrdsl8fsuvlvm20if or events docid 0ith2zlcais5yywhsdtje to be included format data, in the case sinks docid\ uhmcdtk0trx quipd8pey 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 tags & labels docid\ zb70hnsdfnj3sj42myjxi , asset properties, or events) what format the output should follow (plain json or sparkplugb) 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 using 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 events docid 0ith2zlcais5yywhsdtje 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 verify compliance with their use cases test outputs thoroughly before going live with third party integrations more information creating a forwarder docid\ xalp36b2qlv9pdgo83p4c