Mastering Filter Execution Options in BMC Remedy AR System

Mastering Filter Execution Options in BMC Remedy AR System: A Deep Dive for Practitioners

In the intricate world of BMC Remedy AR System (now part of BMC Helix ITSM), workflow automation is the engine that drives efficiency and ensures business processes run smoothly. At the heart of this automation lies the powerful filter object. Filters are the unsung heroes, constantly monitoring for specific conditions and reacting to them in sophisticated ways. But what truly dictates *when* a filter springs into action? The answer lies in its Filter Execution Options. Understanding these options is paramount for any AR System developer, administrator, or consultant looking to build robust, responsive, and predictable workflows.

This article will take you on a comprehensive journey through the various filter execution options, explaining their nuances, practical applications, and how they interact with other AR System components. We’ll also touch upon related workflow actions and utilities that complement filter functionality, providing you with the knowledge to optimize your AR System solutions.

Understanding the Filter: The Core Workflow Object

Before we dive into execution options, let’s quickly reacquaint ourselves with what a filter is in BMC Remedy AR System. Think of it as a rule or an event-driven program that resides on the AR System server. It’s designed to:

Be triggered at the server level: Filters don’t run on the client side; they are processed by the AR System server itself, ensuring consistent behavior across all users.
Interact with the database: Filters are designed to query, retrieve, and sometimes modify data stored within the AR System database.
Run in response to specific operations: A filter waits for a particular event or action to occur before it evaluates its qualification.
Act on the current request if it meets a qualification: The filter’s qualification is its gatekeeper. Only if the current request satisfies this condition will the filter’s actions be executed.
Execute on the AR System server with administrator permissions: This grants filters the necessary power to perform their tasks but also emphasizes the need for careful design to avoid unintended consequences.
Typically operate at the form level: While their execution is server-side, filters are usually associated with a specific form and operate on requests within that form. Their default execution order is often 500, but this can be customized.

The Heart of the Matter: Filter Execution Options

The Execution Option of a filter is a crucial setting that defines the specific event or operation that will trigger its evaluation and potential execution. When a user or a system process performs an action on a request within a form, the AR System server checks if any filters are configured to run for that particular operation and if the filter’s qualification is met. Let’s break down each execution option:

1. Modify

Description: Executes when a request is modified.

In Practice: This is perhaps one of the most common and intuitive execution options. Whenever a user or a process makes a change to an existing record (a request) in a form, and then saves those changes (e.g., clicks “Save” or implicitly through another action that commits changes), a filter set to ‘Modify’ will be evaluated. If the filter’s qualification is met, its actions will run.

Real-World Example: Imagine a filter on the ‘Incident’ form that’s set to ‘Modify’ and has a qualification like 'Status' = "Resolved" AND 'Resolution' != "AR Admin Default Response". When an agent modifies an incident, changes the status to “Resolved,” and provides a specific resolution (not the default one), this filter might trigger to send a notification to the customer or update a related record. If the agent only changes the ‘Assignee’ field and doesn’t change the ‘Status’ to “Resolved,” this specific filter wouldn’t be triggered by that modification.

Troubleshooting Tip: If a filter set to ‘Modify’ isn’t running, check the qualification carefully. Ensure the fields being modified are actually part of the filter’s qualification expression. Also, verify that the user performing the modification has the necessary permissions. Sometimes, a ‘Commit Changes’ action from an Active Link might be performing the modification, and the timing of that commit relative to the filter execution can be important.

2. Submit

Description: Executes when a request is submitted to the server.

In Practice: This option fires when a brand new request is created and committed to the database. This is the perfect moment to perform initial data validation, assign default values, set up relationships, or trigger initial notifications for a new entry. It runs *after* the data has been successfully written to the database.

Real-World Example: Consider a filter on the ‘Change Request’ form set to ‘Submit’ with no specific qualification (meaning it always runs for submissions). Its action could be to assign a unique Change ID that is automatically incremented, or to set the ‘Requestor’ field to the currently logged-in user if it’s left blank. Another example: a filter could automatically create a related task record when a new service request is submitted.

Interview Relevance: “Can you explain the difference between ‘Submit’ and ‘Modify’ execution options for filters, and when would you use each?” This is a fundamental question to gauge understanding of basic filter behavior.

3. Delete

Description: Executes when a request is deleted.

In Practice: When a request is removed from the database, a filter configured with the ‘Delete’ execution option will be triggered. This is useful for maintaining data integrity, performing cleanup operations, or logging the deletion of sensitive information. It’s important to note that the request data might still be accessible for a very brief period during the deletion process, allowing filters to act upon it.

Real-World Example: If a customer record is deleted, a ‘Delete’ filter might be configured to remove all associated contact information or related support tickets from other forms to prevent orphaned data. Or, it might log the deletion event with details about who deleted the record and when into an audit log form.

Troubleshooting Tip: Deleting is a destructive operation. If a ‘Delete’ filter isn’t running, ensure the user has permission to delete the record. Also, be aware that complex relationships or workflow might interfere with the clean deletion process. Test deletions in a non-production environment.

4. Get Entry

Description: Executes when a request is retrieved.

In Practice: This is a more specialized option. It triggers when a user or a system process performs a search or opens an existing record to view its details. It’s not about changing data, but rather about reacting to the act of *retrieving* data. This can be used for auditing access, dynamically populating fields based on the retrieved record, or triggering other workflow based on what’s being viewed.

Real-World Example: A filter set to ‘Get Entry’ on a sensitive ‘Confidential Information’ form might log every time a record is viewed, noting the user and timestamp. Another use case could be on a ‘Knowledge Article’ form, where viewing an article increments a ‘View Count’ field via a filter set to ‘Get Entry’ and a subsequent ‘Set Fields’ or ‘Push Fields’ action.

Interview Relevance: “How can you track or audit when a specific record is viewed in BMC Remedy without directly modifying the record itself?” The answer often involves the ‘Get Entry’ filter execution option.

5. Merge

Description: Executes when a request is merged into the database by using BMC Remedy Data Import, a DSO independent copy transfer, or the data import command line interface.

In Practice: This option is specifically designed for bulk data import scenarios. When you use tools like AR System’s Data Import, or when data is replicated via Distributed Server Option (DSO), filters set to ‘Merge’ will be evaluated. This is critical for ensuring that data being imported is validated, transformed, or related correctly upon entry into the system.

Real-World Example: If you’re importing thousands of new user records from a CSV file using Data Import, a filter set to ‘Merge’ could run for each record. This filter might check if a user with the same login ID already exists (and potentially update it if the ‘Merge’ option is handled by the import tool in a specific way, or create a new one), assign default group memberships, or set initial status values. Without this option, imported data might bypass crucial business logic.

Troubleshooting Tip: When importing large datasets, ‘Merge’ filters can significantly impact import performance. If imports are slow, analyze the efficiency of your ‘Merge’ filters. Ensure their qualifications are optimized and their actions are not overly complex or resource-intensive.

6. Service

Description: Executes when a Service active link action is performed. The filter accesses a request with the field values passed by the active link action and those retrieved from the database, if any, and returns output values to the calling request. No other database operation is performed.

In Practice: This is a unique execution option that bridges the gap between Active Links and Filters. When an Active Link performs a ‘Service’ action, it essentially “calls” a filter designed to run with the ‘Service’ execution option. The Active Link passes data to this filter, and the filter can perform some processing (without directly modifying the database itself) and return results back to the Active Link. This is powerful for encapsulating complex logic within filters that can be invoked by client-side workflow.

Real-World Example: An Active Link on a form might have a button that, when clicked, triggers a ‘Service’ action. This action could pass the current request’s ID and a specific parameter to a filter. The filter, set to ‘Service,’ might then query a different form, perform calculations based on the data from both the calling request and the queried form, and return a calculated value (e.g., an estimated delivery date) back to the Active Link. The Active Link can then display this value to the user or use it in further client-side actions. Crucially, this filter itself doesn’t save anything to the database.

Interview Relevance: “Explain the role of the ‘Service’ execution option for filters and how it differs from other options.” This question probes understanding of how Active Links and Filters can interact more dynamically.

Key Workflow Actions and Their Relevance to Filters

Filters don’t operate in isolation. They often leverage various workflow actions to achieve their objectives. Understanding which actions are available to filters and how they can be used is essential for effective workflow design.

Action Type	Filters	Description/Relevance
Distributed Server Option (DSO)	✔	Allows filters to participate in or initiate DSO-related operations, often used for data replication or synchronization between AR System servers.
Direct SQL	✔	This is a potent but potentially risky action. It allows filters to execute raw SQL commands directly against a database. Crucially, BMC strongly advises against using this to modify AR System’s own internal tables, as it can lead to severe data corruption. Its primary use is for integration with external databases. Real-World Example: A filter might use Direct SQL to push updated customer contact information from an AR System form into a separate marketing database or CRM system. Or, it might query an external inventory system to retrieve stock levels to display on an AR System form. Troubleshooting Tip: Always test Direct SQL thoroughly in a development environment. Ensure your SQL syntax is correct and that the target database is accessible. Be extremely cautious with data modification statements.
Go to Guide Label	✔	Used within workflow organized into guides. This action allows a filter to jump to a predefined “label” within the guide, effectively redirecting the execution flow. This is excellent for creating modular and reusable workflow logic, allowing a filter to branch to a specific set of actions or repeat a section. Real-World Example: In a complex incident resolution process guide, a filter might, based on the incident severity, use “Go to Guide Label” to jump to a section handling high-priority escalations, bypassing standard resolution steps.
Goto	✔	Similar to “Go to Guide Label” but does not require the workflow to be organized into a guide. This action allows a filter to jump to another filter or active link based on its execution order. You can specify a static or variable execution order value. This is useful for creating loops or jumping to a specific point in the workflow for re-evaluation. Real-World Example: A filter might repeatedly validate a set of data fields. If validation fails, it uses “Goto” to jump back to the start of its validation logic (or a preceding filter’s logic) to re-evaluate after a modification is potentially made by another part of the workflow.
Log to File	✔	Allows filters to write custom messages or data to a specified log file on the AR System server. This is invaluable for debugging and auditing, providing detailed insights into filter execution paths and data values. Real-World Example: When troubleshooting a complex filter, you might add “Log to File” actions at various points to see the values of key variables, the qualification results, or to confirm that a particular branch of logic is being executed.
Message	✔	Displays a message dialog box to the user. This can be used to inform the user about the status of an operation, provide warnings, or confirm actions. When used in filters, it’s typically to provide feedback to the user after an operation triggered by the filter. Real-World Example: After a filter successfully merges data from one form to another, it might display a message like “Related information has been successfully updated.”
Notify	✔	Sends an email or other notification to specified recipients. This is a cornerstone of alerting users about important events. Real-World Example: A ‘Submit’ filter on an ‘Approval’ form might use “Notify” to alert the designated approver that a new approval request is awaiting their action.
Push Fields	✔	This is one of the most frequently used actions. It allows filters to copy values from fields in the current request to fields in another request (on the same or a different form), or even to create a new request if one doesn’t exist and the tool allows. It’s essential for data propagation and maintaining consistency across forms. Real-World Example: When a ‘Change Request’ is approved, a ‘Modify’ filter on the ‘Change Request’ form might use “Push Fields” to copy the ‘Change ID’ and ‘Summary’ to a related ‘Release Schedule’ form.
Run Process	✔	Enables filters to execute external programs or scripts on the AR System server or a client machine. This is incredibly versatile for interacting with other systems or performing tasks outside the direct scope of AR System. Real-World Example: A filter might use “Run Process” to trigger a custom script that generates a PDF report of the current request’s details, or to send an SMS notification via an external service.
Service	✔	As discussed earlier, this action is used by Active Links to call a filter with a ‘Service’ execution option. The filter itself also uses this action to initiate the “service call” to another filter (though this is less common than Active Links calling filters). Its key is inter-workflow communication without direct database writes.
Set Fields	✔	Allows filters to set values in fields within the current request. This is fundamental for updating data, assigning default values, performing calculations, and manipulating field content based on conditions. Real-World Example: A ‘Submit’ filter might use “Set Fields” to calculate a ‘Due Date’ based on the ‘Submission Date’ and a predefined service level agreement (SLA) duration.

The arsignal Utility: Server-Level Control

While filters execute in response to user or system actions, the arsignal utility provides a way to force the AR System server to reload or update its internal information. This is often used by administrators to ensure configuration changes or definition updates are recognized by the running server without requiring a full restart.

arsignal can signal the server to reload various components, including:

-a (Alert user info): Updates internal alert user information.
-b (Archive definitions): Recaches and reloads archive definitions.
-c (Configuration file): Reloads the server’s configuration file (e.g., ar.conf or ar.cfg).
-d (DSO process): Transfers a signal to a DSO process.
-e (Escalation definitions): Recaches and reloads escalation definitions. This is important if you’ve modified an escalation and want it to take effect immediately.
-g (Group and data dictionary): Reloads group and data dictionary information from the database.
-l (License information): Reloads license information.
-m (Computed group information): Reloads computed group information.
-p (Application process): Transfers a signal to an application process.
-r (Definitions from database): Recaches definitions from the database. This is a broad command that can refresh various cached definitions.
-u (User information): Reloads user information.

Real-World Example: After adding a new custom group in AR System Administration Console and wanting to immediately apply it to existing filters that might use group permissions, an administrator might use arsignal -g to refresh group information without restarting the server. Similarly, arsignal -e would be used after modifying an escalation.

Troubleshooting Tip: If a change to a server-side object (like an escalation or a form definition) doesn’t seem to be taking effect, arsignal is often the first command to consider. However, always consult the documentation for the specific sigArgument you are using.

Troubleshooting Common Filter Execution Issues

Filter execution issues are a common headache for AR System developers. Here are some typical scenarios and how to approach them:

Filter not running at all:
- Check the Execution Option: Is it set to the correct event (Submit, Modify, Delete, etc.)?
- Verify the Qualification: Is the qualification too restrictive, or is it based on fields that are not being set or modified as expected? Use the ‘Log to File’ action within the filter to print field values and qualification results.
- Execution Order: If another filter with a lower execution order (executed earlier) is aborting the workflow (e.g., using ‘Return$), your filter might never be reached.
- Form Association: Is the filter associated with the correct form?
- Permissions: Does the user performing the action have the necessary permissions on the form and its fields?
Filter running, but not performing the correct action:
- Action Configuration: Double-check the configuration of the specific action (e.g., ‘Push Fields’, ‘Set Fields’). Are the source and destination fields correct? Are the values being mapped as intended?
- Order of Actions within the Filter: If a filter has multiple actions, their execution order matters.
- Data Issues: Is there unexpected data in the fields that the filter is acting upon?
Performance degradation due to filters:
- Complex Qualifications: Overly complex or inefficient qualifications can slow down filter evaluation.
- Inefficient Actions: Actions like ‘Direct SQL’ without proper optimization, or ‘Push Fields’ to a large number of records, can be performance bottlenecks.
- Excessive Filters: Having too many filters triggered by a single operation, especially on heavily used forms, can impact performance.
- Recursive Filters: Be extremely careful to avoid filter loops where a filter triggers itself indirectly, leading to an infinite execution cycle. AR System has built-in protection against this, but it will generate errors and consume significant resources.

Interview Relevance: Essential Questions for AR System Roles

Understanding filter execution options is a hallmark of a proficient AR System professional. Here are some questions you might encounter in interviews:

“Explain the purpose of each filter execution option (Modify, Submit, Delete, Get Entry, Merge, Service).”
“How would you use a ‘Get Entry’ filter to audit record access without altering the record?”
“Describe a scenario where using the ‘Merge’ execution option would be critical.”
“What are the risks associated with using the ‘Direct SQL’ action in a filter, and when might you still consider it?”
“How can you control the flow of execution within multiple filters on a single form?” (Hint: Execution Order, Goto actions)
“When would you choose a filter with ‘Service’ execution over a standard filter?”
“Imagine a requirement to notify a manager whenever a critical incident is submitted. Which execution option and workflow actions would you use?”

Conclusion

Filter execution options are the linchpin of effective workflow automation in BMC Remedy AR System. By meticulously choosing the appropriate option and leveraging the powerful workflow actions available, you can craft sophisticated solutions that respond precisely to your business needs. Whether you’re building initial data validation with ‘Submit’, handling real-time updates with ‘Modify’, managing bulk imports with ‘Merge’, or enabling complex client-server interactions with ‘Service’, a solid grasp of these options will elevate your AR System development skills. Remember to always test thoroughly, prioritize performance, and use logging for effective troubleshooting. Mastering these concepts isn’t just about knowing the options; it’s about understanding the strategic impact they have on your AR System implementation.