00197458-01_UG_EDM_V2.2_en.pdf - 第87页
EDM V2.2 / U ser Guid e Ausgabe 10/2013 E dition 87 Example of a simple transitio n <transition name= " getTemplateList " currentState= " clientIdle " event= " pullData "> <newState…
EDM V2.2 / User Guide Ausgabe 10/2013 Edition
86
A "normal" state is declared:
<state name="selectObjects" />
This state is marked as an end state:
<state name="done" isEndState="true" />
Error states are declared as follows:
<state name="timedOut" isErrorState="true" />
A state can be an error state and an end state at the same time:
<state name="failed" isErrorState="true" isEndState="true" />
The names of the states must be unique. Next, the events that the workflow engine can react to are
declared in the configuration file:
<event name="pullData" />
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
87
Example of a simple transition
<transition name="getTemplateList" currentState="clientIdle"
event="pullData">
<newState name="waitTemplateList">
<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">
<newState name="waitTemplate" value="OK">
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.
AcquireTemplateAction,DataExchange" />
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.Send
RequestAction,DataExchange" />
</newState>
<newState name="canceled" value="Cancel" />
</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 name="timeoutDefault" currentState="all" event="timeOut">
<newState name="timedOut" />
</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.

EDM V2.2 / User Guide Ausgabe 10/2013 Edition
88
Example of a transition with parameters (some details omitted)
<transition name="removeRestoredObjectsFromClearingPool" ... >
<parameter key="ignoreFailedDeletions" value="true" />
...
</transition>
6.3.2.2 Workflow Modules
Basics
Figure 6-1 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 that allows flexible extension and configuration.
To simplify reconfiguring the system on-site, all possible states, even those that are not used, as
well as all events and transitions are contained in the standard configuration. 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:
Example of the standard flow
<transition name="selectIdentities" currentState="selectObjects"
event="selectIds"
class="Siemens.SiplacePro.EDM.DataExchange.Actions.SelectIdentities
Action,DataExchange">
…
</transition>
<!-- Pull workflow variants -->
<!-- Use fixed selection
<transition name="useIdentities" currentState="selectObjects"
event="selectIds"
class="Siemens.SiplacePro.EDM.DataExchange.Actions.UseConfiguredI
dentitiesAction,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:
Example of an adapted configuration
<!--
<transition name="selectIdentities" currentState="selectObjects"
event="selectIds"
class="Siemens.SiplacePro.EDM.DataExchange.Actions.SelectIdentitiesAction
,DataExchange">
…
</transition> -->
<!-- Use fixed selection -->
<transition name="useIdentities" currentState="selectObjects"
event="selectIds"
class="Siemens.SiplacePro.EDM.DataExchange.Actions.UseConfiguredIdentitie
sAction,DataExchange">
…
</transition>