|
|
@@ -239,11 +239,16 @@ Both operations use some data, where *models/A* modifies one of its data inputs
|
|
|
}
|
|
|
|
|
|
This simple Process Model is equivalent to the following statements in the code.
|
|
|
-Note that we do not know the type of the activity in the operations, and therefore put an asterisk (\*) there::
|
|
|
+Note that we do not know the type of the activity in the operations, and therefore put an asterisk (\*) there.
|
|
|
+Also, the order in which these operations execute is undefined, as either order is fine.
|
|
|
+We therefore leave it up to the Modelverse to decide upon an order::
|
|
|
|
|
|
>>> execute_transformation_*("models/A", {"First": "my_models/data_a1", "Second": "my_models/data_a2"}, {"Second": "my_models/data_a2"})
|
|
|
>>> execute_transformation_*("models/B", {"input": "my_models/data_b1"}, {"output": "my_models/data_b2"})
|
|
|
|
|
|
+In this case, it doesn't seem useful to use processes, though it is possible for such processes to contain *Decision* nodes, which can be used for arbitrary control flows.
|
|
|
+As everything runs on the Modelverse, instead of constantly requiring communication with the client, performance should be higher due to reduced network latency.
|
|
|
+
|
|
|
When enacting, the FTG+PM is executed by starting at the initial node.
|
|
|
The first element it points to is executed, thereby branching, deciding, or executing an activity.
|
|
|
Due to the branching, it is possible for multiple activities to be scheduled concurrently.
|
