Workflow
Workflow is a powerful tool to overlay client-specific business logic on top of baseline NetForum objects (for example, Individual, Organization, or Membership) in a way that keeps a site on the upgrade path. As workflow is set up at the object level, it will be called in iWeb, eWeb, and xWeb.
Note: SQL back-end updates to a column do not trigger a workflow, as those updates are not tied to a baseline NetForum object.
Workflow is made up of two concepts: a Workflow Rule and one or more Workflow Tasks linked to the Rule. A Rule is tied to a NetForum Object and defines when the workflow will be triggered. A Rule will have one or more Tasks, which are actions that are executed when the Rule is invoked.
Important! In order to create or edit a Workflow, a user must have a Toolkit license.
The word workflow means different things to different people. In NetForum, Workflow is not the same as a Wizard. Workflow doesn't walk you through a series of pages or processes. An end user will not "see" Workflow on a web page--what Workflow does is invisible and behind the scenes. Workflow tasks can be developed to create Tasks and send Emails that prompt users to do things, but Workflow will not automatically guide a user from one page to another page to another page.
Custom Facade Objects
Abila has altered all baseline facade objects to look for Workflow. Any custom Facade objects developed by clients or Abila implementation staff will require additional code in the Insert, Update and Delete methods to call WorkFlowUtils.CheckRules() method if that Object is to execute Workflow.
In the Commit() and RollBack() section of the code in each of the Insert, Update and Delete methods of your custom Facade object, you need to call WorkFlowUtils.CheckRules() method with the appropriate enumerator as WorkflowUtils.Operation.Insert, WorkflowUtils.Operation.Update and WorkflowUtils.Operation.Delete.
Here is an example where we had added the additional code to call WorkFlowUtils.CheckRules() method in an object's HardDelete method. The additional code is surrounded by comments //Workflow Call
if (oEr.Number == 0){ //Workflow Call if (CurrentTransaction == null) { oTrx.Commit(); oTrx = null; } WorkflowUtils.CheckRules((FacadeClass)this, WorkflowUtils.Operation.Delete, oConn, oTrx); //Workflow Call this.ListNeedsRefresh = true;}else{if (CurrentTransaction == null)oTrx.Rollback();}if (CurrentConnection == null)oConn.Close();
As noted above, the enumerator needs to be changed to or in the respective methods in the CheckRules method call.
WorkflowUtils.Operation.Delete
WorkflowUtils.Operation.Insert
WorkflowUtils.Operation.Update
Debugging Workflow
If your workflow is not firing, consider the following questions:
- Is the WorkFlowEnabled System Option set to True?
- Is the supports workflow checkbox on the Workflow Object checked?
- Is the Form you are saving associated with the Workflow Object? Remember that Workflow fires at the Object level. Check the Form where you are expecting to see the Workflow firing to confirm that it is based on the Workflow Object.
- Make sure that the first Task you want to fire has the start task checkbox selected, or else the Workflow will not know where to start.
- Is the active check box on the Workflow rule selected? The rule is not in effect until it is marked as active.
- Have you just changed your Workflow definition but the change does not seem to be taking effect? If so, clear cache. NetForum caches certain parts of Workflow metadata for performance, so you might need to clear the cache before your revised Workflow takes effect.
- See Workflow Tasks for more troubleshooting tips.
- If the Object of the Workflow is a custom class that inherits from a base facade class, then in your class you need this line of code: this.bExecuteInheritedWorkflow = true; to make Workflow execute. See FacadeClass Properties for more. For example:
namespace ZZZComponents{ class ZZZIndividual : Avectra.netForum.Components.CO.CO_Individual { public ZZZIndividual() { this.bExecuteInheritedWorkflow = true; }