Customization designs

You can use different design approaches to extend the code in the on-premises and BMC Helix ITSM environments. Before you consider making customizations, we recommend that you make maximum use of the configuration capabilities that BMC Helix ITSM applications provide. This section familiarizes you with the information that you need to consider when you are designing customizations.

Extensibility

Design your applications in a way so that you can extend them to include new functionality. This way of designing applications helps in implementing functionality on a modular level and with extension hooks. If one module is enhanced, others can leverage the new extensions with minimal effort. Use the extension hooks to add functionality without breaking the implementation.

Define the areas where you can make most of your customizations. Create a filter guide, or active link guide, where you can put your own customized workflow that automatically starts in the context of a particular action. Creating such guides defines a known interface where you can make changes, and provides an interface for adding new functionality in future releases. For more information about guides, see Business logic object designs.

Data driven application design helps in the areas where changing data lets a function perform in multiple different ways; for example, the automatic assignment. Automatic assignment functionality can run with different load-balancing methods.

Extensibility assessment

When assessing extensibility, we recommend that you consider the following questions:

• Will a function be extended to perform new tasks in future releases?
• Can you configure this function to perform in multiple different ways with the data, rather than having to change the workflow?
• How many temporary or display-only fields does this function require?
• Is this functionality implemented the same way on the client and the server?

Code reuse

You can build a set of workflow operations by using Action Request System once and then reuse the workflow across multiple forms. You build your workflow so that it can be shared by multiple modules and applications. To accomplish this flexibility, the workflow must use field IDs that are unique across all forms.

For calling a workflow at different times, encapsulate it in a filter or active link guide so that the base code can be shared and specific code can be used to call the workflow, which makes the workflow more function-oriented. Building code in this manner makes the footprint of the application smaller because a fewer number of Active links and Filters exist in the application. Also, this approach makes the code easier to maintain because changes can be made in one place rather than in multiple places. For more information about guides, see Business logic object designs.

Reuse assessment

When assessing your reuse, BMC suggests that you ask the following questions:

• Can this function exist in other forms or other applications?
• Are the fields used in this function unique across forms?
• Are the fields registered?
• Does the naming convention of the workflow indicate that it is shared (if it is a shared piece of code)?
• Is the workflow encapsulated in a guide so that it is easier to see the functionality grouping?

AR System platform leverage

To reduce customization effort and increase value, configure your design to leverage the functionality provided by the AR System platform. Design your applications to work out-of-the-box, without customization, and with the following features:

• Distributed Server Option (DSO) — Ensure that all form interdependencies are well documented so that it is possible to construct DSO mapping files to support applications distributed across servers. The design must support these files. Ensuring that Field 179 is populated with a unique ID will assist in identifying similar records across multiple servers.
• Row Level Access—Field 112 should be present on most application forms to plan for row-level access support.
• Public Access—Plan your application design for external-facing applications that will have nonlicensed users accessing them. By ensuring that the Submitter Mode field is set to Locked, the design enables users to modify their own requests even if they do not have a write license; see  Enabling submitters to modify requests .
• Localization—The Field 160 is present on forms that store localized data; see  Localization reserved field .
• Email Engine—Use the Email Engine for all inbound and outbound email processing. Design this access and support into the application; see  How Email Engine works .
• Reporting Interface—If possible, place reports in the AR System report form and interface.

Server and client performance

For guidelines and tips to assist you in designing for server and client performance, see Server and client performance.

Internationalization support

When designing for internalization (I18N) support, be aware of the following issues:

• Avoid hardcoding strings within a workflow that need to be translated. This includes qualifications, and passing data via open window calls.
• Ensure that all message IDs are unique and are stored in the message catalog forms.
• Any forms that are being queried from menus or using active links with the fallback locale mechanism must have the special Locale field (Field 160) on the forms. This will enable the system to perform the appropriate locale lookup.
• Design installations with I18N in mind to allow the choice of language to be installed.
• Sample data must be localizable.
• We recommend an application have only one code line for each language. A different set of code must never be required for a specific language.
• If messages will be exposed to end users, any executables that are included with the application must include a message catalog.
• Do not construct sentences or concatenate strings together to relay information. Different languages require different orderings for the words.
• Leave extra space in your user interface to accommodate longer label names when translated.

User interface object designs

For guidelines to design the user interface objects, see User interface object designs.

Business logic object designs

For guidelines to design the business logic objects, see Business logic object designs.

Message IDs

The error, note, and warning message numbers (IDs) used in the message action for active links and filters must be unique. This requirement helps with debugging. For internationalization (I18N) support, enter messages into the AR System Message Catalog form so that they can be translated to different languages. The message ID is one of the keys used to look up the appropriate message for a language. Register these values, so that they not conflict with other applications. For more information, see   Localizing message components of a form view .

Many applications maintain their own Application Message Catalog form with records that have message strings that are mostly shown on dialog boxes (display-only forms) in the form of questions to end users. Associate the message ID records with a Used By value of String Catalog.

Naming applications

AR System applications follow a naming standard similar to form names. The standard naming format for a AR System application is System Code:Application Name Description.

Flashboard designs

For naming convention and standard format of flashboards, see Flashboard designs.

Custom AR system reports

For information about fields that are used to define data for reports, see Custom AR System reports

Workflow coding style

Workflow is triggered by a user action (such as submitting a form or clicking a button). Workflow acts on the data stored in forms to automate business processes. For recommendations concerning workflow coding style, see Workflow change guidelines.

Avoiding latency issues by using service calls

When you make customizations, ensure that your changes do not affect the overall response time of client systems that are interacting with the system. Any workflow on a client system that gathers information must pull that data from the server in the least number of calls possible. If your workflow is designed to make multiple calls from the Mid Tier to the AR System server, and back, the response time issues might occur due to this latency.

To reduce the number of calls to the AR System server, you can use AR System server service calls. In a service call, the active link workflow makes a single call to the AR System server. That single call causes a form to start a filter workflow that gathers the necessary information and pulls it back to the client.