The concept of flow
All the elements of the HTTP request constitute the processing flow. The starting point of the processing of this flow is represented by the black circle at the start of the Workflow.
The path of the flow is represented by the arrows in the graph. The flow will be analyzed, processed, and/or modified as it traverses each node, then sent to the final server.
The Workflow is a flow-processing tree that we manipulate in graphical form.
Thus you can represent the data flow – that is, a request – in the form of attributes and tables of attributes (e.g.: http.request.uri). But you can also use Workflow processing objects like conditions, modifications, deletions and additions. These objects are generically called nodes.
A node is the equivalent of a function or a processing instance. It has input attributes and output attributes. The output attributes will enrich the processing flow and will be available for subsequent nodes.
To see the list of required input attributes and attributes provided as output, click on the square in the node at right.
Once the node is deployed, in the upper part we can see the attributes necessary for processing. Any missing attribute is shown in red.
The concept of Attribute
An attribute is a typed value, available in the processing flow.
The possible types of attributes are:
- Character string (S: String)
- Boolean (B: Boolean)
- Table (T: Table)
- XML document (X: XML)
- Internal (I: Internal)
The symbol for the type of the attribute is shown at the left of each attribute.
In the lower part is the list of the attributes the node will add to the processing flow.
There are predefined nodes that can be used, among other purposes, to create or modify attributes (and thus manipulate the request); make decisions (to continue execution on one branch or the other of the tree as a function of logical tests on the attributes); send a response to the client or send its request to the backend (after any modification); manipulate client/backend session cookies; parse XML, then validate it (WSDL, schemas) or extract data from it (XPath) in attributes; perform predefined filtering or several personalized filterings of the request with the ICX engine; launch predefined or personalized alerts; manipulate data from X509 certificates; launch HTTP or LDAP subrequests (by processing the response in the form of attributes); associate shared data with a simple key or a user session and use it to process the subsequent requests (possibly in other tunnels), etc.
There are also other more specific predefined nodes such as virtualization / encryption / verification of backend cookies, verification of the client request and/or the backend’s response by an ICAP server, limiting of requests for a given user (identified by his/her IP address, session, or other), verification of form data in read-only mode generated by the backend (Form Field Tracking), detection of changes in static backend pages, configuration or creation of authentications usable by the WAM engine, etc.
Finally, you can create your own nodes (called sub-Workflows) which use predefined nodes or other sub-Workflows to perform specific processing, with a configurable interface (parameters, inherited attributes), and are therefore reusable at several points in the same Workflow or in several Workflows.
The list of nodes is available here: Workflow nodes
Main Workflow and sub-Workflow
There are two types of Workflow: main and sub-Workflow.
A main (root) Workflow can be assigned to a Tunnel; it contains the nodes applied to the request, which can be predefined nodes (by category), or else sub-Workflows (predefined or created).
A sub-Workflow can only be called from another Workflow or a sub-Workflow; it serves to group a (logical) sequence of nodes together.
It can require input parameters and/or attributes, manipulate them, and make decisions in response to them.
It can also provide output attributes, which can be processed by the calling Workflow.
The attributes required and/or provided by the sub-Workflow are called the interface of the sub-Workflow.
Specific case: Response-type sub-Workflows
When a sub-Workflow, classified in the Response category, is used in a Workflow or another sub-Workflow, the calling Workflow continues execution of its nodes after the call to the Response sub-Workflow.
When a sub-Workflow is not classified in the Response category and it generates a response (Proxy Request, Generate Response, SOAP Fault Response) or calls another sub-Workflow which generates a response, execution will be interrupted at the exit point of this sub-Workflow and the response will be sent immediately to the client.