Workflow Rule Definitions

Creating Workflow Rule Definitions

The workflow rule services you add to the Archibus Workflow Rules (afm_wf_rules) table are the public interface to your business logic. Follow these guidelines:

  • Group related business logic operations into service classes. An example is the CostService (CostService.java) that encapsulates all logic for creating Scheduled Costs and moving approved Scheduled Costs to the Costs table. Name services in UpperCamelCase.
  • For each business operation, create a public method in the service class, e.g. createScheduledCosts. Name methods in lowerCamelCase.
  • Write a unit test for each method. If you have difficulty writing an isolated unit test for your Service, this is an indication that your Service might have too broad a contract and should be divided into multiple Services. (TestCostService.java is an example of a unit test)
  • If one or more of service methods execute long-running jobs, make the service class extend JobBase.
  • Create one Archibus Workflow Rules (afm_wf_rules) table entry for one service class if possible; that is, create a single rule entry that covers all methods in the AbCommonResource-CostServices class rather than separate rule entries for each method (e.g. AbCommonResources-CostServices-createScheduledCosts).
    • Exception 1: Scheduled workflow rules. If you have a scheduled workflow rule, you will need a rule entry for each scheduled workflow rule method.
    • Exception 2: Workflow rule methods with heightened security. The primary reason for registering workflow rules with the Archibus Workflow Rules table is security. Archibus Administrators can assign a Security Group to a workflow rule service to restrict the types of users that can execute that rule. You only need to create a separate Archibus Workflow Rules table record for a method if that method is likely to have a more restricted group of users than the whole class. For example, if you have a CapitalExpenses service, but you believe sites will want to restrict access to the CapitalExpenses-approveExpense method to just certain groups of users, then create a separate Archibus Workflow Rule for that method.

Understanding the Workflow Rule Fields

All workflow rules that are available for the application use are listed in the Workflow Rules (afm_wf_rules) database table. There is one database record per workflow rule. Some of the important database fields are:

  • activity_id : Primary Application .  (e.g. AbSolutionsWorkflow).  ID of the application that the workflow rule “belongs” to; serves to categorize and search workflow rules.
  • rule_id : Rule Name .  (e.g. helpDeskApprove) Unique ID of the workflow rule within its application.
  • rule_type : Rule Type .  Whether the workflow rule is a Message rule (called from the UI by an http message) or a Scheduled rule (run at predefined time intervals by the program itself).
  • group_name . Security Group .  (e.g. “SYS-USRMGR”) The security group that the user must belong to in order to be able to invoke the rule. An empty value allows any user to run the rule.
  • xml_rule_props : XML Rule Properties .  XML field containing additional workflow rule properties.  The most essential tag is the eventHandler tag (e.g. <eventHandler class="com.mycompany.eventhandler.helpdesk.HelpDeskExampleHandlers" method="helpDeskApprove"> . This tag holds the information about Java class and method that is invoked by this rule.
    • If you leave the method attribute empty, this Workflow Rule entry will control security for all public methods in the specified service class (class-level security).
  • xml_schedule_props : XML Schedule Properties .  XML field containing additional properties for scheduled rules only, such as startTime and repeatInterval.
  • is_active : Active? whether the workflow rule will be executed when called or if it has been centrally deactivated.


You can think of the Workflow Rules table as an organized, searchable registry of all logic rules that can be invoked within Web Central.  The table has two main purposes.

  • It maps Workflow Rule names (e.g. AbSolutionsWorkflow-helpDeskApprove ) to Java classes and methods that implement them. In this way, the table isolates the presentation layer from the details of the implementation.  This table lets team members working on business logic publish the API into the logic in a form that they or their colleagues can call from Archibus forms and views. The team members working on the Archibus forms and views can invoke this business logic just using the rule names; they do not need to know any of the details of the Java classes or use Java at all.
  • It controls the security of sensitive rules, such as approval rules or system management actions, by assigning Security Groups to rules.