00195366-01_InstallationManual_EDM_en.pdf - 第47页

Installation Manual SIPLACE EDM Edition 11/2006 class =" Siemens.SiplacePro.EDM.DataExchange.Actions.AcquireT emplateAction,DataExchange " /> < action class =" Siemens.SiplacePro.EDM.Dat aExchange.Ac…

Installation Manual SIPLACE EDM Edition 11/2006

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

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

emplateListAction,DataExchange" />

<action

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

uestAction,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.AskForTemplateAct

ion,DataExchange">

<action

46 of 66

Installation Manual SIPLACE EDM Edition 11/2006

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

emplateAction,DataExchange" />

<action

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

uestAction,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 only one “newState”

tag like in the first example in

Figure 12, 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:

</transition>

Figure 14 Default 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.

47 of 66

Installation Manual SIPLACE EDM Edition 11/2006

5.3.2.2 Workflow modules

5.3.2.2.1 Basics

Figure 15 shows all currently available modules that can be used to form a workflow. However,

since future requirements with respect to designing processes are difficult to assess, it was decided

to follow an implementation path which allows flexible extension and configuration.

To make reconfiguring the system on-site as easy as possible, all possible states, even those that

are not used, as well as all events and transitions are in the

VDM Blob extension (see chapter 5.3.3

VDM Blob Extensions). Those transitions that must be executed (shown in the figure without a

colored border) as well as those for the standard flow (highlighted in gray in the figure) are activated.

These transitions can be replaced by any alternative found in the same level of the flow chart. To do

this, the “old” transition is commented out and the new one is commented in. If several transitions

belong to a module, then all these transitions are to be commented in or out accordingly.

An example is shown below to clarify this. The standard flow for the selected objects in the default

configuration appears as follows:

<transition name="selectIdentities" currentState="selectObjects"

event="selectIds"

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

n,DataExchange">

…

</transition>

<!-- Use fixed selection

<transition name="useIdentities" currentState="selectObjects"

event="selectIds"

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

tiesAction,DataExchange">

…

</transition> -->

This must now be converted to a fixed set of objects to be transferred. This means that the

configuration must be adapted as follows:

48 of 66