This documentation supports the 18.05 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.

Filter phases

Actions within filters are carried out in one of three phases. All Phase 1 actions are carried out immediately. Phase 2 and Phase 3 actions are queued to be carried out later. See Use case scenario for filter processing.

Using a phased approach to filter processing helps to make sure the following actions occur:

  • Notifications are sent and that processes are run only after the database operations are successful. If any database operation fails, all subsequent actions are suppressed, and database changes are rolled back. So, the system defers to a final phase the operations that should not run until database transactions have been committed and there is no chance that a rollback occurs.
    For example, you can create a filter to notify Shipping that a purchase order is ready to be fulfilled. If, during the filter processing, an error occurs, the chain of events are rolled back, and the transaction is not committed to the database. Without phases in filter processing, Shipping would be notified and the equipment would be sent, but no record of the task would be committed to the database.
  • All data values are complete and available to the notification that is sent as well as to Push Fields operations that create related records.
  • Obtaining a write lock (which is an exclusive lock) for a Push Fields operation is delayed until the point at which a write is performed to the main data table. This shortens the duration of the exclusive portion of the transaction, and improves throughput.

Phase 1 actions

The following Phase 1 actions are always performed as soon as they can be:

  • Call Guide
  • Exit Guide
  • GoTo
  • Go To Guide Label
  • Log to File
  • Message
  • Set Fields
  • Service

Phase 2 actions

Phase 2 actions are queued when they are encountered and performed after all Phase 1 actions from all filters execute. If a Phase 2 action triggers more Phase 1 actions, then those Phase 1 actions are performed before the next Phase 2 action. If a Phase 2 action triggers more Phase 2 actions, then they are added to the end of the Phase 2 queue.

Each request with a filter executing against it has its own Phase 2 queue. So if a Push Fields action triggers the execution of a nested filter against the target request, the Phase 2 action in that filter that apply to that request are queued separately in the Phase 2 queue for that request. Those Phase 2 actions are run after the Phase 1 action in the nested filter are complete. The remaining Phase 2 actions in the outer filter are run after the nested filter Phase 2 actions.

Phase 2 actions include:

  • Push Fields
  • Direct SQL

Phase 3 actions

Phase 3 actions do not include any database interaction. All Phase 3 actions encountered are queued and performed after all Phase 1 and Phase 2 actions.

Unlike the separate Phase 2 queues, there is one Phase 3 queue for the request against which filter execution is originally triggered and any other requests which have filters

Phase 3 actions include:

  • Notify
  • Run Process
  • DSO

Phase 3 actions are presumed successful, but can fail and not affect the operation's success.

Filter phasing exceptions

There are exceptions to the phasing process:

  • For get actions (filters with Execute On set to Get Entry) and delete actions, Phase 1 and Phase 3 actions occur together.
  • For get operations, there is generally no database change, so the actions need not be phased. However, there might be database changes as the result of Push Fields actions that the get operation triggers.
  • For delete operations, you cannot defer actions because the delete action removes the current record, so the record would not be available for the actions later. The subsequent actions need to run when the data is still present.

The following tables further describe when certain operations are processed.

Filter phasing for Create and Merge operations
1 Filters run (including Phase 1 actions).


2 Create operation. (Entry ID is created.) Database transaction occurs.
3 Phase 2 actions occur.
4 Phase 3 actions occur.


Filter phasing for Set operations
1 Filters run (including Phase 1 actions).


2 Phase 2 actions occur. Database transaction occurs.
3 Entry is modified in the database.
4 Phase 3 actions occur.


Filter phasing for Get operations
1 Data is retrieved from the database.


2 Filters run (including all Phase 1 and 3 actions).


3 Phase 2 actions occur. Database transaction occurs.
Filter phasing for Delete operations
1 Filters run (including all Phase 1 and 3 actions).


2 Phase 2 actions occur. Database transaction occurs.
3 Entry is deleted in the database.

Overriding filter processing phasing

Sometimes, processing filter actions in phases is limiting or inefficient. For example, an application might be used as a subsystem of another application, where the results of the subsystem's work are needed immediately by the calling application. 

You can override phasing for Direct SQL, Notify, Run Process, and Distributed Server Option actions. If you override Push Fields actions, the actions take the intermediate values, but the database transaction is deferred.

Warning

Be very careful about how you use overriding filter processing phasing. Improper use can produce inconsistent, confusing, and potentially inaccurate results. It is recommended that you avoid using this capability unless it is critical to your functionality.



Remember, if you override the phases for a filter, Request IDs and create dates are not available during a Create operation. Also, a modified date is not available during a Create or Modify operation ($TIMESTAMP$ might be a suitable workaround in these situations). Furthermore, if there is a failure in the server, users might receive notifications for a request that does not really exist. 

Finally, the data values used during a given operation are the data values at the point at which the action is performed. This data value might not be the final value for some of the fields. The operation can be performed with intermediate values instead of the final values that you might expect. 

As an alternative, display-only fields are available, and they retain their values throughout the transaction. If your workflow needs an intermediate value at a later stage, storing it in a display-only field for later access is often the best answer. You get all the advantages offered by filter-action phases with respect to the transaction in progress and still retain the intermediate values.

The following sections discuss two methods for overriding filter processing phasing:

  • Using a special override naming convention
  • Releasing pending operations

 Using a special override naming convention

To override the phases for a specific filter, for example, one of a sequence of filters executed in a filter guide, you can force the filter run actions in-line (sequentially) by using a special convention for the filter name. When you create or modify the filter, its name must end in a back quote character followed by an exclamation point (`!) that has a Notify action runs the notification during Phase 1. 

Put the Phase 3 actions to run in Phase 1 in a filter with the override naming convention in a filter guide. Put actions that require normal phasing in filters without the special name elsewhere in the guide.

Important

The  __c Filter ignores the filter phases. 

For example, a filter "testFilter`!__c" ignores the filter phases.

 Releasing pending operations

Use the Application-Release-Pending Run Process command in a filter or escalation to open a database transaction to perform operations as various filter actions are performed instead of deferring the operations. 

When an Application-Release-Pending command is run, any Phase 2 actions queued by child filters are executed. This makes the changes due to these action available to the remaining action in the parent filter. 

For example, assume form A has workflow that includes a Push Fields actions that pushes values to form B and that form B has a filter with a Modify condition that is triggered by the Push Fields action. The form A workflow is suspended while the form B filter is executed and the form B filter is said to be a child of the form A workflow. If the form B filter runs Phase 2 actions, they remain queued until the form A workflow completes all its Phase 1 actions. This means that the form A workflow cannot use the modifications made by the form B filter Phase 2 actions. 

If the form A workflow includes a Run Process action with the Application-Release-Pending command after the Push Fields action and the form B filter execution, the Phase 2 actions queued by the form B filter are run at that point so that the rest of the form A workflow actions can use the modifications they make.

Note

The Application-Release-Pending is modified to automatically run in filter Phase 1. Therefore, you no longer need to use the special filter naming convention to override filter phasing for this command.

Delaying entry creation

To delay the creation of individual form entries so that they can be created in bulk, use the Application-Set-Filter-Phasing Run Process command. This command determines whether form entries are created when the workflow operation to create them occurs or whether they are created in bulk during a later filter phase. 

For more information, see Process commands.

Related topic

Filter processing in BMC Remedy AR System server


Was this page helpful? Yes No Submitting... Thank you

Comments