Demystifying AR System (ARS) Basics: A Deep Dive for IT Professionals

In the fast-paced world of IT service management and business process automation, understanding the foundational platforms is crucial. One such robust and widely adopted platform is the BMC Remedy Action Request System, often referred to simply as AR System or ARS. For many IT professionals, Remedy is the application, and AR System is its powerful engine. This article aims to demystify AR System, covering its core concepts, architecture, key components, and practical insights that are invaluable for both new adopters and seasoned veterans.

What is BMC Remedy Action Request System (ARS)?

At its heart, BMC Remedy Action Request System is a powerful, fourth-generation platform designed for automating business processes. The beauty of AR System lies in its accessibility; it empowers non-programmers to build sophisticated business workflow applications without needing to delve into complex programming languages or development tools. These applications can then be deployed seamlessly across various environments, including web, Windows, UNIX®, and Linux®.

AR System serves as the foundational layer for BMC’s IT Service Management (ITSM) suite, acting as the bedrock upon which critical ITSM applications like Incident Management, Problem Management, and Change Management are built. It’s also capable of automating a wide spectrum of support and business processes beyond IT, making it a versatile tool for organizations looking to streamline operations.

The Genesis: From Remedy Corporation to BMC Software

The history of AR System is a tale of evolution and acquisition. Founded in 1990, the original Remedy Corporation introduced the Action Request System in 1991. Over the years, Remedy Corporation grew, eventually being acquired by Peregrine Systems, Inc. in 2001. However, Peregrine Systems faced bankruptcy in 2002, leading to BMC Software acquiring the Action Request System. This acquisition brought the platform under the BMC umbrella, and it has since been known as BMC Remedy Action Request System. This historical context is important, as you might still encounter references to “Remedy” as the application and “Action Request System” as the underlying technology. For clarity, there’s no functional difference; it’s simply the evolution of its naming and ownership.

Key Timeline Milestones:

• 1990: Remedy Corporation is founded.
• 1991: Remedy introduces its Action Request System.
• 1995: Remedy goes public.
• 1996: Remedy introduces new applications and launches Flashboards.
• 2001: Remedy is acquired by Peregrine Systems, Inc.
• 2002: Peregrine Systems files for bankruptcy and sells Remedy to BMC Software, Inc.
• 2003: Remedy continues to operate as a BMC Software subsidiary.

AR System Architecture: A Layered Approach

Understanding the architecture of AR System is key to appreciating its scalability and flexibility. It’s typically structured in distinct tiers, each with a specific role:

Key Concepts and Components

Delving deeper into AR System reveals a set of fundamental concepts and components that are essential for building and managing applications.

Forms: The Building Blocks of Data Representation

Forms are the primary way AR System represents data. Think of them as the user interface and the underlying database tables for your applications. They are schema definitions that dictate what information is collected and how it’s displayed. Different types of forms exist:

• Regular Forms: The most common type, used for direct data entry and display.
• View Forms: Primarily used to display data without allowing modifications.
• Join Forms: Allow you to combine data from multiple regular forms into a single view, enabling more complex reporting and data aggregation. BMC recommends joining up to 6 forms for optimal performance, though more are technically possible.
• Vendor Forms: These are special forms that enable AR System to access external data sources. They act as an interface to data residing outside the AR System database, effectively making external data appear as if it were part of an AR System form.
• Advanced Forms: This can encompass View forms and Vendor forms.

Each form has a unique Form ID, with common ones being: Regular (1), Join (2), View (3), Display (4), and Vendor (5).

Workflows: The Automation Engine

Workflows are the automated processes that drive your AR System applications. They define the actions that occur in response to specific events. The primary workflow objects are:

• Active Links: These are triggered by client-side operations or information displayed on the current form. They execute in response to user actions like clicks, key presses, or form opening. Importantly, active links cannot be triggered via API programs and require at least one action to be defined. If you save a form with the same name as an existing one, AR System will append _c to the new active link’s name to ensure uniqueness.
• Filters: Filters operate on the server-side and are triggered by form transactions such as Submit, Modify, or Delete operations. They are essential for enforcing business logic, validating data, and initiating server-side actions based on data changes.
• Escalations: Similar to filters, escalations are server-side workflow objects. However, they are triggered based on predetermined time intervals rather than direct user actions or data modifications. They are ideal for tasks like sending overdue notifications or running periodic data cleanups.

When a form is deleted, its associated active links and filters are also deleted, but only if they are not associated with any other forms.

Menus: Guiding User Input

Menus provide users with predefined options for fields, simplifying data entry and ensuring consistency. They can be:

• Static: Options are hardcoded or come from a specific form’s data dictionary.
• Dynamic: Options are fetched via search or SQL queries, allowing for more dynamic content.

Character fields are particularly well-suited for menus, as any character field can have a menu attached to it. The refresh rate of a menu (On Connect, On Open, On 15 Minute Interval) is crucial for balancing data currency with performance. Note that character menus are static and do not require a refresh mode.

Fields: The Data Carriers

Fields are the individual elements on a form that hold specific types of data. Key field types include:

• Character Fields: Used for alphanumeric text. They can be overwritten and are often used with menus. Web reports do not support diary fields or attachment fields, but they do support currency fields.
• Diary Fields: These are special character fields that append new entries rather than overwriting them. Each entry is prefixed with a timestamp and the user who made the entry, preserving a history of changes. This format is typically represented in the database as [modified timestamp in seconds -| User -| Data].
• Attachment Fields: Allow users to attach files to a record.
• Attachment Pool: A data type that can hold multiple attachments for a single record.

Character Field vs. Diary Field: A key distinction is that character fields can be overwritten, while diary fields append data with a timestamp and username, preserving all entries.

Groups and Permissions: Controlling Access

AR System employs a robust system for managing user access and permissions. This is achieved through Groups, which are collections of users, and Permission Groups/Roles which define what those groups can do.

• Types of Groups:
  • Explicit Groups: Users are manually assigned to these groups (e.g., Admin, Sub-Admin).
  • Implicit Groups: Users belong to these groups based on specific conditions or roles (e.g., Public, Assignee, Submitter).
• Group IDs: These are integer identifiers for groups. Ranges are allocated for AR System, regular/computed groups, CMDB groups, and future applications. For example, 0-1000 are typically for AR System groups.
• Access Levels: Permissions can be set at various levels, including View, Change, and None, to control user actions on forms, rows, and columns.

Core Fields: The Essential Data Points

Every AR System record (or request) has a set of core fields that are fundamental to its management:

• Request ID (Unique identifier for each record)
• Submitter
• Create Date
• Assigned To
• Last Modified By
• Modified Date
• Status
• Status History (Often hidden, but accessible for review)

TheRequest ID field can be customized with a prefix and length restrictions through its properties in Developer Studio. The Status History can be viewed by modifying the Status field and navigating through the View menu.

Database Interaction and Configuration

AR System relies heavily on a relational database for storing its metadata and application data. Understanding this interaction is crucial for administration and troubleshooting.

Database Structure and Tables

When AR System is installed, it creates several essential tables in the specified database. The sequence of table creation during installation typically includes:

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

Workflow objects are stored in specific tables:

• Active Links: dbo.actlink and dbo.actlink_
• Filters: dbo.filter and dbo.filter_
• Escalations: dbo.escalation

When a form is saved, AR System typically creates three types of tables in the database:

• T (Transaction Table): Stores the actual data for the form.
• B (Binary Table): Stores attachments and other binary data.
• H (History Table): Stores status history for records.

The database user for AR System is typically ARAdmin, with default credentials often being ARAdmin and password AR#Admin#. The primary AR System database is usually named Arsystem.

Configuration Files

The ar.cfg file (or armid.cfg for Mid Tier) is critical for AR System server configuration. It stores settings and is dynamically created during installation. Passwords and other sensitive configuration details are saved within these files.

Data Storage for Dates and Times

AR System stores date and time values as the integer number of seconds elapsed since January 1, 1970, 00:00:00 GMT. This method, known as “epoch time” or “Unix time,” is used for dates ranging from January 1, 1970, through January 18, 2038. This includes accounting for leap years.

Attachment Handling

Attachments are managed through a system involving attachment pools and attachment fields. When an attachment is created, the system typically creates two tables: BSchema_id and Battachpoolid. Within the binary table of a transaction, an attachment typically results in columns like C (file path), CO (original size), and CC (compressed size).

Licensing and User Access

AR System employs different license types to manage user access and control costs. Understanding these is vital for IT administrators.

• Fixed Licenses: These are assigned to individual users and allow them to log in without waiting. The submitter can change if the license type is Fixed.
• Floating Licenses: These are more costly and are shared among users. A user can log in, and a floating license is consumed. If no floating licenses are available, the user might be restricted to read-only access or have to wait. Floating licenses are often utilized during shift-based work to optimize costs.

License Scenario: If you have 5 fixed and 5 floating licenses, an unlimited number of users can *log in*. However, only 10 users can actively use a licensed session at any given time. Others will have to wait for a license to become available.

Developer Studio Access

For users to log in to BMC Remedy Developer Studio, they need appropriate permissions. Beyond the “Demo” user, adding a user to the struct sub-admin group is typically required to grant them developer access.

Overlay Groups: Customization and Upgrades

Overlay groups are a fundamental concept for managing customizations in AR System, especially when dealing with upgrades and patches. They allow for granular control over how customizations are applied and inherited.

• Overlay Group 1: Restricts users to working only with overlay and custom objects. In Developer Studio, this forces users into “Best Practice Customization” mode.
• Overlay Group 0: Restricts users to working only with base mode objects (out-of-the-box). In Developer Studio, this forces users into “Base Developer” mode.
• Overlay Group Clear: Provides no restrictions, allowing users to work with base, overlay, or custom objects freely.

Granular Overlays: This feature allows for more precise customization by letting you choose specific subcomponents of an object to apply different overlay types to. This minimizes reconciliation efforts during upgrades.

• Additive Overlay (Extensions Overlay): Adds customized information to existing origin object definitions.
• Overwrite Overlay: Replaces the origin object entirely, ignoring its original definition. Useful for removing permissions, for example.
• No Overlay (Inheritance Overlay): The default. The object or its parts inherit properties from the origin object without changes.

Troubleshooting Common Issues

Even the most robust systems can encounter hiccups. Here are some common areas and how to approach them:

Interview Relevance

Understanding AR System is often a key requirement for roles in IT Service Management, application support, and BMC administration. Knowing the fundamentals can significantly boost your confidence and performance in interviews.

Conclusion

BMC Remedy Action Request System is a cornerstone of modern IT service management and business process automation. Its ability to empower non-programmers to build sophisticated applications, combined with its robust architecture and flexible customization options, makes it an indispensable tool for organizations aiming for efficiency and streamlined operations. By grasping the core concepts outlined in this article—from its architecture and key components to its database interactions and licensing models—you’ll be well-equipped to navigate, manage, and leverage the power of AR System effectively.

Whether you’re a newcomer to the platform or looking to deepen your expertise, a solid understanding of AR System basics is the first step towards mastering its full potential.