How to on Best Practices for Designing Flows in Fuuz

How to on Best Practices for Designing Flows in Fuuz

The following list of standards is a listing of requirements that must be completed prior to deploying a Data Flow in Fuuz.

Note: Violations are OK while working on flows — just resolve them all prior to requesting a production deployment.

The intent of all these standards is to:

1. Improve the consistency of flow designs
2. Provide inline documentation for future reference
3. Increase the efficiency of support by others that haven't been involved
4. Track all changes for visibility

Naming

Naming the flow is super important. The format is as follows:

{#1 Primary Fuuz Object} {#2 direction or verb(s)} {#3 External Platform} {#4 Name of Primary External Object} {#5 Event Type}

1. The primary Fuuz Object data is being pulled from or pushed into
2. "From", "To", or verbs like "Badge In/Out" or "Workcenter Mode on Data Change"
3. "NetSuite", "Plex", "Plex (API)", "QuickBooks", "RedZone", etc. (Note: Plex and Plex (API) are very different sources)
4. "Bin", "Location", "Ledger" (only required if the Fuuz Object is not the same)
5. "on Data Change" (this is the only event type that is currently required)

Examples:

• Locations From NetSuite Bins — a standard integration that sends locations to Fuuz from NetSuite's list of Bins.
• Locations To NetSuite Bins on Data Change — a standard integration that sends locations to NetSuite's list of Bins from Fuuz when updates are captured with data change events.
• Facilities from NetSuite Locations — another integration from NetSuite, highlighting that our objects don't line up with NetSuite.
• WorkOrder Process Defaults From Fuuz Default Product Strategy Processes on Data Change — prepopulates WorkOrder Process records with a copy from the default Product Strategy Process tables on a data change event, specifically the "add" event.

Important: Renaming a flow doesn't change the flow's ID. If you need to rename the flow, you will need to export the contents into an empty flow with the new name.

Documentation

1. Every flow needs a meaningful description of what it does, including connections used and an overall summary.
2. Every version needs a description of the changes being made. If you make additional changes after setting the initial description, please update it.
3. Every node needs a meaningful description. Period. No exceptions.
4. Every flow must have a walkthrough.
5. Every walkthrough must include all nodes in logical order.
6. This walkthrough will be used during the review and deployment process.
7. Take note: the configured walkthrough is stored directly inside the flow. You must save the flow after configuring the walkthrough.

General

1. All nodes must have a unique and meaningful name (think about error log messages in the future).
2. Nodes cannot use the default name, even if that name is unique.
3. All nodes with a connection on the left-hand side must be connected to another node.

Debug Nodes

1. Descriptions are important — use them to highlight specific test cases.
2. Test cases are required to prove your testing prior to deployment.

Conditionals

1. Conditionals should be very descriptive.
2. Conditionals cannot use double negatives (e.g., $not(false)).
3. It is strongly recommended to use If/Else in most situations, even if the else condition goes nowhere.
   • Note: if this recommendation results in a double negative to continue on a true path, consider using the else path instead.

Context

1. Label everything in context with a wrapping variable. Never set or merge context with a transform that is just $ — instead use {plexResponse: $}.
2. If your context has a lot of unnecessary data, prune it prior to storage.
3. If your context is large and is no longer needed, remove it.

Important: Context is shared with each node downstream. Forks and broadcasts will significantly increase memory usage by a factor equal to the number of concurrent transactions. It is very important to keep a clean context with only what you need during these situations.

Flow Control

1. Broadcasts are dangerous — in most cases there is another way to solve the problem.
2. Keep in mind the nesting limitations of a flow; broadcasting more broadcasts quickly burns up your resources and will cause errors.

Events

1. All flows with a Request node must have at least one Response node.
2. Data Changes can trigger a lot of flows; they should be followed immediately by a conditional statement to reduce executions.
3. Topics, publishing, and subscribing are the preferred method of handling pagination of large data sets.

Integration

1. The name of the node must indicate what it is calling (e.g., "Calling Plex DS - POs_Get (key:12345)").
2. The description of the node must include the parameters and a description of the intent (e.g., "Pulling POs with status of Open").
3. $integrate() is highly discouraged in transforms and will most likely be deprecated next year. (The intent is to make all outbound calls pink in color for easier reference.)
4. It is highly recommended that a native node is used over the HTTP node (e.g., don't use HTTP to call Salesforce unless the Salesforce node doesn't meet your needs).

IIOT

1. Communication with the Edge Gateway can be time consuming; it is recommended that tag reads triggered by a flow read multiple tags at once.

See Also

• Data-Flow-Design-Standards-Design-Standards
• Data-Flow-Nodes-Reference
• Flow-Control-Nodes
• Integration-Nodes
• Debugging-and-Testing-our-Fuuz-Data-Flows

---

Source: support.fuuz.com