Navigation-Concept

From GeoMedia Smart Client
Jump to: navigation, search
Workflows Overview Editor Settings Design API Changes Navigation Concept JavaScript API



This section tries to "translate" the theory from the preceding chapters into a practical example. The starting point is the concept of navigation in workflows, which is followed by an explanation of controllers. The implementation of triggers and a sample-workflow finish this chapter. The Java application "Workflow-Editor" will be used to generate this workflow.


The "flow" through workflows depends on the controller defined in the XML Workflow file. There are several possibilities for routing a user through a workflow. The navigation through a workflow can roughly be divided into two basic approaches: 1. Navigation via Workflow-Nodes (childnodes) and related controllers 2. Navigation via buttons (FormAction - elements)


Ad 1. - Navigation via Workflow-Nodes Three standard controllers can be defined inside the WorkflowSettings.xml at the Workflow-Node element, which are:

  • Controller = "Workflow": This is the default controller (which is used if no controller is defined explicitly).
  • Controller = "List": This controller opens a set of records displayed in list form; the columns of the list are definable.
  • Controller = "Form": This controller opens a table-record ready for editing.


Ad 2. - Navigation via buttons The navigation-concept via buttons is defined inside the FormSettings.xml at the FormAction element.




Pfeil new.png To the top Pfeil new.png

"Workflow"-Controller, Routing Behavior and triggers

When a Workflow-controller is deployed, the form attribute must not be set. Starting from a "root" node, a Workflow-controller can branch out into two possible directions, depending on optional conditions which have to be passed:

a) n>1 child nodes that are visible (and pass a potential condition): The child nodes are displayed in a list.

0701 workflow controller 1.png


b) exactly n=1 child node (which passes a potential condition): The Workflow skips the display of this single node in a (one-element) list and redirects further to this child node. The child node can be another list of WorkflowNodes or a single Workflow-Node which includes a form attribute (form="TABLENAME") and, therefore, displays this table as a form or list.


0701 workflow controller 2.png

0701 workflow controller 3.png

Short comment on conditions at Workflow-Nodes: There are two types of conditions at Workflow-Nodes:

  • static conditions:
a static condition looks like
 condition = "true"



This is the default case (and therefore does not need to be defined explicitly).
  • dynamic conditions:

A common practice in evaluating a "dynamic" condition at a Workflow-Node is by using an SQL statement with a DECODE or CASE inside which delivers 0 or 1. A possible sample might look like:

condition = "SQL[SELECT DECODE(COUNT(*),0,1,0) FROM PR_OPERATION_UNIT WHERE OPERATION_ID={FORM.OPERATION_ID} AND {FORM.TEMPLATE_GUID} IS NULL]"



Other possibilities for evaluating can be defined programmatcally or via SESSION-Keys (refer to ):

       condition = "OBJECT[...]"
or
       condition = "SESSION[KeyExists()]"

Triggers on Workflow-Nodes with Workflow-controller:

Workflow-Triggers can be defined for Workflow-Nodes (with controller="Workflow"); they must have the method="after" attribute set. A Workflow-Trigger might look like the following:

  1. <WorkflowNode controller="Form" emptyform="true" form="INCIDENT" id="11" label="Create Incident">
  2.  <WorkflowNode id="110" label="Assign Tasks">
  3.    <WorkflowTrigger condition="SQL[Select count(*) FROM INCIDENT1 WHERE RPI_ID={SESSION.INCIDENT1.RPI_ID} AND GEOMETRY IS NULL]" method="after" name="UPDATE"
  4.     type="SqlTrigger">
  5.       <Param name="Sql" value="SQL[UPDATE INCIDENT1 SET GEOMETRY=SDO_GEOMETRY(2001,NULL,SDO_POINT_TYPE(X, Y, NULL),NULL,NULL) WHERE RPI_ID={SESSION.INCIDENT1.RPI_ID}]"/>
  6.           </WorkflowTrigger>
  7.    <WorkflowNode condition="SQL[Select count(*) FROM INCIDENT1 WHERE RPI_ID={SESSION.INCIDENT1.RPI_ID} AND TYPE_ID=7]" id="1100" label="Abandoned Vehicle">
  8.      <WorkflowNode controller="Form" emptyform="true" follownode="120" form="VEHICLE" id="11001" label="Vehicle details">
  9.      ...
  10.      </WorkflowNode>
  11.      ...
  12.    </WorkflowNode> 
  13.    ...
  14.  </WorkflowNode>
  15.  ...
  16. </WorkflowNode>


The behavior is the following:

  • The user uses the INCIDENT form to create an incident; then the user clicks Save.
  • Now the Workflow-Node id="110" is accessed (it is the only node at this level; therefore, the node is "skipped") and then the Workflow-Trigger is accessed.
  • If the condition evaluates to true (which means that, if the geometry has not been set until now, the Param-Tag is accessed and the UPDATE is performed).
  • Now the Workflow-Node id="1100" is accessed (it is the only node at this level; therefore, the node is "skipped") and then the Workflow-Node id="11001" is accessed.
  • ...



Pfeil new.png To the top Pfeil new.png

"List"-Controller, Routing-Behavior and triggers

When a List-controller is deployed, the form attribute must be set to specify the referenced table. The Workflow-Engine then selects the data from this table and shows the content of defined columns in a list. The definition of the column-visibility in the list is defined within the FormSettings.xml at the "FormField" with visible = "form,list" (or just visible = "list" if the column will only be visible at list-level, but not inside the form).

When selecting one list-row, the engine stores the ID-value of this row in the Table SEC_SESSION as parameter {SESSION.TABLENAME.IDFIELD}, for example, {SESSION.PR_AGENCY.ID}, and it redirects to the next Workflow-Node.


The selected row of a list can be referenced from the FormSettings.xml by {ROW.ID}; the visibility of this FormAction is defined as list[ROW], which means that the specified action (button) is available for each list-entry.

Edit list buttons.png

 <FormAction name="EditSymbology" label="Edit" action="SCRIPT[IG.loadSymbology({ROW.ID})]" type="row" image="ig-icon-edit" submit="false">


Using the controller="List", the workflow can branch out into three different directions:

a) If the attribute Follownode on the list-node is specified, the engine redirects directly to this follownode (for example, follownode="220").

b) n>1 child nodes that are specified below the current Workflow-Node (which holds the control form="list"); the child nodes are displayed in a list.

Example:

<WorkflowNode id="120" label="Overview Organisations" controller="List" form="AGENCY"  condition="true" >
    <WorkflowNode id="1210" label="Edit Organisation" controller="Form" form="AGENCY"  condition="true" >
    </WorkflowNode>
    <WorkflowNode id="1220" label="Delete Organisation" controller="Form" form="AGENCY"  condition="true" >
    </WorkflowNode>
</WorkflowNode>



c) n=1 child node that is specified below the current Workflow-Node (which holds the control form="list"); the engine redirects directly to this node (which again might be a form- or a list-controller).

Example:

<WorkflowNode id="120" label="Overview Organisations" controller="List" form="AGENCY"  condition="true" >
    <WorkflowNode id="1210" label="Edit Organisation" controller="Form" form="AGENCY"  condition="true" >
    </WorkflowNode>
</WorkflowNode></nowiki>



The Display-Behavior inside a List-controller can also be extended in the FormSettings.xml by using FormAction elements:

  • action="filter": Implements a filter-functionality in the List-View
  • action="clearfilter": Implements a clearfilter-functionality in the List-View


Blue.png The Routing-Behavior inside a List-controller can also be extended in the FormSettings.xml by using FormAction elements and by using an action="redirect" attribute.



Triggers on Workflow-Nodes with List-controller: Workflow-Triggers can be defined for Workflow-Nodes (with controller="List"); they must have the method="after" attribute set. The trigger will be executed after the selection of a row in the list, but before the access of a subsequent Workflow-Node. A Workflow-Trigger might look like the following:


<WorkflowNode id="100" label="Einsatzliste" controller="List" form="PR_EVENT_V" condition="true" showworkflowlinks="false" view="EventList">
    <WorkflowTrigger type="DbTrigger" name="DBTRIGGER_LAGE" method="before" 
            condition="SQL[SELECT Value FROM Table WHERE Column_ID={ROW.ID} AND Column_State = 'Valid']">
        <Param name="Sql" value="SQL[INSERT INTO PR_SITUATIONREPORT_ENTRY (GUID, EVENT_ID,STATUS, CDTS) VALUES (NEW_GUID(), {FORM.EID} ,0)]" />
    </WorkflowTrigger> 
</WorkflowNode>



Pfeil new.png To the top Pfeil new.png

"Form"-Controller, Routing-Behaviour and triggers

When a Form-controller is deployed, the form attribute must be set to specify the referenced table. This controller will mostly be used (hierarchically) "below" a controller="list" definition and will always show a form with the designated form-fields.


The Routing-Behavior is different from the controllers workflow and list, as it is defined within the FormSettings.xml in the <FormAction>-element as an action-attribute.

a) action="save": Saves the data of the current form and has the same routing behavior as the controller="list". The ID of the currently opened form will be stored in the SEC_SESSION table and is accessibly via {SESSION.TABLENAME.IDFIELD}.

b) action="SCRIPT[IG...]"

 <FormAction ... action="SCRIPT[IG.captureGeometry()]" />

c) action="delete"


Triggers on Workflow-Nodes with Form-controller: Workflow-Triggers can be defined for Workflow-Nodes (with controller="Form"); the method can be "before" (common method) and "after" (method which is used slightly differently from the "after"-methods explained above).

  • method="before": The trigger will be executed before the currently opened form will be modified (inserted, updated, or deleted).
  • method="after": The trigger will only be executed after a save on the currently opened form.




Pfeil new.png To the top Pfeil new.png

Using Filters in Navigation

Refering to filters at Workflow-Nodes:

It is possible to select an item from a list which is kept "in memory" for the navigation through the next nodes. This concept is implemented by the use of the filter-attribute and the session variable.

The Workflow-Node might look like the following:

<WorkflowNode ... controller="list" form="ACTIVE_TASK" ...>

The reference in the form is set by the filter-attribute:

 <Form name="Active_Task" table="ACTIVE_TASK" filter="INCIDENT_ID = {SESSION.INCIDENT.ID}" ...>

Using conditions at Workflow-Nodes:



Language: English