Demystifying BMC Remedy AR System Filters: Your Workflow Powerhouse

In the intricate world of IT Service Management (ITSM), automation is the key to efficiency and accuracy. BMC Remedy AR System, a robust platform for managing IT services, offers a powerful suite of tools to achieve this. Among these, Filters stand out as crucial components of its workflow engine. If you’ve ever wondered how Remedy seamlessly automates tasks, responds to data changes, and keeps your processes running smoothly, you’re in for a treat. This article will dive deep into the heart of BMC Remedy AR System Filters, unraveling their purpose, functionality, and how they contribute to a streamlined workflow.

Understanding the AR System Workflow Engine

Before we zoom in on Filters, it’s essential to grasp the broader concept of workflow in BMC Remedy AR System. Think of workflow as the brain of your automated processes. It’s a sequence of actions designed to execute in response to specific events or conditions. The AR System platform orchestrates these actions using three primary workflow objects:

• Active Links: These are client-side workflow objects that trigger based on user interactions or information displayed on the current screen. They’re your go-to for immediate visual feedback, like changing field colors, displaying messages, or fetching data from other forms without a full server roundtrip.
• Filters: These are server-side workflow objects that react to changes in form transactions as data is processed. They’re the workhorses for enforcing business logic, updating related records, and ensuring data integrity.
• Escalations: Similar to Filters, Escalations are also server-side. However, their trigger isn’t a specific user action but rather a predetermined time interval. They’re perfect for periodic checks, reminders, or automated follow-ups on outstanding requests.

Essentially, workflow automates your company’s processes by linking these active components—Active Links, Filters, and Escalations—to trigger specific actions based on predefined conditions and execution options. Workflow generally refers to the collective operations orchestrated by these components within the AR System.

Deep Dive into BMC Remedy AR System Filters

Now, let’s shine a spotlight on Filters. Unlike Active Links that operate on the user’s machine in real-time interaction, Filters are server-bound. This means they execute on the BMC Remedy AR System server, benefiting from administrator-level permissions and direct access to the database. This server-side execution is key to their power and reliability.

What Triggers a Filter?

Filters are designed to react to specific operations occurring on forms. These operations, known as “Execution Options,” are the lifeblood of a filter’s trigger. When a request within a form undergoes one of these operations, the AR System server checks if any Filters are configured to act upon it. If a Filter’s qualification matches the current request and operation, the Filter springs into action.

The primary Execution Options that can trigger a Filter are:

• Submit: This is perhaps the most common trigger. When a new request is submitted to the server, the Filter can execute its actions. Think of validating data, creating related records, or assigning a default value.
• Modify: When an existing request is updated and submitted back to the server, a Modify trigger can be activated. This is perfect for updating related information, recalculating fields, or notifying stakeholders of a change.
• Delete: When a request is marked for deletion, a Delete trigger can initiate cleanup operations, such as removing associated data from other forms or logging the deletion.
• Get Entry: This trigger fires when a request is retrieved from the database. While less common for complex actions, it can be used for initial data population or setting up display-specific logic.
• Merge: This option is relevant when requests are consolidated or imported into the database using tools like BMC Remedy Data Import, DSO, or the command-line interface. Filters can ensure data consistency during these bulk operations.
• Service: This unique execution option allows a Filter to be invoked by a “Service” action from an Active Link or another Filter/Escalation. It’s a way to perform complex server-side logic without directly modifying the database initially, returning output values for further processing.

Audit Form Fields: A Closer Look at Trigger Actions

To understand the granular level of what triggers an action, consider these audit-related actions:

• 1 - GET ENTRY: Corresponds to retrieving a record.
• 2 - Set: Generally refers to modifying field values.
• 4 - Create: Directly maps to the ‘Submit’ operation.
• 8 - Delete: Directly maps to the ‘Delete’ operation.
• 16 - Merge: Corresponds to the ‘Merge’ operation.

These numerical values are often seen in server logs and diagnostic tools, helping pinpoint the exact operation that initiated a workflow event.

The Power of Qualifications

A Filter doesn’t just execute every time a form transaction occurs. It only acts if a specific qualification is met. This qualification is a logical expression that the current request must satisfy. For example, a Filter might only trigger if the ‘Status’ field of a ticket is set to ‘Closed’ and the ‘Resolution’ field is empty. This ensures that your automation is precise and only affects the relevant records.

Execution Order: Commanding the Flow

In the AR System, workflow objects are assigned an Execution Order number. This numerical value dictates the sequence in which Filters are processed. Filters with lower numbers are executed before those with higher numbers. The default execution order for Filters is 500, but you can adjust this to control the precise order of operations. This is crucial when multiple Filters might apply to the same transaction; you want to ensure they run in the intended sequence.

Interview Relevance: Understanding execution order is a common interview question. Be prepared to explain why it’s important and how you would troubleshoot workflow issues related to execution order.

Filter Actions: What Can They Do?

Once a Filter is triggered and its qualification is met, it performs a series of Actions. These actions are the core of what makes the workflow automation powerful. Here’s a look at some key actions available within Filters:

Common Filter Actions:

• Set Fields: This is a fundamental action that allows you to set the value of one or more fields in the current request. You can set static values, values from other fields, or dynamically calculated values.
• Push Fields: This action is used to transfer data from fields in the current request to fields in another request (on the same or a different form). It can be used to create new requests or update existing ones. This is a cornerstone for relational data updates and cascading changes.
• Log to File: Essential for debugging and auditing, this action writes information to a specified log file on the AR System server. It’s invaluable for tracing the execution path and understanding data flow.
• Message: Displays a message to the user. This can be an informational message, a warning, or an error.
• Run Process: This powerful action allows you to execute external programs or scripts on the AR System server or a client machine. This opens up a world of possibilities for integration with other systems, sending emails, or performing complex system tasks.
• Direct SQL: Enables you to execute raw SQL commands against a database. This is a critical action for integrating with non-AR System databases, but it comes with a significant caution.
• Commit Changes: When used in a Filter (though more commonly associated with Active Links in a dialog context), it can apply changes to the database, effectively performing the primary form action (Submit, Modify, Delete).
• Distributed Server Option: Used for operations involving distributed servers, allowing actions to be performed across multiple AR System server instances.
• Service: As mentioned earlier, this triggers other filters designed to perform specific services, often returning data for further processing without immediate database modification.

Actions Exclusive to Filters (and Escalations)

Some actions are specifically designed for server-side workflow and are not typically available in client-side Active Links:

• Call Guide: Executes a guide (a sequence of workflow objects) to perform a series of predefined steps.
• Exit Guide: Terminates the execution of a guide.
• Go to Guide Label: Redirects workflow execution to a specific labeled section within a guide. This is instrumental in creating modular and reusable workflow components.
• Goto: Similar to “Go to Guide Label” but doesn’t require the workflow to be part of a guide. It allows you to jump to a specific execution order number, effectively altering the normal sequence of Filter execution. This can be useful for looping or executing specific sets of actions multiple times.

Comparison Table: Workflow Action Availability

Filters vs. Escalations: A Clear Distinction

While both Filters and Escalations are server-side workflow objects that interact with the database and use similar actions, their triggering mechanisms are fundamentally different:

• Filters: Triggered by specific events like a record Submit, Modify, or Delete operation. They act on the current request that meets their qualification.
• Escalations: Triggered by a time interval. When an escalation runs, it scans the database for all requests that meet its qualification, not just the one currently being processed.

Think of it this way: A Filter is like a security guard reacting instantly when someone tries to enter a restricted area. An Escalation is like a daily patrol that checks all areas for any unauthorized activity.

Furthermore, Escalations are executed by a dedicated AR System server process, often referred to as the ar_escalator user, ensuring they run even when no interactive user is logged in.

Practical Examples and Use Cases

1. Auto-Assignment of Tickets

When a new Incident ticket is submitted (Execution Option: Submit), a Filter can check the ‘Category’ and ‘Subcategory’ fields. If these match certain criteria (Qualification), the Filter can use a Set Fields action to assign the ticket to a specific support group or individual by updating the ‘Assigned Group’ or ‘Assignee’ fields.

2. Data Validation and Derivation

Upon ticket modification (Execution Option: Modify), a Filter can validate that a ‘Resolution’ is provided if the ‘Status’ is changed to ‘Closed’. If not, it could display a Message action to the user or use Set Fields to force the user to select a resolution. It can also derive values, for instance, calculating the ‘Downtime Duration’ based on ‘Start Time’ and ‘End Time’ fields using a Set Fields action with a calculated expression.

3. Related Record Updates

When a Change Request is approved (Status changes to ‘Approved’ via Modify), a Filter can use the Push Fields action to create a corresponding Change Request Task record in a related form, pre-populating it with essential information from the Change Request.

4. Integration with External Systems

When a Problem Investigation ticket is resolved, a Filter can use the Run Process action to execute a script that sends an API call to an external CMDB system to update the status of a Configuration Item (CI) associated with the problem. Or, it might use Direct SQL to push data to a legacy database for reporting purposes.

5. Enforcing Data Integrity with Merges

During a data import (Execution Option: Merge), a Filter can run to ensure that incoming records don’t have duplicate ‘Request ID’s if that’s a business rule. It can also use Set Fields to populate missing mandatory fields based on existing data in other forms.

Troubleshooting Filter Execution Issues

When your automation doesn’t behave as expected, Filters are often the first place to look. Here’s a systematic approach to troubleshooting:

1. Check Server Logs: Enable detailed AR System logging. The AR System Server SQL Log and AR System Filter Log are your best friends. Look for entries related to the form and operation you’re testing. The arsignal utility (e.g., arsignal -e serverName) can force the server to reload escalation definitions, which is useful if you suspect definition caching issues. Similarly, arsignal -r serverName reloads all definitions from the database.
2. Verify Qualifications: Double-check the qualification used in your Filter. Ensure it’s correctly written and accurately reflects the conditions under which the Filter should run. Use the AR System API and tools to test your qualifications against sample data.
3. Examine Execution Order: If multiple Filters are involved, ensure their execution order is set correctly. A Filter running too late might not find the data it expects, or a Filter running too early might overwrite data needed by another.
4. Action Configuration: Meticulously review the configuration of each action within the Filter. Are the correct source and destination fields specified in Push Fields? Is the SQL statement valid in Direct SQL? Is the command line correct for Run Process?
5. Permissions: Remember Filters run with administrator permissions. However, if a Filter’s action involves interacting with another system (e.g., via Run Process), ensure the service account running the AR System server has the necessary permissions on the target system.
6. Filter vs. Active Link: Confirm you’ve built the workflow in the right place. If you need immediate user feedback or client-side actions, an Active Link is probably more appropriate. Filters are for server-side processing.
7. “Commit Changes” vs. “Run Process PERFORM-ACTION-APPLY”: For saving changes on modify, both can achieve the objective. However, for dynamic workflow generation where actions depend on field values that change during processing, Run Process is often preferred as its execution can be more dynamically controlled. “Commit Changes” tends to be more straightforwardly logged.

Advanced Considerations and Best Practices

• Modularity: Break down complex logic into smaller, reusable Filters. Use Go to Guide Label or Goto actions to manage the flow effectively. This makes troubleshooting and maintenance much easier.
• Documentation: Clearly document the purpose of each Filter, its qualification, and the actions it performs. Use comments within the Filter definition itself.
• Performance: Be mindful of the number of Filters, their complexity, and the efficiency of their qualifications and actions. Overly complex or numerous Filters can impact server performance. Avoid unnecessary database calls.
• Direct SQL Caution: While powerful for integration, avoid using Direct SQL to modify data in AR System’s own tables (especially those holding object definitions or form data). This is a recipe for data corruption and is unsupported. Stick to integrating with external databases.
• Service Action Nuances: Understand how the Service action behaves differently when used by Active Links versus Escalations, especially concerning database updates.

Conclusion: Empowering Your AR System with Filters

BMC Remedy AR System Filters are indispensable tools for building intelligent, automated business processes. By understanding their server-side nature, trigger mechanisms, and the wide array of actions they can perform, you can significantly enhance the efficiency, accuracy, and reliability of your IT service management operations. Whether it’s ensuring data integrity, automating ticket assignment, or integrating with external systems, Filters empower you to tailor the AR System to your unique business needs.

Mastering Filters is not just about knowing the technicalities; it’s about understanding how to leverage them strategically to create seamless workflows that drive business value. So, next time you encounter a process that feels a bit too manual, remember the power of the AR System Filter – your key to unlocking true automation.