Workflow coding style

In BMC Remedy AR System, workflow refers to operations carried out by active links, filters, and escalations. Workflow can be triggered by user actions (such as submitting a form or clicking a button), by other workflow, and by time. Workflow acts on the data stored in forms to automate business processes.

This topic provides recommendations concerning workflow coding style.

• Guides
• Unqualified searches
• DSO aware workflow

Guides

Use guides to group and reuse workflow as functions. The BMC Remedy AR System is flexible in its support for guides, which can lead to poor coding styles. For example, it is possible to define a set of workflows within a guide, attach the guide to several forms, but not attach specific workflow items within the guide to the same set of forms. This approach can lead to selectively skipping workflow on specific forms. BMC recommends that you not use this technique but instead define guides with workflow that is always attached to the same forms as the guide. 

Unqualified searches

Always develop in the most restrictive setting with the server setting Allow Unqualified Searches unselected. This raises more awareness for the need to qualify tables and other workflow objects. For client-side active links that start on Search mode, remember that all fields being set should be accessible and visible to end users so that if unqualified searches are permitted at their site the expected result occurs in the client. For more information, see Avoiding unqualified searches.

DSO aware workflow

The Distributed Server Option (DSO) that is available with the BMC Remedy AR System platform enables you to transfer data between forms on two servers. It requires you to configure the DSO service, create mappings to map forms and fields between the two servers, and to create DSO workflow (filters) to perform the transfer and delete functionality. For more information, see Configuring the Distributed Server Option (DSO) Service for BMC Remedy ITSM and Configuring BMC Remedy Distributed Server Option.

The DSO filter that transfers the data starts on a merge action, and the DSO delete filter starts on a delete action. To avoid a clash between out-of-the-box workflow and the DSO merge filters, qualify the merge filters to not start if the user is a distributed server.

Because the DSO delete filter deletes the form records, bypass all the out-of-the-box delete workflow so that it does not start when triggered by a DSO delete.

Make the out-of-the-box workflow DSO aware by performing the following actions as coding standards:

1. DSO qualify any new merge filters that you create. The exceptions are the merge filters that check for unique records and provide messages (as those need to be caught on a DSO transaction, too). Add the following information to the Run IF qualification for the merge filters:

   AND ($USER$ \!= "Distributed Server")

   
   Some filters have a mix of OR and AND clauses in the Run IF qualification, so ensure that you have the brackets in the correct place, for example:

   (($OPERATION$ = "CREATE" ) OR ($OPERATION$ = "MERGE" ) OR
   (($OPERATION$ = "SET" ) AND ( 'z1D Action' = "BUILDUNIQUE" ))) AND (
   'Permission Group Type' = "Application Permission") AND ( 'z1D Previous
   Operation' = "SET" ) AND ($USER$ \!= "Distributed Server" )

2. Add any new forms with delete workflow to this shared workflow:

   SHR:SHR:SkipDeleteFiltersFor_DSO_User

Related topics

Workflow overview
Creating guides