Rel = file-list href = "./ OsWorkflow Basic Concept. Files / FileList.xml>
First, the concept of workflow
First, the concept of workflow
1. Steps, status and action
Workflows To describe steps (Step), steps of the step, the relationship between the steps, and the conditions and permissions to perform each step, each step may contain one or more action (anctions), the action will make The state of one step changes.
For an executive workflow, the switching handover is inevitable. A workflow has one or more current steps at a certain time, each of which has a status value, and the status value of the current step constitutes a status value of the workflow instance. Once a step is completed, then this step will no longer be the current step (but switching to a new step), usually a new current step will be established to ensure that the workflow continues. The final status value of the completed step is specified with the OLD-Status property, and the setting of this status value will occur before switching to other steps. The value of Old-Status can be arbitrary, but in general, we are set to finished.
Switch itself is an action result of an action. Each step can contain multiple actions, which action to load is determined by the ultimate user, external event, or TriggerD. As the action is completed, a specific step switch will also occur. The action can be limited to the user, user group, or current state. Each action must contain a Unconditional Result and 0 or more Conditional Results.
Therefore, in general, a workflow consists of multiple steps. Each step has a current state (for example: Queued, Underway, or finished), one step contains multiple actions. Each step contains multiple actions that can be performed. Each action has the conditions performed, and there is also a function to be executed. The action contains RESULTS that can change status and current workflow steps.
2. Results, Joins, And Splits
(1) UNCONDITIONAL RESULT
For each action, there must be a Unconditional Result. A Result is a series of instructions that will tell OSWORKFLOW what is going to do. This includes switching the workflow from one state to another.
(2) Conditional Result
Conditional Result is an extension of UNCONDITIONAL RESULT. It requires one or more Condition subtabs. The first CONDITIONAL (using the AND or OR type) indicates the step of switching, the occurrence of the switching step is caused by a user performs an action.
(3) Three different RESULTS (Conditional or Unconditional)
- A new, single step, and a combination of states.
- A combination split into two or more steps and states.
- Combine this and other switches into a new single step and a combination of states.
Each Different Result corresponds to a different XML description, you can read http://www.opensymphony.com/OSworkflow/workflow_2_6.dtd, get more information.
Note: Typically, a SPLIT or a JOIN will not cause a split or join to occur.
1 Single steps and status results can be described:
2 Split into multiple states from one state to describe:
...
Status = "underway" ooner = "$ {someowner}" /> Status = "underway" ooner = "$ {sometherowner}" /> 3 Multiple status merge into a state described: ... ... "Finished" .Equals (jn.getstep (6) .gedstatus () && "finished" .equals (jn.getstep (8) .getStatus ()) The above description may be a bit vague, but you should pay attention to the condition tag, which uses a "JN" variable, using this variable, you can form an expression to determine the condition of the merge action. This expression means: "When the state of ID = 6 and ID = 8 turns into the state of Finished, the combined action happens when the switches they want are JOIN =" 1 ". 3. External functions OsWorkflow defines a standard solution for external business logics to be defined and executed. This is achieved by using "functions". Osworkflow has two function, pre and post step functions. The preunctions is performed before the process of steps occur. An example is a function of acquiring the name of the caller name, and the name of the acquired caller is used as a result to switch to the state. Another example is the most recent caller of the pre-function to update most of the actions. These two functions are provided as a standard tool function, which is very practical in actual workflows. Post Functions has the same scope of application with Pre functions, and the POST Functions is performed after the state changes. An example of a typical Post Functions is: After an action is executed, send someone to someone email. For example: When a document is in the 'Research' step, and execute the 'MarkReadyforreView' action, you want to send an email to all Reviewers. There may be many reasons for using Post Functions and Pre functions. One is if the user clicks the completion button twice and sends two execution of the action, and the PRE function of this action will perform a long time, then this long period of execution may be executed multiple times, because the switching action is not yet At this time, OSWORKFLOW will consider the second execution action is reasonable. So to change this function into a Post function. Under normal circumstances, the pre function should be simple and can perform quickly. Functions can be defined in two separate locations: Step (STEP) and Action. Typically, Post Functions and Pre Functions are defined in an action. Pre-functions defined in the action refers to the function to be executed before the action occurs. When the workflow is switched, the function is used to do something, whether it is sending E_mail, or for future use setting variables. When post functions and pre functions are defined in STEP, the use is a bit different. Pre-functions defined in stepp refers to execution before switching to this STEP The function. Note: These functions will be applied to all switches of this step, even because this step itself is switched, for example, in the same step, all preunctions will also be called when transferred by the Queued state to the underway state. Similarly, Post Functions in Step will leave this step before the process leaves this step. 4. Trigger Functions Trigger Functions is the same as other functions, and the difference is that they are not linked to an action. They also logo through a unique ID. These functions are usually in an environment running in a system-level user or an informal user. Trigger Functions is used through the API of OsWorkflow. 5. Validators Validator is the validity used to check the input of an action. This action will be executed if you enter the eligible condition. If you do not meet the conditions, you will throw an invalidInputException exception. 6. Registers A Register is an auxiliary function that can return an object, which can be used to access other common objects in the function, especially in the entity in Workflow. The registered object can be any type, an example of a typical registration object is: Document, Metadata, Issue, and Task. Here is an example of registers: ... Owner = "$ {availableManager}" /> ... 7. Conditions Conditions can be implemented in different languages, like Validators, Registers, and Functions. Conditions can be organized with an AND or OR logic operator. Conditions is usually in contact with Conditional Results, and RESULT will only be executed when the condition is established. Conditions is very similar to the function, the only difference is that the conditiones return is the boolean value, not the void. 8. Variable Interpolation In all functions, conditions, validators, and registers, you may have to provide a range of parameters. These parameters will be converted to parameter map, which will be discussed later. Similarly, Status, Old-Status, and Owner tags in the Workflow descriptor will also be dynamically parsing into variables. A variable is identified: $ {foo}. When OSWORKFLOW identifies this format, it first goes to transientvars to find the keyword for foo, if not found, then go to the propertyset, if you have not found, the variable foo will be converted to an empty String. One thing of particular importance is that in the case of args, if the variable is the only argument, the argument will not be of type String, but instead whatever the variable type is. However, if the arg is a mix of characters and variables The entire argument is converted to string no matter what. That Means The Two Arguments Below Are Very Different In That Foo Is A Date Object and Bar Is A String: 9. Permissions and Restrictions Permissions can be assigned to users and / or groups based on the state of the workflow instance. These permissions are unrelated to the functionality of the workflow engine, but they are useful to have for applications that implement OSWorkflow. For example, a document management system might have the permission name "file-write-permission" enabled for a particular group only during the "Document Edit" stage of the workflow. That way your application can use the API to determine if files can be modified or not. This is useful as there could be a number of states within the workflow where the "file-write-permission" is applicable, so instead of checking for specific steps or conditions, the check can simply be made for a particular permission.10. Auto actions Sometimes, we need some actions to be automatically performed based on some conditions. To achieve this, you can join the auto = "true" attribute in the Action. The process will examine the conditions and limitations of this action. If the condition is in line, this action will be executed. Auto action is performed by the current caller, so the caller of the action will perform permission check. 11. Integrating with Abstract Entities It is recommended to create a new attribute within your core entity, such as "Document" or "Order". Create a new property inside: WorkflowID. This way, when new "document" or "ORDER" is created, it can associate with a Workflow instance. So, your code can find this Workflow instance through the OsWorkflow API and get the information and action of this Workflow. 12. Workflow Instance State Sometimes, specify a state for the entire Workflow instance is very helpful, it is independent of the process of executing the process. OsWorkflow provides "meta-states" that can be included in some Workflow instances. These "meta-states" can be created, activated, suspended, killed, and completed. When a workflow instance is created, it will be in the CREATED state. Then, as long as one action is executed, it will automatically become an Activated state. If the caller does not clearly change the status of the instance, the workflow will keep this state until the workflow is over. When the workflow is not possible to perform any other actions, the workflow will automatically become the Completed status.
