Difference between revisions of "Main nodes"
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The main nodes in order to draw a flow are: | The main nodes in order to draw a flow are: | ||
| + | [[File:mainNodes.png|thumb|{{GVESB}} Main nodes]] | ||
*Start Node: Represents the node of a flow started. | *Start Node: Represents the node of a flow started. | ||
| − | *Check Node: Is the node where {{GVESB}} makes decisions and determines what the next node to execute. Each Check node has a basic routing mechanism that chooses the | + | *Check Node: Is the node where {{GVESB}} makes decisions and determines what the next node to execute. Each Check node has a basic routing mechanism that chooses the next node only of the presence or absence of errors indicated by exceptions, also by right-you can edit operations condtion for routing and add to the flow. |
| − | next node only of the presence or absence of errors indicated by exceptions. | ||
*Wait Node: Allows you to insert delays in the execution of a stream. | *Wait Node: Allows you to insert delays in the execution of a stream. | ||
| Line 10: | Line 10: | ||
*Notification Node: It allows a notification to signal on the process flow.For each 'NotificationNode' is associated with a list of notifications (Notification) that handle the type of message to send and the medium on which to write the notification. ES: log4j, JMX. The order in which notifications are performed is the insertion order. A notification can be described as 'critical', which is vital for the proper execution of the flow. If a notification 'critical' throws an exception, the flow fails, and the exception is inserted into the buffer specified by the 'output' of NotificationNode. The NotificationNode not read an input buffer, as may be specified a different one for each notification. | *Notification Node: It allows a notification to signal on the process flow.For each 'NotificationNode' is associated with a list of notifications (Notification) that handle the type of message to send and the medium on which to write the notification. ES: log4j, JMX. The order in which notifications are performed is the insertion order. A notification can be described as 'critical', which is vital for the proper execution of the flow. If a notification 'critical' throws an exception, the flow fails, and the exception is inserted into the buffer specified by the 'output' of NotificationNode. The NotificationNode not read an input buffer, as may be specified a different one for each notification. | ||
| − | *ChangeGVBuffer Node: It lets you make a change in the data buffer. You can perform manipulations on the data buffer, set new properties or modify existing ones | + | *ChangeGVBuffer Node: It lets you make a change in the data buffer. You can perform manipulations on the data buffer, set new properties or modify existing ones using scripting languages such as JavaScript or OGNL.Using the right mouse button you can modify or add operations OutputServices. |
| − | using scripting languages such as JavaScript or OGNL. | ||
*SavePoint Node: DB allows you to save the state of execution of the workflow. They can also be stored business information in the form of name-value pairs. | *SavePoint Node: DB allows you to save the state of execution of the workflow. They can also be stored business information in the form of name-value pairs. | ||
*End Node: End the flow execution. | *End Node: End the flow execution. | ||
| + | |||
| + | =={{VULCON}} Configuration== | ||
| + | |||
| + | You might insert into your workflow one of the Nodes described above by drag and drop it into the {{VULCON}} Editor View. | ||
| + | |||
| + | When one of these nodes is inserted into the editor (excluding Start), a new element will appear into the {{L_VULCON}} Core View, under the element [[Flow]] (or [[SubFlow]]) of your Service [[Operation]]. The following table shows this: | ||
| + | |||
| + | {|class="gvtable" | ||
| + | ! Node !! GVCore element !! Description | ||
| + | |- | ||
| + | | Check || [[GVNodeCheck]] || Defines the nodes where {{GVESB}} makes decisions and determines which is the next node to execute. | ||
| + | |- | ||
| + | | Wait || [[GVWaitNode]] || Enters the delays in the execution of a workflow | ||
| + | |- | ||
| + | | Notification || [[GVNotificationNode]] || Indicates a notification on execution of the workflow. | ||
| + | |- | ||
| + | | ChangeGVBuffer || [[ChangeGVBufferNode]] || Allows to make a change to the data buffer. | ||
| + | |- | ||
| + | | SavePoint || [[GVSavePointNode]] || Saves flow state in DB. | ||
| + | |- | ||
| + | | End || [[GVEndNode]] || Ends the workflow execution | ||
| + | |} | ||
| + | |||
| + | {{VOTE}} | ||
Latest revision as of 19:48, 19 April 2012
The main nodes in order to draw a flow are:
- Start Node: Represents the node of a flow started.
- Check Node: Is the node where GreenVulcano® ESB makes decisions and determines what the next node to execute. Each Check node has a basic routing mechanism that chooses the next node only of the presence or absence of errors indicated by exceptions, also by right-you can edit operations condtion for routing and add to the flow.
- Wait Node: Allows you to insert delays in the execution of a stream.
- Notification Node: It allows a notification to signal on the process flow.For each 'NotificationNode' is associated with a list of notifications (Notification) that handle the type of message to send and the medium on which to write the notification. ES: log4j, JMX. The order in which notifications are performed is the insertion order. A notification can be described as 'critical', which is vital for the proper execution of the flow. If a notification 'critical' throws an exception, the flow fails, and the exception is inserted into the buffer specified by the 'output' of NotificationNode. The NotificationNode not read an input buffer, as may be specified a different one for each notification.
- ChangeGVBuffer Node: It lets you make a change in the data buffer. You can perform manipulations on the data buffer, set new properties or modify existing ones using scripting languages such as JavaScript or OGNL.Using the right mouse button you can modify or add operations OutputServices.
- SavePoint Node: DB allows you to save the state of execution of the workflow. They can also be stored business information in the form of name-value pairs.
- End Node: End the flow execution.
VulCon Configuration
You might insert into your workflow one of the Nodes described above by drag and drop it into the VulCon Editor View.
When one of these nodes is inserted into the editor (excluding Start), a new element will appear into the VulCon® Core View, under the element Flow (or SubFlow) of your Service Operation. The following table shows this:
| Node | GVCore element | Description |
|---|---|---|
| Check | GVNodeCheck | Defines the nodes where GreenVulcano® ESB makes decisions and determines which is the next node to execute. |
| Wait | GVWaitNode | Enters the delays in the execution of a workflow |
| Notification | GVNotificationNode | Indicates a notification on execution of the workflow. |
| ChangeGVBuffer | ChangeGVBufferNode | Allows to make a change to the data buffer. |
| SavePoint | GVSavePointNode | Saves flow state in DB. |
| End | GVEndNode | Ends the workflow execution |
{{#w4grb_rate:}} <w4grb_ratinglist latestvotes items="5" nosort/>
