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.

Related topics

Filter-processing

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.

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.

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.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*