Mastering AR System Workflows: A Comprehensive Call Guide
In the intricate world of enterprise service management, the ability to automate and streamline processes is paramount. BMC Remedy AR System, a robust platform for IT Service Management (ITSM), offers a powerful suite of workflow capabilities that can transform how your organization operates. This article serves as your in-depth guide to understanding and leveraging AR System workflows, with a particular focus on the “Call Guide” action and its role within Active Links, Filters, and Escalations. Whether you’re a seasoned AR System administrator, a developer, or an aspiring ITSM professional, this guide will equip you with the knowledge to build more efficient and intelligent applications.
What Exactly Are Workflows in AR System?
At its core, a workflow in AR System is the automated sequence of actions designed to accomplish a specific business process. Think of it as a digital blueprint for how tasks are executed, decisions are made, and data flows within your system. These workflows are not just static rules; they are dynamic engines that trigger actions based on predefined conditions, user interactions, or scheduled events. They are the backbone of automation, ensuring consistency, reducing manual errors, and accelerating operational efficiency.
AR System achieves this automation through three primary workflow objects:
- Active Links: These are client-side operations that respond to user interactions or information displayed on the current screen. They are your first line of response to what a user is doing right now.
- Filters: These are server-side processes that scrutinize form transactions as they are being processed. They act as gatekeepers and logic engines when data is submitted, modified, or deleted.
- Escalations: These are also server-side workflows, but their trigger is time-based. They periodically check the database for requests that meet specific criteria, allowing for proactive actions or scheduled maintenance.
Understanding the Building Blocks: Forms and Schema
Before diving deep into workflows, it’s crucial to grasp how AR System represents data. At the database level, forms are essentially tables. The structure of these forms, known as the schema, dictates how information is stored and retrieved. Workflow objects interact with these forms to manipulate data, display information, and drive business logic.
Active Links: Responding to User Interaction
Active Links are your go-to for creating dynamic user experiences. They are triggered by a user’s actions within the AR System interface. Imagine a scenario where clicking a button should instantly update a field with the current date and time, or perhaps change the color of a label to indicate a critical status. That’s the power of an Active Link.
Here are some key characteristics of Active Links:
- Client-Side Execution: They run within the user’s application window, providing immediate feedback.
- User-Driven: They are triggered by operations like clicking a button, selecting an item from a dropdown, or even just moving focus from one field to another.
- API Limitation: Importantly, Active Links cannot be triggered programmatically via an API. Their interaction is strictly human-driven.
- Naming Convention: AR System is smart enough to prevent duplicate names. If you try to create an Active Link with a name that already exists, the system will automatically append
_cto the new name. - Mandatory “Add” Action: Every Active Link must contain at least one “add” action, which is essentially the core operation it performs (e.g., setting a field value, displaying a message).
- Save As Behavior: When you save a form using the “Save As” function, Active Links are not copied over to the new form. However, if you rename the form, the associated Active Links will remain intact.
Filters: Enforcing Business Rules on the Server
Filters are the workhorses for enforcing business rules and data integrity. They operate on the server, scrutinizing data as it’s submitted, modified, or deleted from a form. This means they can perform complex validations, automatically populate fields based on other data, or even trigger external processes. Filters are executed with administrator privileges on the AR System server.
Key aspects of Filters:
- Server-Side Processing: They execute on the AR System server, giving them access to more robust processing power and the ability to interact directly with the database.
- Transaction-Triggered: Filters respond to specific operations on a form, such as submitting a new record, modifying an existing one, or deleting a record. The Execution Options table details these triggers.
- Database Interaction: Filters are designed to interact with the database, retrieving data as needed to make decisions or update records.
- Request Qualification: A filter only acts if the current request (the record being processed) meets a predefined qualification (a set of conditions).
- Form-Level Execution: Filters are associated with a specific form and execute based on operations on that form.
- Execution Order: Filters are assigned an execution order, typically starting at 500. This numerical order determines the sequence in which multiple filters on the same form are processed. Lower numbers execute before higher numbers.
Escalations: Time-Based Automation
Escalations are your solution for tasks that need to happen automatically at specific times or after a certain period has elapsed. Think of reminders for overdue tasks, automatic reassignment of tickets that have been idle for too long, or scheduled data cleanup. Unlike filters, which are reactive to user actions, escalations are proactive, driven by the clock.
Key characteristics of Escalations:
- Server-Side and Time-Driven: They run on the AR System server and are triggered by a schedule (e.g., every hour, every day at midnight) or a time interval.
- Database Scope: They can search and act upon all requests in the database that match their qualification, not just the current one being processed. This is a critical distinction from filters.
- Dedicated User: Escalations are executed by a specific system user, typically
ar_escalator, which helps in auditing and managing their permissions. - Proactive Operations: Their primary purpose is to find and act on records that meet certain conditions based on time, rather than direct user interaction.
Access Control: Securing Your Data
A critical aspect of any AR System implementation is managing who can see and do what. This is where Permission Groups and Roles come into play. These mechanisms allow administrators to define granular access controls, ensuring that users can only interact with the forms, rows (records), and columns (fields) they are authorized to. This is vital for maintaining data security and compliance.
The Powerhouse: Workflow Actions
Now, let’s talk about the actions that make workflows come alive. These are the specific operations that Active Links, Filters, and Escalations can perform. The choice of action depends on the workflow type and the desired outcome.
The “Call Guide” Action: Orchestrating Complex Logic
The Call Guide action is a fascinating and powerful tool. It allows you to delegate a complex sequence of operations to a separate workflow object called a “guide.” Think of a guide as a mini-workflow or a script that can be called upon by other workflows. This promotes modularity, reusability, and makes your overall workflow logic much more manageable. You can use it within both Active Links and Filters.
When to use Call Guide:
- When you have a set of steps that need to be executed multiple times across different workflows.
- To break down a very complex process into smaller, more digestible, and maintainable units.
- To create reusable logic blocks that can be easily updated in one place, affecting all workflows that call it.
Here’s a glimpse of how actions are distributed across workflow types, highlighting where Call Guide fits:
| Action Type | Active Links | Filters | Escalations |
|---|---|---|---|
| Call Guide | ✔ | ✔ | |
| Change Field | ✔ | ||
| Close Window | ✔ | ||
| Commit Changes | ✔ | ||
| Distributed Server Option | ✔ | ✔ | |
| Direct SQL | ✔ | ✔ | ✔ |
| Exit Guide | ✔ | ✔ | |
| Go to Guide Label | ✔ | ✔ | |
| Goto | ✔ | ✔ | |
| Log to File | ✔ | ✔ | ✔ |
| Message | ✔ | ✔ | ✔ |
| Notify | ✔ | ✔ | |
| Open Window | ✔ | ||
| Push Fields | ✔ | ✔ | ✔ |
| Run Process | ✔ | ✔ | ✔ |
| Service | ✔ | ✔ | ✔ |
| Set Fields | ✔ | ✔ | ✔ |
Filter Execution Options: When Do They Fire?
Filters are versatile, but their execution is tied to specific events within a form’s lifecycle. Understanding these options is key to ensuring your filters trigger precisely when you need them to.
| Execution Option | Description |
|---|---|
| Modify | Triggers when a request (record) is modified and saved. |
| Submit | Triggers when a new request is submitted to the server. |
| Delete | Triggers when a request is deleted. |
| Get Entry | Triggers when a request is retrieved from the database (e.g., during a search). |
| Merge | Executes when a request is merged into the database. This commonly occurs during data imports via tools like BMC Remedy Data Import, DSO, or the command-line interface. |
| Service | This is a special execution option. It’s triggered when a Service active link action is performed. The filter then accesses request data passed from the active link and from the database. It returns output values but does not perform any other database operations itself. This is powerful for passing data between different parts of a workflow or for interacting with external services. |
Deep Dive into Specific Workflow Actions
Let’s explore some of the most impactful workflow actions, understanding their nuances and use cases.
Actions Exclusive to Active Links
Some actions are designed purely for client-side, user-driven interactions:
- DDE (Dynamic Data Exchange): A legacy technology for data exchange between applications. Primarily used in older Active Links.
- Change Field: Dynamically modifies properties of fields on the client, such as their label, color, or visibility.
- Close Window: Closes the current AR System window.
- Commit Changes: This action is complex. When used with a dialog box (often in conjunction with Open Window/Close Window), it captures data from the dialog and pushes it to the parent form without an immediate database save. When used with a regular form, it performs the major form action (Submit, Search, Modify) and saves data to the database.
- OLE Automation: Another older technology for inter-application communication.
- Open Window: Opens a new AR System window, often used to display dialog boxes or navigate to other forms.
- Run Macro: Executes a pre-recorded macro in BMC Remedy User. This is client-side only and not available in the web client.
- Wait: Pauses the execution of an Active Link for a specified duration.
Actions for Filters and Escalations (and sometimes Active Links)
These actions are powerful server-side tools:
- Direct SQL: Allows you to submit any valid SQL command to a non-AR System database. Crucially, BMC strongly advises against using Direct SQL to modify AR System tables directly. This can lead to data corruption and is unsupported. Its intended use is for integrating with external databases.
- Go to Guide Label: Within a guide, this action allows you to jump to a specific labeled section, creating branching logic or loops.
- Goto: Similar to Go to Guide Label but is more general. It instructs the system to execute the next active link or filter with an execution order greater than or equal to a specified number. This can be used to re-execute a sequence of workflows.
- Log to File: Writes a message or variable content to a specified log file on the AR System server. Invaluable for debugging!
- Message: Displays a pop-up message to the user.
- Notify: Sends an email notification to specified recipients. This action is available in Filters but not Escalations.
Actions Available Across All Workflow Types (AL, FLR, ESCL)
These are the most versatile actions:
- Distributed Server Option (DSO): Facilitates data transfer between AR System servers.
- Push Fields: The workhorse for data synchronization. It copies values from specified fields in the current request to another request in the same or a different form. It can update existing records or create new ones.
- Run Process: Executes an external program or command on either the client or the server. This is highly flexible and can be used for scripting, interacting with other applications, or running AR System commands.
- Service: As mentioned, this action triggers filters with an “Execute On” condition of “Service.” It’s used to pass data for processing without direct database modifications in Active Links/Filters, or to set values in the database if output data is provided in Escalations. It can integrate with web services.
- Set Fields: The most fundamental action for modifying data. It allows you to set the value of one or more fields in the current request. This is crucial for updating records based on logic.
Understanding “Commit Changes” vs. “PERFORM-ACTION-APPLY” in Run Process
This is a common point of confusion. Both actions can save a request during a modify operation. However:
- Commit Changes is logged in the AR System server log files, providing an audit trail of the action.
- The specific action performed by Run Process (like
PERFORM-ACTION-APPLY) is not explicitly logged as “Commit Changes.”
When to use Run Process: It’s often preferred when you need to dynamically generate workflow actions. For example, if the action to be performed depends on a field’s value, Run Process allows you to construct the command line dynamically.
Audit Form Fields: Tracking Changes
Understanding how changes are logged is vital for auditing and troubleshooting. The Audit Form Fields provide a mechanism to track various actions performed on records. The Description column in the reference outlines these actions:
- 1 – GET ENTRY: When a record is retrieved.
- 2 – Set: When fields are set or modified.
- 4 – Create: When a new record is created.
- 8 – Delete: When a record is deleted.
- 16 – Merge: When a record is merged into the database.
These values are often bit-coded, meaning you can combine them to represent multiple actions occurring simultaneously. For instance, a value of 6 would indicate both “Set” (2) and “Create” (4) actions, which might happen during an initial record creation where fields are immediately populated.
Production Cache vs. Development Cache Mode
The AR System server’s cache mode significantly impacts performance and administrative operations:
- Production Cache Mode (Default): This is ideal for busy production environments. Administrative operations (like deploying new workflows or modifying configurations) create a separate, temporary copy of the cache. This allows regular users to continue working seamlessly without being interrupted.
- Development Cache Mode: In this mode, administrative operations can lock out other users from the shared cache. The system waits for all users to complete their operations before allowing administrative changes. This mode can be problematic for long-running tasks like escalations, as they might be incompatible with frequent administrator thread changes.
Understanding this distinction is crucial for planning deployments and troubleshooting performance issues. In production, aim for production cache mode. During development and testing, development cache mode can sometimes be useful for immediate reflection of changes, but always be mindful of the impact on other users.
Advanced Workflow Concepts and Utilities
Filter Phasing: Orchestrating Email Notifications
The E-Mail Engine and its associated configurations, like the Email_Notification web path, are part of how AR System handles outbound email notifications. This path specifies the base URL for email notifications. If it’s left blank, the system defaults to using the Default Web Path. This is important for ensuring that links within automated emails correctly point back to your AR System environment.
DSO Configuration for Firewalls
When dealing with Distributed Server Options (DSO) across different network segments, firewall configurations can be a hurdle. You might need to enable a placeholder mode from the DSO tab within the AR System configuration. This allows the DSO process to establish communication channels through firewalls by using predefined placeholders for communication endpoints.
The `arsignal` Utility: Commanding the AR System Server
The arsignal utility is a command-line tool used to send signals to the AR System server, forcing it to reload or update specific internal information. This is incredibly useful for making configuration changes take effect without restarting the entire server.
Here are some common `arsignal` commands:
arsignal -a serverName[:port][sigArgument]: Updates internal Alert user information.arsignal -c serverName[:port][sigArgument]: Reloads configuration fromar.conf(orar.cfg). This is essential after manually editing these files.arsignal -e serverName[:port][sigArgument]: Recaches and reloads escalation definitions. Use this after deploying new or modified escalations.arsignal -g serverName[:port][sigArgument]: Reloads group and data dictionary information from the database.arsignal -r serverName[:port][sigArgument]: Recaches definitions from the database. This is a general-purpose reload.arsignal -u serverName[:port][sigArgument]: Reloads user information.
Note: The serverName[:port] part is crucial. If you are running the command on the server itself, you might be able to omit the server name. Always refer to the official BMC documentation for the most up-to-date and comprehensive list of `arsignal` arguments and their specific functions.
Ports and Queues: Network Communication and Threading
The Ports and Queues Tab in AR System administration is where you configure the network communication channels for your server. This includes setting up server ports and RPC numbers. Crucially, this section also allows you to configure server queues and threads. AR System’s multithreaded architecture is designed to handle many concurrent operations efficiently. By tuning the server queues and threads, you can optimize how the server handles incoming requests, background tasks, and workflow processing, thereby improving overall system performance and responsiveness.
Troubleshooting Common Workflow Issues
Even with the best design, workflows can encounter problems. Here are some common pitfalls and how to address them:
1. Workflow Not Triggering
Possible Causes:
- Incorrect Qualification: The conditions defined in your filter or escalation are not being met by the record. Double-check the qualification logic.
- Execution Order Conflicts: For filters, an earlier filter might be terminating the workflow or modifying data in a way that prevents your filter from running. Verify the execution order of all relevant filters.
- Workflow Disabled: The active link, filter, or escalation might be accidentally disabled in the AR System application.
- Cache Issues: Especially after deploying changes, the server cache might not have updated. Use
arsignal -rorarsignal -eto force a reload. - Client-Side vs. Server-Side: Ensure you’re using the correct workflow type for the action. An active link won’t trigger on a server-side event, and vice-versa.
Troubleshooting Steps: Use the AR System logs (especially the API, Filter, and Escalation logs) to trace the execution flow. The Log to File action is your best friend here!
2. Workflow Performing Incorrect Actions
Possible Causes:
- Incorrect Field Mapping: In Push Fields or Set Fields actions, the source and destination fields might be mixed up, or the wrong fields selected.
- Data Type Mismatches: Attempting to push text data into a numeric field without proper conversion can lead to errors.
- Logic Errors in Qualifications: The logic for deciding whether to perform an action might be flawed.
- Unintended Side Effects: A workflow might be performing an action that inadvertently impacts another process or record.
Troubleshooting Steps: Use debug logging extensively. Step through the workflow in the debugger (if available) or add Message actions to display field values at critical points. Review the action configurations meticulously.
3. Performance Degradation
Possible Causes:
- Inefficient Queries: Filters or escalations that perform complex searches on large datasets without proper indexing can be very slow.
- Excessive Workflow Chaining: Too many workflows triggering each other in a loop or a very long chain can consume significant resources.
- Direct SQL to Non-Indexed Tables: Poorly optimized SQL queries in Direct SQL actions.
- Resource Contention: Overloaded server resources (CPU, memory, disk I/O) can impact workflow execution.
- Development vs. Production Cache Mode: Running in development mode in production can cause performance bottlenecks.
Troubleshooting Steps: Monitor server performance metrics. Analyze AR System logs for long-running workflows. Optimize SQL queries, ensure appropriate database indexing, and consider restructuring workflows to be more efficient. Review server queue and thread configurations.
Interview Relevance: What Interviewers Look For
When discussing AR System workflows in an interview, interviewers are looking for more than just theoretical knowledge. They want to see your practical understanding and problem-solving skills. Be prepared to:
- Explain the differences: Clearly articulate the distinctions between Active Links, Filters, and Escalations, and when you would choose each.
- Provide use cases: Give real-world examples of how you’ve used specific actions (like
Push Fields,Run Process, or evenCall Guide) to solve business problems. - Discuss troubleshooting: Share your approach to debugging common workflow issues. Mention your familiarity with AR System logs and debugging tools.
- Understand performance implications: Talk about how workflow design can impact system performance and what steps you take to optimize it.
- Explain automation benefits: Articulate the business value of using AR System workflows – efficiency, consistency, error reduction, and enhanced user experience.
- Showcase understanding of actions: Be able to describe the purpose and limitations of key actions like
Direct SQL,Commit Changes, andService.
Highlighting your experience with the Call Guide action demonstrates an understanding of building modular and maintainable solutions, which is highly valued.
Conclusion
AR System workflows are the engine that drives automation and efficiency within your ITSM landscape. By understanding the distinct roles of Active Links, Filters, and Escalations, and by mastering the various workflow actions, including the strategic use of Call Guide, you can build sophisticated, responsive, and reliable applications. Effective workflow design not only streamlines operations but also enhances user experience and provides valuable data insights. Remember to always test thoroughly, leverage logging for debugging, and keep performance implications in mind. With this comprehensive guide, you’re well-equipped to harness the full power of AR System workflows.