Demystifying Regular Forms in BMC Remedy AR System: The Backbone of Your Data Management

In the intricate world of IT Service Management (ITSM) and enterprise application development, data organization is paramount. BMC Remedy AR System, a robust platform for building and managing business applications, relies heavily on a well-defined structure for its data. At the heart of this structure lie Regular Forms. While seemingly straightforward, understanding their nuances, their place within the broader AR System architecture, and how they interact with other form types is crucial for any administrator, developer, or consultant working with the platform. This article aims to demystify these foundational elements, providing practical insights, real-world examples, and considerations for troubleshooting and interview success.

Understanding Form Types in BMC Remedy AR System

Before diving deep into Regular Forms, it’s beneficial to understand the landscape of form types available in BMC Remedy AR System. These different types serve distinct purposes, enabling flexibility and powerful data integration capabilities. The Form ID, a simple numerical identifier, is often used internally by the system to differentiate these types.

The Core Form Types and Their IDs

BMC Remedy AR System categorizes forms into several key types, each with specific functionalities:

• Regular Form (ID: 1): This is your foundational, everyday form. It’s where you define fields, create UI elements, and store your primary business data. Think of it as the basic building block for most applications.
• View Form (ID: 3): A View Form doesn’t store data itself. Instead, it acts as a dynamic presentation layer, pulling data from one or more other forms (typically Regular Forms or Join Forms). It’s excellent for creating tailored user interfaces or reports without duplicating data.
• Join Form (ID: 2): As the name suggests, a Join Form is used to combine data from two or more existing forms. This is a powerful way to present related information from different sources in a single view, avoiding the need for complex manual data aggregation.
• Vendor Form (ID: 5): This specialized form type allows BMC Remedy AR System to interact with external data sources that are not directly managed by AR System itself. This is achieved through the use of a Vendor form and a corresponding Vendor Tool.
• Archive Form: Typically used for historical data. When records in a primary form reach a certain age or meet specific criteria, they can be moved to an Archive form, helping to keep the primary form lean and performant.
• Audit Form: Designed to track changes made to data within other forms. Audit forms log modifications, deletions, and sometimes even creations of records, providing a valuable history for compliance and debugging.

It’s worth noting that a Join Form can be created by joining various other form types, including Regular, View, Vendor, Archive, and Audit forms. This highlights the interconnected nature of AR System data structures.

The Humble Yet Mighty Regular Form

The Regular Form is the workhorse of BMC Remedy AR System. When you initiate the creation of a new form in the Developer Studio, you’re most likely creating a Regular Form unless you have a specific need for another type from the outset.

Key Characteristics of a Regular Form:

• Data Storage: A Regular Form directly stores the data defined by its fields within the AR System database.
• Field Definitions: This is where you define all the fields that will hold your data – text fields, integer fields, date fields, choice lists, etc.
• UI Design: You design the user interface (UI) for the form, arranging fields, adding labels, and creating the visual layout that users will interact with.
• Workflow Association: Business logic, such as Active Links, Filters, and Escalations, is typically built and associated with Regular Forms to automate processes and enforce business rules.
• Permissions and Access Control: You define who can view, modify, or create records within a Regular Form, ensuring data security.

Real-World Analogy: Think of a Regular Form like a well-organized spreadsheet or a dedicated database table. It has columns (fields) and rows (records), and it’s the primary place where your information lives.

When to Choose a Regular Form

The decision to use a Regular Form is usually the default choice when:

• You need to store specific business data that doesn’t inherently exist in another system.
• You are building a new application module from scratch.
• You require a dedicated repository for a particular type of information (e.g., Incidents, Changes, Problems, Users).
• You need to apply complex business logic (workflows) directly to the data.

For instance, if you’re building a new ticketing system, you’d likely create a “Tickets” Regular Form. This form would contain fields like “Ticket ID,” “Subject,” “Description,” “Status,” “Assigned To,” and “Date Created.”

Understanding Form Types in Server Information

The Form Type of Server Information plays a crucial role in how AR System manages data and interacts with external sources. When you configure the Server Information, you define how the system should interpret and handle data for a particular form. For example, a Vendor Form has its type set to “Vendor” in the Server Information, especially when it extracts data from a text file. This tells AR System to use specific mechanisms to retrieve and present this external data as if it were native to the system.

For Regular Forms, the “Form Type” in Server Information would typically be set to “Regular,” indicating that it’s a standard AR System form for data storage and retrieval.

Join Forms: Unifying Data from Multiple Sources

Join Forms are a powerful feature for consolidating information. They allow you to present data from multiple forms in a single interface without duplicating the source data. This is achieved by defining relationships between fields in the participating forms.

Key Aspects of Join Forms:

• Creating Joins: You can create join forms by linking various existing form types, including Regular, View, Vendor, Archive, and Audit forms.
• Join Criteria: The criteria that define how records from different forms are linked are crucial. It’s important to note that there was a known issue in AR System 8.1 where the join criteria could not be changed once defined, which was considered a bug in the development. While this might have been addressed in later versions, it underscores the importance of carefully planning your join criteria upfront.
• Performance Considerations: While powerful, poorly designed Join Forms can impact performance. Ensure your join criteria are efficient and that you’re not joining an excessive number of forms or using inefficient join methods.

Example: Imagine you have a “Users” Regular Form and an “Asset Inventory” Regular Form. You could create a Join Form to show which user is assigned which asset. The join might link the “User ID” field in the “Users” form to the “Assigned To” field in the “Asset Inventory” form.

Vendor Forms: Bridging the Gap to External Data

Vendor Forms are essential when you need to integrate AR System with data residing outside its direct database. This allows your AR System applications to access and display information from other systems, such as legacy databases, flat files, or even web services.

How Vendor Forms Work:

• External Data Sources: Vendor Forms enable BMC Remedy AR System to access arbitrary external data sources.
• Vendor Tool: This integration is facilitated by a specialized tool provided by BMC that acts as an intermediary between AR System and the external data source.
• Form Type in Server Information: As mentioned, the Form Type of Server Information for a Vendor Form is explicitly set to “Vendor.” This is particularly evident when the data is being extracted from sources like text files, where the Vendor Tool plays a critical role in parsing and presenting the data.

Example: Suppose you have a separate system that manages employee HR data, and you want to display employee details within an AR System application (e.g., for a support request). You could create a Vendor Form that points to this HR system, allowing AR System to query and display employee information without needing to import it directly into the AR System database.

Help Text and User Experience

The Help Text associated with fields on a form is a vital component of user experience and system usability. It provides contextual guidance to users interacting with the application.

Understanding Help Text Behavior:

The way help text is displayed can vary depending on the user’s login credentials:

• Login by Demo User: When logged in as the ‘Demo’ user (or potentially other privileged users depending on configuration), the help text will display more detailed information. This typically includes the Field Name (label Name), the Field ID, and the actual Help Text value. This is invaluable for developers and administrators testing or troubleshooting forms.
• Login by Other Users (Registered Users): For standard users, the help text will show just the Help Text Value. This provides a cleaner, less technical interface.
• No Help Text Value: If a field has no specific help text value defined, the system will fall back to displaying its field description. This description might include technical details like the field’s symbol, keyword, or length, offering some level of guidance even without explicit help text.

Practical Implication: Designing effective help text is crucial. For end-users, it should be clear, concise, and directly address how to use the field. For developers, the detailed output for Demo users can be a lifesaver for quick field identification and understanding.

Granular Overlays: Modernizing Customization

As BMC Remedy AR System evolves, so do the methods for customizing out-of-the-box objects. Granular Overlays represent a significant advancement in how customizations are managed, particularly in reducing conflicts during upgrades and patches.

What are Granular Overlays?

Granular Overlays allow you to choose specific subcomponents of an object (like a form, a field, or a workflow) and apply different overlay types to them. This means you don’t have to override the entire object just to make a minor change. You can inherit other aspects from the original (origin) object, minimizing the amount of reconciliation needed after system updates.

The Three Types of Granular Overlays:

1. Additive Overlay (Extensions Overlay)

   This is used when you want to add custom information or functionality to an existing object without altering its original definition. If the origin object is updated during an upgrade, your additions are appended to the new definition. This is the safest approach for adding new elements like custom fields or additional workflow logic that shouldn’t interfere with core functionality.

   Example: Adding a custom field to an out-of-the-box “Incident” form to track a specific departmental requirement. The original “Incident” form remains untouched, and your custom field is added as an extension.

2. Overwrite Overlay

   In this type, the entire overlaid object is used, and the origin object’s definition is ignored. This behavior is similar to how non-granular overlays worked in earlier versions. It’s appropriate when you need to completely replace or remove aspects of the origin object. This is a more aggressive approach and requires careful consideration.

   Example: Removing specific permissions from an out-of-the-box form if the default permissions are too broad for your specific implementation. You are overwriting the original permission settings.

3. No Overlay (Inheritance Overlay)

   While its name might suggest no customization, this is technically still an overlay. It’s the default for most object components. If you don’t make any changes to an out-of-the-box object or its parts, they will inherit their properties directly from the origin object during an upgrade. This is used for object properties that should remain unchanged and simply follow the origin object’s definition.

   Example: Leaving an out-of-the-box field with its default label, type, and behavior. It will inherit these properties as is, and if the origin object’s label changes in a patch, your “No Overlay” component will also pick up the new label.

Granular Overlays are a modern approach to customization in AR System, promoting maintainability and reducing upgrade headaches. When working with forms, especially those based on BMC’s ITSM applications, understanding overlays is as important as understanding the forms themselves.

Form Deletion and Workflow Associations

A common administrative question revolves around the deletion of forms and their associated workflows, particularly Active Links.

When a Form is Deleted:

If you delete a form that has Active Links associated with it, those Active Links will also be deleted. However, this deletion only occurs if you delete all forms that are associated with that specific Active Link. This is a safeguard to prevent orphaned workflow components that might cause errors.

Implication: Before deleting a form, it’s prudent to review its associated workflows (Active Links, Filters, Escalations) to understand the impact. You might need to disassociate or reconfigure these workflows before proceeding with form deletion.

Interview Relevance: Mastering Form Concepts

For anyone aspiring to work with BMC Remedy AR System, a solid understanding of forms is fundamental. Interviewers will often probe your knowledge of form types, their characteristics, and how they are used in practice.

Key Concepts to Master for Interviews:

• Clearly define the purpose of a Regular Form, View Form, Join Form, and Vendor Form.
• Explain how a Join Form combines data and the importance of join criteria.
• Describe the role of a Vendor Form in integrating with external data sources.
• Discuss the benefits and types of Granular Overlays and how they differ from traditional overlays.
• Explain the behavior of Help Text for different user roles.
• Be prepared to discuss scenarios where each form type would be the appropriate choice.
• Understand the relationship between forms and workflows (Active Links, Filters) and how deletion impacts them.

Conclusion

Regular Forms are the bedrock of data management within BMC Remedy AR System. While other form types like View, Join, and Vendor forms offer specialized functionalities, understanding the core principles of Regular Forms is essential for building robust and efficient applications. Coupled with a grasp of modern customization techniques like Granular Overlays and a keen eye for user experience through features like Help Text, administrators and developers can leverage the full power of the AR System platform. By mastering these concepts, you not only enhance your technical proficiency but also position yourself for success in the competitive field of ITSM and application development.