Index Pipeline stages are used to create and modify PipelineDocument objects. Query Pipeline stages are used to modify Request objects and Response objects.

​
Pipeline stage properties

Fusion associates a pipeline stage definition with a unique ID and stores the definition so that stages can be reused across pipelines and applications. In addition to an ID, all stages have the following properties:
  • type (required): an enumeration, one of the defined Fusion pipeline stage types, e.g., “index-logging”. If the Fusion UI is used to define the stage, this property is filled in automatically.
  • label (optional) : a string field with a maximum length of 255 characters. The label is displayed on the Fusion UI.
  • skip (optional): a boolean value, If true, pipeline processing bypasses this stage altogether. The default is false.
  • condition (optional): a JavaScript expression that evaluates to true (1) or false (0).
    If this condition evaluates to false, this stage is skipped. The default is true.

​
Pipeline condition expression

The JavaScript expression specified in the condition property of a pipeline stage has access the pipeline objects.

​
Index pipeline stage condition example

An index PipelineDocument has two available variables: “doc” and “ctx”. Check whether pipeline document contains a named field: 
doc.hasField("acl_ss")

​
Query pipeline stage condition examples

Run this stage only for mobile clients: 
params.deviceType === "mobile"
Run this stage when debugging is enabled: 
params.debug === "true"
Run this stage when the query includes a specific term: 
params.q && params.q.includes("sale")
Run this stage when multiple conditions are met: 
request.hasParam("fusion-user-name") && request.getFirstParam("fusion-user-name").equals("SuperUser");
!request.hasParam("isFusionPluginQuery")
The first condition checks that the request parameter “fusion-user-name” is present and has the value “SuperUser”. The second condition checks that the request parameter “isFusionPluginQuery” is not present.

​
Run stages asynchronously

Some stages allow for asynchronous processing for work that may take a while, keeping the overall pipeline moving. Fusion does not block the request thread while the stage is waiting. Instead, it waits for the stage’s result right before it needs it to finish the response.

​
When to use asynchronous processing

Use asynchronous processing for the following:
  • A stage calls out to a remote system.
  • The stage reads or writes large files or blobs.
  • The stage can run in parallel with other stages.
Use synchronous processing for the following:
  • The stage does only local work and typically finishes in under a couple of milliseconds.
  • The stage coordinates tasks that must happen one at a time.

​
Benefits of asynchronous processing

Asynchronous processing allows:
  • Lower latency by overlapping slower calls with other work.
  • Greater resilience because if one asynchronous call is slow or errors out, Fusion can time it out without stalling the whole pipeline.
  • Easier error recognition and resolution because timeouts and cancellations are scoped to the stage.