Demystifying Audit Actions: The Backbone of Your BMC Remedy AR System Auditing Strategy
In the realm of IT Service Management (ITSM) and enterprise systems, robust auditing is not just a good practice; it’s a fundamental requirement. It’s the unseen guardian that tracks who did what, when, and why, providing critical insights for security, compliance, troubleshooting, and process improvement. In BMC Remedy AR System, this vital function is powered by what we call “Audit Actions.” Understanding these actions is paramount for anyone responsible for configuring, managing, or troubleshooting AR System workflows.
Think of Audit Actions as the specific events that trigger the system to record a change or an interaction. These are the atomic units of auditable activity. When you configure your AR System workflows, you’re essentially telling the system, “When this specific thing happens, make sure to log it.” This article will delve deep into what these Audit Actions are, how they relate to different workflow types, and why they are so crucial for maintaining a healthy and compliant AR System environment.
Understanding the Core Audit Actions
At its heart, BMC Remedy AR System categorizes audit-triggering events into distinct actions. These are represented by numerical values, which are often used internally by the system and in logs. However, understanding their English equivalents is far more practical for daily administration. Here are the primary Audit Actions:
- 1 – GET ENTRY: This action is triggered whenever a request (a record in a form) is retrieved from the database. This could be a user performing a search, an active link fetching data, or a filter initiating a lookup. It signifies that a piece of information has been accessed.
- 2 – Set: This is a broad category that encompasses modifications to fields. When a user or a workflow changes the value of a field on a form, this action is often the underlying event recorded.
- 4 – Create: This action is invoked when a new request is created in the system. Whether it’s a new incident, a change request, or any other record, its inception is logged under this action.
- 8 – Delete: As the name suggests, this action is triggered when a request is permanently removed from the system.
- 16 – Merge: This action is specific to scenarios where data from one or more sources is consolidated into a single request, often used in data import processes like BMC Remedy Data Import or DSO (Distributed Server Option) independent copy transfers.
These numerical values might seem cryptic, but they represent fundamental operations within the AR System. Often, when you’re reviewing audit logs or debugging workflows, you’ll see these numbers associated with specific events. They are the fingerprints left behind by system activities.
Audit Actions in the Context of Workflows
The real power of understanding Audit Actions lies in how they interact with different workflow types: Active Links, Filters, and Escalations. Each workflow type plays a role in how and when these audit events are captured or triggered.
Action Types and Their Reach
Let’s look at common action types within these workflows and how they relate to auditing. The table below provides a good overview:
| 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 | * | * | * |
The asterisk (*) in the table indicates that the action type is supported within that workflow type. This table highlights that certain actions are exclusive to specific workflow types, while others are versatile and can be leveraged across multiple. For instance, “Change Field” is primarily an Active Link action, whereas “Push Fields” is a workhorse found in all three.
Filter Execution Options: When Do They Fire?
Filters are the engine room of AR System business logic, and their execution is often tied to specific events. The “Filter execution options” define precisely when a filter is triggered, and consequently, when its associated Audit Actions are considered:
| Execution option | Description |
|---|---|
| Modify | Executes when a request is modified. This directly relates to the ‘Set’ Audit Action, as field values are being changed. |
| Submit | Executes when a request is submitted to the server. This is often associated with the ‘Create’ Audit Action, as a new request is being finalized. |
| Delete | Executes when a request is deleted. This directly maps to the ‘Delete’ Audit Action. |
| Get Entry | Executes when a request is retrieved. This is the core trigger for the ‘GET ENTRY’ Audit Action. |
| Merge | 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. This directly maps to the ‘Merge’ Audit Action. |
| Service | 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. This is a more specialized execution mode, often used for data retrieval and manipulation without direct database commits on the target form, but still relevant to auditing accessed data. |
The interplay between Audit Actions and Filter Execution Options is fundamental to creating effective audit trails. If you want to audit every time a specific field on an incident request is modified, you’d configure a filter to execute on ‘Modify’ and potentially trigger logging actions within that filter.
Actions in Different Workflow Types: A Closer Look
It’s important to note that not all actions are universally available across all workflow types. This distribution is strategic, ensuring that actions are used in contexts where they make the most sense.
| Only in AL | In FLR & ESCL but not in AL | In FLR but not in ESCL |
|---|---|---|
| DDE | Call guide | Call guide |
| Change Field | Change Field | Change Field |
| Close Window | Close Window | Close Window |
| Commit Changes | Commit Changes | Commit Changes |
| OLE Automation | Distributed Server Option | Distributed Server Option |
| Open Window | Direct SQL | Direct SQL |
| Run Macro | Exit Guide | Exit Guide |
| Wait | Go to Guide Label | Go to Guide Label |
| Goto | Goto | |
| Log to File | Log to File | |
| Message | Message | |
| Notify | Notify | |
| Open Window | Open Window | |
| Push Fields | Push Fields | |
| Run Process | Run Process | |
| Service | Service | |
| Set Fields | Set Fields |
This matrix is invaluable. For instance, you can see that “DDE” and “OLE Automation” are exclusively for Active Links, often used for client-side integrations. “Direct SQL” is a powerful but potentially risky tool available in Filters and Escalations, allowing direct interaction with non-AR System databases. Understanding these boundaries prevents configuration errors and ensures you use the right tool for the job.
Deep Dive into Specific Actions
Let’s explore some of the more nuanced actions and their practical implications:
DDE Action: Client-Server Data Exchange
The DDE (Dynamic Data Exchange) action is purely an Active Link action. Its purpose is to facilitate data transfer between a client AR System application (like BMC Remedy User) and other applications that support DDE. For auditing, its relevance is indirect; it’s about how data moves, not necessarily direct record modification. However, if DDE is used to populate fields that are then modified, the subsequent actions would be audited.
Direct SQL Action: Bridging to External Databases
The Direct SQL action is a potent tool, usable in Active Links, Filters, and Escalations. It allows you to execute any valid SQL command directly against a non-AR System database. This is typically used for integrations where you need to push data to or pull data from external systems.
Caution: BMC strongly advises *against* using Direct SQL to modify tables managed by AR System itself (object definitions, form data). Doing so can lead to severe data corruption. Its intended use is for interacting with *external* databases.
Real-world example: Imagine a scenario where your IT asset management system is external to AR System. You might use a Direct SQL action in an AR System filter to update asset status in the external database whenever an incident related to that asset is resolved in AR System. The audit trail would then reflect that a database operation was attempted via this action.
Goto and Go to Guide Label: Controlling Workflow Flow
Both Goto and Go to Guide Label actions, available in Active Links and Filters, are crucial for managing the execution order of your workflows.
- Goto: This action allows you to jump to a specific execution order number. The system will then execute the first item with an order number greater than or equal to the specified value. This is useful for creating loops or conditional jumps in your workflow logic.
- Go to Guide Label: This action redirects workflow execution to a designated “label” within a guide. Guides are sequential lists of active links or filters, and this action provides a way to jump to specific points within them.
These actions don’t directly perform data modifications but influence which other actions get executed, indirectly impacting what gets audited.
Run Macro Action: Leveraging BMC Remedy User Features
The Run Macro action is exclusive to Active Links and is designed to execute macros created within BMC Remedy User. This functionality is tied to the client-side application and is not supported in the web client. Its auditing relevance is minimal; it’s more about invoking client-specific automation.
Run Process Action: Executing External Commands
The Run Process action is a versatile tool found in Active Links, Filters, and Escalations. It allows you to execute an independent process on either the client machine or the AR System server. The command specified in the “Command Line” field is executed.
Practical application: You might use ‘Run Process’ to trigger a script that sends an email notification, invokes an external API, or starts another application. If this process modifies data or generates logs, those actions would be audited. The system logs that a ‘Run Process’ action occurred, but the specifics of the executed command might not be explicitly detailed in the AR System audit log itself, depending on configuration.
Service Action: Interacting with Service-Oriented Logic
The Service action is available in Active Links, Filters, and Escalations. Its primary role is to trigger filters configured with an “Execute On” condition of ‘Service’. This action allows for data exchange without necessarily performing a full database commit on the target form.
In Active Links and Filters, it’s used to pass input field mappings and optionally a database request ID to retrieve output data for further processing. No direct database modifications occur on the target form in this mode.
However, when used in Escalations, the Service action *can* modify database values if output data is provided. This makes it relevant for auditing data changes initiated via this mechanism.
Commit Changes Action: Saving Your Work
The Commit Changes action, primarily used in Active Links, has a dual personality:
- With Dialog Boxes: When used in conjunction with ‘Open Window’ and ‘Close Window’ actions for dialog boxes, ‘Commit Changes’ captures data entered in the dialog. It pushes these values to fields on the parent form but *does not* initiate a database save. The audit would reflect that fields were potentially updated, but not that a full request save occurred.
- With Regular Forms: When applied to regular forms, join forms, view forms, or vendor forms, ‘Commit Changes’ applies the modifications to the form and triggers the major form action (Submit, Search, Modify). In this context, it *does* submit data to the database, meaning the underlying Audit Actions for creation, modification, or deletion would be invoked.
Push Fields Action: Automating Data Propagation
The Push Fields action is incredibly powerful and widely used across Active Links, Filters, and Escalations. Its core function is to automate data updates by transferring values from selected fields in the current request to another request, either on the same form or a different one. It can also be used to create new requests.
This action is directly linked to the ‘Set’ Audit Action when it updates existing fields, and the ‘Create’ Audit Action when it creates new requests. You can push data from virtually any field type, including complex ones like tables, provided the target field is a data-carrying field. It’s essential for workflows that synchronize data between different forms or applications.
The Subtle Art of “Commit Changes” vs. “Run Process PERFORM-ACTION-APPLY”
A common point of confusion for administrators is the difference between ‘Commit Changes’ and ‘Run Process’ with the ‘PERFORM-ACTION-APPLY’ command. Both can result in saving a request when used in a ‘Modify’ context.
- Commit Changes: When used on a regular form, this directly initiates a save operation. In the audit logs, you’ll typically see “Commit Changes” explicitly logged.
- Run Process “PERFORM-ACTION-APPLY”: This is a more dynamic approach. It’s often favored for generating workflows on the fly because the action can be dynamically determined by field values. While it also results in saving the request, the AR System audit logs might simply show the underlying database operations (like ‘SET’ or ‘MERGE’) without explicitly stating “Run Process PERFORM-ACTION-APPLY” as the initiator.
For developers focused on dynamic workflow generation, ‘Run Process’ offers greater flexibility. However, for straightforward saves, ‘Commit Changes’ is simpler and more explicit in its logging.
Troubleshooting Audit-Related Issues
When audits aren’t behaving as expected, or you’re struggling to understand a particular logged event, here are some common troubleshooting steps:
- Enable Audit Logging Granularity: Ensure that auditing is enabled for the specific form and fields you’re interested in. Check the AR System Administration Console under “System > AR System Administration > Server Information > Permissions.” Within the “Audit” tab, make sure auditing is active. You can also control field-level auditing from the form definition.
- Review Workflow Logs: The most powerful tool for understanding workflow behavior is AR System logging. Enable detailed workflow logging (e.g., “Filter,” “Active Link,” “Escalation”) in the Server Information settings. Then, use the `ar.log` file (or configure specific log files for workflows) and tools like `aremote` or `arapi` to analyze the execution flow and identify which actions are firing and when. Look for mentions of the Audit Actions (1, 2, 4, 8, 16) or the specific action types (Set Fields, Push Fields, etc.).
- Check Execution Order: The order in which Active Links and Filters execute is critical. A ‘Goto’ action or a simple misconfiguration in execution order can cause workflows to skip or execute prematurely, impacting what gets audited.
- Understand Workflow Dependencies: If an action is part of a chain (e.g., an Active Link fires a Filter, which then fires another Active Link), understanding these dependencies is key to tracing the audit trail.
- “Get Entry” vs. “Set”: Differentiate between simply viewing a record (‘Get Entry’) and actually modifying it (‘Set’). If you expect a change to be audited but only see ‘Get Entry’ events, it means the record was retrieved but not saved or committed.
- Direct SQL and External Systems: If you’re using ‘Direct SQL’ and not seeing expected results or audits, verify the connectivity to the external database. Also, remember that AR System itself might not have direct visibility into the *internal* operations of the external database.
- arsignal Utility for Cache Reloads: Sometimes, changes to workflow definitions or server configurations don’t immediately take effect. The `arsignal` utility is your friend here. You can use commands like `arsignal -r serverName` to force AR System to recache definitions from the database. This is crucial for ensuring your audit configurations are active.
Interview Relevance: What Recruiters Look For
When you’re in an interview for an AR System administration or development role, demonstrating a solid understanding of audit actions and workflows is a significant advantage. Be prepared to:
- Explain the Audit Actions: Clearly articulate what each of the five core audit actions (GET ENTRY, Set, Create, Delete, Merge) signifies.
- Describe Workflow-Action Relationships: Discuss which actions are available in Active Links, Filters, and Escalations and why. Use examples.
- Differentiate Action Types: Be able to explain the purpose and usage of actions like ‘Push Fields’, ‘Run Process’, ‘Direct SQL’, and ‘Commit Changes’.
- Troubleshooting Scenarios: Walk through how you would diagnose a problem where an audit event isn’t being logged or an action isn’t behaving as expected, referencing AR System logs and configuration settings.
- Impact on Compliance: Discuss how proper audit configuration contributes to regulatory compliance and security best practices.
A well-articulated understanding of these fundamental concepts shows that you can manage the system’s integrity, troubleshoot effectively, and build robust, auditable solutions.
Conclusion
Audit Actions are the granular components that enable comprehensive auditing within BMC Remedy AR System. By understanding what triggers these actions, how they interact with different workflow types, and the specific nuances of each action, administrators and developers can build systems that are not only functional but also transparent, secure, and compliant. Mastering these concepts is not just about configuration; it’s about building trust and providing accountability within your IT landscape.