Control Records in BMC Remedy Action Request System

Understanding the foundational elements of BMC Remedy Action Request System (ARS) is crucial for anyone involved in its administration, development, or advanced usage. Among these foundational elements, ‘Control Records’ play a subtle yet vital role in the system’s architecture and operational integrity. While not always overtly visible to end-users, these records are the silent guardians of system settings, configurations, and crucial identifiers. This article aims to demystify control records, explain their significance, and touch upon related concepts that ensure a robust ARS environment.

The Genesis: Remedy and Action Request System

Before we dive deep into control records, it’s essential to clarify the terminology. Many are familiar with “Remedy” and “Action Request System” (ARS) as distinct entities. However, as the provided reference highlights, there is no fundamental difference. The journey began with Remedy Corporation introducing the Action Request System. Later, after acquisitions by Peregrine Systems and subsequently by BMC Software, the platform evolved into what is now known as BMC Remedy Action Request System. This historical context is important because the core concepts, including how control records are managed, have largely remained consistent through these transitions.

What Exactly Are Control Records?

In the context of BMC Remedy ARS, “Control Records” isn’t a single, explicitly defined object type in the same way a “Form” or “Active Link” is. Instead, the term broadly refers to a set of critical system records that manage fundamental aspects of the ARS server’s operation, configuration, and internal workings. These records are often stored in system-level tables and are integral to the AR System’s lifecycle, from installation to ongoing maintenance.

Think of them as the system’s internal “settings panel” that isn’t directly accessible through the user interface for modification but is essential for its proper functioning. The most prominent example of a control record is the control table, which is typically the first table created during an ARS installation.

The Crucial control Table

The control table is a cornerstone of the AR System’s architecture. It holds essential configuration parameters and unique identifiers that the AR System server relies upon to operate. Key pieces of information managed here include:

• System Initialization Parameters: Settings that dictate how the AR System server starts up and behaves.
• Unique Identifiers: Such as the server’s own internal ID, which is vital for communication and integration with other components.
• License Information: While license management has its own interfaces, underlying system checks might reference data originating from or related to control records.
• Operational Flags: Various internal flags that control specific system behaviors.

The integrity of the control table is paramount. Any corruption or accidental deletion of records within this table can lead to severe system instability or prevent the AR System server from starting altogether. This is why direct manipulation of these system tables is strongly discouraged.

Other Key Control-Related Tables

Beyond the primary control table, several other system tables often function as “control records” in a broader sense, managing specific aspects of the ARS environment. These include:

• controlRecordIds: As the name suggests, this table likely manages sequences or specific types of record IDs used internally by the system.
• arschema: This table is fundamental, storing metadata about all the forms (schemas) in the system, including their IDs, names, and types. While it’s a metadata repository, it controls how ARS references and accesses forms.
• schema_index: Manages the indexing strategies for various schemas, impacting query performance and data retrieval.
• schema_group_ids: Likely involved in mapping schema permissions to groups, playing a role in access control.

The sequence of table creation during an ARS installation, as provided, clearly illustrates the importance of these initial control structures: control, controlRecordIds, arschema, schema_index, and schema_group_ids. This order ensures that the foundational elements for managing schemas and system parameters are in place before application-specific data structures are established.

The AR System Architecture and Control

Understanding control records becomes clearer when viewed within the AR System’s layered architecture. The system is typically divided into:

• Client Tier: User interfaces, developer tools (like Developer Studio), and migration tools.
• Mid Tier: The web server component that translates client requests for web users and interfaces with the server tier.
• Server Tier: The heart of ARS, housing the AR System server itself, which manages workflow (active links, filters, escalations), and interfaces with the data tier. This tier also hosts auxiliary servers like the Email Engine and Flashboards server.
• Data Tier: The database servers where all application data and system metadata are stored.

Control records, particularly those in tables like control and arschema, reside in the Data Tier but are fundamentally managed and utilized by the Server Tier. The server relies on these records to correctly identify itself, access its configuration, and manage the schemas that represent your applications.

Database Specifics and Control

The AR System is designed to be flexible regarding its underlying database. Common configurations include:

• Windows / SQL Server
• Windows / Oracle
• Solaris / Oracle
• HP-UX / Oracle
• AIX / DB2
• AIX / Oracle
• Red Hat / Oracle

Regardless of the chosen database, the AR System server interacts with it through standardized interfaces. The specific control records reside within the AR System’s database (e.g., named Arsystem with the default administrative user ARAdmin and password AR#Admin#). The database schema for workflow objects also reflects this control structure:

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

These tables, while containing workflow definitions, are still part of the system’s core structure, akin to control records for process automation.

Configuration and Control: The ar.cfg File

While many system settings are embedded in control records within the database, the AR System server’s configuration is also heavily influenced by configuration files. The ar.cfg file (or ar.conf on Unix-like systems) is paramount here. This file, dynamically created during installation, contains critical server configuration changes.

Important Note: The reference mentions that passwords can be saved into the .cfg file. While this is technically true for certain service accounts or initial setup credentials, it’s a significant security concern. Best practices dictate using more secure methods for credential management, such as OS-level service account security or dedicated credential stores, rather than plain text in configuration files.

ar.cfg dictates settings like:

• Server name and ports
• Logging levels
• Plugin configurations
• Cache settings
• And many other operational parameters.

Changes to ar.cfg typically require an AR System server restart to take effect, further emphasizing its role as a fundamental control mechanism.

Licensing: A Form of Control

Licensing is a critical aspect of controlling user access and system utilization. AR System offers various license types, including Fixed and Floating. The interplay between these license types and user login attempts is a form of control:

• Fixed Licenses: Dedicated to a specific user.
• Floating Licenses: Can be shared among a pool of users, typically used during specific working hours or for temporary access. If you have 5 fixed and 5 floating licenses, up to 10 users can log in concurrently. If more users attempt to log in, they will queue and wait for a license to become available.

Floating licenses are generally more costly but offer flexibility, especially in environments with staggered work shifts. Managing these licenses effectively is a key administrative control.

Access Control and Group Management

Control over who can access what is managed through AR System’s robust group and permission system. This is another vital layer of control:

• Types of Groups:
  • Explicit Groups: Manually assigned to users. Examples include admin, sub-admin, customize.
  • Implicit Groups: Users belong to these based on specific conditions or system roles (e.g., Submitter, Assignee, Public).
• Group ID Ranges: Different ranges are allocated for various group types (AR System, regular, computed, CMDB, dynamic groups).
• Group Types for Permissions:
• View: Can see data but not modify.
• Change: Can view and modify data.
• None: No access.
• Overlay Groups: These are special groups that control whether a user can work with base objects, overlay objects, or custom objects in Developer Studio. Setting the Overlay Group field to 1 restricts users to custom mode, 0 restricts to base mode, and a clear value allows access to all. This is a powerful control for development environments.

These group and permission settings directly influence what users can see and do within the system, acting as fine-grained control mechanisms.

Data Storage and Control: Dates, Timestamps, and Fields

The way AR System stores data impacts how it’s controlled and interpreted:

• Date/Time Storage: AR System stores dates and times as the integer number of seconds since 00:00:00 GMT on January 1, 1970 (Unix epoch time). This method allows for efficient storage and calculation for dates between January 1, 1970, and January 18, 2038.
• Core Fields: AR System has 9 core fields (Request ID, Submitter, Create Date, etc.) that are fundamental to every record and are managed with specific system controls. The “Status History” (Field ID 15) is a critical control record for tracking the lifecycle of a request.
• Character vs. Diary Fields:
  • Character Fields: Alphanumeric data. Can be overwritten. Menus can be attached to them.
  • Diary Fields: Designed for appending text. Each entry includes a timestamp, user, and the appended data, maintaining a full history. This is a form of controlled historical record-keeping.
• Attachment Pool: For attachments, AR System uses a specialized field type and underlying tables (e.g., BSchema_id, Battachpoolid) to manage binary data. This structured approach controls how attachments are stored and associated with records.

Workflow as Controlled Execution

The core of AR System’s automation lies in its workflow objects. These are essentially controlled sequences of actions:

• Active Links: Triggered by client-side operations (user actions on the current screen). They execute in the client or mid-tier and are NOT triggered by API programs. They cannot have the same name as another active link on the same form and typically require at least one action.
• Filters: Triggered by server-side events such as submitting, modifying, or deleting a record. They are crucial for enforcing business rules and data integrity.
• Escalations: Similar to filters but triggered based on scheduled time intervals. They are used for proactive actions like overdue reminders or automated closures.

These workflow objects, along with associated Permissions (controlling access to forms, rows, and columns) and Roles, form the intricate web of controlled execution that defines your business processes within ARS.

Forms and Their Control Structures

Forms are the primary interface for users and developers. Their control structures are manifold:

• Form IDs: Different form types have unique IDs (Regular=1, Display=4, Join=2, View=3, Vendor=5). These IDs are fundamental control elements.
• View Forms: Allow presenting data in a specific layout for different users or purposes.
• Vendor Forms: Enable AR System to access arbitrary external data sources, acting as a controlled gateway to external information.
• Join Forms: Combine data from multiple forms based on defined criteria. BMC recommends joining up to 6 forms, though more are technically possible. The join criteria, once defined, cannot be easily changed (a noted quirk in some versions).
• Overlay Groups and Granular Overlays: As mentioned, these control customization. Granular overlays allow fine-grained control by applying different overlay types (Additive/Extensions, Overwrite, No Overlay/Inheritance) to subcomponents of an object. This minimizes reconciliation efforts during upgrades.

Menus: Controlled Data Presentation

Menus provide selectable lists of options for fields. They are a form of controlled data:

• Types of Menus:
• Static: Defined directly (Character, Form data dictionary, Field data dictionary).
• Dynamic: Retrieved from external sources (Search, SQL).
• Menu Refresh Modes: Controls how often menu content is updated (On Connect, On Open, On Interval). This balances currency with performance. Character menus are static and not refreshed.
• Menu Storage: Stored in tables like dbo.char_menu and dbo.field_enum.
• Permissions: You cannot directly assign permissions to menus. However, the permissions of the character field to which the menu is attached will govern access.
• Levels and Children: Menus have a hierarchy (e.g., 15 levels, 99 children for character/file menus), providing controlled structure.

Troubleshooting and Best Practices Related to Control Records

Given their critical nature, issues with control records can be daunting. Here are some common scenarios and advice:

Interview Relevance

Understanding control records and related concepts is vital for ARS administrators and developers. Here’s why:

Conclusion

Control records, though often operating behind the scenes, are fundamental to the stability, security, and functionality of BMC Remedy Action Request System. From the initial installation tables like control and arschema to configuration files like ar.cfg, and extending to the structured management of data, users, and workflow, ARS employs numerous control mechanisms. A deep understanding of these elements is not just academic; it’s essential for effectively administering, troubleshooting, and developing robust solutions on the AR System platform. By respecting these control structures and adhering to best practices, you ensure the longevity and reliability of your ARS deployments.

For further in-depth information, refer to the official BMC Remedy AR System documentation, particularly the Administration and Development guides.

Official BMC Documentation Links:

• BMC Remedy Action Request System Documentation (example for a specific version, search for your version)
• AR System Configuration Files
• Workflow Objects in AR System