Concepts/en - Versionsgeschichte

Cg: /* Test Data Generator Blocks */

2026-02-26T21:05:55Z

Test Data Generator Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:05 Uhr
Zeile 554:		Zeile 554:
	the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#185a9140-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.8: The Console Command Editor</a>.		the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#185a9140-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.8: The Console Command Editor</a>.

	==== Test Data Generator Blocks ====		==== Test Data Generator Action Blocks ====

	The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction.png]] <span class="KEYWD">Test Data Generator Block element</span> is the element type used to <em>supply artificially generated data values</em> to other Steps. This is useful especially for simulating elements that are usually delivering the values, but are not always or not yet available. A second purpose for this Block type is to control the execution flow by yielding time scheduled values.		The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction.png]] <span class="KEYWD">Test Data Generator Block element</span> is the element type used to <em>supply artificially generated data values</em> to other Steps. This is useful especially for simulating elements that are usually delivering the values, but are not always or not yet available. A second purpose for this Block type is to control the execution flow by yielding time scheduled values.
Zeile 563:		Zeile 563:

	The Data Generator Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Generic Values List Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#189947f0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.9: The Generic Values Editor</a>.		The Data Generator Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Generic Values List Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#189947f0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.9: The Generic Values Editor</a>.


	==== Schema Definition Restrictions ====		==== Schema Definition Restrictions ====

Cg: /* Shell Command Blocks */

2026-02-26T21:05:42Z

Shell Command Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:05 Uhr
Zeile 543:		Zeile 543:
	The Shell Script Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Script Content Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#181f0ee0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.7: The Script Code Editor</a>.		The Shell Script Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Script Content Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#181f0ee0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.7: The Script Code Editor</a>.

	==== Shell Command Blocks ====		==== Shell Command Action Blocks ====

	The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction.png]] <span class="KEYWD">Console Shell Command Block element</span> is the element type used to implement an elementary functionality block in form of a <em>console shell command</em> in an OS dependent manner. The command is <em>directly passed</em> to the underlying operating system, so the scope of possible executables to call depends on the platform on which the session is running.		The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction.png]] <span class="KEYWD">Console Shell Command Block element</span> is the element type used to implement an elementary functionality block in form of a <em>console shell command</em> in an OS dependent manner. The command is <em>directly passed</em> to the underlying operating system, so the scope of possible executables to call depends on the platform on which the session is running.

Cg: /* Shell Script Blocks */

2026-02-26T21:05:31Z

Shell Script Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:05 Uhr
Zeile 531:		Zeile 531:
	Inside the code, the Data Pins of the Block can be directly accessed using the Pin's name, and used as if they were code variables. A single restriction exists for this access, according to the nature of the Data Pins: Reading values is only possible for the Input Pins' variables, while writing is only possible for the Output Pins' variables.		Inside the code, the Data Pins of the Block can be directly accessed using the Pin's name, and used as if they were code variables. A single restriction exists for this access, according to the nature of the Data Pins: Reading values is only possible for the Input Pins' variables, while writing is only possible for the Output Pins' variables.

	==== Shell Script Blocks ====		==== Shell Script Action Blocks ====

	The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction.png]] <span class="KEYWD">Shell Script Block element</span> is the element type used to implement an elementary functionality block in form of <em>shell script source code</em> in an OS dependent scripting language. The code contents are <em>directly passed</em> to the underlying operating system, so the scope of possible shell or batch script dialects depends on the platform on which the session is running.		The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction.png]] <span class="KEYWD">Shell Script Block element</span> is the element type used to implement an elementary functionality block in form of <em>shell script source code</em> in an OS dependent scripting language. The code contents are <em>directly passed</em> to the underlying operating system, so the scope of possible shell or batch script dialects depends on the platform on which the session is running.

Cg: /* Code Blocks */

2026-02-26T21:05:18Z

Code Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:05 Uhr
Zeile 521:		Zeile 521:
	In contrast to the Compound Action Block, an Elementary Block does not contain an Internal Workflow Property. Instead, each specialized Elementary Block type has a particular Property according to that type.		In contrast to the Compound Action Block, an Elementary Block does not contain an Internal Workflow Property. Instead, each specialized Elementary Block type has a particular Property according to that type.

	==== Code Blocks ====		==== Code Action Blocks ====

	The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <em>source code</em> in a particular <em>programming language</em>. The execution is performed either by expecco itself (its embedded interpreters) or by an external language interpreter. Currently, two internally executed syntax patterns are supported: [[Bild:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Bild:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax. Supported external languages are Python, NodeJS, Groovy and others.		The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <em>source code</em> in a particular <em>programming language</em>. The execution is performed either by expecco itself (its embedded interpreters) or by an external language interpreter. Currently, two internally executed syntax patterns are supported: [[Bild:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Bild:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax. Supported external languages are Python, NodeJS, Groovy and others.

Cg: /* Using Elementary Blocks */

2026-02-26T21:04:31Z

Using Elementary Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:04 Uhr
Zeile 515:		Zeile 515:
	There are several items which are concerned in the Execution Context inheritance. First is the <span class="KEYWD">Variable Environment</span>: Each Compound Block defines an own Variable Environment, possibly overdubbing parts or all of the Variable Environment inherited from its encapsulating Execution Context. Second is the <span class="KEYWD">Inventory</span>: Also, each Compound Block defines an own Local Inventory, that may pass Resource Acquirement Requests to the Inventory of its encapsulating Execution Context. Third, but not of great interest to the user, is the internal <em>logging</em> mechanism: Activity Logs are always attached to the superordinate Activity Log instance in their Execution Context after the Activity has finished execution.		There are several items which are concerned in the Execution Context inheritance. First is the <span class="KEYWD">Variable Environment</span>: Each Compound Block defines an own Variable Environment, possibly overdubbing parts or all of the Variable Environment inherited from its encapsulating Execution Context. Second is the <span class="KEYWD">Inventory</span>: Also, each Compound Block defines an own Local Inventory, that may pass Resource Acquirement Requests to the Inventory of its encapsulating Execution Context. Third, but not of great interest to the user, is the internal <em>logging</em> mechanism: Activity Logs are always attached to the superordinate Activity Log instance in their Execution Context after the Activity has finished execution.

	=== Using Elementary Blocks ===		=== Using Elementary Action Blocks ===

	<span class="KEYWD">Elementary Blocks</span> provide the <em>basic functionality</em> of an expecco project. They are used to model basical calculation or logical combination units, or to query and control external devices. These can be local or remote processes as well as hardware devices that are attached by some kind of hardware interface.		<span class="KEYWD">Elementary Action Blocks</span> provide the <em>basic functionality</em> of an expecco project. They are used to model basical calculation or logical combination units, or to query and control external devices. These can be local or remote processes as well as hardware devices that are attached by some kind of hardware interface.

	In contrast to the Compound Block, an Elementary Block does not contain an Internal Workflow Property. Instead, each specialized Elementary Block type has a particular Property according to that type.		In contrast to the Compound Action Block, an Elementary Block does not contain an Internal Workflow Property. Instead, each specialized Elementary Block type has a particular Property according to that type.

	==== Code Blocks ====		==== Code Blocks ====

Cg: /* Code Blocks */

2026-02-26T21:03:41Z

Code Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:03 Uhr
Zeile 525:		Zeile 525:
	The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <em>source code</em> in a particular <em>programming language</em>. The execution is performed either by expecco itself (its embedded interpreters) or by an external language interpreter. Currently, two internally executed syntax patterns are supported: [[Bild:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Bild:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax. Supported external languages are Python, NodeJS, Groovy and others.		The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <em>source code</em> in a particular <em>programming language</em>. The execution is performed either by expecco itself (its embedded interpreters) or by an external language interpreter. Currently, two internally executed syntax patterns are supported: [[Bild:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Bild:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax. Supported external languages are Python, NodeJS, Groovy and others.

	Each element of this type contains exactly one <span class="KEYWD">Code Content Property</span>, which holds the <span class="KEYWD">Source Code Text Content</span> that is interpreted according to the used language's syntax at runtime. It is also possible to <em>switch the syntax pattern</em> for already implemented Code Blocks, causing the code to be automatically converted to that particular syntax style.		Each element of this type contains exactly one <span class="KEYWD">Code Content Property</span>, which holds the <span class="KEYWD">Source Code Text Content</span> that is interpreted according to the used language's syntax at runtime. It is also possible to <em>switch the syntax pattern</em> for already implemented internal language Code Blocks, causing the code to be automatically converted to that particular syntax style.

	The Code Block element type offers all functionalities that are needed to make full programmatic use of the underlying operating system, including access to interfaces, file systems, and other processes, by providing appropriate objects for use inside the code.		The Code Block element type offers all functionalities that are needed to make full programmatic use of the underlying operating system, including access to interfaces, file systems, and other processes, by providing appropriate objects for use inside the code.

Cg: /* Code Blocks */

2026-02-26T21:02:58Z

Code Blocks

← Nächstältere Version		Version vom 26. Februar 2026, 21:02 Uhr
Zeile 523:		Zeile 523:
	==== Code Blocks ====		==== Code Blocks ====

	The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <em>source code</em> in a particular <em>programming language</em>. Currently, two syntax patterns are supported: [[Bild:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Bild:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax.		The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <em>source code</em> in a particular <em>programming language</em>. The execution is performed either by expecco itself (its embedded interpreters) or by an external language interpreter. Currently, two internally executed syntax patterns are supported: [[Bild:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Bild:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax. Supported external languages are Python, NodeJS, Groovy and others.

	Each element of this type contains exactly one <span class="KEYWD">Code Content Property</span>, which holds the <span class="KEYWD">Source Code Text Content</span> that is interpreted according to the used language's syntax at runtime. It is also possible to <em>switch the syntax pattern</em> for already implemented Code Blocks, causing the code to be automatically converted to that particular syntax style.		Each element of this type contains exactly one <span class="KEYWD">Code Content Property</span>, which holds the <span class="KEYWD">Source Code Text Content</span> that is interpreted according to the used language's syntax at runtime. It is also possible to <em>switch the syntax pattern</em> for already implemented Code Blocks, causing the code to be automatically converted to that particular syntax style.

Cg: /* Arranging Steps */

2026-02-26T20:53:29Z

Arranging Steps

← Nächstältere Version		Version vom 26. Februar 2026, 20:53 Uhr
Zeile 385:		Zeile 385:

	Another possibility to create Step instances is first to <em>copy</em> an existing Step instance, and then <em>paste</em> it into the same or into another Activity Diagram. Multiple Steps can also be copied at once, and can be pasted as a whole. It is not possible to copy and paste single Connections, but when copying multiple Steps at a time, the Connections which are between them are also copied. This allows to copy and paste <em>complete sub structures</em> of existing Workflows, including all Connections comprised.		Another possibility to create Step instances is first to <em>copy</em> an existing Step instance, and then <em>paste</em> it into the same or into another Activity Diagram. Multiple Steps can also be copied at once, and can be pasted as a whole. It is not possible to copy and paste single Connections, but when copying multiple Steps at a time, the Connections which are between them are also copied. This allows to copy and paste <em>complete sub structures</em> of existing Workflows, including all Connections comprised.

			The popup menu of the diagram editor provides a function to create new step via a selection dialog. This includs various filters and even an additional tool to search for actions which generate a given result (search by example).

	[[Bild:PIC_Concepts_Workflows_MovingSteps.png\|frame\|Figure 5.3.2-2: Positioning Steps]]		[[Bild:PIC_Concepts_Workflows_MovingSteps.png\|frame\|Figure 5.3.2-2: Positioning Steps]]

Cg: /* Arranging Steps */

2026-02-26T20:50:33Z

Arranging Steps

← Nächstältere Version		Version vom 26. Februar 2026, 20:50 Uhr
Zeile 380:		Zeile 380:
	==== Arranging Steps ====		==== Arranging Steps ====

	Steps can be added to the Workflow in several ways. The most usual way is to select a Block element in the <span class="KEYWD">element Navigation Tree</span>, and to simply <em>drag</em> its symbol into the Activity Diagram Area. This creates a new Step instance in the Workflow, which is then depicted as a <em>building block</em> with the appropriate Pins in the Activity Diagram. Such a new Step initially has the Pin Configuration specified in the Block's Schema Definition.		Steps can be added to the Workflow in several ways. The most usual way is to select a Block element in the <span class="KEYWD">element Navigation Tree</span>, and to simply <em>drag</em> its symbol into the Activity Diagram Area. This creates a new Step instance in the Workflow, which is then depicted as a <em>building block</em> with the appropriate Pins in the Activity Diagram. Such a new Step initially has the Pin Configuration specified in the Block's Schema Definition. You can also Copy-Paste actions from the navigation tree.

	[[Bild:PIC_Concepts_Workflows_CreatingSteps.png\|frame\|Figure 5.3.2-1: Initial Step Creation by Drag & Drop]]		[[Bild:PIC_Concepts_Workflows_CreatingSteps.png\|frame\|Figure 5.3.2-1: Initial Step Creation by Drag & Drop]]

Cg: /* Workflow Execution */

2026-02-26T20:20:53Z

Workflow Execution

← Nächstältere Version		Version vom 26. Februar 2026, 20:20 Uhr
Zeile 507:		Zeile 507:
	There are two different events that can cause a Step to initialize an Activity: The first is the <span class="KEYWD">Autostart option</span>, which can be set as a Step Configuration parameter inside the according Activity Diagram. When the Autostart option is set for a Step, the Step will initialize exactly one Activity instance each time the comprising Workflow is beginning an execution. The second is the <span class="KEYWD">Input Pin Evaluation</span>, which analyzes the value occupancies of the Data Input Pins according to the adjusted Triggering Condition Type. The Gating Type can be adjusted in the Schema Editor. When the relevant input values meet the Gating Type's demands, and the Enable Trigger - if activated - also holds a value, the Step will initialize a new Activity instance.		There are two different events that can cause a Step to initialize an Activity: The first is the <span class="KEYWD">Autostart option</span>, which can be set as a Step Configuration parameter inside the according Activity Diagram. When the Autostart option is set for a Step, the Step will initialize exactly one Activity instance each time the comprising Workflow is beginning an execution. The second is the <span class="KEYWD">Input Pin Evaluation</span>, which analyzes the value occupancies of the Data Input Pins according to the adjusted Triggering Condition Type. The Gating Type can be adjusted in the Schema Editor. When the relevant input values meet the Gating Type's demands, and the Enable Trigger - if activated - also holds a value, the Step will initialize a new Activity instance.

	It is important to know that <em>initializing</em> an Activity is <em>not</em> the same as <em>executing</em> an Activity. When an Activity is initialized, only the internal object is prepared, and the according set of input values is attached to that object. Execution can however start at a later point of time, depending on ~~parallelity~~ ~~limitation~~ of the Step, and on the Activity's position in the execution queue. This means that the values that the internal functionality of the Activity will work on are the first values present at the Step's Input Pins in the moment of the invocation (= Activity initialization), and changes in the value constitution (especially on the parametric Input Pins) are not recognized by the Activity when its execution starts.		It is important to know that <em>initializing</em> an Activity is <em>not</em> the same as <em>executing</em> an Activity. When an Activity is initialized, only the internal object is prepared, and the according set of input values is attached to that object. Execution can however start at a later point of time, depending on any parallelism limit of the Step, and on the Activity's position in the execution queue. This means that the values that the internal functionality of the Activity will work on are the first values present at the Step's Input Pins in the moment of the invocation (= Activity initialization), and changes in the value constitution (especially on the parametric Input Pins) are not recognized by the Activity when its execution starts.

	Another important issue when executing Workflows is the so-called <span class="KEYWD">Execution Context</span>, which denotes the <em>executing environment</em> of an Activity. Activities, meanwhile, can only be spawned from Steps, and Steps can only exist inside of Workflows. Executing a Workflow means executing Activities of the Steps inside. This especially affects Compound Block Steps, because these have own Workflows as their internal functionalities. When a Compound Block Step's Activity is executed, it constitutes the Execution Context for all Activities spawned from its internal Steps. The special thing about it is that the Activity not only <em>creates</em> its individual Execution Context, but also <em>inherits</em> the properties of its own encapsulating Execution Context.		Another important issue when executing Workflows is the so-called <span class="KEYWD">Execution Context</span>, which denotes the <em>executing environment</em> of an Activity. Activities, meanwhile, can only be spawned from Steps, and Steps can only exist inside of Workflows. Executing a Workflow means executing Activities of the Steps inside. This especially affects Compound Block Steps, because these have own Workflows as their internal functionalities. When a Compound Block Step's Activity is executed, it constitutes the Execution Context for all Activities spawned from its internal Steps. The special thing about it is that the Activity not only <em>creates</em> its individual Execution Context, but also <em>inherits</em> the properties of its own encapsulating Execution Context.