Summary
The ADVENTURE Process Designer is the key tool in the stage of designing Virtual Factories, which collaborates with assistive tools like ADVENTURE Simulation and Optimization, to deliver ADVENTURE brokers with the core functionality to accomplish this task.
The component’s main object is the Smart Process Model and it provides the required functionality to manage its lifecycle and perform tasks related to the different phases.
A new Process Model is created in the Process Designer either as an empty model or based on a ready-to-use template from templates repository. As the ADVENTURE broker starts to design (edit) the process, the model enters its ‘in design’ phase. This is the core phase for the Process Designer and the designer can perform several types of tasks in it:
• Manage process metadata with the goal to enable automation and make the process discoverable
• Design process models, e.g. add/configure/remove process activities or other process model elements, using the notation and semantics supported by the Process model design tool
• Use the Simulation component to trigger simulation of the process and verify its qualities before executing it and potentially return to redesign for better results
• Use the Optimization component to trigger optimization of the process for optimal business goal results and potentially return to redesign for better results
• Save for further work or share the designed process model
• Load, if the process model has been saved earlier or has been shared by another user
A process model that is in design state can be saved. Process models that have been designed in external tools, compatible with the ADVENTURE platform, may be imported into the system and saved for further use too. Further, the process models can be exported in a standard format. Saved process models can be loaded back into in design state for further changes. By default, saved process models are private to their owners. However they can also be shared by their owners with other ADVENTURE members for exploration and collaboration. Those that have been shared can be unshared to become private again.
When a process model design is ready to be executed, e.g. process activities have services bound to them, a broker can request a new instance of the model to be executed by the Process Execution Engine. This changes the state of the process model to active. During their active phase, process models can eventually be in executing or executed state. These two states depend on the process model instances that are executed in the Process Execution Engine. If there’s at least one model instance that is currently in execution state in the Process Execution Engine, then the model’s state is executing. If there was at least one model instance that had been executed previously but none are executing currently, the model state is executed.
The executing and executed states control the last stage in the process model lifecycle. Models, which have at least one instance in executing state cannot be removed (become deleted or inactive). Process models that have instances only in executed state (past executions have occurred, but none currently) can be become inactive, but not deleted (physically removed), in order to preserve history of relations between processes, member profiles and services. Process models that have never been executed (no associated instances in active state exist) can be safely deleted.
Active processes that are executing can be opened in design when changes are needed due to required adaptations.
More information & hyperlinks