Demystifying BMC Remedy AR System: A Deep Dive into its Architecture and Functionality

In the intricate world of IT Service Management (ITSM), few platforms have stood the test of time quite like BMC Remedy Action Request System (AR System). For decades, it has served as the bedrock for robust ITSM solutions, enabling organizations to automate complex business processes, streamline operations, and enhance service delivery. But what exactly powers this venerable platform? This article aims to peel back the layers, offering a comprehensive, human-like technical exploration of BMC Remedy AR System, its architecture, core components, and the intricacies that make it a powerhouse in the ITSM landscape.

The Genesis of Remedy AR System

To truly understand Remedy AR System, it’s helpful to know its lineage. The story begins in 1990 with the founding of Remedy Corporation. Just a year later, in 1991, they introduced the Action Request System, initially designed with network management in mind. The company’s growth led to a public offering in 1995, followed by the introduction of key applications like Change Management and Asset Management, alongside the innovative Flashboards, in 1996.

The landscape shifted in 2001 when Remedy was acquired by Peregrine Systems. However, this union was short-lived, as Peregrine Systems filed for bankruptcy in 2002. It was during this tumultuous period that BMC Software acquired the Action Request System. Since 2003, Remedy has operated as a vital component and subsidiary of BMC Software, its name evolving to the familiar BMC Remedy Action Request System. It’s important to note, for clarity, that there isn’t a functional difference between “Remedy” and “Action Request System” in the context of the current product; “BMC Remedy Action Request System” is the unified, official designation.

Understanding the Core: AR System Platform vs. Remedy Applications

Often, terms like “AR System” and “Remedy” are used interchangeably, but there’s a subtle distinction worth making. The AR System Platform is the foundational technology. It’s the engine that enables automation of business processes without the need for extensive, traditional programming. It’s designed for flexibility, supporting deployments across Windows, UNIX, and Linux environments. Think of it as the operating system for your ITSM applications.

Remedy applications, on the other hand, are the specialized tools built *on top of* the AR System platform. These are the applications that most users interact with daily to manage incidents, problems, changes, service requests, and more. Examples include BMC’s own ITSM suite.

Deconstructing the Architecture: A Layered Approach

The BMC Remedy AR System is built upon a robust, multi-tiered architecture designed for scalability, performance, and maintainability. Understanding these tiers is crucial for anyone involved in its administration or development.

1. The Client Tier

This is where user and administrative interaction begins. The client tier comprises the various interfaces through which users access and manage the AR System. This includes:

• User Clients: Applications like BMC Remedy User, allowing end-users to interact with Remedy applications.
• Developer Clients: Tools such as BMC Remedy Developer Studio (for development and customization) and BMC Remedy Data Import/Migrator (for data management).
• Web Browsers: Accessing Remedy applications through the Mid Tier.

2. The Mid Tier

Acting as the bridge between client applications and the AR System server, the Mid Tier is a crucial component for web-based access. It typically runs on a web server (like Tomcat or Jboss) and performs several key functions:

• Request Translation: It translates incoming client requests into a format the AR System server understands.
• Response Interpretation: It takes the server’s responses and formats them for display back to the client.
• Web Services Handling: It facilitates integration with other systems via web services.
• Server-Side Processes: It can execute specific server-side processes that are initiated by web clients.

Troubleshooting Tip: If web users are experiencing slow performance or connection issues, check the health and resource utilization of your Mid Tier servers. Restarting the Mid Tier service is often a good first step.

3. The Server Tier

This is the heart of the AR System. The AR System server is the primary engine that controls workflows, manages data access, and executes business logic. It hosts a variety of server-side applications and components:

• AR System Server: The core daemon that orchestrates everything.
• Server-Side Applications: Specialized servers like the Approval Server, Email Engine, and Flashboards server that extend the platform’s capabilities.
• Plug-in Servers: Including C/Java plug-in servers that handle custom integrations and specific functionalities.

Note: The AR System server typically uses a default database user, commonly named ARAdmin, to connect to its operational database, often named Arsystem.

4. The Data Tier

This tier encompasses the actual databases and any other data sources that the AR System server interacts with. This can range from relational databases like Oracle, SQL Server, or DB2, to potentially other data repositories through vendor forms.

Core Concepts and Functionality

Workflows: The Automation Engine

Workflows are the lifeblood of AR System, defining the automated processes that drive your IT operations. They dictate how data flows, how approvals are managed, and how the system responds to events. There are three primary types of workflows:

• Active Links: These are client-side workflows that execute based on user actions or information displayed on the current screen. They’re great for providing immediate feedback, updating fields on the fly, or triggering client-side actions. They cannot be triggered via API programs.
• Filters: These are server-side workflows that fire during form transactions (submit, modify, delete). They are responsible for enforcing business rules, performing data manipulations, sending notifications, and initiating other server-side actions.
• Escalations: Similar to filters, but they are time-based. They continuously monitor requests in the database and trigger actions when specific conditions are met after a predefined interval. Think of them as automated “check-ins” or proactive problem solvers.

Interview Relevance: Be prepared to explain the differences between Active Links and Filters, and when you would use each. A common question is: “When would you use an Active Link versus a Filter?” The key differentiator is where they execute: client-side (Active Link) vs. server-side (Filter).

Forms: The Building Blocks of Data

Forms are the user interfaces through which data is captured, displayed, and manipulated. AR System offers several types of forms:

• Regular Forms: The most common type, used for direct data entry and display.
• Join Forms: Allow you to combine data from two or more regular forms based on a defined join criteria. BMC recommends joining up to 6 forms for optimal performance, though more are technically possible.
• View Forms: Provide a specific perspective or subset of data from another form, often used for reporting or limiting user access to certain fields.
• Vendor Forms: A powerful mechanism that allows AR System to interact with and retrieve data from external data sources as if they were local AR System forms. This is crucial for integrations.
• Advance Forms: This category includes View forms and Vendor forms, highlighting their advanced capabilities for data abstraction and integration.

Form IDs: Each form type is associated with a specific ID: Regular (1), Join (2), View (3), Display (4), Vendor (5).

Fields: The Data Containers

Fields are the individual elements within a form that hold specific data. AR System supports a wide variety of field types, each with unique characteristics.

• Character Fields: Versatile for storing alphanumeric text. Menus can be attached to character fields.
• Diary Fields: Designed for appending information with a timestamp and username. Each new entry is added to the previous ones, preserving a history. This is different from character fields which can be overwritten.
• Date/Time Fields: Store date and time values. In AR System, these are stored as the integer number of seconds since January 1, 1970, 00:00:00 GMT, up to January 18, 2038. This is often referred to as “epochtime” or “unix time.”
• Attachment Fields: Used to store file attachments.
• Attachment Pool Fields: A more advanced way to manage multiple attachments, creating separate tables to store binary data.

Practical Example: The distinction between a Character field and a Diary field is a common interview question. A Diary field is ideal for logging activities or comments, ensuring every contribution is preserved. A Character field might be used for a single-value description that can be edited.

Core Fields: The Unsung Heroes

Every record in AR System has a set of core fields that are fundamental to its identity and lifecycle. These include:

1. Request ID (unique identifier for each ticket/record)
2. Submitter
3. Create Date
4. Assigned To
5. Last Modified By
6. Modified Date
7. Status
8. SD (Short Description)
9. Status History (Field ID 15, often hidden from users)

User and Access Management: Groups and Permissions

Controlling who can see and do what is paramount. AR System employs a sophisticated system of groups and permissions to manage access at various levels – forms, rows, and columns.

Types of Groups

Groups can be categorized as either Explicit or Implicit.

• Explicit Groups: Users are manually assigned to these groups. Examples include “admin,” “sub-admin,” “customize,” etc. These groups provide direct access to granted objects and fields and are defined for a specific server.
• Implicit Groups: Users belong to these groups based on certain conditions or circumstances, often tied to specific fields or system-defined roles. They are not directly assigned. Examples include “public,” “assignee,” and “submitter.”

Group ID Ranges: Understanding group ID ranges helps in managing and troubleshooting:

• 0-1000: AR System built-in groups and current applications.
• 1000-13004 & 13007-14999: Regular and Computed groups (explicit).
• 13005-13006: CMDB groups.
• 14999-59999: Reserved for future AR System applications.
• 60000-60999: Dynamic or implicit groups.

Interview Relevance: Differentiating between explicit and implicit groups and providing examples is a common interview topic.

View/Change/None Permissions

Within group management, you’ll encounter “View,” “Change,” and “None” permissions for specific objects. This allows for granular control over what actions users can perform.

Overlay Groups: Modern Customization

Overlay groups are a critical feature introduced to facilitate cleaner customizations and easier upgrades. They control access to objects based on their modification state:

• Overlay Group = 1: Restricts users to working on overlay and custom mode objects (Best Practice Customization mode in Developer Studio).
• Overlay Group = 0: Restricts users to working on base mode objects (Base Developer mode in Developer Studio).
• Overlay Group = (clear): No restrictions, allowing access to base, overlay, or custom objects.

Granular Overlays: This advanced concept allows customization at a more detailed level within an object. The types include:

• Additive Overlay / Extensions Overlay: Adds customizations without overwriting the original.
• Overwrite Overlay: Replaces the original object with the custom version.
• No Overlay / Inheritance Overlay: Inherits properties from the origin object without changes.

SEO Tip: Using terms like “granular overlays,” “best practice customization,” and “upgrade path” naturally weaves in relevant keywords.

Configuration and Administration

Configuration Files

The primary configuration file for the AR System server is ar.cfg (on Windows). This file contains crucial server settings and is dynamically generated during installation. It’s also where sensitive information like passwords might be stored (though best practices advise against this for highly sensitive credentials).

Database Considerations

The AR System database typically uses specific user credentials (e.g., ARAdmin) and is named Arsystem. Understanding the underlying database system is vital for performance tuning and troubleshooting.

Platform Recommendations: The “best” platform hinges on your IT staff’s existing expertise and infrastructure.

• Windows shops often opt for Windows/SQL Server.
• UNIX shops typically choose the most prevalent UNIX flavor and database in their environment.

Popular Configurations (in order of prevalence):

1. Windows / SQL Server
2. Windows / Oracle
3. Solaris / Oracle
4. HP-UX / Oracle
5. AIX / DB2
6. AIX / Oracle
7. Red Hat / Oracle

Larger enterprises tend to favor UNIX, while smaller to mid-sized companies often find Windows/SQL Server a more accessible and cost-effective solution.

Sequence of Table Creation During Installation

During a fresh AR System installation, tables are created in a specific order to establish the foundational database schema:

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

Understanding Port Numbers

Network connectivity and firewall rules rely on knowing the standard port numbers used by AR System components and related technologies:

• DB2: 50,000
• Oracle: 1521
• SQL Server: 1433
• JAVA Plugin Server: 9999
• Flash/Board Server: 1150 (Note: Some documentation may refer to 9998 for Flashboards; always verify your specific version.)
• SMTP: 25
• DIS Server Port: 2000

Troubleshooting Tip: If the Email Engine isn’t sending emails, ensure port 25 is open between the AR System server and your SMTP server. Similarly, check port 9999 for Java plugin communication.

License Management

AR System uses a license model to control concurrent access.

• Fixed Licenses: A specific number of users are allocated a license that is always available to them.
• Floating Licenses: These licenses are shared among a pool of users. While more costly, they are ideal for shift-based workforces where not everyone needs simultaneous access. If all floating licenses are in use, users will wait for one to become available. In some scenarios, a user might be granted “read-only” access if no licenses are available.

A common setup is 5 fixed and 5 floating licenses, allowing unlimited logins but capping concurrent usage.

Data Storage and Manipulation

Timestamps and Dates

As mentioned, date and time values are stored as the integer number of seconds since the Unix epoch (January 1, 1970). This method allows for efficient storage and comparison of date/time data.

Menus: Navigation and Data Selection

Menus are user-defined lists that provide predefined choices for fields. They can be:

• Static: The menu options are hardcoded (e.g., Character menus, Form Data Dictionary, Field Data Dictionary).
• Dynamic: The menu options are retrieved from a data source at runtime (e.g., Search menus, SQL menus).
• File Menus: Can be either static or dynamic.

Refresh Rates: How often menus are updated is controlled by settings like “On Connect,” “On Open,” or “On 15 Minute Interval.” “On Open” can impact performance if the menu is complex. Character menus, being static, do not refresh.

Note: Deleting a form or field associated with a menu does not delete the menu itself.

Attachment Pool Details

When using the Attachment Pool data type, AR System creates two database tables. One stores the main data (linked by the Request ID), and the other stores the binary attachment data. Each attachment entry includes file path, original size, and compressed size.

Interview Tip: Be ready to explain how attachments are stored, especially differentiating between attachment fields and attachment pools.

TBH Tables: Tracking Changes

When a form is saved, AR System may create up to three associated tables for tracking:

• T (Transaction Table): Stores the primary record data.
• B (Binary Table): Stores binary objects like attachments or active links.
• H (History Table): Stores the history of status changes for a record.

Troubleshooting Common Issues

Character String Exceeds Maximum Size

If you encounter an “ARERR [559] Character string exceeds maximum size allowed” error, it typically means a character field is trying to store more data than its defined limit. This is particularly problematic with multi-byte character sets.

Solution: Increase the input length of the character field in Developer Studio or use a Diary field for appending data.

Login Issues with Developer Studio

If you’re unable to log into Developer Studio with an account other than “Demo,” ensure that the user is assigned to the “struct sub-admin” group. This group grants necessary permissions for development activities.

Help Text Display Discrepancies

When users log in as “Demo,” they see more detailed field information (Field Name, Field ID, Help Text). Other users typically only see the Help Text. If Help Text is absent, they might see the field description.

Solution: Always populate Help Text for fields to ensure users receive guidance on their purpose and usage.

Form Deletion and Workflow Impact

Deleting a form in AR System also deletes any associated Active Links. This is an important consideration during maintenance or cleanup.

Version Information and Platform Specifics

Accessing Version Details

You can find detailed version information for your AR System installation by navigating to the “application properties form”.

Operating System and Web Server Support

For AR System 8.1.00, supported operating systems include Windows and Linux. Web servers such as Tomcat and Jboss are common, requiring a servlet engine. While IIS can be used, BMC does not typically recommend it.

Database Support

AR System 8.1.00 supports major databases like IBM DB2 (port 50000), Oracle (port 1521), and Microsoft SQL Server (port 1433).

Conclusion

The BMC Remedy Action Request System is a powerful and enduring platform that forms the backbone of many critical IT service management processes. By understanding its layered architecture, core components like workflows and forms, and the intricacies of its access control mechanisms, IT professionals can effectively administer, customize, and leverage its capabilities to their fullest potential. Whether you’re a seasoned administrator, a budding developer, or an IT leader aiming to optimize service delivery, a solid grasp of AR System fundamentals is invaluable.

This deep dive has aimed to provide a comprehensive yet accessible overview, equipping you with the knowledge to navigate the complex world of BMC Remedy AR System with confidence.