00196806-01_IM_EDM_1.9_EN.pdf - 第48页

Installation Manu al SIPLACE Engine ering Data Manag er (EDM) Version 1 .9 Issue 02/2009 48 W hen starting, you will firs t need to declar e all states, e vents and tr ansitions. T his is nec essar y so that the workflow…

Installation Manual SIPLACE Engineering Data Manager (EDM) Version 1.9 02/2011 Edition

47 / 65

5.3 Configuration of the workflow

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), and

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

Both parts of the process may differ, though, 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

discussed in 5.4.1 Application templates.

NOTE:

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

environment.

5.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 a little 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.

5.3.2 … and application

5.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 5.2.3.21 Client workflow configuration).

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

theory.

This set of events is termed the "input alphabet" in theoretical computer science. For those of you who are interested!

Installation Manual SIPLACE Engineering Data Manager (EDM) Version 1.9 Issue 02/2009

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, we 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.

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:

<action

Installation Manual SIPLACE Engineering Data Manager (EDM) Version 1.9 02/2011 Edition

49 / 65

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

ateListAction,DataExchange" />

<action

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

ction,DataExchange" />

</newState>

</transition>

Figure 12 Example of a simple 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.

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

event="templateList"

class="Siemens.SiplacePro.EDM.DataExchange.Actions.AskForTemplateAction,D

ataExchange">

<action

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

ateAction,DataExchange" />

<action

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

ction,DataExchange" />

</newState>

</transition>

Figure 13 Example of a conditional 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 in Figure 12, 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 Figure 14: