6.-Remedy General Customization Best Practices

April 2012

BMC Remedy Workshops

Remedy General Customization Best Practices

Copyright 2/17/2014 BMC Software, Inc 2

Remedy Customization Best Practices

Recommended Attendees- Remedy Consultants/Developers/Administrators.

Desired Outcome- Share best practices in related to Remedy customization

Preserve customizations through upgrades.

Review types of customizations that may vary in maintenance efforts.

- Provide guidance for setting customization expectations and limits

Format- Review BMC best practices.

- Discuss and answer questions.


Customization Categories

General Customization Principals- Definition and Use of Overlays

- Object Naming Conventions

- Performance Impact Considerations

- Additional Considerations

Specific Customization Guidelines- Form Changes

- Workflow Changes

Specific Customization Guidelines

Customization Best Practice | General Concepts

Customization Categories


Customizations typically fall into three different categories- Configuration (Data configuration changes)

i.e. Update Notification Text, configure skins

- Extensions (New objects)

i.e. Add a new rule (filter) to check the format of a given field.

- Customization/Complex Changes (to out of box objects)

i.e. Changing the values in a pull down selection list.

Impact/risk of the customization typically increases as you move down the list above.- Configuration Low Impact

- Extension Low to Moderate Impact

- Customization/Change Moderate to High Impact

Customization Best Practices | Customization Categories


Impacts/risks can include: (typically after an upgrade)- Unexpected data.

- Fields that overlap on upgrade.

- Workflow that fails to function properly on upgrade.

- Workflow that no longer makes sense after upgrade and introduction of new features.

Even with the use of Overlays, customizations may still fail to function properly after an upgrade.

Customization Best Practices | Customization Categories

General Customization Principals


Overlays (Definition)

- An overlay is a copy of a BMC Remedy AR System structure or workflow object that is used in place of the origin object. Out-of-the-box BMC Remedy AR System application and server objects, and objects created in the Base Development mode of BMC Remedy Developer Studio, are origin objects.

- To customize out-of-the-box BMC Remedy AR System objects and ensure that the customizations are not lost when a BMC Remedy AR System application or server is upgraded, create an overlay of the origin object, and modify the overlay instead of the origin object.

- New objects should be created as Custom objects.

- Overlay and Custom objects are managed in the Best Practice mode within Developer studio.

Customization Best Practices | Customization Principals


Overlayable Objects

- Active Links

- Images

- Active Link Guides

- Escalations

- Menus

- Filters

- Forms

- Views

- Fields

- Web Services

- Packing Lists

- Local Applications


Non - Overlayable Objects

- Custom Objects (Not part of base application)

- Deployable Applications

- Overlay Objects (only one level of overlay)

- DSO Mappings/Pools

- Flashboard Objects


Overlay Restrictions

- Does not preserve customizations made to base objects that are deleted/removed during an upgrade.

- Does not merge customizations with functionality added during an upgrade. For example, if you create an overlay of a filter guide that contains 3 filters, if during the upgrade a fourth filter is added, that change will not be reflected in the overlay. On forms, new fields added during an upgrade may not align with custom fields on the view.

- Does not allow fundamental changes to out of box objects. For example, you cant change a fields data type.

It is important to note that overlays will preserve your customizations but they do not guarantee that the customization will function properly or even make sense after an upgrade. Therefore, customize and use overlays only where needed!!!



Overlay Use Principals

- Any customization should be done using Best Practice mode and overlays. Never make changes to the base objects.

- If using an overlay to a field, ensure the field continues to be used for its same purpose. Fields need to continue to be used as intended for their original purpose, otherwise updates may break the customization and/or not make sense. If needed create a new field, if the purpose is different.

- When making a change to a form layout, also create a view overlay on all views that are impacted by the change. This will help preserve your form change layout on an upgrade. For multiple languages, view overlays may need to be created for each language view for the change to be done.



Overlay Use Principals (Continued)

- Always consider performance impacts in any customization. E.g. use table field chunking, reduce calls to the server by using Service actions, etc.

- Customizations, even when done in an overlay, still need to be tested/verified on an upgrade.



Naming Conventions

It is typically considered good practice to define and use a naming convention when creating new objects. This allows for the easy identification of objects within Developer Studio and when reviewing logs.

Naming conventions typically have the following format:- Start with a 3 character code that identifies the customer/company.

- Incorporates the out of box application 3 character module code.

- Uses semi-colons (:) to separate codes.

- The leading 3 character code is sometimes referred to as the namespace.

Example:- COM = [My Company]

- HPD = [Help Desk or out of box Incident module]

- COM:HPD:[Object Name/Description]

- This allows me to identify the customer this object is associated with and what module it is associated with.



Performance Considerations

When designing customizations, always consider performance implications. Typical performance considerations include:- On form results lists, consider adding chunking to display rows 1000 at a

time or less. (Will improve web performance).

- On table fields, consider using chunking, displaying between 50 500 rows at a time.

- On table fields, consider when the table contents need to be refreshed. Do not refresh via workflow often and dont always load the table upon form display as well. Table may not be visible until other actions are taken such as clicking a button, etc.

- Do not create multiple active links making queries back to the server. Instead consider using a Service action where with one call/trip, you can retrieve several pieces of data.



Performance Considerations (Continued)

Typical performance considerations include:- Remove fields that are not being used on the view. Reduces the size of

the form (a bit), that is being generated in the browser.

- Limit the use of escalations. Consider creating multiple escalation threads to handle frequent escalation activities, such as out of box Notifications and SLM service targets.

- Evaluate indexing when adding new fields or creating a new form.

- When using tool tips, restrict or use data only available on the current form and avoid additional calls to the server/database.

- Avoid polling menus or interval (timed) active links.

- Use type ahead menus sparingly. If necessary, define min. number of characters to enter first. This can reduce the number of values to be displayed.



Additional Considerations

Make use of the Change Log for each object to document the change and/or purpose of the object. This can be helpful if and when you generate documentation using the built-in object document generator within Developer Studio.

Consider the use of packing lists to group together related customizations. This has the following advantages:- Allows other developers to quickly identify customizations associated

with a module or application function.

- Easy to export as a package (definition file) and import into other environments.

- Helps track and identify what needs to be tested on an upgrade.


Specific Customization Principals


Form/View/Field Customizations

Always make changes using an overlay of the form and view.

- Changes to some fields, if they are on multiple views, will require view overlays to be created for all views impacted. This is often seen with the different language views.

- You can return to the original view but deleting the view with the overlay.

Instead of modifying a view directly for changes in images or colors, consider the use of the AR Skins features.

Customization Best Practices | Specific Principals


Form/View/Field Customizations (Continued)

Never change the database names for existing fields. Analytics reporting often depends on these values.

Never delete/remove existing fields. Hide them if not required.

For linear selection fields, you can only add new values to the end of the list. Changing orders within selection fields can have unintended consequences in the workflow.- It is recommended to avoid changes to any status field due to potential

workflow impacts.

For custom selection fields, you can add new values for numbers that are not currently used.

If adding a new field that will be used in an integration. Ensure it is added to the related Interface forms.

Customization Best Practices | Specifics Principals


Form/View/Field Customizations (Continued)

When adding a new field, especially to main forms like the Help Desk or Change forms, do not make those fields required. This could break out of box integrations. - Instead, consider creating an active link to verify a fields requirement.

Active links run on the client and are unlikely to interfere with integrations like a field attribute change or a filter.

When creating new fields, buttons, etc., always use a field ID outside the range reserved by BMC. BMC Reserved ranges are:- 1 536,870,911

- 1,000,000,000 2,000,000,000

Do not alter out of box field attributes such as Required/Optional, data type, or pattern match. These attributes are likely to be overwritten in an upgrade or cause workflow errors.



Workflow

Adhere to a naming convention to keep new workflow within its own workspace.

Do not convert or change out of box optional process to required processes. This could break other dependencies.

Build new workflow that is isolated from out of box workflow as much as possible. E.g. Fields are set to Read Only when a user does not have permission to a record. If you have a custom field, do not add onto the existing workflow that sets fields to Read Only, rather build your own Active Link to handle the custom field. This will reduce potential conflict on an upgrade.



Workflow (Continued)

Attempt to stick to the following workflow to avoid impacting the primary flow:

- Client-side workflow (active links) that provides for navigation to other forms or displays lookups to select data that is pulled into the existing form

- Server-side business logic (filters) that perform the following operations:

Validation of data in new fields that have been added

Additional notifications (either as integration points to the BMC Remedy ITSM Notification Engine or as separate BMC Remedy Action Request System notifications)

Pushing data into other forms that have been added

Setting data from newly added forms into fields that have been added .



Workflow (Continued)

Attempt to stick to the following workflow to avoid impacting the primary flow:

- Server-side Escalation Logic, which enables data to be polled periodically and permits actions to be performed on this data. You can add this functionality to new forms, but use caution when you are adding it to existing forms because it might impact system performance.

- Menu Objects, which you can add to fields to enable the lookup of data to populate fields. If you define a menu as a type-ahead menu, it will show values based on the data being entered in the field. However, use this option sparingly to avoid performance impacts on the form.

Note: BMC does not recommend making changes to the out-of-the-box notification workflow because the changes might affect the processing of the applications. Instead, add new notifications that support your notification functionality requirements.


Common Customizations


Common Customizations - Notifications

There are several common customizations requests that may arise and BMC has the following considerations for some of these as follows:

- BMC does not recommend making changes to the out-of-the-box notification workflow because the changes might affect the processing of the applications. Instead, add new notifications that support your notification functionality requirements.

- Notifications you dont want to use can be disabled via configuration.

Customization Best Practices | Common Customizations


Common Customizations Process Flow Bar

The process flow bar is the area at the top of the main process screen that shows the overall process involved for a particular application. At each stage of the process, a number of available actions can occur for each process state.

You can customize the process flow bar to extend the actions that can occur for any individual process state. You cannot customize the process flow stages. For example, if you wanted to add a new value to the "Investigation and Diagnosis" stage of an incident, you could add a new action to appear on the drop-down menu via configuration data in the system, and then add your own Active Link workflow that would be triggered based on the selected data.



Common Customizations Work Detail

Work Detail logs are used to track changes on many different types of records (Incidents, Changes, Tasks, etc.) Part of a Work Detail record is the Work Info Type.

The Work Detail, you can customize the Work Info Type field to add new values. New values that you add should be odd numbers so they do not conflict with future values that BMC might add. Do not remove an out-of-the-box Work Info Type values because their removal might cause upgrade problems.



Common Customizations ITSM Relationships

One of the key structures used to link BMC Remedy ITSM applications is the application relationship model. You can use the relationship module to search for relationships and display the relationships in a table. From the table you can then perform actions on the data via Quick Actions forms.


This customization could be considered an extension since we are only adding configuration data and adding a new active link to process the action.


Common Customizations Status Reason List

The status reason is a value that is contextual to the current status. You can extend this field is to provide some additional information for the current status or provide a way to trigger workflows from a function that occurs during the specific status.


This customization includes adding configuration data to the SYS:Status Reason Menu Items form, but also a change to a hidden selection field on the primary form. E.g. HPD:Help Desk Status_Reason.


Questions ???

Customization Best Practices | Wrap Up


Learn more at www.bmc.com

Date post:	15-Oct-2015
Category:	Documents
Upload:	sam589
View:	9 times
Download:	0 times

6.-Remedy General Customization Best Practices

Documents