ARCHIBUS Web Central

Workflow Rules and Business Logic

Web Central applications are typically built using view panels and controls, such as forms, reports, or multi-dimensional reports. These view panels are data-bound, which means that they use Web Central framework to work with the business data stored in the database. They can display, filter, sort, edit, create new or delete existing data records just using Web Central's view format, without requiring any custom code to be written for the server.

The standard framework support is sufficient for most application needs, but not for all of them. Advanced applications may require additional business logic to be implemented on the server. For example, when the user submits new work request, the business logic for that action may or may not need to generate additional work order records based on the request data, send or not send email notifications depending on the user role, and so on.

In general, you use the data-bound controls to update fields of data that are entered and reported directly. For instance, you can update the Work Request Description with no other functionality than the default data-bindings. You use the business logic to update fields of data that need more calculation or control. For instance, When a Work Request gets a “Closed” status, you may need to ensure that related operations like debiting parts from inventory or charging back costs to account codes is triggered. Accordingly, you would always want to update the Work Request Status field via a business logic API that ensures that other related operations pertaining to that new status were completed correctly.

The business logic in Web Central is created in form of workflow rules and jobs. These are server-side functions that are either called from the user interface (message rules and jobs), or invoked at predefined time intervals (scheduled rules). Workflow rules can accept input parameters, such as user input values, and return results, such as messages or calculated values. Specific application parameters may be configured by the Site Administrator to be retrieved by a workflow rule. See "Using Application Configuration Parameters"

New in V18.1

Web Central V18.1 makes it easier to write business logic and to deploy it at customer sites by adding:

Class-level security: All public methods of specified event handler class can be registered as entries in the Workflow Rules table. You can add new methods – and therefore new workflow rules - without changing the database. This means that you can distribute updated business logic simply by distributing the compiled JAR file. You will only need to issue a database change if you add a new event handler class.
Simplified event handlers: You can define event handlers as regular Java methods with input parameters and return values. For most frequently used parameter types, there is no need to pull values out of the Event Handler Context, or to convert string into Java objects – the Workflow Rule Container does it automatically.

Event-handler class

An event-handler class is a Java class that holds a collection of methods that provide a related set of business functionality. For instance, the Cost Service event handler provides a set of methods for handling recurring, scheduled, and historical costs.

Event-handler method

An event-handler class contains a set of methods for each functional operation, such as approveScheduledCost() or createCostProjection().

Workflow Rule

You can call these methods from the Web Central interface by referencing the event-handler class and method name in actions on the interface forms, e.g.

<action id="Approve">
<title>Approve Scheduled Costs</title>
<command type="workflowRule" ruleId="AbCommonResources-CostService-approveScheduledCost"/>
</action>

Workflow Rules Table

To allow the event handler methods to be invoked from forms, you register the event-handler class with the Workflow Rules table. This table maps the rule name that you use in the form action to the name of the Java class that the program will execute. This table also defines the Security Group that a user should belong to in order to be able to execute the rule. The Workflow Rules table holds two types of entries:

Message Rules: These are rules that are invoked from messages sent from the interactive forms on the client browser when the user clicks an action button. You can register all methods of an event-handler class as workflow rules with a single class entry in the Workflow Rules table. You can also register each event-handler method individually, if certain methods, such as approval methods, require different security.
Scheduled Rules: These are methods of the service that the Web Central server itself invokes server-side on a regular schedule (every hour, day, etc.) You have one Workflow Rules table entry per method, as the Workflow Rules entry defines the schedule of how often the rule is to be invoked. Scheduled rules run in the context of the SYSTEM ADMINISTRATOR users’ account.

Typical Uses

Invoking Workflow Rules

Business Process Owners can invoke rules from their own forms by calling them from view actions.
Forms Integrators can invoke rules from Java Script.
Logic Integrators can invoke them from Java.

Securing Workflow Rules

You can control access to the services by specifying Security Groups for these services in the ARCHIBUS Workflow Rules (afm_wf_rules) table. Users must then be members of that group to invoke any part of that service.

Creating Workflow Rules

You can create your own workflow rules. You do so by writing a Java class with a series of public methods. You must register the service with the ARCHIBUS Workflow Rules table – you need one entry per new event handler class.

Scheduled Rules

You can also use the ARCHIBUS Workflow Rules table to define rules that should run on a particular schedule, such as every hour or every night. You need one entry per each scheduled event handler method.