Demystifying the Client Tier in BMC Remedy Action Request System

In the complex, multi-layered architecture of BMC Remedy Action Request System (ARS), understanding each tier is crucial for effective administration, development, and troubleshooting. Today, we’re diving deep into the Client Tier – the very first point of interaction for most users and the gateway to the powerful functionalities of AR System. Far from being just a simple user interface, the client tier encompasses a range of tools and applications that enable seamless interaction with the AR System.

Before we embark on this journey, a quick clarification: “Remedy” and “Action Request System” are, in essence, the same lineage. The product, originally developed by Remedy Corporation, is now known as BMC Remedy Action Request System after BMC Software acquired it. This history is important for context, but for our purposes, we’ll be referring to it as BMC Remedy AR System or simply AR System.

Understanding the AR System Architecture: A Layered Approach

To truly grasp the Client Tier, we need to see it within the broader context of the AR System architecture. This architecture is typically visualized in three or four distinct tiers, each with its own responsibilities:

• Client Tier: As mentioned, this is where the user experience begins. It houses all AR System clients, from the applications users interact with daily to the powerful development and migration tools.
• Mid Tier: This acts as the web-facing bridge, enabling users to access AR System applications through a web browser. It translates requests, handles web services, and processes server-side logic for web clients.
• Server Tier: The brain of the operation. This tier contains the AR System server itself, orchestrating workflow processes, managing access to data, and housing crucial server-side applications like the Approval Server and Email Engine.
• Data Tier: The persistent storage. This is where your databases reside, acting as the backbone for all AR System data.

Our focus, the Client Tier, is the entry point to this entire ecosystem. It’s where the magic of user interaction and system management truly begins.

The Diverse Roles of the Client Tier

The Client Tier isn’t a monolithic entity. It comprises various clients, each serving a specific purpose. At its core, its primary function is to present information to application users and capture their input. However, this definition expands significantly when we consider the tools used for building and maintaining the system:

• User Applications: These are the everyday interfaces that end-users interact with to submit requests, track incidents, manage assets, or perform any other business process automated by AR System. Think of the typical screens you see when logging into a service desk application.
• Developer Tools: For those who build and customize AR System, tools like BMC Remedy Developer Studio are essential clients. These tools allow for the creation and modification of forms, workflows, and other system components.
• Migration and Import Tools: Tools like BMC Remedy Data Import and BMC Remedy Migrator are also considered clients. They facilitate the movement of data and configurations between different AR System environments, a critical task for any administrator or implementer.
• Alerting Mechanisms: Clients like BMC Remedy Alert might be part of this tier, enabling proactive notifications and system monitoring.

Essentially, any application or tool that directly communicates with the AR System server from an end-user or administrator’s perspective resides within the Client Tier.

Key Components and Concepts within the Client Tier

To operate effectively within the AR System environment, understanding certain underlying concepts is vital. These often manifest within the Client Tier interactions:

Forms: The Building Blocks of AR System

Forms are the fundamental structures within AR System, analogous to tables in a relational database. They define the layout and structure of data presented to users. Within the Client Tier, users interact with these forms to view, enter, and modify information.

• Regular Forms: The most common type, used for standard data entry and display.
• View Forms: These are essentially shortcuts or specialized views of other forms, allowing for tailored presentation of information to different user groups.
• Vendor Forms: These are powerful tools that allow AR System to access and manipulate data from external data sources without needing to import it directly. This is achieved through BMC components, making them invaluable for integrating disparate systems.
• Advance Forms: The reference mentions “view form” and “vendor form” as examples of advanced forms. This typically implies forms with more complex configurations or integrations.

Form IDs provide a numerical identifier for different form types, helping the system internally manage them:

• Regular: 1
• Join: 2
• View: 3
• Display: 4
• Vendor: 5
• Custom form IDs can also exist (e.g., 12453).

Fields: The Data Holders

Fields are the individual elements within a form that hold specific pieces of data. Understanding the different field types is crucial for effective design and troubleshooting:

• Character Fields: These are versatile alphanumeric fields. They can hold text and can be attached to menus. However, they have a maximum size limit, and errors like ARERR [559] Character string exceeds maximum size allowed: field name can occur if this limit is breached.
• Diary Fields: Unlike character fields, diary fields are designed for audit trails and historical data. When data is entered or modified, it’s appended with a timestamp, the user’s name, and the data itself. This ensures that all historical entries are preserved, making them ideal for tracking changes over time. Web reports, however, do not support diary fields.
• Attachment Fields: These allow users to attach files to a record.
• Attachment Pool: A more advanced mechanism for managing attachments, often involving multiple tables for efficient storage and retrieval.

Troubleshooting: Character vs. Diary Field

A common question in interviews and a practical consideration for developers: what’s the key difference? Character fields are overwriteable; once you save new data, the old data is gone. Diary fields, on the other hand, append new entries, creating a historical log. This is critical for auditing and tracking changes. The database format for diary fields is typically `[modified timestamp in seconds -| User -| Data]`.

Workflows: The Automation Engine

Workflows are the heart of AR System’s automation capabilities. They define the processes and actions that the system performs based on specific triggers. Within the client tier, users might indirectly trigger workflows, while developers actively design them.

• Active Links: These execute based on client-side operations, such as user clicks, form opening, or field changes. They can perform actions like displaying messages, modifying fields, or even pushing data to other forms. Active links are performed on the client’s current form window and cannot be triggered via API.
• Filters: Filters are server-side workflows that trigger in response to data transactions like form submission, modification, or deletion. They are essential for enforcing business logic and data integrity.
• Escalations: These are time-based workflows. They periodically check for records that meet certain criteria and trigger actions, such as sending notifications or updating statuses.

Database Table Names for Workflows:

• Active Link: `dbo.actlink` (and `dbo.actlink_` with action name appended)
• Filter: `dbo.filter` (and `dbo.filter_` with action name appended)
• Escalation: `dbo.escalation`

Menus: Enhancing User Input

Menus provide predefined lists of options for users to select from, streamlining data entry and reducing errors. They can be attached to character fields and other data fields.

• Static Menus: Fixed lists of options, such as character menus or menus populated from a form’s data dictionary.
• Dynamic Menus: Menus that retrieve their options from external sources like searches, SQL queries, or files.

Refresh Modes for Menus:

To ensure menus are up-to-date, different refresh modes can be configured:

• On Connect: Menu is retrieved when the user opens it after selecting the form. Reopening the form is needed for updates.
• On Open: Menu is retrieved every time the user opens it. This can impact performance, so use judiciously.
• On 15 Minute Interval: A balance between currency and performance, retrieving the menu on opening and then every 15 minutes.

Note: Character menus are static and do not refresh. Menus are stored in tables like `dbo.field_enum` and `field_enum_value`.

Licensing and User Access

Understanding AR System licensing is crucial for managing user access and system performance, especially from the Client Tier perspective.

• Fixed Licenses: Dedicated licenses assigned to specific users.
• Floating Licenses: A pool of licenses that can be shared among users. When a user logs in, they consume a floating license. If no licenses are available, the user might gain read-only access. Floating licenses are often more costly and suitable for shift-based workforces.

License Question: If you have 5 fixed and 5 floating licenses, how many users can log in?
Answer: Unlimited users can log in, but they will have to wait for a license to become available if all are in use. This highlights the difference between login access and active license usage.

Troubleshooting: Read User Status

If a user attempts to log in and all available licenses (both fixed and floating) are in use, they might be granted “Read User” access. This grants read-only access to the system, allowing them to view data but not make changes. This is a critical point to understand when diagnosing user access issues.

Platform Configurations and Database Interactions

The choice of operating system and database for your AR System deployment significantly impacts performance, scalability, and administration. While the Client Tier doesn’t directly dictate these choices, the underlying platform influences the client’s responsiveness and overall user experience.

Popular Configurations (based on support calls):

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

Generally, larger enterprises opt for UNIX-based systems, while mid to smaller companies tend to prefer Windows and SQL Server. The principle is to align with your IT staff’s existing expertise for easier administration.

Database User and Tables

By default, AR System uses the ARAdmin database user to interact with the Arsystem database. Understanding the underlying database tables is crucial for deep-dive troubleshooting and performance tuning. For instance:

• Control Tables: The initial tables created during installation, such as control, controlRecordIds, arschema, schema_index, and schema_group_ids, form the core structure of the AR System.
• Workflow Tables: As mentioned, tables like dbo.actlink, dbo.filter, and dbo.escalation store the definitions of your automation.
• Attachment Tables: For attachments, tables like `BSchema_id` (holding file path, original size, compressed size) and `Battachpoolid` (linking request ID to binary data) are involved.
• Menu Tables: `dbo.char_menu` stores menu definitions.
• Core Fields Storage: Essential fields like Request ID, Submitter, Create Date, Assigned To, etc., are fundamental to every record.

Date/Time Storage:

A fascinating detail: AR System stores date/time values as the integer number of seconds since January 1, 1970 (the Unix epoch time). This format covers dates from 1970 to January 18, 2038, due to the limitations of a 32-bit integer. This is a common interview question!

Configuration Files and Ports

Key configuration details are managed in files and through specific port numbers:

• Configuration File: The ar.cfg file (on Windows) stores AR System server configuration settings. It’s dynamically created during installation. Crucially, passwords can be saved within this file, necessitating strict access control.
• Port Numbers: Various components communicate over specific ports. Knowing these is vital for network troubleshooting and firewall configuration:
  • DB2: 50,000
  • Oracle: 1521
  • SQL Server: 1433
  • Java Plugin Server: 9999
  • Flash/Board: 1150 (Note: 9998 mentioned in some docs for Flash Board, always verify with your version)
  • SMTP: 25
  • DIS Server Port: 2000

Advanced Concepts and Troubleshooting

As you delve deeper into AR System, understanding concepts like overlays and groups becomes essential for managing customizations and permissions.

Overlay Groups and Granular Overlays

Overlays are a mechanism for customizing out-of-the-box AR System objects without directly modifying them. This is critical for preserving customizations during upgrades and patches.

• Overlay Group Field:
  • Set to 1: Restricts users to working on overlay and custom mode objects in Developer Studio (Best Practice Customization mode).
  • Set to 0: Restricts users to working on base mode objects (Base Developer mode).
  • Clear/Blank: No restrictions; allows access to base, overlay, or custom objects.
• Granular Overlays: Introduced to provide finer control. This allows customization of sub-components of an object, further minimizing conflicts during upgrades. Types include:
  • Additive Overlay (Extensions Overlay): Adds custom information without overwriting the base.
  • Overwrite Overlay: Replaces the base object entirely.
  • No Overlay (Inheritance Overlay): Inherits properties from the base object.

Groups and Permissions

Groups are fundamental for managing access control in AR System. Permissions can be granted at the form and field levels.

• Types of Groups:
  • Explicit Groups: Users are manually assigned to these groups. Examples include ‘admin’, ‘sub-admin’, ‘customize’.
  • Implicit Groups: Users belong to these groups based on specific conditions or attributes within their requests. Examples include ‘public’, ‘assignee’, ‘submitter’.
• Group ID Ranges: AR System reserves specific ranges for different types of groups to ensure unique identification and management.
• 0-1000: AR System groups and current applications.
• 1000-13004 & 13007-14999: Regular and computed groups.
• 13005-13006: CMDB groups.
• 14999-59999: Future AR System applications.
• 60000-60999: Dynamic groups.
• Group Types for Menus/Permissions: View, Change, None.

Troubleshooting: Granting Permissions

If you need to grant common permission to a large number of forms, the efficient method is to search for the relevant group, right-click on it, select “Assign Permissions,” and then add the desired forms. You cannot directly give permissions to menus; they inherit permissions from the character field they are attached to.

Version Information and Timestamps

Version Information: The application properties form is your go-to place for finding detailed version information about your AR System installation.

Timestamps: The term “epochtime” refers to Unix time, the number of seconds elapsed since January 1, 1970. This is how AR System stores its date and time values.

Practical Examples and Interview Relevance

The Client Tier and its associated components are frequent topics in AR System interviews. Here are some practical examples and common questions:

• Question: How is time stored in AR Server?
  Answer: As the number of seconds since January 1, 1970 (Unix epoch time).
• Question: Difference between Character and Diary field?
  Answer: Character fields can be overwritten; Diary fields append data with timestamps and user details, maintaining a history.
• Question: How to give a prefix to the Request ID field and restrict its length?
  Answer: In the Request ID field’s properties, set a default value (e.g., “ABC”) for the prefix and configure the “Input Length” under the Database tab to restrict its overall length.
• Question: How to see the 9th field “Status History”?
  Answer: In Remedy User, open a form in modify mode, go to the “View” menu, and select “Status History.” A shortcut is to press Control*H.
• Question: A user should be able to log into Developer Studio other than “Demo”.
  Answer: Add the user to the struct sub-admin group.
• Question: What are the database tables for Attachments?
  Answer: Tables like `BSchema_id` (for file paths and sizes) and `Battachpoolid` (linking request IDs to binary data).
• Question: When a form is deleted, is the active link also deleted?
  Answer: Yes, but only if the active link is associated with all forms that are being deleted.

Troubleshooting and Best Practices for the Client Tier

Issues within the Client Tier often manifest as slow performance, unresponsive applications, or unexpected behavior.

• Performance: If clients are slow, investigate network connectivity, the load on the Mid Tier server (if applicable), and the complexity of the workflows being triggered. For client-side issues, browser cache and local system resources can also play a role.
• Active Link Behavior: Ensure active links are correctly configured and not conflicting with each other. Test them in Developer Studio to pinpoint issues. Remember, active links run on the client, so client-side debugging tools can be helpful.
• Form Loading Issues: If forms are taking too long to load or not displaying correctly, check form definitions, associated workflows, and any data retrieval mechanisms (like vendor forms or complex queries).
• Attachment Uploads/Downloads: Verify the configuration of attachment fields, their maximum size limits, and the underlying database capacity.
• Logging: For intricate client-side issues, enabling AR System client logging can provide invaluable insights into the sequence of events and potential errors.

In conclusion, the Client Tier of BMC Remedy Action Request System is far more than just a user interface. It’s a dynamic environment that includes user applications, development tools, and critical system utilities. A solid understanding of its components, how they interact, and the underlying concepts like workflows, permissions, and data storage, is essential for anyone working with AR System. By mastering this tier, you gain a powerful advantage in developing, managing, and troubleshooting your AR System applications.