The OTX data model consists of a central core (core or base library) and various function-specific extensions (libraries). The Core describes the structure of each document OTX. It specifies the general flow logic and contains all the control structures, declarations, error handling and extension mechanisms. The following are the main features and elements are described.

Core architecture based library within the OTX

• Key Features
• Main elements
• Data Types
• Procedures
• Parameter
• Declarations
• Nodes (activities or nodes)
  
  • Compound Node - Group
  • Compound Node - Loop
  • Compound Node - Branch
  • Compound Node - Parallel
  • Compound Node - Handler
  • Atomic nodes - EndNodes
  • Atomic nodes - Action
• Expressions (terms)
• Beispielbedatung

Key Features

The data model has the following main features:

• Imperative, structured programming
• Declaration of procedures, variables, constants, and metadata
• Access to environmental data
• Specification field in each node as well as free comments
• Extension points for the integration of new features
• Control Structures
• Loops (while, do-while, for, for-each)
• Verzeigungen (if-then-else)
• Parallel processes
• Views (sequences, calculations, etc.)
• Error and exception handling

Main elements

The data model consists of the following main elements, see image:

• Data Types
• Procedures
• Parameter
• Declarations
• Activities (nodes)
• Expressions (terms)

Core data model - Key elements

Data Types

OTX in all variables, parameters and characteristics have a data type. The Core defines a set of basic data types, see Fig.

OTX Core Data Types

The data types are divided the following groups:

• simpleType
  • Boo­lean
  • Float
  • Byte­Field
  • Integer
  • String
• complexType
  • List (Array)
  • Map (Key-Value Pairs)
• Exception
  • UserException
  • OutOfBoundsException
  • TypeMismatchException
  • ArithmeticException
  • InvalidReferenceException

Complex data types can be simple or complex data types in turn be composite. The List and Map types are generic types with any depth. The user exception is the only exception that can generate the author using the Throw activity. With the various libraries usually are added other complex data types.

Procedures

A procedure describes the sequences (sequences). It consists of

• Parameters,
• various declarations (Constants, Variables, Comments, throws, visibility) and
• a sequence (flow) of nodes (Nodes), see Fig.

OTX elements of a procedure

A procedure is the exportable part of OTX document. It can be used as the entry point of a drain system or be called by other procedures outside the OTX document.

Parameter

The parameters define the input and output variables of a procedure. They are divided into:

• InParameter

  Values ​​are treated as constants and can not be changed within the procedure. Missing parameters are either initialized with the initial value of the parameter declaration or data type.

• InOutParameter

  It is passed references, ie a change in value is visible to the caller. Missing parameters are either initialized with the initial value of the parameter declaration or data type.

• OutParameter

  Return values ​​of the procedure. Writes the procedure is nothing in the parameters, either the initial value of the parameter declaration or the data type returned

OTX parameter & declarations

Declarations

Variables and constants must be declared. The declaration, there are only two places:

• global, At the level of the document or
• locally, At the level of the procedure.

Constants are defined at design time and runtime modified. Variables can be changed at will by the procedure. If no default value defined a variable with the default data type is initialized.

Nodes (activities or nodes)

A node represents a single step in a process (flow). He is usually referred to here as activity. There are two types of nodes:

• Atomic-Node

  Simple activity, which may include any other activities. Example: Action, Return, Continue, Break, Throw and Exit

• Compound Node

  Can other activities and processes contained in any depth. Example: Group, loop, branch, parallel and Handlers

OTX main core nodes (activities)

Compound Node - Group

The Group node is the simplest compound node. It combines a sequence of nodes into a logical block (group) together. The author shows that the unity of the sequence and supports a clear and modular structure of the processes. Group nodes can OTX designers together or unfolded.

Group Node

Compound Node - Loop

A loop (Loop) is used for repeated execution of one or more activities. The figure shows the four types of loops are shown:

OTX loop nodes (loops)

• For­Loop

  For the run-loop, until the counter has reached the final value.

• ForE­ach­Loop

  Loop that is run through each element of a collection.

• While­Loop

  the loop is traversed until the condition returns the value False. The condition is tested at the beginning of the loop.

• DoWhileLoop

  the loop is traversed until the condition returns the value False. The condition is tested at the beginning of the loop.

A break node terminates the current loop and continues execution at the next Atomic nodes or the overlying compound node. Continue a node terminates the current iteration in a loop and continues execution with the next iteration. When grinding with a condition, the condition at the beginning (While) or be tested at the end of the loop (DoWhile).

Compound Node - Branch

Branches (Branch) are used for conditional execution of sequences. They consist of one or more branches with a condition (condition) and a sequence (flow). The conditions are evaluated from left to right. The first sequence in which the condition is true is executed. Branches where the condition is not true to be ignored. Is there more than one branch, the last branch has no condition. He is then executed if no condition is true (Else).

OTX Branch nodes (branches)

Compound Node - Parallel

A parallel node (parallel) consists of at least two sequences (Lane) that run simultaneously. Each lane is running it in a separate thread. The order of execution of the Lanes is indeterminate. The node can normally only be terminated synchronously. This means that until all lanes must be completed before the node is terminated. However, there are several conditions that enforce a particular termination of Lanes:

OTX Parallel Node

• TerminateLanes Node

  The TerminateLanes node terminates the current lane and signaled to the other lanes to exit. The signalized lanes work from the current node Atomic and exits. After all lanes are finished, and the entire node is terminated.

• Return node

  The return ends the current node Lane waits until all other lanes are finished and then ends the entire procedure.

• Except

  Dispatched within a lane an unhandled exception, terminates the current lane. After all other lanes are finished except at the higher layers for processing is passed.

Note: It does not define a timeout. It is thus possible to bring the process into a deadlock.

Note: The lanes should never have dependencies on each other!

Compound Node - Handler

A handler knots is used to monitor sections within a sequence of unexpected behavior (exceptions or exceptions). It consists of 3 blocks, which can in turn contain sequences:

OTX Handler Node (error handling)

• Try block
  The try block is the area to be monitored. Each sequence (flow) can have a try-section. If no exception is raised, the processing after the last catch block continues. If an exception is raised, the processing is terminated immediately, and followed the sequence fits the catch block for Exception.

• Catch block
  A Catch block is the actual exception handler. Catch each block can be assigned to an exception. If a matching catch block found, no further catch blocks processed. If no matching Catch block is found, the error handling to the next outer sequence is passed.

• Finally block
  The Finally block is always executed, regardless of whether an exception occurred or not. It is used to clean up resources.

Atomic nodes - EndNodes

Will cease within a sequence of the last node, the execution is passed to the next node in the outer sequence. If no further external sequence exists, the procedure is finished. This is the default action sequences. With EndNode node sequences can be terminated as the default behavior in a different way. There are 4 different EndNode Node:

• Return
  Finished the whole procedure at once and passes the execution to the caller.

• Continue
  Ends the outer loop immediately and sets the execution in the target attribute specified loop continues. Before finishing the loop condition is checked again.

• Break
  Ends a loop or a parallel node immediately. The processing is the next node in the Target attribute specified loop / continued parallel.

• Throw
  Throws an explicit exception / exception. Ends the execution of the current context and returns the processing to the next error handler.

Atomic nodes - Action

OTX is an action in an atomic node, the behavior of the so-called action-realization is determined. The OTX-core and in particular all extension libraries define the respective action realizations.

• Core: Assignment, Increment, ListInsertItem ...
• DiagCom: CreateComChannel, ExecuteDiagService ...
• HMI: message dialog, ConfirmDialog ...

OTX Action Nodes

An action node can have multiple implementations, see Validity concept. In several implementations, the first realization is running, that ValidFor attribute is either blank or TRUE. Other implementations are ignored. An action node must have no realization, see Specification-implementation approach. An action without realization is only the specification and is ignored at run time.

Expressions (terms)

Terms used to describe expressions (expressions). Terms used in many different places:

• In Actions
• In Para­me­tern
• In Bedin­gun­gen

Terms have a return value and include values, variables, or again term in any depth. The arguments of a term are not affected by the evaluation, ie, a term has no side effects! A term is categorized by its return type, see figure:

OTX types of terms (expressions)

Within the OTX designer most terms are presented graphically as activities.

OTX term as activities

Each library can be defined by the Core-derived new Terms Terms

Beispielbedatung

The following picture OTX document in XML format is shown. It shows an example of a simple process. In a global scope is valid is defined. There is a procedure with a variable of type Integer. In the end an environment variable is set data1 to the value "abc".

OTX simple example workflow in XML format