Demystifying the AR System Server Tier: The Engine Room of Your ITSM

In the intricate world of IT Service Management (ITSM) and enterprise application architectures, understanding the core components is paramount. When we talk about BMC’s AR System, one tier stands out as the powerhouse, the orchestrator of processes, and the gatekeeper of data: the Server Tier. This isn’t just a collection of software; it’s the brains of the operation, where the magic of workflow automation, data management, and application logic truly happens. Let’s dive deep into what makes the Server Tier tick, why it’s crucial, and what you need to know to manage, troubleshoot, and even excel in interviews related to it.

The Heartbeat of AR System: The AR System Server

At the absolute core of the Server Tier is the AR System Server itself. Think of it as the central processing unit (CPU) for your entire AR System environment. Its primary responsibilities are twofold:

• Workflow Execution: It’s responsible for interpreting and executing the business logic defined within your AR System applications. This includes the complex interplay of active links, filters, and escalations that automate tasks, guide users, and ensure data integrity.
• Data Management: It acts as the intermediary between the client applications (like BMC Helix ITSM, or Remedy User Tool) and the Data Tier (your databases). It handles requests for data, applies security and workflow rules, and ensures that data is stored and retrieved correctly.

Without the AR System Server, your forms would be static pages, and your automated processes would grind to a halt. It’s the engine that drives your ITSM processes forward, ensuring that requests are handled efficiently and that your IT services run like a well-oiled machine.

Beyond the Core: Essential Server-Side Applications

While the AR System Server is the main act, it’s supported by a cast of crucial server-side applications that extend its capabilities significantly:

The Approval Server

This is your digital stamp of authorization. The Approval Server automates the approval process, routing requests to the right people at the right time. Whether it’s approving a change request, a request for a new piece of hardware, or a user’s access rights, the Approval Server ensures that all necessary sign-offs are obtained before proceeding, providing a robust audit trail.

The Email Engine

Communication is key in any ITSM process. The Email Engine is responsible for sending and receiving emails. It can be configured to send notifications to users about ticket updates, approvals, or other important events. Conversely, it can also process incoming emails, turning them into AR System requests or updating existing ones. This bridges the gap between the digital world of AR System and the ubiquitous nature of email.

BMC Remedy Flashboards Server

For those who love data visualization, the Flashboards server is your best friend. It allows you to create dynamic, real-time dashboards and reports that present key performance indicators (KPIs) and operational metrics in a visually appealing and easily digestible format. This helps stakeholders quickly grasp the health and performance of IT services.

Extending Functionality with Plug-in Servers

AR System’s modular design allows for extensibility through plug-in servers. These components allow you to integrate with external systems or perform complex operations that aren’t natively built into the core AR System server.

• C Plug-in Servers: These are typically used for legacy integrations or when performance-critical operations are required. They leverage the C programming language for maximum efficiency.
• Oracle Java Plug-in Servers: With Java being a dominant language in enterprise development, these servers allow you to leverage Java-based libraries and applications to extend AR System functionality. This is a common choice for modern integrations and custom logic.

The presence and configuration of these plug-in servers are vital for extending AR System’s capabilities beyond its out-of-the-box features, enabling seamless integration with other enterprise tools.

Configuration: The `ar.cfg` File

How does the AR System Server know how to behave? A lot of that is dictated by its configuration. The primary configuration file for the AR System server is typically ar.cfg (or ar.conf on Unix/Linux systems). This file, dynamically created during installation, holds crucial settings that dictate everything from database connections to performance tuning parameters. It’s the Rosetta Stone for understanding your AR System server’s behavior.

Troubleshooting Tip: If your AR System service won’t start, or you’re experiencing strange behavior, the ar.cfg file is one of the first places to look. Corrupted entries, incorrect paths, or mismatched parameters can cause significant issues. Always back it up before making changes!

Database Interactions: Users and Sequences

The AR System Server constantly interacts with your database. Understanding these interactions is key to performance tuning and troubleshooting.

Default Database Credentials

During installation, default credentials are set up to allow the AR System server to communicate with the database. These are:

• Database User (Default): ARAdmin
• Database Password (Default): AR#Admin#

While these are defaults, it’s a security best practice to change them to stronger, more unique credentials in a production environment.

Database Table Sequences During Installation

When AR System is installed, it creates several essential tables in the database. The order in which these tables are created or referenced is important:

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

These tables form the foundational metadata for your AR System environment.

Database Table Mappings

AR System maps its internal objects to database tables. Understanding these mappings helps in direct database queries or understanding data structure:

• Active Link: Mapped to database tables like dbo.actlink and often has a corresponding dbo.actlink_ table for specific data.
• Filter: Similar to active links, mapped to dbo.filter and dbo.filter_.
• Escalation: Mapped to the dbo.escalation table.

Performance Tuning: Garbage Collection and Ports

Keeping your AR System running smoothly often involves optimizing its performance. Two key areas are garbage collection and port management.

Garbage Collector

Xincgc is the incremental garbage collector used by AR System. Its role is to efficiently reclaim memory that is no longer in use. Properly configured garbage collection is vital to prevent memory leaks and ensure consistent performance, especially under heavy load.

Port Numbers

AR System relies on various ports to communicate with databases, clients, and other services. Knowing these is crucial for network configuration, firewall rules, and troubleshooting connectivity issues:

• DB2: 50,000
• Oracle: 1521
• SQL Server: 1433
• JAVA plugin port: 9999 (This is a common default, but can be reconfigured.)
• Flash/Board: 1150 (Note: Some documentation might show 9998; verification is always good practice.)
• SMTP: 25 (Standard port for sending emails.)
• E-mail Engine: (The provided text doesn’t specify a default port, but it’s crucial to know and configure this for email functionality.)
• DIS Server Port: 2000

Troubleshooting Tip: If you’re facing connection issues between your AR System server and the database, or between the server and other services, check your firewall rules to ensure the necessary ports are open. Port conflicts can also arise if other applications are using the same ports.

Version Information and Application Properties

Keeping track of your AR System version is essential for support, upgrades, and compatibility. This information is readily available within the application itself:

• Version Information: You can typically find detailed version information on the “application properties form” accessed through the “Share” menu within the AR System interface.

Managing Customizations: Overlay Groups

One of the most significant features in modern AR System deployments is the concept of overlays for customizations. Overlay groups provide a structured way to manage how customizations interact with vendor (base) objects, especially during upgrades.

• Overlay Group set to 1: This restricts users to working on overlay and custom mode objects. In BMC Developer Studio, users will operate in Best Practice Customization mode. This is ideal for developers focused on creating new customizations without altering base objects.
• Overlay Group set to 0: This restricts users to working on base mode objects. In Developer Studio, users will operate in Base Developer mode. This is for administrators or developers who need to work directly with the original vendor objects (though this is generally discouraged for customizations).
• Overlay Group set to (clear): This offers the most flexibility, providing no restrictions on access. Users can interact with base, overlay, or custom objects. This is often the default for general users or administrators who need a broad view.

Understanding overlay groups is critical for ensuring that your customizations are robust, maintainable, and survive application upgrades without conflicts.

Understanding Groups and Permissions

Access control in AR System is heavily reliant on groups. These groups define who can see and do what within the system. The structure and ranges of Group IDs provide a framework for organizing these permissions.

Group ID Ranges

The allocation of Group IDs follows a logical structure:

• 0-1000: Reserved for AR System’s internal groups and currently installed AR System applications.
• 1000-13004 and 13007-14999: Designated for regular and computed groups used by custom applications and extensions.
• 13005-13006: Specifically for CMDB (Configuration Management Database) related groups.
• 14999-59999: Reserved for future AR System applications and components.
• 60000-60999: Allocated for dynamic groups, which are determined by conditions rather than direct assignment.

Types of Groups

Groups can be broadly categorized:

• Explicit Groups: These are groups to which users are directly assigned. Access is granted based on the permissions assigned to that specific group. They are defined for a particular AR System server. Examples include groups like admin, sub-admin, customise, struct admin, and struct sub-admin.
• Implicit Groups: These groups are assigned to users dynamically based on certain conditions or circumstances, often related to the content of special fields. Users are not directly members of these groups; their membership is inferred. Dynamic groups also fall under this category. Examples include Arsystem, public assigne, assigne group, submitter, and assignee.

Group Categories & Ranges Summary

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

Implicit Group Assignments (Examples)

Certain group IDs have predefined meanings and are often implicit:

• public: 0 (Implicit) – Grants very basic access.
• Administrator: 1 (Explicit) – Full administrative rights.
• customize: 2 (Explicit) – Permissions to customize application objects.
• Submitter: 3 (Implicit) – Typically refers to the user who submitted a request.
• Assignee: 4 (Implicit) – Refers to the user assigned to a request.
• Sub Administrator: 5 (Explicit) – Lesser administrative privileges than Administrator.
• Assignee Group: 7 (Implicit) – Refers to the group assigned to a request.
• Struct Admin: 8 (Explicit) – Structural administration rights.
• Sub Struct Admin: 9 (Explicit) – Lesser structural administration privileges.

Data Storage and Representation

How AR System stores and represents data is fundamental to its operation. This includes dates, core fields, and even how attachments are handled.

Date/Time Storage

Dates and times are stored in a surprisingly efficient way: as the integer number of seconds since January 1, 1970, 00:00:00 GMT. This representation is effective for dates ranging up to January 18, 2038. This is a common Unix-based timestamp format.

Core Fields (Database IDs)

Certain fields are fundamental to every AR System form and are assigned specific database IDs:

• Request ID: 1 (The unique identifier for each record.)
• Submitter: 2 (The user who created the record.)
• Create Date: 3 (The timestamp when the record was created.)
• Assigned To: 4 (The user or group currently responsible for the record.)
• Last Modified By: 5 (The user who last modified the record.)
• Modified Date: 6 (The timestamp of the last modification.)
• Status: 7 (The current stage of the record in its lifecycle.)
• SD: 8 (Likely a placeholder or internal field, not typically user-facing.)
• Status History (Hidden): 15 (Tracks changes to the ‘Status’ field.)

Menus: Types and Refresh Modes

Menus in AR System provide dropdown selections and can be of various types:

• Types:
  • Static: Data is hardcoded or pulled from specific sources.
    • Character: Static values defined directly.
    • Form data dictionary: Populated from a form’s fields.
    • Field data dictionary: Populated from another field’s values.
  • Dynamic: Data is fetched at runtime.
    • Search: Allows users to search for values.
    • SQL: Fetches data directly from a database query.
  • File: Can be either static or dynamic, often used for lists of files.
• Deletion Complication: Deleting a field or form associated with a menu does not delete the menu itself. You’ll need to manually remove unused menus.
• Refresh Modes (for non-character menus):
  • On Connect: The menu is retrieved when the user first connects or selects the form after connecting.
  • On Open: The menu is retrieved every single time the user opens it. This can impact performance if the menu data is large or the query is complex.
  • On 15 Minute Interval: The menu is retrieved on open and then refreshed every 15 minutes. This offers a balance between up-to-date data and performance.
• Character menus are static and do not refresh.

View Related Complications

Views are a powerful concept in AR System, allowing for different representations of data:

• View Field: A field that is part of a view.
• View Form: A specific type of form that acts as a view of another form.
• Form View: The mechanism used to create a view of a form, often tailored for different user roles or purposes.

Form ID Types

Forms in AR System have different purposes, indicated by their Form ID type:

• Regular: 1 (Standard forms.)
• Display: 4 (Used for displaying data, often read-only.)
• Join: 2 (Combines data from multiple forms.)
• View: 3 (Provides a filtered or specific perspective on data.)
• Vendor: 5 (Used to interface with external data sources.)

Character vs. Diary Fields

A common point of confusion is the difference between Character and Diary fields:

• Character Fields: These are standard text fields where the content can be overwritten.
• Diary Fields: These fields are designed for logging or appending information. Each entry includes the date, user, and the data itself, ensuring that all historical information is maintained and appended, not overwritten.

Attachment Pool Management

Handling attachments is a key function. AR System uses a specific data type and associated tables:

• Data Type: attachment pool
• Attachment Field: A field with the data type attachment.
• Database Tables:
  • BSchema_id: Stores metadata about the attachment, such as file path, original size, and compressed size.
  • Battachpoolid: Stores the actual binary data of the attachment and its associated Request ID.

Troubleshooting Tip: If users are reporting issues with attachments (e.g., not uploading, not downloading), check the disk space on the AR System server and the database server, as well as the permissions on the attachment storage location.

Database Storage Location (Example)

While the exact path varies depending on your database system and configuration, a typical SQL Server data file location might look like this:

C:\Program Files (x86)\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

Server Names Storage

Information about the AR System servers you connect to is usually stored in the ARLogin file within your workspace directory.

Vendor Forms and Unique Identifiers

• Vendor Forms: These are special forms that enable AR System to access and manipulate data residing in external data sources, essentially making non-AR System data appear as if it’s within AR System.
• GUID (Global Unique Identifier): This is a 128-bit value used to uniquely identify a form across different AR System servers. This is crucial for managing customizations and ensuring that objects are correctly referenced when moving between development, test, and production environments.

The Backbone of Automation: Workflow Objects

The true power of AR System lies in its ability to automate business processes. This is achieved through various workflow objects:

TBH Tables: The Data Triad

When AR System stores data, it often uses three types of tables:

• T (Transaction Table): This is where the main data for your forms is stored.
• B (Binary Table): This table is used to store binary data, such as attachments, active links, and other objects that are not simple character or numeric data.
• H (History Table): This table stores historical data, most notably the status history of requests, providing an audit trail of changes.

Workflow Definition

Workflow is defined as the set of processes a company uses to run itself. AR System automates these processes through:

• Forms: The schema that represents your data, essentially the tables in the database.
• Active Links: These are client-side workflow objects, triggered by user interactions within the current form window. They can display messages, change field properties, push or fetch data, but cannot be triggered by an API call.
• Filters: These are server-side workflow objects that trigger based on data/record/transaction interactions. Common triggers include Submit, Modify, and Delete operations.
• Escalations: These workflow objects are triggered based on time intervals. They continuously check for requests in the database that meet specific criteria and then execute actions.

The interplay between these objects forms the foundation of your ITSM processes.

Granular Overlays: Mastering Customization

The introduction of granular overlays has revolutionized how customizations are managed in AR System, especially with the shift towards best practices.

• Granular Overlays: Allow customization of subcomponents of an object (like a field’s appearance or a filter’s conditions) with different overlay types, providing more precise control than full object overlays.
• Additive Overlay (Extensions Overlay): This type of overlay adds customized information or behavior to the original object. If the origin object is modified during an upgrade, these additions are typically appended, preserving your customization. This is the most common and recommended type for extensions.
• Overwrite Overlay: This overlay replaces the entire overlaid object with the customized version. The original object’s properties are ignored. This is used for scenarios where you need to fundamentally change an object, such as removing inherited permissions. Use with caution, as it can lead to significant deviations from vendor best practices.
• No Overlay (Inheritance Overlay): This is the default behavior when an object is not explicitly overlaid. It simply inherits all properties from the origin object without any changes. This is used when no specific modifications are needed for a particular object within a customization.

Installation Logs and System Files

When things go wrong, or you need to understand the history of your installation, log files and system configuration files are your best resources.

• ARS Installation Log Files Location: A typical location for installation logs on a Windows system might be:
  C:\Users\Administrator\AppData\Local\Temp\1\arsystem_install_log.txt. (This path can vary based on the installer and user.)
• Host File and Services with Port Number: These critical Windows system files are located at:
  C:\Windows\System32\drivers\etc.
  • The hosts file maps IP addresses to hostnames.
  • The services file maps service names to their port numbers, which AR System may reference for various communications.

Troubleshooting Tip: If you encounter errors during AR System installation or startup, scour the installation logs. They often contain the precise error messages and stack traces needed to diagnose the problem. Similarly, issues with network connectivity to specific services could point to problems in the hosts or services files.

Conclusion: The Indispensable Server Tier

The AR System Server Tier is far more than just a piece of software; it’s the operational heart of your ITSM solution. From orchestrating complex workflows to managing data interactions and facilitating integrations, its components work in concert to deliver the automation and efficiency that businesses rely on. A deep understanding of its architecture, configuration, and underlying mechanisms is not just beneficial – it’s essential for anyone involved in managing, developing, or supporting an AR System environment. By mastering the concepts discussed, you’ll be well-equipped to troubleshoot effectively, optimize performance, and confidently tackle any challenges that come your way.