Third, Osworkflow Validators
Like OsWorkflow function, OsWorkflow's Validators has three different forms: java-based, beanshell, and BSF. Java-based Validators must implement the com.Opensymphony.Workflow.valiDator interface (or if you want to implement the com.opensymphony.workflow.valiDatorRemote interface) if you via remote EJB. In all java-based validators, you have to throw an InvalidInputException.
However, in the implementation of Beanshell and BSF, the situation is slightly different because the exception thrown in Scripts cannot spread out in the Java runtime environment. In order to achieve this purpose, the value returned by Beanshell or BSF is returned as an error message, and the logic is like this:
- If returned is an InvalidInputException object, then this object will be immediately thrown to the client.
- If returned is a map, then this MAP is used in an error / error message pair in InvalInotInputException.
- If the returned is a string [], the even value is used as a keyword (key), the odd value is used to be used, so that the above MAP can be constructed.
- If it is not the three situations, the return value will be converted to a String object and as an error message.
Four, OSWORKFLOW Registers
The Register in OSWORKFLOW is a runtime variable that can be dynamically registered in the definition file of Workflow. Registers is very useful in many occasions. For example: You want to provide a way to get Workflow to access an entity in its descriptor file. At this time, you can define a register to encapject this entity. If this entity is a local session ejb, you have to use the com.opensymphony.workflow.util.ejb.local.localeJbregister registration class. For example, in the back post-function, you can access this entity and can call the method in this entity by Beanshell Script.
Registers also have three implementations: java-based, beanshell and bsf.
Java-based
Java-based Registers must implement the com.roencyysymphony.workflow.register interface (or if it is remote EJB, you have to implement the com.opensymphony.workflow.registerRemote interface).
2. Beanshell and bsf registers
The values returned by Script or objects will be the object you registered.
Note: In the interface of Registers, you only need an Args Map parameter, which is because registers calls at all regardless of the user's input.
3. Example:
The following example will illustrate the functionality and use of the Register. Here REGISTER is used in a simple log Register, which has an accessible variable "log", which can be accessed within the life of the entire workflow. The logger can do a lot of useful jobs, such as adding an instance ID of the workflow to the logging. We define the REGISTER in the top layer of the descriptor file of Workflow.
As can be seen from the code, we created a logRegister called log, and also specified a value of TRUE to address the addressIDID.
We can use this variable anywhere in the Workflow descriptor file. E.g:
The above function will output "Function Called" and add an instance ID of Workflow before output.
V. Conditions
Among the Script of BSF and Beanshell, there is a special object called "JN". This variable is an instance of the com.opensymphony.workflow.joinNodes class, which is used in Join-Conditions. In addition, the differences between Conditions and Functions is that Conditions must return a TRUE or FALSE value. This value can be a string of "true" or "false", or a "true" or "false" Boolean, or even a function containing the toString (), its return value is "true" or " False "object.
Each Condition must be defined as a subtab as a conditions. When you use the "and" type, all the value of all the Condition tags must be "true", and the entire Conditions can be True. Otherwise, the entire Conditions will return "false". If you use the "OR" type, as long as there is a CONDition tag value "true", the entire Conditions is True, and only when all the Condition tags must be "false", the entire Conditions can be false. If you want more complex logical judgment, then you have to consider using the Condition or ConditionRemote interface, Beanshell or BSF. Note: If only one condition is included in the Conditions tab, the type can be omitted.
Here is some standards of OsWorkflow comes with the standard Conditions:
--OSuserGroupCondition - Use OSuse to determine if the caller is in the parameter "group".
--Statuscondition - Judging whether the status of the current step is the same as the parameter "status".
--Allowowneronlycondition - If the caller is the owner of the specified step, only Return true if you do not specify the step, return the current step. - Denyownercondition - Contrary to the AllowowNeronlyCondition function.
