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 services. These are server-side functions that are either called from the user interface (workflow rule services and long-running jobs), or invoked based on server-side events (scheduled services and data event services). 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 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 service 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 service class.
• Simplified services: You can define services 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.

Workflow Rule Service Class

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

Workflow Rule Service Method

A workflow rule service 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 workflow rule class and method name in actions on the interface forms, such as:

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

Workflow Rules Table

To allow the workflow rule methods to be invoked from forms, you register the workflow rule service 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 three types of entries:

• Message Rules: These are rules that are invoked when users click action buttons on interactive forms in the client browser. You can register all methods of a workflow rule service class as workflow rules with a single class entry in the Workflow Rules table. You can also register each workflow rule service method individually, if certain methods, such as approval methods, require different security.
• Scheduled Rules: These are rules that the Web Central server invokes 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.
• Data Event Rules: These are rules that the Web Central server invokes in response to certain data change events, for example, changing a department in the Rooms table.

Typical Uses

Invoking Workflow Rules

• Business Process Owners can invoke rules from their own forms by calling them from view actions.
• Form 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 service 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 service method.