Effector 6.3 developer manual

XML reference 6.3

Effector Studio 6.3 summary

Effector Studio 6.3 manual

Effector 6.2 developer manual

XML reference 6.0

Effector Studio 3.2 summary

Effector Studio 3.2 manual

Business processes

This chapter provides help in understanding the modelling and configuration of business processes.

In general, the individual business processes are the visual renderings of real-life business processes. With their help, manually performed tasks become traceable and verifiable. The individual steps may communicate with one another within the system, thus, their use simplifies the flow of documents and data among workplaces.

Each process has a starting and an end point where it is headed and what it reaches through various stages during its life cycle, following some preprogrammed logic.

In Effector, the configuration and mapping of processes is based on state transitions, and the start- and end-states of the process.

The object binding the processes is called Workflow (Workflow) object, which is the representation of the given business process. The individual states are handled in the Event objects and their descendants. A workflow step (WorkflowStep) corresponds to an event in the system. The state transitions can be configured using the so-called Triggers configured in the individual business objects.

The simple process called "Negotiating a business meeting" can be describes as follows:

  • States (Events):

    • A: Arranging the details of the meeting
    • B: Scheduling the meeting
    • C: Recording the outcome of the meeting
  • State transitions (Triggers):

    • A -> B: No date is scheduled; further negotiation is needed.
    • A -> C: Date is scheduled, the meeting can take place.
    • B -> B: Scheduling failed, another attempt of scheduling is needed.
    • B -> C: Date is scheduled, the meeting can take place.

Its visual representation in a flowchart is as follows:

State transition graph

The workflow engine in Effector is capable of versioning the processes making their modification easier.

Available features

  • Registering processes in the system
  • Configuring processes

Registering processes in the system

The list of processes and individual process steps in the system are described by the XML files located in the Workflow directory.

Collection file of processes:

The existing processes in the system are listed in the _WorkFlows.xml_file located in the XML root directory.

<Workflows xmlns="http://effector.hu/schema/ns/workflows">
    <Workflow>
        <ObjectType>basicprocess</ObjectType>
        <Caption>Basic process</Caption>
    </Workflow>
    <Workflow>
        <ObjectType>complexprocess</ObjectType>
        <Caption>Complex process</Caption>
    </Workflow>
</Workflows>

This file must exist even if there is no process at the customer. In such a case, it does not contain any WorkFlow nodes. In the above example, there are two processes defined. Each process definition has an ObjectType node, this will be the type of the process, while the value of the Caption node will be the name of the process. (This information is displayed in Effector Studio only.)

Each WorkFlow node must have a configuration file in the WorkFlow directory, whose name is consistent with the following naming convention: WorkFlow<name>.<version>.xml, where <name> denotes the value of the ObjectType attribute of the WorkFlow node, while <version> contains an ordinal number starting from 1 and matching the current version. This process description file defines the steps of the given process.

WorkFlowRendszertervezes.1.xml

Process description file:

<Workflow xmlns="http://effector.hu/schema/ns/workflow">
    <Steps>
        <Step>
            <Caption>Project registration</Caption>
            <BusinessObject>BusinessObjectProjectRendszertervezes</BusinessObject>
        </Step>
        <Step>
            <Caption>01. Under arrangement </Caption>
            <BusinessObject>BusinessObjectEventRendszertervezes01Elokszites</BusinessObject>
        </Step>
        <Step>
            <Caption>02. Feasible</Caption>
            <BusinessObject>BusinessObjectEventRendszertervezes02Megvalosithato</BusinessObject>
        </Step>
        <Step>
            <Caption>03. Solved</Caption>
            <BusinessObject>BusinessObjectEventRendszertervezes03Megoldva</BusinessObject>
        </Step>
    </Steps>
    <Graph>{"WFStepDimensions":null,"Links":null}</Graph>
</WorkFlow>

The individual steps can be listed in the Step node of the Steps collection. These are the objects playing a role in the process. The BusinessObject node contains the BusinessObject reference pertaining to the step, while the value of the Caption node includes the name of the process step. (This information is displayed in Effector Studio only.)

Optional node IsSubWorkflow allows to creat subprocesses. It's a logical value and false by default. It's currently used by Effector Studio.

The transitions related to the individual process steps are contained by the individual BusinessObjects, and they can be set using the Tigger nodes therein. For a detailed description see Business objects.

Configuring processes

The following complex example illustrates how to configure a process in the system, however, it focuses only on the process itself and does not contain all the aspects.

Let us create the process mentioned in the introduction of the chapter:

First, we need to register the new process in the WorkFlows.xml located in the root directory:

<WorkFlows xmlns="http://effector.hu/schema/ns/workflows">
    <Workflow>
        <ObjectType>Example</ObjectType>
        <Caption>New example process</Caption>
    </Workflow>
</WorkFlows>

Following the registration of the process, we need to create the appropriate process descriptors and the related business objects. The definition of the process needs to be saved in the WorkFlowExample.1.xml file.

States to be modeled:

  • A: Arranging the details of the meeting
  • B: Scheduling the meeting
  • C: Recording the outcome of the meeting

       <WorkFlow xmlns="http://effector.hu/schema/ns/workflow">
           <Steps>
               <Step>
                   <Caption>Setting up a meeting</Caption>
                   <BusinessObject>BusinessObjectProjectPelda</BusinessObject>
               </Step>
               <Step>
                   <Caption>Arranging the details of the meeting</Caption>
                   <BusinessObject>BusinessObjectEventPeldaStepA</BusinessObject>
               </Step>
               <Step>
                   <Caption>Scheduling</Caption>
                   <BusinessObject>BusinessObjectEventPeldaStepB</BusinessObject>
               </Step>
               <Step>
                   <Caption> Recording the outcome of the meeting</Caption>
                   <BusinessObject>BusinessObjectEventPeldaStepC</BusinessObject>
               </Step>
           </Steps>
       </WorkFlow>
    

NOTE: Do not forget to create the Project object! (BusinessObjectProjectPelda)

  • BusinessObjectEvent U_Event_ID [##Session.UserID##] Arranging the details of the meeting true false '[##Parent.Responsible##]'

As seen in the above example, if we would like to set the value of a field based on a field of the parent object, we need to use the Parent reference group: '[##Parent.Responsible##]'. This way, we can set that the same person who was the owner of the previous step will also be the owner of the current task, but any of the parent object’s fields can be similarly referenced.

The trigger responsible for forwarding the process:

        <Triggers>
            <Trigger action="Create" sourceBusinessObject="Project" sourceObjectType="Example" event="Created" />
        </Triggers>

**NOTE: Do not forget that the triggers need to be set at the last step!**
  • Triggers part of the BusinessObjectEventPeldaStepB.xml

    If the StartDate is empty, further negotiation is needed. This step can be launched from two places: following the original entry or upon entering an unsuccessful scheduling. This is illustrated by the following trigger configuration:

       <Triggers>
           <Trigger action="Create" sourceBusinessObject="Event" sourceObjectType="BusinessObjectEventExampleStepA" event="Done">
               <Condition type="Simple" return="boolean" default="true">'[##Field.StartDate##]' == ''</Condition>
           </Trigger>
           <Trigger action="Create" sourceBusinessObject="Event" sourceObjectType="BusinessObjectEventExampleStepB" event="Done">
               <Condition type="Simple" return="boolean" default="true">'[##Field.StartDate##]' == ''</Condition>
           </Trigger>
       </Triggers>
    
  • Triggers part of the BusinessObjectEventExampleStepC.xml

    The final step will always take place if any of the following events occurs: event A or B reaches a ready state when the StartDate field representing the scheduled date is filled.

       <Triggers>
           <Trigger group="0" action="Create" sourceBusinessObject="Event" sourceObjectType="BusinessObjectEventExampleStepA" event="Done">
               <Condition type="Simple" return="boolean" default="true">'[##Field.StartDate##]' != ''</Condition>
           </Trigger>
           <Trigger group="0" action="Create" sourceBusinessObject="Event" sourceObjectType="BusinessObjectEventExampleStepB" event="Done">
               <Condition type="SQL" return="boolean" default="false">SELECT CASE WHEN '[##Field.StartDate##]' != '' THEN 'true' ELSE 'false' END</Condition>
           </Trigger>
       </Triggers>
    

    Example 2:

       <Trigger group="0" action="RunSQL" sourceBusinessObject="Event" sourceObjectType="BusinessObjectEventExampleStepB" event="Done">
           <SQL>
               osp_wrk_ChangePortfolio '[##Triggered.ProjectID##]', 3, '[##Session.UserID##]'
           </SQL>
       </Trigger>
    

    In the example the trigger runs a stored procedure, that changes the status of the given process, if the previous step ran successful. The reference Triggered points to the newly created object.

    Example 3:

       <Trigger group="0" action="RunSQL" sourceBusinessObject="Event" sourceObjectType="BusinessObjectEventPeldaStepC" event="Done">
           <SQL>
               osp_wrk_ChangePortfolio '[##Field.ProjectID##]', 4, '[##Session.UserID##]'
           </SQL>
       </Trigger>
    

    As shown in the above example, the object referencing itself in the trigger can carry out an arbitrary operation. In this example, the stored procedure gets the ProjectID from which the given step was generated; that is, in the triggers the Field always refers to a field of the creating step.

On launching the process, a row is generated in the WorkFlow table of the database. The value of the ObjectType node under WorkFlow will be in the ObjectType column. The system inserts the value of the generated WorkFlowID into the WorkflowID column of the objects taking part in the process, thus connecting the object to the process. These objects are the BusinessObjectEvent and the BusinessObjectProject.

Linked process

In Effector we have a chance to link several processes, for instance if we want a process to be launched after a given step of another process, or if two separate processes are running concurrently and at one point the next step of one process depends on a step of the other process.

Example (BusinessObjectEventA.xml):

    <Trigger sourceBusinessObject="Event" sourceObjectType="WorkFlowB_Step1" action="Create" isAttachedWorkflow="true" attachedWFTemplate="WorkFlowB" event="Done">
        <Condition type="SQL">
        ...
        </Condition>
    </Trigger>

In the following example, the EventA process step must follow the WorkFlowB_Step1 step of the WorkFlowB type process. By setting the value of the isAttachedWorkflow attribute to true we can specify that this is part of a linked process, while the value of the attachedWFTemplate attribute indicates the type of the linked process (the value of the ObjectType node). In such cases, we need to enter the process step in the sourceObjectType attribute from which the given step must start off.

In this case, the FSYS_AttachedWorkflow database table stores which process is linked to which; its fields are:

  • EventID: The unique ID of the given process step in the Event table.
  • Project: The unique ID of the given process in the Project table.
  • To_Project: The unique ID of the linked process in the Project table.
  • Workflow: The unique ID of the given process in the WorkFlow table.
  • To_Workflow: The unique ID of the linked process in the WorkFlow table.

  • Last update: 2 weeks 5 days ago
  • Effector