Source and Trigger Nodes

Source & Trigger Nodes

Article Type: Node Reference Audience: Developers, App Admins Module: Data Flows / Node Designer Applies to Versions: Platform 3.0+ Prerequisites: Basic understanding of Data Flow concepts

1. Overview

What are Source & Trigger Nodes?

Fuuz is an event-driven platform, and Source & Trigger nodes are crucial for building reactive solutions. These nodes provide flexibility to listen on event streams within the platform or events triggered by external systems. Source nodes are the starting points that determine when and how a flow executes, providing the initial payload.

Categories of Nodes:

• Debug/Testing Nodes: Used during development to simulate triggers and test flows
• Production Event Nodes: Deployed triggers that listen for real events in production
• Pub/Sub Nodes: Topic-based messaging for decoupled, asynchronous communication

Complete Node Reference

Category	Node	Purpose	Execution
Debug/Test	Source	Manual testing trigger with custom payload	On-demand
Debug/Test	File Source	Attach local file to simulate FTP/file integration	On-demand
Debug/Test	Data Change Source	Simulate data change events during design	On-demand
Production	Data Changes	Listen on Create/Update/Delete for data models	Asynchronous
Production	Request/Response	Synchronous API endpoint for screens/external calls	Synchronous
Production	Device Subscription	Subscribe to gateway device events (PLCs, sensors)	Asynchronous
Production	Webhook	Receive HTTP POST from external systems	Asynchronous
Pub/Sub	Topic	Subscribe to messages from a user-created topic	Asynchronous
Pub/Sub	Publish	Publish data to a topic for other flows to consume	Fire-and-forget

2. Source Node (Debug)

The Source node allows you to use a payload from anywhere that you can paste directly into the node's editor panel and then consume in your flow for testing purposes. In a production scenario, the contents of this node's payload would be replaced by some other listener, trigger, or API call.

Configuration Parameters

Parameter	Description
Payload	The JSON payload to pass to the next node
Context	The context to pass to the next node. Allows simulating context in the middle of a flow. Note: Context changes here will NOT persist in deployed version.

Tip: Remove or disable Source nodes before deploying flows to production. They serve no purpose in production and can confuse maintenance developers.

3. File Source Node (Debug)

The File Source node provides the option to attach a file from your local system to simulate receiving data from a third party. This is useful when testing flows that would normally be called through a Request/Response or would pull a file from an FTP you don't currently have access to.

Configuration Parameters

Parameter	Description
File	Drop a file or select from your local file explorer
File Directory	Simulate the directory where this file would be stored (useful for FTP simulations)
Output Encoding	UTF8 or Base64

File Encoding Guide

Encoding	Use For File Types
UTF8	XML, JSON, CSV, XLS, and other text-based files
Base64	JPG, PNG, PDF, and other binary files

4. Data Change Source Node (Debug)

Fuuz is an event-driven architecture that allows you to listen on event streams for many different types. Data change events are emitted when a record in a data model is created, updated, or deleted.

The Data Change Source node allows you to simulate this data being sent into the flow, as the data change event stream is not started until you have deployed the flow.

Configuration Parameters

Parameter	Description
API	Application or System
Type	The Data Model Type (Data Flow, Units, custom models, etc.)
Operation	Create, Update, or Delete
Before Data	The record prior to the change (for Update/Delete testing)
After Data	The record after the change (for Create/Update testing)

5. Data Changes Node (Production)

The Data Changes node allows you to listen on data change event streams from the Fuuz Platform for System models or custom Application models. When a record is created, updated, or deleted, the platform creates an event with the type of model, the operation, and the data before and after the change.

Configuration Parameters

Parameter	Description
API	Application or System
Type	The data model to listen on changes for
Operations	Create, Update, Delete (can select multiple)

Note: Design Standard — Data Changes can trigger many flow executions. They should be followed immediately by a conditional statement to reduce unnecessary executions.

6. Request and Response Node

The Request node is used to initiate a flow in Fuuz from an internal or external request. You must use a Response node on all terminating branches of the Data Flow to respond to the request with the payload.

Important: Timeout Warning — If a Response node is not triggered within 5 minutes after the Request node is triggered, you will receive a timeout response.

This node is very useful for creating modular processes that perform specific actions and can be called by other flows using the Execute Flow node.

Usage Requirements

• Request Node: Entry point for the flow — receives incoming payload
• Response Node: Must be placed on all terminating branches to return data
• Flows with Request nodes can be called via Execute Flow node or external HTTP requests

Note: Design Standard — All flows with a Request node must have at least one Response Node on every terminating branch.

7. Device Subscription Node

The Device Subscription node is used to subscribe to physical devices set up in Fuuz through the Edge Gateway. Any dropdowns left blank will act as a wildcard, allowing you to subscribe to multiple subscriptions with one node.

Configuration Parameters

Parameter	Description
Device Driver Type	Base driver type (e.g., Printer) — devices share common functionality
Device Driver	Specific driver (e.g., Native Printer via USB/Serial or TCP Printer via network)
Device	Specific device (e.g., "Production Floor Printer 1")
Edge Gateway	Gateway to receive events from (useful with multiple gateways)
Device Subscription Type	Type of subscription (varies by driver)
Device Subscription	Specific subscription to listen on

8. Webhook Node

The Webhook node is used to receive requests to a webhook made inside or outside of the platform. Webhooks are defined on the Webhooks screen. Webhooks are topics that can be published to through an HTTP POST request from outside of the system.

Note: Key Concept — All Webhooks are topics, but not all topics are Webhooks. Webhooks are specifically exposed for external HTTP access.

Configuration Parameters

Parameter	Description
Webhook	Select the webhook to consume (defined on the Webhooks screen)

Important: Payload Wrapping — Anything published to a Webhook is automatically wrapped in an object with a "value" property. See Section 11 for handling this.

9. Topic Node (Subscribe)

The Topic node is used to subscribe to messages from a specific topic. Topics are user-created event streams. To receive an event on a topic, another process (Screen or Data Flow) must publish to it first. The data published must be valid JSON.

Configuration Parameters

Parameter	Description
Topic	The topic the node will subscribe to

Important: Payload Wrapping — Payloads are NOT returned from a topic node as they were provided. Payloads will be wrapped in an object with the property name "value". See Section 11 for handling this.

10. Publish Node

The Publish node allows you to publish data to a topic created in the platform. This is useful for chaining multiple processes together.

Use Case Example

You have two Data Flows: A and B. Flow B is dependent on the completion of Flow A, but Flow A may take a long time to complete. You can publish an event when Flow A completes. Flow B listens on the topic Flow A publishes to. Once Flow B receives an event on that topic, it can start its process.

Configuration Parameters

Parameter	Description
Topic	The topic the node should publish a payload to
Bulk Publishing	If input is an array, publishes each index as a single event. Disable to publish the entire array as one payload.

Note: Design Standard — Topics, publishing, and subscribing are the preferred methods of handling pagination for large data sets.

11. Payload Wrapping Behavior

Both Topic and Webhook nodes wrap incoming payloads in a "value" property. This is important to understand when designing flows.

Example

Published Payload:

{
  "data": {
    "Part_No": "123",
    "Revision": "A"
  }
}

Topic/Webhook Node Output:

{
  "value": {
    "data": {
      "Part_No": "123",
      "Revision": "A"
    }
  }
}

Handling the Wrapper

The easiest way to handle this is with a script node after the Topic/Webhook node that removes the value property wrapping your payload:

$.value

12. Best Practices

Event Design Standards

• All flows with a Request node must have at least one Response Node on every branch
• Data Changes should be followed immediately by a conditional to reduce unnecessary executions
• Topics, publishing, and subscribing are preferred for handling pagination of large data sets
• Handle the "value" wrapper from Topic/Webhook nodes with a script node
• Remove Source nodes before deploying to production

Topic/Publish Patterns

• Use topics to decouple long-running processes
• Use Bulk Publishing for processing arrays as individual events
• Disable Bulk Publishing when you need the entire array as one payload
• Consider using topics for retry patterns and error handling

Debug/Testing Patterns

• Use Data Change Source to test flows before deployment (event stream doesn't start until deployed)
• Use File Source with proper encoding (UTF8 for text, Base64 for binary)
• Source node Context changes do NOT persist — use Set/Merge Context nodes for production

13. Troubleshooting

Symptom	Likely Cause	Resolution
Request times out after 5 minutes	Missing Response node on a branch	Ensure all terminating branches have Response nodes
Topic payload structure wrong	Value wrapper not handled	Add script node with $.value to unwrap
Too many flow executions	Data Changes without filtering	Add conditional immediately after Data Changes node
Webhook not receiving data	Webhook not defined or flow not deployed	Create the webhook on the Webhooks screen; deploy flow
Data Change Source not triggering in deployed flow	Using debug node instead of production node	Replace Data Change Source with Data Changes node
Device events not received	Wildcard filters too broad or gateway offline	Narrow subscription filters; verify Edge Gateway status
Context not persisting after Source node	Source node context is for testing only	Use Set/Merge Context nodes for production context

14. Related Resources

• Data Flow Design Standards — Event handling guidelines
• Fuuz Platform Nodes — Execute Flow for calling Request/Response flows
• IIoT & Gateway Nodes — Device setup and Edge Gateway configuration
• Flow Control Nodes — Schedule Node for time-based triggers
• Debugging & Context Nodes — Additional debug tools
• Notification Nodes — Send/Receive notifications
• System Administration — Webhook configuration
• Platform Website: fuuz.com

15. Revision History

Version	Date	Author	Description
1.0	2025-01-01	Fuuz Documentation Team	Initial release - Comprehensive consolidated guide covering all Source and Event nodes.
1.1	2025-01-01	Fuuz Documentation Team	Consolidated from separate Event Nodes and Debugging Nodes articles. Added Publish node, payload wrapping section, File Source encoding details.

See Also

• Data-Flow-Nodes-Reference
• Fuuz-Platform-Nodes
• IIoT-and-Gateway-Nodes
• Flow-Control-Nodes
• Debugging-and-Context-Nodes
• Notification-Nodes

---

Source: support.fuuz.com