00197458-01_UG_EDM_V2.2_en.pdf - 第86页

EDM V2.2 / U ser Guid e Ausgabe 10/2013 E dition 86 A " norm al " st ate i s de cla red: <state name= " selectObjects " /> This s tate is mark ed as an end s tate: <state name= " done &q…

EDM V2.2 / User Guide Ausgabe 10/2013 Edition

6.3 Workflow Configuration

The production process design varies greatly from customer to customer, which means the data

storage process also varies. Two aspects in particular stand out in this regard:

● the actual process of data flow – the dynamic part – between the central server (EDM Master

Server) and the local clients (EDM Line Servers)

● the type and amount of data to be transferred – the static part.

Both parts of the process may differ in customer processes. This section deals with the dynamic

part, the actual control of the flow of data. The configuration of the static part – the application

templates – is dealt with in section 5.1.6.

NOTICE

The workflow only needs to be configured if the default values do not work in your

environment.

6.3.1 Theory

The production process of the customer is depicted in a workflow using a finite state machine. A

finite state machine is a concept from theoretical computer science. It helps to know some

terminology to understand this concept.

A finite state machine generally consists of:

● A set of states. In the following, this set is called Q.

● Exactly one start state belonging to Q.

● A subset of Q that contains the valid end states.

● A subset of Q that contains the error states.

● A set of Events.

● A set of state transitions that cause a state q

to move to state q

when a certain event occurs.

A maximum of one transition can be defined for each state/event pair.

6.3.2 Application

6.3.2.1 Syntax and Options

The theory presented in the previous section must now be implemented in a manageable form for

actual use. This is done in the client workflow configuration file (see also section 6.2.6.21). This file

is in XML format. The following text deals with the contents of this file and how they relate to the

theory.

When starting, you will first need to declare all states, events and transitions. This is necessary so

that the workflow engine operating on the configuration file can more easily verify the finite state

machine.

First, you define the start state:

In the following state declarations, isStartState="true" is not allowed to appear any more

because a finite state machine has exactly one start state.

EDM V2.2 / User Guide Ausgabe 10/2013 Edition

A "normal" state is declared:

This state is marked as an end state:

Error states are declared as follows:

A state can be an error state and an end state at the same time:

The names of the states must be unique. Next, the events that the workflow engine can react to are

declared in the configuration file:

The names of the events also need to be unique because they are referenced in the definitions of

the transitions just like the states.

The transitions are the heart of the workflow definition. They are a kind of "building block" that can

be used to model a customer workflow.

They determine the reactions to incoming events. Every transition can execute any number of

actions when triggered by an event. To permit a certain degree of control, a transition can be

equipped with a special action that has a return value. Such actions are called controllers. In this

case, the initial state, event and result of the action are passed to the next state. An example of this

is shown below:

EDM V2.2 / User Guide Ausgabe 10/2013 Edition

Example of a simple transition

<transition name="getTemplateList" currentState="clientIdle"

event="pullData">

<action

class="Siemens.SiplacePro.EDM.DataExchange.Actions.

AcquireTemplateListAction,DataExchange" />

<action

class="Siemens.SiplacePro.EDM.DataExchange.Actions.

SendRequestAction,DataExchange" />

</newState>

</transition>

This transition goes from the clientIdle state to the waitTemplateList state when the

pullData event is triggered. Two actions are performed during the transition, each of which is

specified in the class notation known from the application configuration. The actions are executed

in the order they are listed in the file.

Example of a conditional transition

<transition name="selectTemplate" currentState="waitTemplateList"

event="templateList"

class="Siemens.SiplacePro.EDM.DataExchange.Actions.AskForTemplate

Action,DataExchange">

<action

class="Siemens.SiplacePro.EDM.DataExchange.Actions.

AcquireTemplateAction,DataExchange" />

<action

class="Siemens.SiplacePro.EDM.DataExchange.Actions.Send

RequestAction,DataExchange" />

</newState>

</transition>

This transition performs the state transition while taking a controller into account. This special

action is specified using the attribute "class" in class notation. In this case, there is not just one

"newState" tag as in the first example, but instead there is one tag for each possible output of

the controller. To handle these tags, the "value" attribute is added to the "newState" tag. A

controller always returns a string, so the result can always be stored in the XML file.

To make it easier for the author of the workflow configuration to handle application cases such as

the transition for all states to valid error states like the ones arising in EDM in the form of timeouts

due to the asynchronous communication, the transitions can also be defined as shown in the

example below:

Example of a default transition

</transition>

Specifying "all" for the initial state causes this transition to be used for all states. The transition

above therefore defines a general timeout response. A default transition is only executed when no

specific transition is defined for the particular event. This means you can implicitly define more than

one transition for a state/event pair. However, it is not possible to describe more than one default

transition for an event.

Transition may have static parameters to configure the behavior of the transition. These are

paramers can only be accessed by the action being executed.