Changes between Version 1 and Version 2 of Workflow
- Timestamp:
- Nov 12, 2019, 9:19:07 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Workflow
v1 v2 11 11 The aforementioned tools are found in plugin -> Workflow Tools. Both tools require a running workflow engine. This means two things, first Renew has to be started with certain parameters set and second the simulation needs to be running (with the "workflow compiler" formalism, see [[WFNet]]). The needed parameters are the workflow adaptor this can be set by "-Dde.renew.access.adaptor= <wfadaptor>" and <wfadaptor> can be either "de.renew.workflow.!ResourceBundleAdaptor" or "de.renew.workflow.!DatabaseAdaptor" and depending on the adapter additional information have to be provided. For the "!ResourceBundleAdaptor" this is the location of the access.properties and workflow.properties and in case of the "!DatabaseAdaptor" that are information about the database. Instead of starting Renew and setting the parameters with the commandline it is recommended to use a startscript instead, the included startscripts that come with the [[#Examples| examples]] can be used as a reference. 12 12 13 The setup of the workflow engine will now be described on the basis of the "!ResourceBundleAdaptor", the setup for the database variant is very similar (see the [[#Phoneshop -Example|phoneshop example]] for comparison ). Note that the !AdminTool is only fully useable with the database.13 The setup of the workflow engine will now be described on the basis of the "!ResourceBundleAdaptor", the setup for the database variant is very similar (see the [[#PhoneshopExample|phoneshop example]] for comparison ). Note that the !AdminTool is only fully useable with the database. 14 14 15 15 For the "!ResourceBundleAdaptor" the access.properties defines the different roles of the system, the users with there login data and associated roles and rules which contain the roles. The workflow.properties defines the tasks with associated rules, class, priority and description as well as the forms if any. If there are forms there should also be a <formname>.properties for each form which includes the different fields of the form. The access.properties and workflow.properties are the only mandatory files for the "!ResourceBundleAdaptor", form properties and other files like custom classes are only to be created if needed. … … 64 64 65 65 66 After the setup the simulation of a net can be started. The net (or nets as a task can also include a subworkflow, see [[#Phoneshop -Example|phoneshop example]]) should include task-transition (from the [[WFNet]] plugin) for every task mentioned in the workflow.properties. As mentioned on the [[WFNet]] plugin page a task transition needs a inscription with the following syntax: [taskName,parameter(,result(,priority))]66 After the setup the simulation of a net can be started. The net (or nets as a task can also include a subworkflow, see [[#PhoneshopExample|phoneshop example]]) should include task-transition (from the [[WFNet]] plugin) for every task mentioned in the workflow.properties. As mentioned on the [[WFNet]] plugin page a task transition needs a inscription with the following syntax: [taskName,parameter(,result(,priority))] 67 67 68 68 * taskName - The name of the task, has to be in the workflow.properties