00197458-01_UG_EDM_V2.2_en.pdf - 第85页
EDM V2.2 / U ser Guid e Ausgabe 10/2013 E dition 85 6.3 W orkf lo w Configur ation The produc tion proc ess des ign varies gr eatl y from customer to customer , which m eans the dat a storage pr ocess als o varies. T wo …
EDM V2.2 / User Guide Ausgabe 10/2013 Edition
84
Parameters
Setting Default Valid for Explanation
LineDataTransferStatusMonitor.
OldEntriesThreshold
30 days
Data
Transfer
Manager
Specifies the period after
which an entry in the status
monitor is classified as "old" in
the Data Transfer Manager
(and is therefore removed with
the Delete old entries
button).
History.MaxiumLength 10 Data
Transfer
Manager
Maximum number of history
entries in the Data Transfer
Manager.
Table 6-14: Settings for data transfer – parameters
EDM V2.2 / User Guide Ausgabe 10/2013 Edition
85
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
1
to move to state q
2
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:
<state name="clientIdle" isStartState="true" />
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
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: