00197458-01_UG_EDM_V2.2_en - 第88页

EDM V2.2 / U ser Guid e Ausgabe 10/2013 E dition 88 Example of a transition with paramet ers (some de tails omitted) < transition name = " removeRestoredObjectsFromClearingPool " ... > < parameter key …

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.

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

Example of a transition with parameters (some details omitted)

...

</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>

<!-- 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> -->

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

event="selectIds"

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

sAction,DataExchange">

…

</transition>

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

Additional Configuration

Some of the modules require that you specify additional settings. The affected modules are labeled

accordingly in Figure 6-1. The custom section of the application configuration was used to make

room for the additional configuration attributes.

The module VDM for CS adds the VDM BLOB handling option to each application template that

affects component shapes. When this module is activated, the Vision data is also transferred for

each component shape pulled.

Module: VDM for CS

Key Form Contents

Configure VDM as described.

Table 6-15: Additional settings for "VDM for CS"

Module: Fixed Template

Key Form Contents

templateName String Name of the application

template to be used

Table 6-16: Additional settings for "fixed templates"

Example for Table 6-16:

</customConfig>

Module: Fixed Objects

Key Form Contents

objectNames A semicolon-separated (";"), full SIPLACE

Pro path. The following generalized

constructs are allowed for the object names:

Type:* - All objects of this type

Type:Path\* - All objects of this type in this

path (not in subfolders of this

path)

List containing the names

of the objects to be

transferred.

Table 6-17: Additional settings for "fixed objects"

Example for Table 6-17:

</customConfig>