Introduction

This reference is addressed to developers who want to create or edit Intershop 7 pipelines using Intershop Studio's Pipeline Editor.

This pipeline deals with the reserved pipeline nodes which serve as flow control nodes provided by the Pipeline Framework.

Reference

For more information about pipeline nodes which are not provided by the Pipeline FW see:

Concept - Pipeline Nodes

For mor information about pipelets see:

Concept - Pipeletsas well as the according chapter in the Application Programming Guide.

Pipeline Components Palette

Pipelines are composed of pipelets, pipeline nodes and flow control nodes. While the pipelets perform the business logic, the flow control nodes are the decisive marking points in the pipeline flow. All available pipeline elements are displayed in the Pipeline Components palette of the Pipeline Editor. All pipeline nodes are linked by transitions, symbolized by arrows leading into and out of the nodes. The point at which a transition touches a node is symbolized by a small circle, called a connector.

Properties of Pipeline Nodes

A pipeline node's properties are displayed and edited in the Properties View. To view all properties:

1. Navigate to toolbar of Poperties tab.
2. Select Filters icon.
   Selection Needed dialog starts.
3. Deselect all filters.
4. Confirm dialog with OK.
   Poperties view displays all properties unfiltertered.

Start Node

Start nodes begin pipelines.

Start nodes have the following behavior and qualities:

• A start node is required to launch any pipeline.
  A given pipeline may also have multiple start nodes. Each start node within a pipeline must have a unique name.
• A start node gets the pipeline dictionary initially from the pipeline processor, or gets an existing pipeline dictionary of a sub-pipeline (see Call Nodeor Jump Node).
  A sub-pipeline is one that is called from within another pipeline, like a subroutine. Any changes the sub-pipeline makes to the pipeline dictionary affects the dictionary of the calling pipeline directly (except the start node is defined strict).
• The start node name is used to identify the wanted pipeline.
  For example, AddToBasket-Start calls the start node Start of the pipeline AddToBasket.
• If parameters are passed to a pipeline via an HTTP request, these parameters, i.e., key names, can be defined in the start node properties.
  If a pipeline is called as a sub-pipeline (using a Call Node), then all dictionary values of the calling pipeline which are accessed by the sub-pipeline can be declared as start parameters.

Start nodes have the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Name (required)

An external identifier for the start name; must be unique within the pipeline.

Session Mode (required; value = persistent | transient | volatile)

Defines a session type for the pipeline.
Persistent sessions write session information to the database, and therefore have session fail over. If the server should stop during a session, the information is still available. Persistent sessions are used in pipeline activity occurring on the application server. User login, ordering, payment, etc., require a persistent session with information written to the database.

Transient sessions hold data in memory, but do not write it to the database. This means that pipelines in the transient mode do not have session fail over. A transient session would be used, for example, when an unrecognized user
browses a catalog. Transient sessions can be upgraded to persistent sessions; for example, once the user stops browsing anonymously and logs in.
Volatile sessions are equivalent to not using a session at all; they start and stop the session within the course of the pipeline.

Call Mode (required; value = public | private | include)

Controls the way a pipeline may be accessed via this start node.
Public mode permits access from an external source using (for example) HTTP requests. Public start nodes are marked with a little globe.

Starting with Intershop 7.4 ( and the associated Intershop Studio 4.3.3) public start nodes have the option Secure. If this flag is set, the server only accepts secure HTTPS connections. Secure start nodes are decorated with a small key image in all Intershop views as well as in the Visual Pipeline Editor.

Private mode permits access from an internal source such as another pipeline, using call or jump nodes.
Include mode allows access via remote include calls (Web Adapter includes, <WAINCLUDE>).

Strict

Strict pipelines will not pass the entire pipeline dictionary.
Strict start nodes define their required input parameteters. In this way, quasi an interface is created. Thus, the reuse is improved.

Visibility

The visibility setting offers a possibility to restrict availability of the pipeline node. This setting is not supported yet.

Parameters

Parameters tab allows to manage node's parameters. Via parameters tab, parameters can be created, added, removed and sorted.

Permissions

This security setting determines what permissions a user must have to call this pipeline.

Error Node

Error nodes are special start nodes with name Error. Error nodes are used to define pipeline-specific error pipelines.

Error nodes have the following proprties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Name (required)

Required: Name has to be "Error".

Session Mode (required; value = persistent | transient | volatile)

Defines a session type for the pipeline.
Persistent sessions write session information to the database, and therefore have session fail over. If the server should stop during a session, the information is still available. Persistent sessions are used in pipeline activity occurring on the application server. User login, ordering, payment, etc., require a persistent session with information written to the database.

Transient sessions hold data in memory, but do not write it to the database. This means that pipelines in the transient mode do not have session fail over. A transient session would be used, for example, when an unrecognized user
browses a catalog. Transient sessions can be upgraded to persistent sessions; for example, once the user stops browsing anonymously and logs in.
Volatile sessions are equivalent to not using a session at all; they start and stop the session within the course of the pipeline.

Call Mode

Error nodes should be private to disallow external access.

Strict

Strict pipelines will not pass the entire pipeline dictionary.
Strict start nodes define their required input parameteters. In this way, quasi an interface is created. Thus, the reuse is improved.

Visibility

The visibility setting offers a possibility to restrict availability of the pipeline node. This setting is not supported yet.

Parameters

Parameters tab allows to manage node's parameters. Via parameters tab, parameters can be created, added, removed and sorted.

Permissions

This security setting determines what permissions a user must have to call this pipeline.

End Node

End nodes are used to end pipelines and sub-pipelines without invoking a template.

End nodes do not clear the pipeline dictionary, and are thus often used to end subpipelines. Sub-pipelines usually end with end nodes; storefront pipelines always end with an interaction node or a jump node.
The end node name property gives each end node a unique identifier. It is used in the case of a sub-pipeline with branches that result in multiple end nodes (see Call Node). The end node name property is also used in conjunction with debugging pipelines.

End nodes have the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Name

The name is an identifier that can be used multiple times within a pipeline.

Strict

Strict pipelines will not pass the entire pipeline dictionary.
Strict start nodes define their required input parameteters. In this way, quasi an interface is created. Thus, the reuse is improved.

Return Value

For strict end nodes: defines which return values are returned in the pipeline dictionary.

Stop Node

A stop node ends the execution of a pipeline.

It is used to handle error conditions in a sub-pipeline that require all calling pipelines to also be aborted. Transactions are rolled back when a stop node is encountered.
A stop node functions as an emergency break since it ends all pipelines. Conversely, end nodes only stop the execution of the sub-pipeline, and processing continues one level higher, in the calling pipeline. Without using a stop node, the same result can only be achieved by throwing an exception from within a pipelet.

Decision Node

A decision node compares two values in the pipeline dictionary or checks for a value in the pipeline dictionary. The result directs the flow of the pipeline into a yes branch or a no branch.

Decision nodes work with key-value pairs in the pipeline dictionary to direct the pipeline flow in two branches, based on whether the result is true( yes branch) or false( no branch).

For example, a decision node might check whether the payment status of an order is authorized. If the status is 1, authorized, the yes branch is used and the pipeline continues, e.g., the shipping status might be checked next. If the status is 0, not authorized, the no branch is used (for example, a message may be called to alert the user that payment has not been authorized).
Decision nodes can check for the existence of any values, whether simple strings or complex objects. They can also compare values that are stored as simple strings or Java number objects.
A decision node is labeled automatically by choosing its operator.

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Condition Key (required)

The dictionary key to compare.

Condition Item (required)

Enter the name of a dictionary key in this field to compare its value with the condition key value in the pipeline dictionary. If the key does not exist in the pipeline dictionary, a PipelineExecutionExeption is thrown.

Condition Value

Enter a value in this field to be compared with the value associated with the key specified in the condition key field.

Operator

Use one of the following operators:

Loop Node

Loop nodes are used to perform logic on all objects in an iterator. The iterator has already been stored in the pipeline dictionary.

• Entry Point
  The entry point of the node, marked by the arrow pointing on the outer element takes the first element from the iterator and stores it in the Element dictionary key. The DO transition is then followed.
• DO (green circle)
  The transition from the DO connector (green circle) performs the desired logic on the element and then leads back to the loop node through the LOOP connector.
• LOOP
  LOOP connector, represented by the arrow pointing on the inner element, checks the iterator to see if any elements remain to be iterated through. If so, the next element from the iterator is stored in the Element dictionary key and
  the DO transition is followed. If not, the NEXT transition is followed.
• NEXT
  This transition is followed in order to end the loop once all the elements in the iterator have been run through, at which point the iterator is reset to the first element. The NEXT connector is represented by the yellow circle.

A Loop node has the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

General | Loop

The name of the iterator that is stored in the pipeline dictionary.

Loop Entry

The current element is written to this key during each iteration of the loop.

Interaction End Node (Interaction Node)

The interaction nodes (continue and end) are used to call a storefront template at a particular point in a pipeline. We recommend using interaction end nodes exclusively, as interaction continue nodes cannot be made session fail over-safe.

Interaction end nodes have the following qualities and behaviors:

• Interaction end nodes call a storefront template to be displayed.
• Interaction end nodes can display templates with known names or the template may be dynamic, i.e., showing different templates depending on the circumstance.
• The pipeline always ends and the pipeline dictionary is cleared after an interaction end node.
  Compare this with the behavior of interaction continue nodes (see Interaction Continue Node).

Interaction end nodes have the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Template

Referenced Name: required for non-dynamic template. To use this option, the template must have a constant name that is always used.
Object Path: required for dynamic templates. Use this option if the template to be used is based on variable data determined by the selected pipeline.

Interaction Processor

Choose from HTMLInteractionProcessor or XMLInteractionProcessor. By default, HTML processing is selected.

Dynamic (value = true | false)

Choose false if the template to be called is known; that is, the same template is always used and does not depend on variable information determined by the pipeline (see Template | Referenced Name above).
Choose true if the template to be used is based on variable information determined somewhere else within the pipeline dictionary. For example, if a template is selected by the method SetDynamicTemplate.

Buffered Template (value = true | false)

Defines the way the Web adapter delivers templates, either in buffered or streamed mode.
The default is buffered mode (true).
In order to save system memory, enable streaming mode by setting this property to false.
Also, for templates that rely on the output from XML pipelines for catalog data, or for templates with a lot of content, the streamed response delivered instantaneously improves storefront response time compared with the buffered
default option.

Transaction Required (value = false | true)

Transaction in this context refers to a specified database transaction. Generally, transactions are specified either within pipelets or placed on connectors; they are very rarely used directly within templates.
Choose false for most situations. This is also the default value.
Choose true if a new database transaction is opened within the template itself. An example for this kind of behavior would be a template containing JavaScript code that requires writing data to the database. However, adding this kind of logic to templates is not encouraged in general.

Interaction Continue Node

Interaction continue nodes invoke templates just as interaction end nodes do. However, note the following important caveat:

Interaction continue nodes have the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Template

Referenced Name: required for non-dynamic template. To use this option, the template must have a constant name that is always used.
Object Path: required for dynamic templates. Use this option if the template to be used is based on variable data determined by the selected pipeline.

Interaction Processor

Choose from HTMLInteractionProcessor or XMLInteractionProcessor. By default, HTML processing is selected.

Dynamic (value = true | false)

Choose false if the template to be called is known; that is, the same template is always used and does not depend on variable information determined by the pipeline (see Template | Referenced Name above).
Choose true if the template to be used is based on variable information determined somewhere else within the pipeline dictionary. For example, if a template is selected by the method SetDynamicTemplate.

Buffered Template (value = true | false)

Defines the way the Web adapter delivers templates, either in buffered or streamed mode.
The default is buffered mode (true).
In order to save system memory, enable streaming mode by setting this property to false.
Also, for templates that rely on the output from XML pipelines for catalog data, or for templates with a lot of content, the streamed response delivered instantaneously improves storefront response time compared with the buffered
default option.

Transaction Required (value = false | true)

Transaction in this context refers to a specified database transaction. Generally, transactions are specified either within pipelets or placed on connectors; they are very rarely used directly within templates.
Choose false for most situations. This is also the default value.
Choose true if a new database transaction is opened within the template itself. An example for this kind of behavior would be a template containing JavaScript code that requires writing data to the database. However, adding this kind of logic to templates is not encouraged in general.

External Name (Required)

Assign a unique name to the start portion of the interaction continue node. On the workspace, this name is joined with the name of the template. When template designers program a URL call to this node, they use the pipeline name
with the start name.

Session Mode (required; value = persistent | transient | volatile)

Defines a session type for the pipeline.
Persistent sessions write session information to the database, and therefore have session fail over. If the server should stop during a session, the information is still available. Persistent sessions are used in pipeline activity occurring on the application server. User login, ordering, payment, etc., require a persistent session with information written to the database.

Transient sessions hold data in memory, but do not write it to the database. This means that pipelines in the transient mode do not have session fail over. A transient session would be used, for example, when an unrecognized user
browses a catalog. Transient sessions can be upgraded to persistent sessions; for example, once the user stops browsing anonymously and logs in.
Volatile sessions are equivalent to not using a session at all; they start and stop the session within the course of the pipeline.

Call Node

Call nodes allow a pipeline to use other pipelines and maintain a single pipeline dictionary. When a call node is used, the called pipeline is executed and completed, then processing returns to the call node in the original pipeline and continues.

Call nodes have the following qualities and behaviors:

• A call node invoke another pipeline from within a pipeline.
  When this relationship between the two pipelines is established, the called pipeline is referred to as a sub-pipeline. Double-click a defined call node to open the target pipeline in a new editor window.
• Multiple call nodes and calls in sub-pipelines can be used.
  The execution flow always runs through the sub-pipeline, then returns to the call node and continues through the calling pipeline.
• Call nodes can have multiple exit points.
  A sub-pipeline that branches can end its execution at different end nodes which each have a unique name (see End Node ). A call node can have multiple exit points which represent these different end nodes.
• Call nodes must have the pipeline and start node name of the called pipeline defined in the node's Properties View.
• For security reasons, by default, dynamic call nodes are only allowed to call public start nodes. If you want to call a private start node, you need to explicitely grant this right to the call node.

The following image illustrates the data flow through Called Pipelines

Call nodes have the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Start Node (Property)

Referenced Name: required for non-dynamic start node. To use this option, the start node must have a constant name that is always used.
Object Path: required for dynamic start node. Use this option if the start node to be used is selected based on variable data determined by the selected pipeline.

Parameter Bindings

The values assigned to parameters.

Return Value Bindings

The values assigned to return values.

Extension Point Node

An Extension Point Node allows to extend a pipeline with extension pipelines from other cartridges.
A extension point node belongs to the family of call nodes. A extension point node must be added to the pipeline you want to extend.

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Extension Point ID

The ID of the extension point (alphanumeric string).

The name should point out when an extension point is called.
To ensure that it is clear to the developer when a certain extension point is called it should meet following naming conventions:

• Apply a meaningful and unique name.
• Use the infinitive if the extension point is called before the certain action is performed.
  E.g. ArtifactCreate
• Use the present participle if the extension point call is done within an transaction.
  E.g. ArtifactCreating
• Use the simple past form when the extension point invocation is done after the action was completed.
  E.g. ArtifactCreated
• Avoid using EP or Extension within the name.

Strict

You can make an extension point node strict. A strict extension point node defines, which parameters are passed to the extension pipeline.

• Required Parameter
  A required parameter will always be available.
• Optional Parameter
  Optional parameters may not exist when calling the extension pipeline.

Parameter Bindings

The values assigned to parameters.

Return Value Bindings

The values assigned to return values.

Jump Node

Jump nodes are used to jump the business flow from one pipeline to another, without losing the pipeline dictionary. The difference between call and jump nodes is that jump nodes do not return the business flow to the original pipeline.

Jump node properties are defined very similar to call node properties. Jump nodes have the following qualities and behaviors:

• Jump nodes transfer the business flow from one pipeline to another while maintaining the active pipeline dictionary.
• Like call nodes, jump nodes must have the pipeline and start node name of the called pipeline defined in the node's Properties View.
  See Call Node.
• For security reasons, by default, dynamic jump nodes are only allowed to call public start nodes. If you want to call a private start node, you need to explicitely grant this right to the jump node.
• Double-click a defined jump node to open the target pipeline in a new editor window.

Join Node

Join nodes bring together two or three flows of a pipeline.

For example, an order pipeline may use a decision node in confirming the user registration. If the user is registered, the pipeline continues; if not, the pipeline can register the user and then continue placing the order. A join node can bring the no branch back to the order creation part of the pipeline.

Transitions

Transitions are the arrow symbols connecting nodes and pipelets together in the workspace. Transitions can be used to set a database transaction explicitly at a particular point in a pipeline.

Transitions have the following properties:

Description (optional)

A descriptive text that you can maintain for your own documentation purposes.

Qualified Name

Transaction automatically get a qualified name composed by the pipeline name and the name of the preceding node or its connector.

Transaction Handling (Optional)

Used to set explicit database transactions. The possible settings are summarized in the following table.

Connectors

Connectors are the points where transitions enter or exit a node or pipelet, and are symbolized by small circles or the node itself.

Every node except the start node has at least one entry point, represented by the node/pipelet itself; every node except the end node, jump node, and interaction end node has at least one exit point (next).

Disconnected connectors are shown as empty circles. Connected connectors are shown as a filled circle. Error connectors and "no"-next-successors of decision-nodes are shown in red. Loop entry's next connectors are shown in green. Pipelet default connectors are shown in blue.