Demystifying BMC Remedy Action Request System: Platform vs. Application

In the intricate world of IT Service Management (ITSM) and business process automation, the name “BMC Remedy” often surfaces. However, a common point of confusion arises when distinguishing between “Remedy” itself and its underlying engine, the “Action Request System” (AR System). Let’s untangle this by understanding what AR System truly is and how Remedy fits into the broader picture.

Understanding the Core: What is AR System?

At its heart, the BMC Remedy Action Request System (AR System) is a powerful, low-code/no-code platform designed for automating a wide array of business processes. Think of it as the engine that drives efficiency and agility within an organization. Its primary strength lies in its ability to empower both technical and non-technical users to build and deploy sophisticated business workflow applications without needing to delve into complex programming languages or development tools.

Key Capabilities of AR System:

• No-Code/Low-Code Development: This is AR System’s flagship feature. It allows business analysts and IT professionals with limited programming backgrounds to design and implement workflows visually.
• Cross-Platform Deployment: Applications built on AR System can be deployed seamlessly across various environments, including Web, Windows, UNIX®, and Linux®, offering unparalleled flexibility.
• Foundation for ITSM: AR System is the bedrock upon which BMC’s comprehensive IT Service Management (ITSM) suite is built. It provides the essential framework for automating and managing IT support and business processes.
• Service Process Management (SPM): As a Service Process Management solution, AR System offers a consolidated platform for automating and managing complex business processes, ensuring consistency and control.
• 4th Generation Programming Language (4GL): While not requiring traditional programming, AR System utilizes a 4GL approach, allowing for rapid development and abstraction of underlying complexities.

Essentially, AR System is the platform. It’s the infrastructure, the tools, and the framework upon which specific solutions are built.

Where Does “Remedy” Fit In?

The term “Remedy” traditionally refers to the applications that were built on top of the Action Request System. In the past, the “Remedy Corporation” developed the Action Request System and various applications that leveraged its capabilities. Over time, through acquisitions and rebranding, the name has evolved.

A Brief History of the Evolution:

• 1990: Remedy Corporation is founded.
• 1991: Introduction of the Action Request System, initially focused on network management.
• 1996: Remedy launches key applications like Change Management and Asset Management, alongside its companion, Flashboards, a tool for data visualization.
• 2001: Remedy Corporation is acquired by Peregrine Systems, Inc.
• 2002: Following Peregrine’s bankruptcy, BMC Software, Inc. acquires the Action Request System.
• 2003 onwards: BMC continues to develop and offer the platform, now known as BMC Remedy Action Request System.

So, when people refer to “Remedy” today, they are often talking about specific applications like BMC Remedy ITSM (which includes Incident Management, Problem Management, Change Management, etc.) or other business solutions built on the AR System platform.

In summary: AR System is the platform; Remedy applications are built on that platform. There is no functional difference between “Remedy” and “Action Request System” in the modern context; the current and accurate name is BMC Remedy Action Request System, highlighting the platform’s lineage and ownership.

Understanding the AR System Architecture

To truly appreciate AR System’s power, it’s helpful to understand its multi-tiered architecture:

1. Client Tier

This layer comprises all the applications that users interact with. This includes:

• User Clients: Such as BMC Remedy User, which provides the primary interface for end-users to access applications and submit requests.
• Developer Clients: Such as BMC Remedy Developer Studio, used for application design, customization, and workflow development.
• Migration and Deployment Tools: Utilities used for moving applications and configurations between environments.

2. Mid Tier

The Mid Tier acts as a crucial intermediary, running on a web server. Its responsibilities include:

• Web Interface: Enabling users to access AR System applications through a web browser.
• Request Translation: Translating client requests into a format the AR System server can understand and processing server responses back to the client.
• Web Service Handling: Managing requests and responses for web services.
• Server-Side Processes: Executing specific server-side processes that deliver AR System functionality to web clients.

3. Server Tier

This is the core processing engine of AR System. It houses:

• AR System Server: The central component responsible for controlling workflow processes, managing data access, and enforcing business rules.
• Server-Side Applications: Specialized components like the Approval Server, Email Engine, and Flashboards server, which provide extended functionality.
• Plug-in Servers: C and Oracle Java plug-in servers that extend AR System’s capabilities through custom integrations.

4. Data Tier

This layer consists of the databases and other data sources where application data is stored and retrieved. The AR System server interacts with this tier to persist and access information.

This robust architecture ensures scalability, reliability, and efficient processing of business workflows.

Key Configuration and Operational Aspects

Delving deeper into AR System reveals various configuration elements that are vital for its administration and operation.

Database and User Details

• The primary AR System database is typically named Arsystem.
• By default, the administrative user for the AR System database is ARAdmin, with a default password of AR#Admin#.

Types of Forms

AR System utilizes different types of forms for various purposes:

• View Forms: Used to display data from other forms or joined forms without storing its own data.
• Vendor Forms: Allow AR System to access external data sources, effectively integrating with other systems.

Licensing Models: Fixed vs. Floating

AR System employs different license types to manage user access:

• Fixed Licenses: Dedicated to a specific user. Only that user can log in using this license.
• Floating Licenses: Shared among a pool of users. A user can log in as long as a floating license is available. When licenses are exhausted, users may be restricted to read-only access until a license is freed up.

Scenario: If you have 5 fixed and 5 floating licenses, an unlimited number of users can log in. However, only 10 users (5 fixed + 5 floating) can actively use the system at any given time. Others will queue or get read-only access. Floating licenses are often more cost-effective for organizations with staggered working hours or shift-based operations, as they can be shared.

Platform Choice: OS and Database Considerations

The choice of operating system and database for AR System can significantly impact administrative costs and performance. BMC typically recommends choosing a platform that aligns with your existing IT infrastructure and staff expertise.

Popular Configurations (based on BMC support calls):

Installation Sequence of Database Tables

During the installation of AR System, the database tables are created in a specific order:

1. control
2. controlRecordIds
3. arschema
4. schema_index
5. schema_group_ids

Configuration Files

The ar.cfg file (on Windows) or arsystem.conf (on Linux/Unix) is crucial for AR System server configuration. This file dynamically created during installation, stores vital settings, including details like database connection information and password configurations.

Database Table Naming Conventions

AR System maps workflow objects to specific database tables:

• Active Links: dbo.actlink and dbo.actlink_ (with action name appended).
• Filters: dbo.filter and dbo.filter_.
• Escalations: dbo.escalation.

Garbage Collection

AR System employs garbage collection mechanisms to manage memory. The Xincgc parameter typically refers to an incremental garbage collector, which helps in optimizing memory usage.

Standard Port Numbers

Understanding port numbers is vital for network configuration and troubleshooting:

Version Information

To quickly find version information about your AR System installation, you can usually access the Application Properties form, which provides comprehensive details.

Advanced Concepts: Overlays, Groups, and Menus

Overlay Groups

Overlay Groups are a fundamental concept for managing customizations and best practices in AR System. They define how users interact with objects (forms, fields, etc.) during development:

• Overlay Group set to 1: Restricts users to working with overlay and custom mode objects, promoting best practice customizations.
• Overlay Group set to 0: Restricts users to working with base mode objects, primarily for maintaining out-of-the-box functionality.
• Overlay Group set to (clear): Provides no restrictions, allowing access to base, overlay, and custom objects.

Granular Overlays: This advanced feature allows for more fine-grained control. You can choose to apply different overlay types (Additive, Overwrite, Inheritance) to subcomponents of an object, minimizing reconciliation efforts during upgrades.

Group IDs and Types

Groups in AR System are used for access control and organization. They have unique integer IDs and can be categorized:

Menus

Menus provide users with selectable options within fields, enhancing usability and data consistency. They can be:

• Static: Defined directly within AR System (e.g., Character field menus).
• Dynamic: Populated from external sources or through queries (e.g., Search menus, SQL menus).

File menus can be dynamic or static. Importantly, deleting a menu does not delete the associated field or form, but rather the menu definition itself.

Refresh Rate in Menus: This setting controls how frequently menu data is updated. Options include On Connect, On Open (use with caution due to performance), and On 15 Minute Interval. Character menus are static and do not refresh.

Core Fields

Every request in AR System has a set of core fields that are fundamental to its lifecycle:

Data Storage and Field Types

Date and Time Storage

AR System stores date/time values as the number of seconds since January 1, 1970 (GMT). This epoch time format allows for efficient storage and calculation. This method is effective for dates ranging from January 1, 1970, through January 18, 2038.

Character vs. Diary Fields

A key distinction for data input:

• Character Fields: Can be overwritten.
• Diary Fields: Append new entries with a timestamp, user, and the data. This preserves historical entries and provides an audit trail within the field itself.

Web reports do not support diary fields, attachment fields, or attachment pools. They also do not support currency values or currency types directly.

Attachment Fields and Pools

AR System supports storing attachments. An attachment field has the data type ‘Attachment’. An attachment pool is a data type that allows for storing multiple attachments. When attachments are saved, two tables are typically created: one to store metadata (like file path, original size, compressed size) and another to store the binary data linked to the request ID.

Workflow Objects: The Engine of Automation

Workflow objects are the backbone of AR System’s automation capabilities. They define the logic that drives business processes.

Forms (Schemas)

Forms are the primary interface for users to interact with data and represent the structure of tables in the database. Form IDs are assigned based on their type:

Active Links

Active Links are client-side workflow objects that trigger actions based on user interactions within the current form window. They can perform operations like displaying messages, changing field properties, or pushing data between forms.

• Triggering: They are triggered by user operations (e.g., clicking a button, changing a field value).
• Limitations: Active links cannot be triggered via API programs.
• Naming: If an active link has the same name as an existing one, AR System appends _c.
• Saving Forms: When a form is saved as a new form, its associated active links are not automatically copied. Renaming the form, however, can incorporate active links.

Filters

Filters are server-side workflow objects that execute when a transaction occurs on a form (e.g., submitting, modifying, or deleting a record). They are used to enforce business rules, update related data, or trigger other processes.

• Execution: Triggered by form transactions on the server.
• Rules: Filters must adhere to a defined set of rules, acting as the core logic for data processing.

Escalations

Escalations are also server-side workflow objects, but they operate based on time. At predetermined intervals, escalations check requests in the database to trigger actions. This is ideal for time-sensitive processes like aging overdue tasks or sending reminders.

Access Control and Permissions

AR System provides robust mechanisms for controlling access to data and functionalities.

• Permission Groups and Roles: These objects are used to define who can access what—whether it’s entire forms, specific rows (records), or individual columns (fields).
• Form Permissions: Control access to forms at a high level.
• Field Permissions: Define access rights for individual fields within a form.

Scenario: Granting common permissions to 100 forms involves selecting a group, right-clicking on it, choosing “Assign Permissions,” and then adding the desired forms. This streamlines the process of managing access for multiple objects.

Troubleshooting Common Scenarios

Permissions for Menus

A common question is how to grant permissions to menus. You cannot directly assign permissions to menus. Instead, the permissions of the character field to which the menu is attached will govern access to that menu.

Attachment Pool Entries

To check attachment pool entries in the database, you would query the relevant tables that store attachment metadata and binary data. This involves understanding how AR System maps attachments to its underlying database structure.

TBH Tables

When you save a form, AR System creates three primary tables in the database:

• T (Transaction Table): Stores the primary data for the form.
• B (Binary Table): Stores attachments and other binary data, and can also house active links (this is a less common configuration).
• H (History Table): Stores the status history of requests, providing an audit trail of changes.

Join Form Limitations

BMC recommends joining up to 6 forms in a Join Form. While more can technically be joined, performance can degrade significantly. The join criteria, once defined, cannot be easily changed in AR System 8.1, and it’s a known limitation.

Form Deletion and Workflow

When a form is deleted, associated active links and filters are also removed, but only if the form is the primary object of that workflow. If a workflow object is associated with multiple forms, deleting one form will not delete the workflow itself, but it will no longer be triggered by that specific form.

Help Text Display

The display of help text in AR System varies based on the logged-in user:

• Demo User: Sees the Field Name (Label Name), Field ID, and the Help Text value.
• Registered User: Sees only the Help Text value. If no help text is defined, it shows the field’s description (symbol, keyword, length).

Installation and Configuration Details

ARS Installation Log Location

AR System installation logs are typically found in a temporary directory, often in C:\Users\Administrator\AppData\Local\Temp\1\ with a filename like arsystem_install_log.txt.

Host File and Services

The hosts file (usually located at C:\Windows\System32\drivers\etc\hosts) and the services file map hostnames to IP addresses and define port numbers for various services, playing a critical role in network communication for AR System.

Interview Relevance and Key Takeaways

Understanding the distinction between AR System as a platform and Remedy as an application is fundamental. When preparing for interviews, focus on:

• The layered architecture of AR System.
• The roles of workflow objects: Active Links, Filters, and Escalations.
• Licensing models (Fixed vs. Floating) and their implications.
• Core fields and their significance.
• Data types like Character vs. Diary fields and their use cases.
• The concept of overlays for customization.
• Group types (Explicit vs. Implicit) for access control.

Conclusion

BMC Remedy Action Request System is a robust and versatile platform that empowers organizations to streamline their operations. By understanding its architecture, core components, and the distinction between the platform and the applications built upon it, IT professionals can harness its full potential. Whether you’re a developer, administrator, or business analyst, a solid grasp of AR System is key to leveraging its capabilities for efficient and effective business process automation.