Integer Fields in BMC Remedy AR System: Unpacking Their Significance

In the intricate world of BMC Remedy AR System (now often part of BMC Helix ITSM), understanding the foundational elements is crucial for effective administration, development, and troubleshooting. Among these, integer fields play a surprisingly vital role, underpinning everything from unique identifiers to critical system configurations. While they might seem simple, their application within AR System is nuanced and deeply integrated into the platform’s architecture. This article aims to demystify integer fields, exploring their various uses, associated concepts, and practical implications.

Integer fields are the backbone of network communication within the AR System ecosystem. They are used to define the specific ports through which various components communicate. Understanding these ports is essential for network administrators and anyone involved in system setup and troubleshooting.

These integer values are critical for establishing connections between the AR System server, databases, and other integrated services. Misconfiguration of these ports can lead to communication failures, preventing the system from functioning as expected.

While not directly an integer field itself, accessing version information often involves navigating to a form where such details are stored. The Application Properties form is a key location where you can find comprehensive information about your AR System installation, including versions of various components.

Overlay groups are a fundamental concept in AR System’s customization model, allowing for granular control over who can modify which parts of the system. Integer fields are used to define the behavior of these overlay groups.

Overlay Group Field Settings

• Overlay Group field set to 1: Users assigned to a group with this setting are restricted to working on overlay and custom mode objects. In BMC Remedy Developer Studio, they can only operate in Best Practice Customization mode. This ensures that users with this setting primarily contribute to extending the system rather than altering its core functionality.
• Overlay Group field set to 0: Users assigned to a group with this setting are restricted to working on base mode objects. In Developer Studio, they can only operate in Base Developer mode. This is typically reserved for users who need to maintain or understand the original system components without making modifications.
• Overlay Group field set to (clear) or empty: When this field is not set, the group imposes no restrictions on accessing base, overlay, or custom objects. This provides the broadest access, usually for administrators who need a complete view and control over all system objects.

Note: For in-depth understanding, refer to the BMC Remedy AR System Developing an application and BMC Remedy AR System Administering documentation. These resources provide detailed insights into the mechanics of overlays.

Every group within AR System is assigned a unique integer identifier, known as the Group ID. These IDs are not arbitrary; they are organized into specific ranges, each signifying a different type or purpose of the group.

Group ID Ranges and Meanings

• 0-1000: Reserved for AR System groups and current AR System applications.
• 1000-13004 and 13007-14999: Designated for regular and computed groups.
• 13005-13006: Specifically for CMDB (Configuration Management Database) groups.
• 14999-59999: Reserved for future AR System applications, providing room for expansion.
• 60000-60999: Allocated for dynamic groups.

These integer IDs are fundamental for AR System’s security and access control mechanisms, ensuring that permissions are correctly applied to the appropriate user groups.

AR System categorizes groups into two primary types, each with distinct management approaches:

1. Explicit Groups

These are groups to which users are manually assigned via the User form. Membership in an explicit group grants users access to all objects and fields that the group has permissions for. A key characteristic is that explicit groups are typically defined for a particular server. This means that if you move objects to a new server with its own explicit groups, you might encounter permission conflicts. For cross-server portability, consider using deployable applications that leverage role permissions mappable to different groups.

Examples: admin, sub-admin, customise, struct admin, struct sub-admin.

2. Implicit Groups

Implicit groups are those where user membership is determined by specific conditions or circumstances, rather than direct assignment. Users automatically belong to these groups based on criteria like the content of special fields within a request. Dynamic groups you create also fall under the implicit category.

Examples: ARSystem, public, assignee, submitter, assignee group.

Expanding on Group IDs, AR System further categorizes groups, associating them with specific ID ranges and their implicit/explicit nature:

• Regular Groups: Range 1000 - 14999. These are typically Explicit groups.
• Computed Groups: Range 1000 - 14999. Also typically Explicit.
• Dynamic Groups: Range 60000 - 60999 (e.g., 60001, 60002, 60003). These are Implicit groups.

Implicit Group Examples and Types

Here’s a more detailed breakdown of common implicit and explicit groups:

• public (0) – Implicit
• Administrator (1) – Explicit
• customize (2) – Explicit
• Submitter (3) – Implicit
• Assignee (4) – Implicit
• Sub Administrator (5) – Explicit
• Assignee Group (7) – Implicit
• Struct Admin (8) – Explicit
• Sub Struct Admin (9) – Explicit

Understanding the distinction between explicit and implicit groups is vital for designing robust security models and managing user access effectively.

Every record (request) in AR System is built upon a set of fundamental fields, many of which are internally represented as integers or rely heavily on integer-based logic. These “9 Core fields” are essential for tracking and managing requests.

The 9 Core Fields:

1. Request ID (1): A unique integer identifier for each request.
2. Submitter (2): Typically stored as a string, but its associated user information is often managed via integer IDs internally.
3. Create Date (3): Stores date/time information.
4. Assigned To (4): Similar to Submitter, string representation but managed with internal IDs.
5. Last Modified By (5): Again, string representation tied to internal IDs.
6. Modified Date (6): Stores date/time information.
7. Status (7): Often a character field, but its underlying values and transitions are frequently managed using integer codes.
8. SD (8): (Short Description) – Typically a string.
9. Status History (Hidden) (15): This field, though often not directly visible, stores a history of status changes.

AR System’s method for storing date and time values is a classic example of using integers to represent complex data. It adheres to the standard Unix time representation.

How AR System Stores Dates:

• AR System stores date/time values as the integer number of seconds that have elapsed since the epoch: 00:00:00 GMT on January 1, 1970.
• This format is capable of storing dates from January 1, 1970, through January 18, 2038.

This “epoch time” or “Unix time” allows for precise chronological tracking and enables efficient date-based comparisons and calculations within the system.

Menus in AR System provide users with selectable options. They can be defined in various ways, and their underlying structure often relies on integer identifiers.

Types of Menus:

1. Static Menus:
   • Character: Defined directly within the field properties.
   • Form data dictionary: Lists fields from a specific form.
   • Field data dictionary: Lists fields from a specific form.
2. Dynamic Menus:
   • Search: Dynamically populated based on search criteria.
   • SQL: Populated by executing an SQL query.

Note: A File menu can be of both static and dynamic types.

Menu Behavior and Deletion

Question: If you delete a menu-associated field or form, will the menu also be deleted?

Answer: No, it will not delete the menu definition. The menu definition persists in the database (e.g., in tables like dbo.char_menu). However, the menu will no longer be accessible or usable from the deleted field or form.

Refresh Rate in Menus

For all menu types except character menus (which are static), a refresh mode must be set to control how frequently the menu’s contents are updated.

• On Connect: Retrieves the menu when the user opens the menu after selecting the form. To see updates, the user must reopen the form.
• On Open: Retrieves the menu each time the user opens it. This can impact performance if used frequently.
• On 15 Minute Interval: Retrieves the menu upon first opening and then every 15 minutes. This balances currency with performance. For browsers, this behaves like ‘On Open’.

Note: Refresh modes affect only the menu’s content, not its definition. Menu definitions are updated upon reconnection.

Views in AR System offer a way to present data differently to various user groups. Integer fields are often involved in managing these view definitions.

• View Field: A field that displays data from a view.
• View Form: A specific type of form that is defined as a view.
• Form View: The ability to create a specific “view” of a form tailored for different users or user groups.

Each form in AR System has a type, and these types are often represented by integer identifiers. This is crucial for the system to understand how to process and manage different forms.

Form Types and their IDs:

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

A value like 12453 might represent a specific form instance or a combination of properties, depending on the context.

Attachment fields and attachment pools are used to store binary data like files. While the data itself is binary, the management and metadata associated with these attachments often involve integers.

• Attachment Pool Data Type: Attachment Pool
• Attachment Field Data Type: Attachment
• Property Field (Max Size): Often has a default value of 0, implying no specific size restriction set at the property level, but other system or database constraints may apply.

Database Tables for Attachments:

Two primary tables are involved:

1. BSchema_id: This table links schemas (forms) to their binary data. Every attachment creates entries here. It typically has three columns related to the transaction:
   • C: Depicts the path of the file.
   • O: Depicts the Original size of the file (in bytes).
   • C: Depicts the Compressed size of the file (in bytes).
2. Battachpoolid: This table stores the actual binary data and its associated Request ID.

Troubleshooting: If attachments are not saving or displaying correctly, check permissions on these database tables and the server’s attachment directory. Ensure the database user has the necessary write privileges.

Character and Diary fields both store text, but they differ significantly in how they handle data modification, a distinction managed through underlying data handling mechanisms often influenced by integer flags.

Key Differences:

• Character Fields: Can be overwritten. When new data is entered, it replaces the existing content.
• Diary Fields: Appended. Each new entry is added to the end of the existing data, usually prefixed with the date, time, and user who made the change. This preserves a complete history of entries.

Web Reports Limitation: It’s important to note that web reports typically do not support diary fields, attachment fields, or attachment pools. They do, however, support currency fields.

AR System maps its forms and data to relational database tables. Understanding this mapping is key for advanced troubleshooting and integration.

Key Database Tables:

• T (Transaction Table): Stores the main data for requests.
• B (Binary Table): Stores attachments, active links, and other binary objects.
• H (History Table): Stores status history for requests.

When a form is saved, AR System creates these tables in the underlying database. For example, a form might be represented by tables like dbo.char, dbo.char_menu, etc., where the prefix often relates to the form’s type or content.

Database Location Example:

This path is an example for a SQL Server instance; the exact location will vary based on the database system and installation path.

Server Names Storage:

Server names are typically stored within the workspace in a file called ARLogin.

Granting users access to develop within AR System requires specific permissions. Integer-based Group IDs play a role here.

Enabling Developer Studio Access:

Scenario: A user needs to log into Developer Studio besides the “Demo” user.

Solution: Add the user to the Struct Sub-Admin group. This group is typically assigned sufficient privileges for development tasks.

Vendor forms are a specialized type of form in AR System that allows the system to access and interact with arbitrary external data sources. They are essentially interfaces to data that resides outside the AR System’s direct database.

A GUID is an integer-based identifier used to uniquely identify a form across different servers. This is crucial for deployments and integrations.

Implementing GUID:

• To assign a GUID to a form, you can use a character field.
• Modify its properties and set the Database ID to 179. This internally designates the field as a GUID field for that form.

AR System provides robust tracking of status changes for requests. This history is stored in a way that allows for auditing and analysis.

Scenario: Tracking Status Changes

When you update a ticket and change its status, the system reflects these changes in the database. For example, changes might be reflected in specific rows associated with the ticket’s status history, often using a pattern like [T0 U0, T1 U1, ... T4 U4], where T represents a transaction and U represents a user/update instance.

Diary Field Value in Database:

After modifying a diary field, its value in the database follows a specific format:

[modified timestamp in seconds -| User -| Data]

If modified again, data is appended to this format, preserving the historical record.

Tree tables, a UI element for displaying hierarchical data, have a property called “Refresh on entry change.”

Scenario: Tree Table Refresh

By setting “Refresh on entry change” to true for a tree table, the table will automatically update its display whenever an entry within it is changed.

Permissions in AR System are granular, allowing control over who can access what. This is managed through groups.

Scenario: Specific Group Permissions

Requirement: Form permission set to vyomgroup & wiproGroup; Field permission set to personal group for both.

This indicates a scenario where access to the form is restricted to members of vyomgroup and wiproGroup, while specific fields within that form are further restricted to members of a “personal group,” demonstrating layered security.

Question: How to give permission to a menu?

Answer: You cannot directly give permission to menus. However, the permissions of the character field to which a menu is attached will be applied to that menu. If a user doesn’t have permission to the field, they won’t be able to interact with the menu attached to it.

When you add two entries to an attachment pool, you would expect to see corresponding entries in the relevant database tables (like Battachpoolid), linking each attachment to its request and storing its binary data.

As mentioned earlier, after saving a form, AR System creates three core types of tables in the database:

• T (Transaction): Holds the primary data of the requests.
• B (Binary): Stores attachments, active links, and other binary objects.
• H (History): Records the status history of requests.

Menus, especially character menus, are stored in database tables such as dbo.char_menu. This table might contain columns like Menu form name, Resolved name, Menuid, timestamp, owner, last changed, refresh, and menutype.

Managing permissions across many forms can be streamlined.

Scenario: Granting Common Permissions

To grant common permissions to 100 forms:

1. Search for the group to which you want to assign permissions.
2. Right-click on the group name.
3. Select “Assign permissions.”
4. Add the desired forms to the group’s permissions.

This approach leverages group-based permissions for efficiency.

Menus in AR System have a hierarchical structure with defined limits for levels and children.

• Levels: Menus (character and file) can have up to 15 levels.
• Children: Each menu item can have up to 99 child menus.

Understanding the installation and core components of AR System is fundamental.

Key Information for ARS 8.1:

• Help Menu: Always the first place to visit for comprehensive information.
• Web Server: A program or computer serving HTTP requests, typically delivering web pages (HTML, objects).
• Supported OS: Windows, Linux.
• Supported Web Servers: Tomcat, Jboss, Servlet:Exec, Other. IIS is supported but not recommended by BMC. A servlet engine is required for Mid Tier.
• Supported Databases & Ports:
  • IBM DB2: 50000
  • Oracle: 1521
  • Microsoft SQL: 1433
• Java Plugin Server TCP Port: 9999
• Flash Board Port: 9998 (Note: Confirm this value as it can vary or be misremembered.)
• SMTP Port: 25

Viewing Status History (Field 9):

To view the 9th field, “Status History”:

1. From Remedy User, modify the Status field.
2. Click on the View menu.
3. Click on Status History.

Shortcut: Open the form in modify state in the User tool and press Ctrl+H.

Prefixing Request ID and Restricting Length:

• Prefix: Click on the Request ID field, open its properties, and set the Default Value (e.g., ABC).
• Restricting Length: Open the Request ID field properties, go to the Database tab, and set the Input Length.

Application Components of AR System:

• Form
• Menu
• Workflow (Active Links, Filters, Escalations)

Clients of AR System:

• User Clients: BMC Remedy User, BMC Remedy Alert, Browsers.
• Developer Clients: BMC Remedy Developer Studio, BMC Remedy Data Import, BMC Remedy Migrator.

First Table After ARS Installation:

The first table created in the database after installation is typically dbo.control.

How Time is Stored in AR Server:

As discussed, time is stored as the integer number of seconds from January 1, 1970, accounting for leap years.

Menu Levels and Children (Revisited):

15 Levels and 99 children for character and file menus.

Archive Forms and Auditing:

• You cannot take an archive of an archive form.
• An archive form is created immediately, but data archiving occurs over time.
• Auditing of audit forms is not allowed.
• You can audit archive forms.
• Archive of an archive form is not possible.
• Audit form’s archive can be archived.

Submitter Field Type:

The Submitter field can only be changed if its type is Fixed. Other types, like dynamic or calculated, do not allow changes to the submitter.

Menu Storage Table:

Menus are stored in tables like dbo.field_enum and field_enum_value, often referencing an internal ID.

ARS Client Count:

AR System supports a large number of clients, estimated to be more than 5000. This includes various types like Mid Tier (e.g., 9 clients) and User Tool (e.g., 3 clients) as examples, though the actual numbers can be higher and depend on licensing and configuration.

Modifying Action Limits:

To change a hardcoded limit, such as for “50 actions,” you might need to modify a header file like C:\Program Files\BMC Software\ARSystem\Arserver\api\include\ar.h and recompile if necessary. This is an advanced task usually handled by BMC support or experienced developers.

Form Type for Server Information:

The server information form is often a Vendor form because it extracts data from text files or external sources. This is a common pattern for system-level information that isn’t directly stored in AR System’s transactional tables.

Join Form Limits:

BMC recommends joining up to 6 forms in a Join Form for optimal performance. While more can be joined, it can lead to performance degradation. Pushing data might involve joining 10 forms at a time, but this is often a compromise.

Join Form Limitations (AR System 8.1):

In AR System 8.1, the join criteria of a Join Form could not be changed once defined, which was considered a bug. Join forms can be created from various other form types, including Join, View, Vendor, Regular, Archive, and Audit forms.

Workflow in AR System refers to the automated processes that run the system, triggered by components like Active Links, Filters, and Escalations. Integer fields are implicitly involved in the execution logic and condition checking.

Workflow Components:

• Forms (Schema): Represent data structures, mapping to tables in the database.
• Active Links: Triggered by user interactions on the client side (e.g., displaying messages, changing field appearances, pushing data between forms).
• Filters: Triggered by data/record interactions on the server side (e.g., submit, modify, delete operations).
• Escalations: Similar to filters but execute based on predefined time intervals.

Permission Groups and Roles are AR System objects used to control access to forms, rows, and columns. These systems rely heavily on underlying integer IDs for groups and permissions.

Active Links are powerful tools for client-side automation. They execute actions based on user operations or information displayed on the current screen.

Active Link Rules:

• Cannot be triggered via API programs.
• Execute on the client side, within the current form window.
• If an active link with the same name already exists, AR System will automatically append _c to the new name.
• At least one Add action is necessary for an active link to be functional.
• When saving a form “as new,” active links associated with the original form are not copied. However, renaming the form can sometimes lead to associated active links being retained or modified.

Granular overlays represent a sophisticated approach to customization, allowing you to modify specific subcomponents of an object rather than the entire object. This significantly simplifies reconciliation during upgrades or patches.

Types of Granular Overlays:

1. Additive Overlay (Extensions Overlay): Used to add custom information to an existing object. If the origin object changes during an upgrade, these additions are appended.
2. Overwrite Overlay: The entire overlaid object is used, and the origin object is ignored. This is similar to non-granular overlays in older versions. Use this when you need to completely replace or remove aspects of the original object, such as removing permissions.
3. No Overlay (Inheritance Overlay): This is the default. If an object or its part is not modified, it inherits properties from the origin object. This is used for properties that should remain unchanged and follow the origin definition.

For more on this, refer to BMC’s official documentation.

Locating AR System installation logs is crucial for troubleshooting installation issues.

Log File Location Example:

The exact path can vary based on the operating system and user profile.

The hosts file and services file are fundamental to network name resolution and port mapping.

Location Example:

These files map IP addresses to hostnames and service names to port numbers, respectively. They are essential for AR System to communicate correctly with other services and databases.

Help text provides contextual information to users about fields.

• Login by Demo user: Shows the Field Name (label), Field ID, and Help Text value.
• Login by Other Registered User: Shows only the Help Text value. If no help text is defined, it displays the field description (symbol, keyword, length).

While integer fields are fundamental, issues can arise:

Understanding integer fields, Group IDs, port numbers, and the underlying mechanisms of AR System is frequently tested in interviews for AR System administrators and developers. Be prepared to discuss:

• The purpose of different Group ID ranges.
• How date/time is stored.
• The distinction between explicit and implicit groups.
• The role of ports in system communication.
• The concept of overlay groups and their impact on customization.
• The differences between Character and Diary fields.

Integer fields, though seemingly simple data types, are the silent workhorses of BMC Remedy AR System. They are instrumental in defining network communication, managing user access through group memberships, structuring data, and controlling system behavior. A thorough understanding of their various applications, from port numbers to Group IDs and date/time storage, is not just beneficial but essential for anyone working with the platform. By grasping these fundamental concepts, you can better administer, develop, and troubleshoot your AR System environments, ensuring efficient and secure operations.

Further Reading:

• BMC Remedy AR System Documentation
• BMC Helix ITSM Documentation