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 Debugging & Context Nodes?

Debugging nodes help you test, troubleshoot, and monitor your data flows during development and production. Context nodes manage shared state that persists throughout a flow execution, allowing you to reference and accumulate data as the flow progresses.

Why are they important?

Enterprise integrations require robust testing capabilities to simulate various input scenarios without connecting to live systems. Context management is essential for flows that process hierarchical data (like orders with line items) or need to accumulate information across multiple operations. Proper logging ensures production issues can be diagnosed quickly.

Node Summary

2. Source Node

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

Configuration Parameters

3. File Source Node

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 a flow that would normally be called through a Request/Response or would pull a file from an FTP you don't currently have access to.

Another useful feature is the ability to point it to a file directory, allowing you to simulate an integration that will later use some version of an FTP file folder setup.

Configuration Parameters

Supported File Encodings

4. Data Change Source Node

Fuuz is an event-driven architecture that allows you to listen on event streams for many different types. The Data Change Source node allows you to simulate data change events for testing, as the data change event stream is not started until you deploy the flow.

Data change events are emitted when a record in a data model is created, updated, or deleted. This allows you to perform real-time integration or business logic based on underlying data changes. The data models can include any system tables or custom tables you define.

Configuration Parameters

5. Preview File Node

The Preview File node allows you to download the payload input as a file. This is useful when creating CSV reports or Document Designer PDFs when you need to see the results during development. This node has no function when the data flow is deployed - it only works in the designer.

Configuration Parameters

File Content Transform Examples

JSON file: Use $jsonStringify(content) to convert the object to a string first.

PDF document: If the PDF was not returned Base64 encoded, call $base64encode(content) on the content string.

6. Log Node

The Log node allows you to log data within a flow when it is triggered. Logs are not created when the flow is run in the designer - they are only generated in deployed flows. The resulting logs are viewable from the Data Flow Logs grid.

Configuration Parameters

Log Levels

7. Echo Node

The Echo node is generally used for visual aesthetics and has no real functionality outside of passing input payload/context to output payload/context unchanged. When deployed, this node will continue to pass input to output.

This can be useful when using a Fork route that passes directly through, where you want something to visually appear in the middle of the flow for clarity.

8. Transition Node (DEPRECATED)

The Transition node often accompanied the Source Node at the start of a flow. By incorporating this node, you could pipe in the payload of the last flow execution as an output, which was useful in troubleshooting inputs and ETLs.

9. Set Context Node

The Set Context node is generally used at the start of a flow but can optionally be used to "Reset" the context at any point throughout the flow. The result of the transform completely replaces your existing context.

Use Case Example: You have Orders and Lines. You might start the flow storing orders in your context, but later query lines. Once you have the lines, you would want to merge the lines with the corresponding orders and then reset the context with that combined value. This way you aren't carrying order data separate from the orders and lines, which improves processing speed.

Configuration Parameters

10. Merge Context Node

The Merge Context node allows you to merge new values on top of existing values in the context. The node uses a deep merge to accomplish this.

Because this uses a deep merge, it allows you to merge data on top of data. This can be beneficial if you have an array of records that you want to add to. However, it can be problematic if you have an updated version of the same array, as it will add the new records on top. It does not do any intelligent merge to update records that already exist. Any time two properties align in name, the values will be merged with the new values overriding existing ones.

Configuration Parameters

Merge Example

Existing Context:

{
  "data": {
    "Parts": [{ "Part_No": "P123", "Revision": "A" }]
  }
}

Merge Transform:

{
  "data": {
    "Parts": [{ "Part_No": "A153", "Revision": "B" }],
    "Customer": { "name": "Acme Industries" }
  }
}

Result (both Parts arrays combined):

{
  "data": {
    "Parts": [
      { "Part_No": "A153", "Revision": "B" },
      { "Part_No": "P123", "Revision": "A" }
    ],
    "Customer": { "name": "Acme Industries" }
  }
}

11. Remove From Context Node

The Remove From Context node is often underutilized. It allows you to remove values from the context at any depth. It's best practice to remove values from the context that will not be re-used to speed up execution, as there is less data being transferred from node to node.

Configuration Parameters

Example

Transform:

["data.Parts"]

This removes the "Parts" property from "data" in the context.

12. Best Practices

Debug Node Standards

• Descriptions are important - use them to highlight specific test cases
• Test cases are required to prove testing prior to deployment
• Never directly log the input data in log message transforms
• Use appropriate log levels (Debug for routine items, Warn/Error for problems)

Context Management Standards

• Label everything in context with a wrapping variable - never set or merge context with a transform that is just "$"
• Use {"plexResponse": $} instead of $
• If context has unnecessary data, prune it prior to storage
• If context is large and no longer needed, remove it

13. Troubleshooting

14. Related Resources

• Data Flow Design Standards - Complete standards for flow development
• Flow Control Nodes Complete Guide - Error handling and flow structure
• Source & Trigger Nodes Complete Guide - Production triggers and listeners
• Data Flow Logs - Viewing and filtering production logs
• Platform Website: fuuz.com

15. Revision History