C API: Understanding BMC Remedy AR System Workflow

In the realm of IT Service Management (ITSM) and enterprise application development, understanding the underlying mechanisms that drive automation and data manipulation is crucial. For those working with BMC Remedy AR System (now part of BMC Helix ITSM), the concept of workflow is fundamental. While direct interaction with the C API might seem like a deep dive, grasping the workflow objects it manages provides invaluable context. This article aims to demystify BMC Remedy AR System’s workflow engine, explaining its core components – Active Links, Filters, and Escalations – and how they are orchestrated. We’ll explore the actions available, execution options, and how these elements contribute to a robust and automated IT environment.

What is Workflow in BMC Remedy AR System?

At its heart, workflow in BMC Remedy AR System represents the structured set of processes that govern how your company operates. Think of it as the invisible intelligence that automates tasks, enforces business rules, and ensures data integrity. This automation is achieved through a combination of intelligent components: Active Links, Filters, and Escalations. These components trigger specific actions based on predefined conditions and execution options, making your applications responsive, efficient, and powerful.

The primary goal of workflow is to automate company processes, enabling systems to respond dynamically to user interactions, data changes, and scheduled events. This leads to:

• Increased Efficiency: Automating repetitive tasks frees up human resources for more complex problem-solving.
• Improved Accuracy: Automated processes reduce the risk of human error in data entry and manipulation.
• Enhanced User Experience: Dynamic updates and responsive interfaces make applications easier and more intuitive to use.
• Streamlined Operations: Consistent application of business rules ensures that processes are followed uniformly across the organization.

Core Workflow Objects: The Building Blocks of Automation

BMC Remedy AR System utilizes three primary types of workflow objects, each with distinct triggers and execution environments:

Forms: The Foundation for Data Representation

Before diving deeper into workflow, it’s essential to understand Forms. In BMC Remedy AR System, forms serve as the schema to represent data, analogous to tables in a relational database. They define the structure of your information, including fields, their data types, and associated properties. Workflow objects operate on the data within these forms.

Active Links: Reacting to User Interaction

Active Links are the frontline of client-side automation. They are designed to execute actions in response to user interactions within the application interface. Imagine a user filling out a form: as they select a value from a dropdown or type into a field, an active link can be triggered. This trigger can then initiate a variety of operations, such as:

• Displaying informational messages to the user.
• Changing the visual appearance of fields (e.g., making a field read-only or changing label color).
• Fetching, pushing, or inserting data to/from other forms.

Key characteristics of Active Links:

• Client-Side Execution: They run on the user’s client machine, making them ideal for immediate feedback and interface manipulation.
• User-Triggered: Actions like clicking a button, changing a field value, or navigating a form can initiate an active link.
• Cannot be API-Triggered: A significant limitation is that active links cannot be directly invoked by API programs.
• Naming Convention: If you attempt to create an active link with a name that already exists, the system will append `_c` to the new name to ensure uniqueness.
• Mandatory Action: An active link must have at least one action defined to perform.
• Form Save Behavior: Saving a form does not automatically copy its associated active links. However, renaming a form will preserve and associate its active links with the new name.

Real-world example: When a user selects “High” priority for a ticket, an active link could automatically populate the “Due Date” field with a date three days from now and change the urgency field’s color to red. This provides immediate visual feedback and sets expectations for the user.

Filters: Enforcing Server-Side Logic

Filters operate at the server level, acting as gatekeepers for data transactions. They are invoked when records (requests) are submitted, modified, deleted, or retrieved from a form. Filters are crucial for enforcing business rules, validating data, and automating server-side processes before data is permanently committed to the database.

Key characteristics of Filters:

• Server-Side Execution: They run on the AR System server, allowing them to interact directly with the database and perform more resource-intensive operations.
• Transaction-Driven: Filters are triggered by specific operations (Submit, Modify, Delete, Get Entry, Merge) occurring on a form.
• Qualification-Based: A filter only executes if its defined qualification (a condition) is met by the current request or transaction.
• Administrator Permissions: Filters typically execute with administrator privileges, giving them broad access to modify data.
• Form-Level Execution: Filters are associated with specific forms and execute within the context of those forms.
• Execution Order: Filters are executed in a specific order, often defaulting to an execution order of 500, allowing for defined processing sequences.

Real-world example: When a user attempts to submit a change request, a filter might check if all required fields (like impacted service, planned start date, and duration) are populated. If any are missing, the filter can prevent the submission and display an error message to the user, ensuring data completeness.

Escalations: Time-Based Automation

Escalations are the time-based workhorses of the workflow engine. Similar to filters, they operate at the server level and interact with the database. However, their trigger is not an immediate user action or data change, but rather a predefined time interval or a specific point in time.

Key characteristics of Escalations:

• Server-Side Execution: They run on the AR System server.
• Time-Driven: Executed at scheduled intervals (e.g., every hour, daily, weekly) or at a specific date and time.
• Batch Processing: Unlike filters that typically act on the current request, escalations can find and act on all requests that meet their qualification within the database at the time of execution.
• Dedicated User: Escalations are often executed by a specific system user, commonly named ar_escalator, for auditing and security purposes.

Real-world example: An escalation might be configured to run every night at 2 AM. It could scan all open incident tickets that have not been updated in the last 48 hours, assign them to a “SLA Breach Pending” queue, and send a notification to the assigned support group manager. This ensures that aging tickets don’t fall through the cracks.

Understanding Workflow Actions: What Can They Do?

Workflow objects – Active Links, Filters, and Escalations – achieve their automation through a rich set of actions. These actions dictate what the workflow will do when triggered. The availability of certain actions can vary between workflow types, reflecting their different execution environments (client vs. server) and purposes.

Common Actions Across Workflow Types

Several actions are versatile and can be utilized across Active Links, Filters, and Escalations, allowing for a consistent approach to certain automation tasks:

Actions Exclusive to Specific Workflow Types

Some actions are tailored for specific environments:

Detailed Explanation of Key Actions:

Direct SQL Action:

This action is incredibly powerful but requires careful handling. It allows you to submit any legal SQL command directly to a non-AR System database. This is invaluable for integrations with other systems that don’t offer a direct API or AR System integration method.

• Use cases: Populating external systems with data from AR System, or pulling data from external sources into AR System (though other integration methods are often preferred for the latter to maintain AR System integrity).
• Caution: BMC does NOT support or recommend using Direct SQL to modify data in tables created by the AR System server itself (those storing object definitions or form data). Doing so can lead to severe data corruption and system instability. Always target external databases.

For more information on integrating external systems, refer to the BMC documentation on integrating with external systems.

Goto Action:

The Goto action provides granular control over the execution order of workflow. Instead of following the default sequence determined by execution order numbers, you can use Goto to jump to another active link or filter. This is particularly useful for creating loops or reusable workflow segments.

• Functionality: When executed, the system looks for the next active link or filter with an execution order greater than or equal to the specified value and executes it. You can specify a static or variable execution order.
• Scenario: Imagine a complex data validation process. You might have a series of checks. If a certain condition is met, you might want to re-run a specific set of validations from the beginning. A Goto action can facilitate this by sending the workflow back to an earlier point.

Go to Guide Label Action:

This action is specifically designed for use within Guides (a construct that organizes workflow steps). It allows you to create modular and structured workflow by directing execution to a designated “label” within a guide. You mark these labels by inserting them before a specific active link or filter.

• Benefit: Enables the creation of repeatable workflow segments and branching logic within a structured guide. If you have a sequence of steps for processing a “new” record versus an “existing” record, you can use Go to Guide Label to direct the flow to the appropriate set of actions.

Run Process Action:

The Run Process action is a powerful tool for interacting with the operating system and executing external applications or scripts. It can be used on the client or the server.

• Capabilities: You can execute AR System commands, workflow process commands, or any external program. This is how you might send an email (beyond basic AR System notifications), generate a fax, or perform custom logging to a specific file format.
• Example: An escalation could use Run Process to call an external script that compresses old log files to save disk space.

For more on interacting with external processes, consult the BMC documentation on running external processes.

Service Action:

The Service action is designed to trigger filters that have an “Execute On” condition set to Service. This is a sophisticated way to orchestrate services within the AR System or to interact with external web services.

• Interoperability: It can work with AR System web services to consume external services or with a Set Fields filter action to consume internal AR System services.
• Data Exchange: It facilitates passing data between the calling workflow and the triggered filter, allowing for dynamic data retrieval and updates without requiring direct database operations in the initial step.

Commit Changes Action:

This action is primarily used in Active Links and has two distinct functions:

• With Dialog Boxes: When used in conjunction with Open Window and Close Window actions for dialog boxes, Commit Changes captures data entered by the user in the dialog and pushes it to the parent form’s fields. Crucially, it does not initiate a save to the database at this point.
• With Regular Forms: When used on regular, join, view, or vendor forms, Commit Changes applies the changes made to the form and performs the major form action (like Submit, Search, or Modify). In this context, it does submit data to the database.

Push Fields Action:

The Push Fields action is a cornerstone for automating data updates across forms. It allows you to transfer values from selected fields in the current request to another request, either in the same form or a different form.

• Functionality: This action can update existing records or create new ones. It supports pushing data from all field types, including hidden fields and fields not currently in the active view. However, you cannot push data to non-data fields like table fields or panel holders.
• Limitations: Each Push Fields action can push data from the current form to only one other form at a time, though it can update multiple requests on that target form.
• Example: When a “Change Request” is approved, a Push Fields action could copy key details (like “New Configuration Item”, “Change Date”, “Approval Group”) into a related “Configuration Management Database (CMDB)” record to ensure accurate documentation.

Commit Changes vs. Run Process PERFORM-ACTION-APPLY

This is a common point of confusion. Both can result in a record being saved when performed on a modify operation. However, they differ in their logging and dynamic generation capabilities:

• Logging: Commit Changes is typically logged explicitly in the AR System log files. Run Process PERFORM-ACTION-APPLY might not be as clearly delineated in logs, making it harder to trace.
• Dynamic Workflow: Run Process is generally preferred for generating dynamic workflows. The actions performed can be dynamically determined based on values from fields or other variables, offering greater flexibility than the more static nature of Commit Changes.

Workflow Execution Options and Auditing

Understanding how and when workflow executes is critical for troubleshooting and design. AR System provides specific execution options for Filters and logging for audits.

Filter Execution Options

Filters are triggered by specific operations on a form:

Audit Form Fields: Tracking Workflow Triggers

AR System logs actions that trigger audits, providing visibility into system activity. These are represented by numerical values:

• 1 GET ENTRY: When a record is retrieved.
• 2-Set: When a record is modified.
• 4-Create: When a new record is created (submitted).
• 8-Delete: When a record is deleted.
• 16-Merge: When records are merged.

These audit flags are essential for security, compliance, and debugging, allowing you to understand who did what and when.

Advanced Workflow Concepts and Utilities

Production vs. Development Cache Mode

This setting significantly impacts how administrative operations and workflow threads interact, especially concerning escalations and long-running processes.

• Production Cache Mode (Default): When administrative operations occur (like server configuration changes), the server creates a separate copy of its cache. This ensures that end-users are not impacted and can continue their work using the shared cache. This is ideal for production environments where service availability is paramount.
• Development Cache Mode: In this mode, administrative operations lock out other users from the shared cache. The admin operation waits for all users and threads (including escalations and archive jobs) to complete before making changes. This can lead to significant delays and is generally unsuitable for production environments due to its disruptive nature.

DDE Action: Client-Server Data Exchange

The DDE (Dynamic Data Exchange) action is exclusively used in Active Links. It facilitates data exchange between a client application and the AR System server. While less common with modern integration technologies, it was historically used for inter-application communication on the same machine.

Filter Phasing and Email Engine

The Email Engine plays a crucial role in sending out notifications. The Email_Notification web path setting in the AR System configuration determines the base URL that appears in email notifications, allowing users to click links directly back into the application.

DSO (Distributed Server Option) and Firewalls

When configuring DSO, particularly in environments with firewalls, you might need to enable a placeholder mode from the DSO tab in the server configuration. This helps ensure that data transfers can occur reliably across network boundaries.

The `arsignal` Utility: Managing Server Operations

The arsignal utility is a command-line tool used to force a BMC Remedy AR System server to reload or refresh specific types of information. It’s a powerful diagnostic and administrative tool.

The general syntax is:

Key options include:

• -c: Reloads the server’s configuration file (ar.conf or ar.cfg). Essential after making changes to these files.
• -e: Recaches and reloads escalation definitions. Useful if escalations aren’t running as expected.
• -r: Recaches definitions from the database. A general refresh for workflow and object definitions.
• -u: Reloads user information.
• -d: Transfers a signal to a DSO process, useful for initiating or resynchronizing distributed operations.

Refer to the BMC documentation on common server administrative tasks for more on `arsignal` and server configuration.

Access Control: Permissions and Roles

While not strictly workflow execution, Access Control mechanisms like Permission Groups and Roles are intrinsically linked to workflow. They dictate who can see what and do what within the application. Workflow actions can be designed to respect these permissions, ensuring that automated processes do not bypass security policies.

Troubleshooting Common Workflow Issues

Interview Relevance

Understanding BMC Remedy AR System workflow is a cornerstone for any developer, administrator, or architect working with the platform. Be prepared to discuss:

• The differences between Active Links, Filters, and Escalations.
• The use cases and limitations of specific actions like Push Fields, Run Process, and Direct SQL.
• How to design for performance and troubleshoot workflow issues.
• The role of caching and `arsignal` in managing server configurations and workflow reloads.
• How workflow interacts with Access Control mechanisms.

Demonstrating a solid grasp of these concepts shows your ability to build efficient, automated, and maintainable solutions within the BMC ecosystem.

By mastering these workflow components, you can unlock the full potential of BMC Remedy AR System, building sophisticated applications that streamline operations, enhance user productivity, and drive business value. The underlying C API, while abstract, is what powers these robust automation capabilities.

Further Reading:

• BMC Remedy AR System Workflow Objects Documentation
• BMC Remedy AR System Actions Documentation
• BMC Remedy AR System Administration Guide