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

6.-Remedy General Customization Best Practices

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

6.-Remedy General Customization Best Practices

Uploaded by

Copyright:

Available Formats

April 2012

BMC Remedy Workshops

You might also like