Demystifying AR System Architecture: A Deep Dive for Practitioners

In the realm of business process automation and IT Service Management (ITSM), few platforms stand as prominently as BMC Remedy Action Request System (AR System). Often referred to simply as “Remedy,” this robust system has been the backbone for countless organizations aiming to streamline operations without delving into complex programming. But what lies beneath the surface? Understanding the intricate architecture of AR System is crucial for anyone tasked with developing, administering, or troubleshooting applications built upon it.

This article will take you on a detailed journey through the AR System architecture, dissecting its components, explaining their roles, and offering practical insights that will resonate with seasoned professionals and aspiring system administrators alike.

The Evolution of Remedy and AR System

Before we dive into the architecture, it’s helpful to understand the historical context. The term “Remedy” is often used interchangeably with “Action Request System.” This stems from the original company, Remedy Corporation, founded in the early 1990s. They developed the Action Request System, a groundbreaking application for network management. Over the years, Remedy Corporation introduced new applications like Change Management and Asset Management. The company was acquired by Peregrine Systems, which later faced bankruptcy. In 2002, BMC Software acquired the Action Request System, and it has since been known as the BMC Remedy Action Request System.

Essentially, the AR System is the platform, and applications like BMC Remedy ITSM are built *on top of* this platform. Think of AR System as the operating system, and ITSM as a sophisticated application running on it. It’s also worth noting that AR System is often described as a fourth-generation programming language (4GL) environment, emphasizing its high-level, declarative approach to application development.

The Multi-Tiered Architecture: A Foundation for Scalability and Flexibility

At its core, AR System employs a layered, or tiered, architecture. This design is fundamental to its ability to scale, remain flexible, and ensure efficient processing. The primary tiers are:

1. Client Tier: The User’s Gateway

This is where the interaction begins. The Client tier encompasses all the tools and interfaces that users and developers interact with. These include:

• BMC Remedy User: The traditional client application used by end-users to interact with AR System applications, submit requests, and view information.
• BMC Remedy Developer Studio: The primary tool for application development and customization. Developers use this to design forms, create workflows, and configure system settings.
• Web Browsers: Accessed via the Mid Tier, browsers provide a web-based interface for users, offering convenience and accessibility.
• Other Clients: This can include utilities like BMC Remedy Data Import and BMC Remedy Migrator, which are also considered clients as they interact with the AR System server.

The key here is that clients present information, gather input, and communicate requests to the Mid Tier or Server Tier.

2. Mid Tier: The Web Connector and Request Translator

The Mid Tier acts as a crucial bridge, particularly for web-based access. It hosts components and add-in services that run on a web server, enabling users to interact with AR System applications through a web browser. Its responsibilities are multifaceted:

• Request Translation: It translates requests originating from web clients into a format that the AR System server can understand.
• Response Interpretation: It takes the responses from the AR System server and translates them back into a format suitable for web display.
• Web Service Handling: The Mid Tier is equipped to handle web service requests, allowing AR System to integrate with other systems.
• Server-Side Processes for Web Clients: It executes specific server-side processes to deliver AR System functionality to web-based users.

Common web servers supported by the Mid Tier include Apache Tomcat, JBoss, and others. While IIS can be used, BMC generally recommends Tomcat or JBoss for optimal performance and compatibility.

3. Server Tier: The Brains of the Operation

This is the heart of AR System, where the core logic resides. The AR System server is responsible for:

• Workflow Orchestration: It controls and executes all workflow processes defined within the applications. This includes active links, filters, and escalations.
• Data Access Control: It manages access to the underlying data in the Data Tier, ensuring that only authorized operations occur.
• Server-Side Applications: This tier hosts essential components like the Approval Server, Email Engine, and BMC Remedy Flashboards server, which provide specialized functionalities.
• Plug-in Servers: The C and Oracle Java plug-in servers, along with their respective plug-ins, execute specialized tasks and extensions to AR System’s core capabilities. The Java plug-in server typically listens on port 9999.

The AR System server itself is configured via the ar.cfg file (on Windows) or arsystem.cfg (on Unix/Linux), which dynamically stores configuration changes made during installation and administration. Passwords, while sensitive, are also stored within these configuration files, underscoring the importance of securing the server environment.

4. Data Tier: The Persistent Storage

This tier is responsible for the physical storage and retrieval of all AR System data. It primarily consists of:

• Database Servers: AR System typically relies on relational databases like Oracle, Microsoft SQL Server, or IBM DB2 to store its schemata, forms, and data. The AR System server interacts with these databases to read and write information.
• Other Data Sources: While less common, AR System can be configured to interact with other external data sources, often through Vendor Forms.

The default database user for AR System is often ARAdmin with a default password of AR#Admin#. It’s imperative to change these default credentials immediately after installation for security reasons.

Key Architectural Components and Concepts

Forms: The Building Blocks of Data Representation

Forms are the fundamental objects in AR System for representing data. They are conceptually similar to tables in a relational database but offer a much richer set of features for user interaction and workflow integration.

• Regular Forms: The most common type, directly mapping to a database table.
• View Forms: Used to present data from multiple underlying forms in a unified view.
• Join Forms: Allow you to link two or more regular forms based on common fields, enabling you to display related data from different sources in a single interface. BMC generally recommends joining up to 6 forms, though more are technically possible, but can impact performance.
• Vendor Forms: Facilitate access to external data sources, allowing AR System to interact with data residing outside its native database.
• Archive Forms: Used to move historical data from active forms to a separate, less frequently accessed location, improving performance on the primary forms. It’s important to note that you cannot archive an archive form.
• Audit Forms: Store historical changes to records, providing an audit trail. Auditing of audit forms is not allowed, but the archive of an audit form is possible.

Each form has a unique Form ID. Typical IDs include:

• Regular: 1
• Display: 4
• Join: 2
• View: 3
• Vendor: 5

Workflows: Automating Business Processes

Workflows are the intelligence behind AR System applications, automating business processes by triggering actions based on predefined conditions. They are the backbone of automation.

• Active Links: These are client-side workflows that execute based on user actions within the current form window. They can display messages, change field properties, or push data to other forms. Active links are triggered by client operations. They cannot be triggered via an API program. If you create an active link with the same name as an existing one, AR System will append _c to the new name. When saving a form, active links are not copied by default; however, renaming a form will usually preserve its associated active links. At least one action is necessary for an active link to be valid.
• Filters: These are server-side workflows that trigger in response to form transactions (submit, modify, delete) at the data layer. They are crucial for enforcing business rules, updating related records, or triggering other processes.
• Escalations: Similar to filters, but they execute based on a scheduled time interval, not necessarily immediate user interaction. They are ideal for tasks like sending reminders, automatically closing inactive tickets, or performing batch updates.

Menus: Enhancing User Input and Navigation

Menus provide a structured way for users to select options or navigate through data. They can be attached to character fields.

• Static Menus: Options are predefined by the developer (e.g., Character, Form data dictionary, Field data dictionary).
• Dynamic Menus: Options are retrieved at runtime (e.g., Search, SQL).

File menus can be both static and dynamic.

Refresh Rate in Menus: This setting determines how often a menu’s contents are updated:

• On Connect: Refreshes the menu when the user opens the form. Reopening the form is needed for updates.
• On Open: Refreshes the menu every time it’s opened. Use judiciously to avoid performance impact.
• On 15 Minute Interval: A balance between currency and performance. Retrieves the menu on open and then every 15 minutes.

Note that character menus are static and do not refresh. Deleting a menu associated with a field or form does not automatically delete the menu definition itself.

Fields: The Granular Data Holders

Fields are the individual elements within a form that store specific pieces of data. AR System offers various field types, each with distinct characteristics.

• Character Field: Stores alphanumeric characters. Can be overwritten. Supports menus. Web reports have limitations with character fields containing multi-byte data.
• Diary Field: Similar to character fields but appends data with a timestamp and user information, preserving the history of entries. This is valuable for tracking changes or conversations within a ticket. In the database, diary field values appear as [modified timestamp in seconds -| User -| Data].
• Attachment Field: Allows users to attach files to a record.
• Attachment Pool: A data type that can hold multiple attachments. Two tables are typically created: BSchema_id (linking to the request) and Battachpoolid (storing binary data). Each attachment creates three columns in the binary table: path, original size, and compressed size.

Core Fields: AR System reserves specific field IDs for critical data:

• Request ID: 1
• Submitter: 2
• Create Date: 3
• Assigned To: 4
• Last Modified By: 5
• Modified Date: 6
• Status: 7
• SD (Service Desk?): 8
• Status History: 15 (Hidden)

Groups and Permissions: Controlling Access

AR System employs a robust permission model to control who can access what data and perform which actions.

• Explicit Groups: Users are manually assigned to these groups. Access rights are granted to the group, and all members inherit those rights. Examples include admin, sub-admin, customizer. Explicit groups are server-specific, so consider deployable applications for cross-server scenarios.
• Implicit Groups: Users are automatically members based on specific conditions or circumstances. Examples include public, assignee, submitter. Dynamic groups also fall under this category.

Group Types:

• View
• Change
• None

Group Categories and Ranges:

• Regular/Computed: 1000-14999 (Explicit)
• Dynamic: 60000-60999 (Implicit)

Overlay Groups: Managing Customizations

Overlays are essential for managing customizations without altering the original “out-of-the-box” (OOTB) objects. Overlay Groups define the level of access and modification users have:

• Overlay Group set to 1: Users are restricted to working on overlay and custom mode objects. They can only work in Best Practice Customization mode in Developer Studio.
• Overlay Group set to 0: Users are restricted to working on base mode objects. They can only work in Base Developer mode.
• Overlay Group cleared: No restrictions; users can access base, overlay, and custom objects.

Granular Overlays take this a step further, allowing customization of subcomponents of an object:

• Additive Overlay (Extensions): Adds new functionality to OOTB objects. Additions are appended during upgrades.
• Overwrite Overlay: Replaces the OOTB object entirely. Useful for removing permissions or significant changes.
• No Overlay (Inheritance): The default. Inherits properties from the OOTB object without modification.

Installation and Configuration Insights

Database Table Creation Sequence

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

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

The control table is the very first table created after installation.

Core Tables for Workflow Objects

Database tables are used to store workflow objects. Table names are often prefixed with the schema name (e.g., dbo. for SQL Server):

• Active Links: dbo.actlink (and dbo.actlink_[action_name])
• Filters: dbo.filter (and dbo.filter_[action_name])
• Escalations: dbo.escalation (and dbo.escalation_[action_name])

Garbage Collection

AR System utilizes a garbage collector to manage memory. The Xincgc parameter refers to the incremental garbage collector, which helps optimize memory usage.

Configuration Files and Locations

• ar.cfg (Windows) / arsystem.cfg (Unix/Linux): Contains AR System server configuration settings.
• AR System Log Files: Typically found in C:\Users\Administrator\AppData\Local\Temp\1\arsystem_install_log.txt (or similar paths depending on the OS and installation).
• Host file and Services: Located at C:\Windows\System32\drivers\etc, this is where port numbers and associated services are defined.

Licensing: Understanding User Access

AR System employs different license types to manage user access. Understanding these is crucial for capacity planning and cost management.

• Fixed Licenses: A user is permanently assigned a license. They can always log in.
• Floating Licenses: A license is acquired when a user logs in and released when they log out. This is beneficial for shift-based workforces or when not all users require 24/7 access. Floating licenses are generally more expensive than fixed licenses.

Scenario: If you have 5 fixed and 5 floating licenses, an unlimited number of users can *log in*. However, they will have to wait for a license to become available if all 10 are currently in use. Users without an available license will typically operate with read-only access.

Common Configurations and Best Practices

While AR System can run on various operating systems and databases, certain configurations are more prevalent due to performance, scalability, and administrative familiarity.

The most popular configurations, based on support call data, are:

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 often lean towards UNIX-based systems for their scalability, while mid-to-smaller companies may find Windows/SQL Server more accessible. Ultimately, the best platform combination is one that your IT staff is most comfortable administering and maintaining, as OS and database administration costs often outweigh the AR System licensing cost in the long run.

Version Information and Development Studio

To find version information for your AR System installation, you can typically access the Application Properties form. This form consolidates essential details about the deployed applications.

BMC Remedy Developer Studio is your primary tool for application development and customization. When working with Developer Studio, understanding the nuances of overlays and customization modes is paramount. The concept of “Granular Overlays” allows for more precise customization by enabling you to choose subcomponents of an object and apply different overlay types, thereby minimizing reconciliation efforts during upgrades.

Troubleshooting Common Scenarios

Status History Viewing

To view the “Status History” (field ID 15), you can:

• In BMC Remedy User, modify the Status field, then go to the View menu and select “Status History.”
• Alternatively, open a form in modify mode in the User tool and press Ctrl+H.

Request ID Prefix and Length Restriction

To give a prefix (e.g., “ABC”) to the Request ID field and restrict its length:

• Open the Request ID field’s properties.
• In the “Default Value” section, set the prefix (e.g., "ABC").
• In the “Database” tab, under “Input Length,” set the desired maximum length.

Form Permissions and Menus

If a scenario requires specific form permissions (e.g., vyomgroup and wiproGroup) and field permissions for different groups, you would configure these within the AR System permissions management tools. For menus, remember that you cannot directly assign permissions to them. The permissions of the character field to which the menu is attached will dictate access to the menu.

Database Table Interactions

• Attachment Pool: Creating two entries in the attachment pool will result in corresponding entries in the relevant database tables, tracking the file paths and sizes.
• Menu Storage: Menus are stored in tables like dbo.field_enum and dbo.field_enum_value, linked by their IDs.
• Form Deletion: When a form is deleted, associated active links are also deleted, provided they are exclusively linked to that form.

Time Storage

AR System stores date/time values as the integer number of seconds since 00:00:00 GMT on January 1, 1970 (Epoch time). This format supports dates up to January 18, 2038. This conversion includes all leap year days encountered within that period.

Conclusion

The BMC Remedy Action Request System is a powerful and flexible platform, underpinned by a well-defined multi-tiered architecture. By understanding the roles of the Client, Mid, Server, and Data tiers, along with the intricacies of forms, workflows, menus, fields, and the permission model, administrators and developers can effectively leverage its capabilities. Whether you’re troubleshooting a sticky workflow, designing a new application, or simply seeking to deepen your understanding of this cornerstone ITSM tool, a solid grasp of its architecture is your most valuable asset.