Remedy Architecture

BMC Remedy IT Service Management 7.
Architecture
October 2006
Copyright 19912006 BMC Software, Inc. All rights reserved.

BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and all other
BMC Software product or service names, are registered trademarks or trademarks of BMC Software, Inc. All other
trademarks belong to their respective companies.
BMC Software, Inc., considers information included in this documentation to be proprietary and confidential. Your use of
this information is subject to the terms and conditions of the applicable end user license agreement or nondisclosure
agreement for the product and the proprietary and restricted rights notices included in this documentation.
Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE
COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by
the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013,
DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time.
Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract
notices should be sent to this address.
Contacting Us
If you need technical support for this product, contact Customer Support by email at support@remedy.com. If you have
comments or suggestions about this documentation, contact Information Development by email at
doc_feedback@bmc.com.
This edition applies to version 7.0 of the licensed program.
BMC Software, Inc.
www.bmc.com
Contents
Introduction ............................................................................................................. 9
ITSM suite description........................................................................................ 9
Features and benefits....................................................................................... 10
ITSM suite architecture.................................................................................... 11
Service Desk process....................................................................................... 11
Change management process .......................................................................... 12
Asset and Configuration Management process ............................................... 13
Conceptual architecture................................................................................... 14
Architecture philosophy .................................................................................. 15
Common application models........................................................................... 17
Foundation architecture ....................................................................................... 27
Reference data ................................................................................................... 27
Infrastructure model ........................................................................................ 27
Foundation components.................................................................................... 27
Company ......................................................................................................... 28
Location .......................................................................................................... 28
Organization.................................................................................................... 30
People.............................................................................................................. 31
Support groups ................................................................................................ 33
Categorization ................................................................................................. 34
Notification Engine ......................................................................................... 36
Assignment...................................................................................................... 37
BMC Remedy Change Management architecture ............................................. 41
Process flows ...................................................................................................... 41
Initiate and record ........................................................................................... 42
Review and authorize...................................................................................... 43
Plan and schedule............................................................................................ 43
Implement ....................................................................................................... 44
Complete and close ......................................................................................... 44
ERDs................................................................................................................... 44
Associations .................................................................................................... 44
Linking ............................................................................................................ 46
Lookup ............................................................................................................ 47
Associated information ERD .......................................................................... 48

Linked data...................................................................................................... 49
Data lookup ..................................................................................................... 51
Comprehensive ERD....................................................................................... 53
Main forms......................................................................................................... 54
Change calendar ................................................................................................ 54
Architectural overview.................................................................................... 55
Executive dashboard ......................................................................................... 59
Architectural overview.................................................................................... 60
Subsystem integration....................................................................................... 61
Requester Console........................................................................................... 61
Cost Management............................................................................................ 61
SLM ................................................................................................................ 61
BMC Atrium CMDB....................................................................................... 62
Interfaces............................................................................................................ 63
Interface forms ................................................................................................ 63
Web services ................................................................................................... 63
Permission model............................................................................................... 66
BMC Remedy Asset Management architecture ................................................. 67
Process flows ...................................................................................................... 68
User interface..................................................................................................... 68
Asset Management and the BMC Atrium CMDB.......................................... 69
Reconciliation ID ............................................................................................ 69
Sandbox........................................................................................................... 70
ERD .................................................................................................................... 70
Asset Management full ERD .......................................................................... 71
Asset Management system forms ..................................................................... 73
Software license management .......................................................................... 74
AST:LicenseMgmtIncludeClass ..................................................................... 76
AST:ConfigLicenseMgmt............................................................................... 76
AST:LicenseMgmtEngine............................................................................... 78
AST:LicenseMgmtException.......................................................................... 78
AST:ManageLicenseMgmtException............................................................. 78
Procurement ...................................................................................................... 79
Contracts ......................................................................................................... 80
Warranty contracts .......................................................................................... 81
Support contracts............................................................................................. 82
Lease contracts ................................................................................................ 83
Maintenance contracts..................................................................................... 84
Software contracts........................................................................................... 85
Standard configurations ................................................................................... 85
Outages............................................................................................................... 86
Schedules ............................................................................................................ 88
Subsystem integration ..................................................................................... 88
Interfaces............................................................................................................ 90
BMC Atrium CMDB API ............................................................................... 90
Interface Forms ............................................................................................... 90
Web Services................................................................................................... 90
Permission model............................................................................................... 91
BMC Atrium CMDB permission model ......................................................... 91
Asset Management roles ................................................................................. 91
Mapping of Asset Management roles to BMC Atrium CMDB roles.............. 91
Row-level security .......................................................................................... 92
Mapping of Asset Management roles to Asset Management functions .......... 92
BMC Remedy Service Desk architecture ............................................................ 94
High-level process flow ..................................................................................... 94
BMC Remedy Incident Management .............................................................. 95
Process flows................................................................................................... 96
Design overview.............................................................................................. 97
Main forms ...................................................................................................... 97
Subsystem integration ..................................................................................... 99
ERD............................................................................................................... 105
Interfaces ....................................................................................................... 106
Licensing model ............................................................................................ 107
Permission model .......................................................................................... 108
BMC Remedy Problem Management............................................................ 108
Problem investigation.................................................................................... 108
Known error management............................................................................. 109
Solutions database......................................................................................... 109
Process flows................................................................................................. 109

Main forms .................................................................................................... 110
ERD............................................................................................................... 112
Interfaces ....................................................................................................... 116
ITSM 7.0 subsystems........................................................................................... 117
Command Automation Interface ................................................................... 117
Overview ....................................................................................................... 117
ERD............................................................................................................... 118
Interfaces ....................................................................................................... 126
Contract Management .................................................................................... 127
ERD............................................................................................................... 128
Interfaces ....................................................................................................... 128
Costing Management ...................................................................................... 129
ERD............................................................................................................... 131
Licensing model ............................................................................................ 131
Definitive Software Library ........................................................................... 132
Architectural overview.................................................................................. 133
Primary components of the DSL................................................................... 133
ERDs ............................................................................................................. 134
Interfaces ....................................................................................................... 137
Web services ................................................................................................. 138
Requester Console and SRMS framework.................................................... 140
Requester Console......................................................................................... 141
SRMS framework.......................................................................................... 144
Task Management System.............................................................................. 157
Architectural overview.................................................................................. 158
Instantiation................................................................................................... 159
Association model......................................................................................... 162
Dependency model: flow mechanism ........................................................... 165
Sequencing (Basic) mode.............................................................................. 167
Data exchange model: variable pool ............................................................. 169
Complete example......................................................................................... 172
ERD............................................................................................................... 173
Interfaces ....................................................................................................... 174

Web services ................................................................................................. 174
Introduction
This document provides the technical details around the applications and
subsystems that comprise the BMC Remedy IT Service Management (ITSM) suite.
It covers architectural details, data models, and key workflow structures to provide
an understanding of how the ITSM applications suite works as individual products,
as well as integrated in a suite.
The applications, subsystems, and foundation data covered in this document are:
Applications
BMC Remedy Service Desk

BMC Remedy Incident Management
BMC Remedy Problem Management
BMC Remedy Change Management
BMC Remedy Asset Management
Subsystems
Command Automation Interface
Contract Management
Definitive Software Library (DSL)
Costing Management
Requester Console and SRMS framework
Task Management System (TMS)
Foundation data
Company
People
Location
Categorizations
ITSM suite description

The BMC Remedy IT Service Management product portfolio streamlines the
processes around IT service desk, asset management, change management, and
service level management, and also enables you to link your business services and
IT infrastructure to help you manage the impact of technology changes on business
and business changes on technologyin real time and into the future. In addition,
you can define and measure service levels, understand and optimize the user
experience, balance current and future infrastructure investments, and view
potential impact on the business using a real-time service model. All of this helps
you manage what matters to deliver Business Service Management (BSM).
Features and benefits

With the BMC Remedy IT Service Management product portfolio, you can:
Align business and IT
Translate business objectives into IT services by facilitating a dialog to define

what the business needs, and get agreement on the specific services and service
levels that IT will deliver to address those needs.
Manage assets to optimize business value by making sure your assets are
supporting business-critical IT services, according to agreed-upon service
levels.
Increase the responsiveness of IT organizations to the business by providing

dynamic service views and service models showing how a single event can
impact crucial business services.
Based on business needs and priorities, proactively manage service levels for
mission critical services delivered by IT operations through real-time
management of service level agreements.
Integrate real-time IT and business impact information, including route cause

data, into incident tickets for improved user value.
Provide visibility into your infrastructure
Rapidly discover what physical and logical elements (servers, routers, switches,
databases, gateways, web servers, application servers) and dependencies that
comprise an application infrastructure.
Quickly discover which underlying IT resources are causing business service

slow downs or outages.
Manage IT and service information at an enterprise scale with secure

distributed roles and responsibilities.
Allow for the identification of chronic bottlenecks and service-impacting

problems and workflow processes.
Provide real-time event consolidation, processing, and integration with existing

tools and help desks, and notification for consolidated control across the entire
IT computing enterprise.
Enhance customer satisfaction
10
Facilitate the creation and maintenance of a service model by not only

discovering the components and relationships of enterprise application
infrastructures, but also by watching for changes and proposing updates to the
service models accordingly.
Enable staff with interactive notification, escalation, and resolution capabilities

using remote devices to make sure IT and business issues are addressed quickly
and efficiently.
Show how the IT assets and staff resources perform against contracted service
levels.
Define, measure, and manage the quality of service experienced by a group of

users.
ITSM suite architecture

The ITSM suite is designed with an overall architecture in mind. Each application
in the suite must work as a standalone application, and also must integrate
seamlessly and provide additional value when other products in the suite are
installed.
The diagram that follows describes that typical data flow supported by the ITSM
suite. Users initiate the process using the Requester Console. The Requester
Console lets users pick what they want to ask for without understanding if the
fulfillment mechanism for that request is an incident or a change request.
Depending on what a user asks for, the Requester Console routes the request to the
incident management process or the change management process.
Service Desk process

The Service Desk process includes the process flows required to resolve outages
and keep the customer working at the appropriate level, as defined by the
companies Service Level Agreements (SLAs). Two processes support the Service
Desk: Incident Management and Problem Management.
When starting at the Requester Console, the incident management process is one
branch the flow can go through. Incident Management 7.0 is compliant with the
ITIL definition of being a process whose main purpose is to get the user back up
and running. To support that concept there are several interactions that help achieve
that goal.
If the Service Level Management (SLM) application is installed, Service Level
Agreements (SLAs) and Operational Level Agreements (OLAs) can get attached to
the incident, based on who is making the request, the urgency of the issue, and the
business services that are being affected by the issue.
Incident Management uses the knowledge database to provide the technician
working the issues with information about like issues that might help resolve the
problem as quickly as possible.
Incident Management also comes with, and tightly integrates with the BMC
Atrium CMDB, to provide a repository for the configuration items (CIs) in the
organization. CIs can be related to the incident to indicate where the issue is
11
happening. You can use the BMC Service Impact manager to look at possible root
causes, and to determine the level of response and resolution required.
While the incident management process is designed to resolve outages and get the
customer working as quickly as possible; for some issues, a root cause might not be
determined. For those issues, a problem investigation can be initiated. The problem
investigation provides the constructs for determining the root cause, tracking it as a
known error, and making determinations if the error is something that should be
corrected in the environment using a change request, or if a work-around can be
provided that can be used instead.
Incident Management and Problem Management can also be processes initiated
outside of a requester. For example, Incident Management can be integrated with
the BMC Service Impact Manager or the BMC Event Manager to automatically
generate incidents based on events in the infrastructure. For an integration with
Service Impact Manager, the event can be correlated to the business services that
are being affected, and generate incidents with the appropriate CIs related for
resolution.
Problem Management can also be initiated using a proactive problem management
approach, where the environment is viewed for trends by reporting. Problem
investigations are then generated.
Change management process

The change management process manages changes in the infrastructure. They can
be large scale changes such as upgrading a set of vital systems, or smaller changes
such as setting up new employees.
The change management process is designed to be open to handle the many
different types of processes that an organization might have.
The process includes three layers of approvals that use the BMC Remedy Action
Request System (AR System) Approval Server as the engine to manage approvals.
The change management process also integrates with the time management
functionality in the underlying AR System platform to view conflicts between a
scheduled change and other changes in the organization.
Integrations that the change management process uses include:
BMC Atrium CMDB, to handle targeting of CIs for changes, and

understanding their relationships with other CIs and business services.
12
BMC Service Impact Manager, to provide an insight into the risk of making a
change, and the systems and business processes that will be affected.
BMC Atrium CMDB, to integrate the change management process with

Configuration Management for pushing changes to the infrastructure.
Asset and Configuration Management process

The combination of the BMC Atrium CMDB and the Asset Management
application provides the model for doing Asset and Configuration Management
within it the ITSM suite.
The configuration management process provides the model for maintaining the
Configuration Items (CIs) that are important to the business, and controlling the
updates that have occurred to those CIs in the Change Management process.
Asset Management processes provide mechanisms to manage schedules, contracts,
procurement, depreciation, and chargebacks.
Primary integrations with Asset Management are at the BMC Atrium CMDB level.
BMC Discovery solutions populate the BMC Atrium CMDB with information
about the CIs in the infrastructure, and their relationships. The BMC Atrium
CMDB also provides a federated integration model to link CIs to other applications,
such as the BMC Service Impact Manager and other third-party products.
Diagram of the ITSM suite architecture
13
Primary ITSM
Apps
General Flow
End
Users
Supporting
Applications
Request
Console
Change
Management
Service Level
Management
Incident
Management
Asset
Management
DSL
Problem
Management
Knowledge
(Known Error)
BMC Atrium
CMDB
Problem
Management
(Investigation)
Conceptual architecture
The overall architecture of the ITSM suite can be separated into three layers:
User subsystem
Back-office primary systems
Supporting subsystems
The top layer consists of systems that provide the interface to users, such as the
Requester Console. The Requester Console is designed as a subsystem for users to
create requests that interface with a back-office system, such as Incident
Management or Change Management
The back-office primary systems are the main applications: Incident Management,
Change Management, Problem Management, and Asset Management. These
systems contain logic and user interfaces specific to those application areas.
14
The final layer consists of supporting subsystems. This common set of subsystems
supports the back-office systems. Subsystems contain generic logic that is specific
to a subsystems function, without embedding functionality from other applications
that use its services.
Back Office
Primary Systems
End User
Subsystem
Examples of subsystems include Task Management System, Costing Management,

Contract Management, and so on.
Request
Console
SRMS Framework
CAI
ITSM Foundation
Change
Management
Asset
Management
Incident
Management
Problem
Management
BMC Atrium CMDB
BMC Atrium CMDB
BMC Atrium CMDB
BMC Atrium CMDB
Task Management
DSL
Task Management
Cost Subsystem
DSL
Cost Subsystem
Cost Subsystem
ITSM Foundation
Cost Subsystem
ITSM Foundation
ITSM Foundation
Knowledge
SLM
SLM
ITSM Foundation
Supporting
Subsystems
SLM
Task
Management
Subsystem
Location
Organization
People
Support Groups
Categorizations
Notification Engine
Cost
Management
Subsystem
Definitive
Software Library
[DSL]
CAI
ITSM
Foundation
ITSM Foundation
Common Automation
Interaction
[CAI]
ITSM Foundation
ITSM Foundation
Architecture philosophy
Definitions of architectural concepts are key to a successful enterprise application
development. They provide the guiding principals for how applications are
designed and developed. The ITSM 7.0 suite of applications follows a strict set of
principals based on a component development model.
The following types of architectural structures are used in the ITSM 7.0 suite:
Systems
Subsystems
15
Subsystem candidates
Shared components
Foundation elements
Systems
An application or system provides a higher level theme of functionality that is

functional by itself, and can in part be made up of and supported by several
subsystems. Examples include Change Management, Asset Management, Incident
Management, and so on.
Subsystems
Subsystems are self-contained, modular, and extendable systems of functionality,

with well-defined and documented interfaces designed to support higher level
systems. Examples include Task Management System, Approval Server,
Assignment Engine, and so on.
Subsystem candidates
A subsystem in development is architected and designed to be modular and support

the characteristics of being a subsystem but without currently meeting the required
rules of being a subsystem.
The required rules for a subsystem include fully developed interfaces encapsulation
as a deployable application, and so on. A subsystem candidate is the first stage of
becoming a formal subsystem to be leveraged in a current release. An example is
the Service Request Management System (SRMS) framework.
Shared components
Segments of workflow and forms can be easily leveraged to perform a common

operation. A shared component serves as a template for a foundation of
functionality that will serve as a child to a parent system or subsystem. Examples
include Yes and No prompt dialog boxes, message confirmation dialog boxes, the
advanced qualification bar, and so on.
Foundation elements
The foundation is comprised of infrastructure workflow and reference data. These

are they primary components that are shared across the applications in the ITSM
suite. These are analogues the key structures that make up a building. You need to
have a strong foundation to build on. The foundational elements in the ITSM suite
make up the key structural and data elements that are needed to build strong
enterprise applications.
Reference data
Shared required data structures can be leveraged across different systems.
Examples include categorization, company data, multi-tenancy model, and ITSM
system forms.
16
Infrastructure model
The infrastructure model can be thought of as the plumbing structure of how things
fit together. Examples include the Notification Engine, association model,
Deployable Application structure, tenancy model, and so on.
Common application models

Deployable application structure
The AR System platform provides the structural component used in the ITSM 7.0
applications to define the deployable application architectural structure.
Deployable applications provide functions that support a component architectural
model. These functions are covered in following sections:
Licensing enforcement
Encapsulation of permissions
Definition of entry points
Ability to import and export as a whole component
Deployable applications are used to wrap each of the different systems and
subsystems that are provided in ITSM 7.0 applications.
Deployable applications contain the following systems and subsystems:
Systems
Incident Management (licensed)
Problem Management (licensed)
Change Management (licensed)
Asset Management (licensed)
Subsystems
Costing Management (licensed)
Task Management System
Definitive Software Library (DSL)
Change Management Dashboards (licensed)
Application Administration Console
Reporting Console
Requester Console
Helper
Foundation elements
17
Foundation sub-elements, such as message boxes and so on
Site
Company
Product catalog
Licensing model
The licensing model has been extended in ITSM 7.0 to add application-level
licenses and user-level licenses. All licenses in the ITSM 7.0 suite of applications
are enabled by the deployable application model described previously.
Application-level licenses
Application licenses provide access to the forms that make up an application. If an
application-level license is not applied to the AR System server, the forms are not
accessible using user clients. This makes user licensing a requirement for importing
data into the applications.
Application-level licenses are enabled for the main applications provided in the
ITSM suite. In addition, application-level licenses are required for the Change
Management Dashboard and the Costing Management subsystems.
User-level licenses
ITSM 7.0 supports Fixed and Floating licensing models for users of the licensed
applications. The ITSM suite supports a model that requires a license (in addition to
any required permissions) to modify records in the application. There are no license
requirements for submitting data into the system; however, there are permission
requirements.
Fixed licensing is a named license that gets assigned to a particular user.
Floating licensing is a pool of licenses that is assigned to a set of users. Users take
up tokens when they log in to an application, and hold on to those tokens while they
are working with the forms in that application. Tokens are released when a user
logs off or a system timeout is reached.
Permission model
The ITSM suite has built a specific philosophy into how the model was designed
for the ITSM suite.
Main concepts defined include:
Abstraction using roles
Common roles
Viewer
User
18
Master
Administrator
Predefined permission groups to support the roles
User access using support groups
Functional roles
Abstractions using roles

Roles are provided by the AR System deployable application model. Roles are
defined within the context of a deployable application. Forms and client-side
workflow in a deployable application have roles defined for permissions instead of
physical permission groups that users are assigned to.
Permissions are enabled for a user by mapping the physical permission groups that
are provided with the applications to the roles that the permission groups should
belong to. By doing this the underlying systems and subsystems can change and
control their permission models without affecting how other applications integrate
with them. This also allows other applications outside of the ITSM suite to
integrate with ITSM systems and subsystems. Customers can also build their own
sets of permissions groups to map into the systems and subsystems.
Common roles
To simplify and provide commonality amongst the applications, each system and
subsystem provides a common set of roles. The system or subsystem can extend
these roles for other specific purposes as needed.
The common roles are:
ViewerProvides the ability to view data in a system or subsystem, but not to

modify data.
UserProvides the ability to modify data, based on support group access.
MasterProvides the ability to modify any record.
AdministratorProvides the ability to configure the system or subsystem.
Predefined permission groups

To support this model, the applications provide predefined explicit permission
groups that map to roles for each of the systems and subsystems.
Also, as shipped, these permission groups are also mapped to the appropriate roles
that are needed from the underlying subsystems. For example, all roles that require
costing data access are mapped to the Financial User role. This predefined
configuration makes it simpler to configure permissions in the application, while
still providing the underlying control.
To enable an easy mapping mechanism, the AR System computed group is used.
Computed groups let you define which groups make up the definition of a group.
19
For example, the following computed group is used to define including all users for
each application in the Cost User role.
User access using support groups

Support groups play a primary role in the permission model for ITSM 7.0. If a user
is a member of a user role, the definition of what records they can modify is based
on if that record has been assigned to one of their support groups. For example, if
users are in the Incident User role and are members of the Hardware support group,
they can only modify incidents that are assigned to the Hardware support group.
They can view other incidents, but they will not be able to modify those incidents.
Functional roles
Functional roles are not permission groups, but are enforced by workflow. For
example, the Manager or Approver role within a support group provides additional
privileges within the application functions. Based on your support group, you can
have different functional roles. For example, in the Hardware support group,
someone can be defined as a manager, but in the Software support group that
person might just be a member.
Multi-tenancy model
Multi-tenancy defines who has access to what data on a row-level basis. For
example, in a service provider environment a single application might be used by
multiple companies, with the data for each company hidden from other companies
using that application.
20
In ITSM 7.0, multi-tenancy is defined using companies. Companies are defined as

operating companies, and users are associated to these operating companies to
define their access rights. A user is associated to a company through the People
form, shown here:
A user can manage multiple companies by adding more companies to the Access
Restrictions list. If a user needs to manage all companies, access can be set to
Unrestricted.
Implementation of multi-tenancy
The services provided by the AR System platform are primary to the
implementation of multi-tenancy. AR System enables you to control access to data
based on permission groups, and determine if those permission groups have access
to individual rows of data. This implementation uses a special set of fields that hold
the list of permission groups that have access to a row. The ITSM suite uses field
ID 112 to enable this feature, although other field IDs are available on the
AR System server and are used by the BMC Atrium CMDB.
This special field 112 is populated on main application forms based on the
companies that are picked to access that record. For example, when you select the
contact and classification companies on the Incident form, workflow updates field
112 values with the group IDs that have been assigned to those companies. For
child records, such as the tasks or costs associated to an incident, the tenancy
information is passed down from the parent.
21
After field 112 is populated, any query to AR System displays only rows of data
that a user has permissions to, based on their permissions, and the permissions in
field 112.
Integration model
One of the main architectural requirements for the ITSM suite is that all systems
and subsystems must provide defined interfaces for integration purposes. These
interfaces abstract the applications that integrate with the systems and subsystems
from the inner workings and from differences in versions.
The common model for interface forms is to use display-only forms to manage the
creation of records and relationships, and to use join forms to manage queries and
modify actions.
BMC strongly recommends that all integrations to Incident Management, Problem
Management, Change Management, Task Management System, and Costing
Management go through the provided interface forms. This will abstract any future
integration from underlying changes to those systems and subsystems.
In addition to the interface forms, web services are provided for most of the
applications. The web services interfaces are a layer on top of the interface forms,
and provide basic create, modify, and query capability to the applications and
subsystems.
For more information about using interface forms and web services, see BMC
Remedy IT Service Management 7.0 Integrations white paper.
Console structures
Consoles are the main user interface to the ITSM 7.0 applications. Two types of
consoles are provided: application-specific consoles that provide application
specific functionality, and common consoles that are used across applications.
Each ITSM application has a console that is focused on the support technician and
a console for the manager. The main difference between these role-based consoles
is the layout and the addition of high-level overviews for managers using of graphs
and charts.
The common consoles include an overview console that combines assigned work
from all applications into one view, and a requester console that is focused on the
users.
Application consoles
Each application console has two views. One focused on the support technician,
and one on the manager. In addition, the Change Management console also
provides the ability to change the support console to focus the work on tasks or
change requests.
22
Overview Console
The overview console provides a view of work assigned across multiple
applications. For example, if users wants to see all incidents, problems, and tasks
assigned to them, they can view them in the overview console.
This implementation uses an ARDBC AR System plug-in to provide a consolidated
view of all assigned work from data sources in multiple applications without using
replication of data or complex SQL views that bypass APIs.
The plug-in architecture is data-driven. Configuration forms define how the plug-in
is set, including which forms to query, which fields to map to the table field, and a
ARDBC form that performs the query.
ARDBC plug-in data setup:
SHR:ARDBCForms
SHR:ARDBC_OverviewConsoleTemplate
SHR:ARDBCFields
Ticket types:
Change
Incident
Problem Investigation
Known Error
Knowledge
CI Unavailability
Purchase Requisition
23
ARDBC plug-in initialization process

ARDBC plug-in is loaded by
the AR System server. This
triggers the ARDBC
initialization functions to run.
ARDBC plug-in queries

SHR:ARDBCForms to get a list of
forms available for use with this plugin, and caches this information.
ARDBC plug-in queries

SHR:ARDBCnumLookup form to get status
mapping between ConsolidatedStatus on
Vendor form and individual forms.
For each form, ARDBC plug-in queries

SHR:ARDBCCFields form to get a list of
fields to retrieve from each form, and the
mapping of those fields to the Vendor
form. This information is also cached.
24
Overview console
(contains table pointing to
Vendor form)
1. Query vendor form to
populate a table on the
console
6. Results are displayed in

the table
Vendor form
(based on
SHR:ARDBCForm)
5. ARDBC plug-in
consolidates results lists
and returns vales to
Vendor form
2. Querying vendor form

triggers ARDBC plug-in
ARDBC plug-in
3. ARDBC plug-in uses cached

information on forms to
consolidate and field mappings
from these forms to the Vendor
form
ARDBC plug-in also constructs a
qualification for each form to
query, based on field mapping
configuration information
4. ARDBC plug-in queries

forms and retrieves results
HPD:Helpdesk
CHG:Infrastructure Change
TMS:Task
Relationship Model
All ITSM 7.0 applications use the same basic structure for relationships between
each application. The structure is based on each application having a relationship
table that shows information in the context of that application while looking out to
the other applications it is integrating with. When a relationship is created between
two applications, two relationship records are created, one in each of the
applications relationship tables, showing the context from that application to the
other application.
25
Incident
HPD:Associations
Target
Target Request
Work Info model

Work logs are components used to track work history. They replace the work diary fields
that were used in previous versions of the ITSM applications.
Each work entry is stored as a separate record in an AR System form. This

approach allows for easier reporting and searching of the Work Info entries
associated with any particular record.
Each Work Info entry can contain up to five different attachments. The attachments
can be associated with the work notes, which results in the attachments being tied
to the record. This provides context to the attachments, and makes it easier to find
them. It also allows for unlimited attachments to be associated to any particular
record.
The work log system also allows for locking records, making records public or
hidden, and categorizing the records.
On a per-application basis, each application uses a separate work log form, but uses
the same structure and workflow around the form. This offloads the processing of
Work Info records to forms that are specific to each application.
26
Foundation architecture
The ITSM Foundation contains data structures and services that are common to all
applications in the ITSM suite.
The Foundation consists of two different concepts: reference data and the
infrastructure model. Think of the foundation as the architecture of a building. The
infrastructure model is analogous to the pipes and electrical wiring, while the
reference data is analogous to the things flowing through the pipes and wires, such
as water and electricity.
Consider the following definitions and examples of foundation components in the context of
how the ITSM applications are built.
Reference data
Data structures and subsystems are shared by many different systems. This data is
central to the running of the application. Examples include People, Companies,
Categories, and so on.
Infrastructure model
Think of the infrastructure model as the plumbing structure, as how things fit
together. Examples include the Notification Engine, association model, Deployable
Application structure, tenancy model, and so on.
Foundation components
The ITSM foundation provides a repository for the following data structures used
by each ITSM application:
Company (tenancy definition and external company definition)
Organization
Location
People
Support groups
Categorization
27
Company
Company is a primary data structure in the ITSM foundation. This structure has the
following two main purposes:
Tenancy definition
Tenancy refers to how data and rules are partitioned within the ITSM applications.
For example, a company might have two different business units that use the
Incident Management application. Each business unit has its own definitions of
data, categorizations, assignment rules and approval rules, and wants to make sure
that this data is not intermixed.
Tenancy allows you to define the partitions between the two business units and
enforce the data level permissions around who can access what data. In this
example, a company would be created for each business unit to define the desired
partitioning of rules and data.
So, a primary function of the company data structure in the ITSM Foundation is to
define those tenants to be used by the ITSM applications. This function of company
is used to define both how the application will partition the data, and the rules for
the application, based on different distinct users of the application.
Business units are one example of partitioning. If you need to partition the data and
the rules of the applications, based on individual business units, then different
companies would be defined for each business unit.
External company definition
You can also use the company definition to define other types of companies that are
used in the application, such as manufacturers, suppliers, and so on, as defined and
used in the Asset Management application.
Location
The location structure within the ITSM applications has a four-tired data model,
where the second and third tires can be optional (the fourth tier, however, is
required). In effect, the data model can be two, three, or four tiers. The Company
field makes up the first tier, Region is the second tier, and Site Group is the third
tier, and Site is the forth tier (where Sites are physical locations with mailing
addresses such as buildings). It is important to note that when creating the location
structures, the regions and site groups will be used to group sites within a company.
Therefore, it is important to have a list of the sites within a company, and then
determine if regions and site groups will be required to arrange the sites in an
organized manner that can be used for reporting purposes.
The Company field and Site field are required on all ticket forms.
28
Sites identify unique physical locations and are associated with one or more
companies.
Workflow can be defined to any level of the Location structure.
ERD
SIT:Site Alias
*
SIT:Site Group Logical Assoc
SIT:Site
*
111
1
SIT:Site Company Association

*
SIT:Site Zone (Deprecated)
*
*
*
COM:Company
1
1
1
CTM:Region
*
SIT:Site Group
29
Organization
Organization describes the role the company component plays in the foundation.
ERD
COM:Company Alias
COM:Company
*
1
1
1
CTM:Region
SIT:Site Group
CTM:People Organization
CTM:Support Group Shift

*
CTM:Support Group
CTM:Support Group Alias

1 1
1
1
*
CTM:Support Group Assignments
CTM:Support Group On
-Call
*
CFG:Approver Lookup
SIT:Site Alias
*
1
SIT:Site Group Logical Assoc

*
SIT:Site Zone (Deprecated)
30
11
SIT:Site
SIT:Site Company Association

*
N
1
COM:Company
COM:Company Alias
N
Company Alias
Company ID
Primary Alias
Company
Company ID
Company Type
1
N
Company
Region
Site Group
Site Group Type
Company
Region
Company
Organizarion
Department
Support Group Shift Name

Support Group ID
CTM: Support Group Alias

N
CTM:Support Group
1
CTM:Support Group
Assignments
CTM:People
Organization
SIT:Site Group
CTM:Region
Company
Support Organization
Support Group
Support Group ID
Support Group Role
Support Group Alias

Support Group ID
Primary Alias
1
CTM:Support Group On-Call
< Business Holidays Tag >

< Business Workdays Tag >
Default Assignment Group ID

Support Group ID
Support Group ID
On-Call Paging Type
Pager Service Provider
CFG:Approver Lookup
SIT:Site Alias
Pager E-mail
Remedy Login ID
Business Holidays Tag
Business Workdays Tag
Approver Login ID
Approval Type
Approval For
N
Site Alias
Site ID
Primary Alias
Pager Phone Number (comprised of):

CC Pager
Area Pager
Local Pager
PIN Pager
SIT:Site
Site
Site ID (system generated)
SIT:Site Group Logical

Assoc
N
Company
Site Group
Site Group Type ("Logical")
Site ID
SIT:Site Zone (ITSP 4.0)

DEPRECATED IN 7.0
Address Details (comprised of):

Street
Country
State/Province
City
Zip/Potal Code
Time Zone
SIT:Site Company
Association
Company
Region
Site Group
Site ID
N
Site Zone
Site ID
People
The People structure within the ITSM applications includes several forms that are
primarily accessed through the CTM:People form. The main form (or parent form),
People, is used to store an individuals contact information, their organization, and
location structures information.
31
ERD
Support Group Functional Roles
- for Support Staff only
- e.g. Change Manager, Support Group
Manager
Company
Region
Organization
Site Group
Department
Attributes
- General Information: Name, VIP
- IT/Skills, Access IDs, Travel
Profiles
Support Organization
Support Group
Financials
Site
- Cost centers (multiples)

- Hourly rate, Accounting code
- A person belongs to a Company and location

- A Support Staff belongs to a Support Group
CI Associations
Permission Groups
- associate to CIs with type: uses,

manages, supports, owns

- allows users access to various
modules
Approval Mapping
- Approval mapping for Change and
User Change Management
Login and Licensing

Information
- stores Login ID and password
- Fixed/Floating/Read license
Notification Preference
- System pre-defined and Userdefined notification preference
based on events
*
Application Permissions
CTM:People
1
*
1
Data Access
*
*
CTM:People Worklog
*
CTM:Support Group Association
*
AST:AssetPeople
*
FIN:CostCenterAssociation
CTM:People Permission Groups
*
CTM:SupportGroup
1
FIN:ConfigCostCentersRepository
Combination of Support Group and Person ID
CTM:SupportGroupFunctionalRole
32
CMDB
Classes
*
User
NTE:CFG-NotificationEvents
Support groups
Support groups play an important role in the ITSM 7.0 application infrastructure.
They are used to define groupings of back-office staff, based on their skills.
Support groups are also used as the initial assignment for a incident, problem, or
change request.
The Support structure can differ from the organization structure.
A support staff member can belong to many support groups.
Vendor support groups can be defined to support external assignment of tickets.
The Support Group role must be specified for information only; there is no
associated workflow.
ERD
From a data model standpoint, the Support Group model is based on the
COM:Company form to hold the support company data, and the
CTM:SupportGroup form to hold the definition of the support group. The
relationships are defined using query menus on the CTM:SupportGroup form. The
Organization value is an attribute on the CTM:SupportGroup form. The menu that
displays the organizational values performs a query against the CTM:Support
Group form to display the available organizations.
Support company
Organization
Support group
33
Support Group ERD

COM:Company
*
1

*
CTM:Support Group
CTM:Support Group Alias

11
1
1
CTM:Support Group Assignments
CTM:Support Group On
-Call
*
CFG:Approver Lookup
CTM:SupportGroup form
Categorization
The categorization structure in ITSM 7.0 is primary to many different functions.
Categorization structures are broken into two distinct components: operational
categorization and product categorization.
34
Operational c ategorization
The operational categorization structure is a three-tier structure defined for
categorization of what work is being done for a particular incident, problem, known
error, change request, or task.
This structure is also used to qualify reporting in the system, qualify how groups
and support staff get assigned, and routing of approvals.
Product categorization
ERD
PCT:Product Catalog
PCT:ProductAlias
1
1
*
*
*
PCT:ProductCompanyAssociation
PCT:Product ModelVersion
/
1
*
PCT:ProductModelVersionPatch
Operational categorization
CFG:Service Catalog
CFG:Service Catalog Association

1
35
CFG:Service Catalog
Categorization ID
Categorization Tier 1
Description
Status
CFG:Service Catalog Assoc

1
Categorization ID
Company
Status
Notification Engine
The Notification Engine provides a back-end workflow model for defining which
notifications should be sent, based on different events in the application.
Support staff use the NTE:CFG-NotificationPreferences form to define which
notifications they want to receive. This is exposed on the People form. Included
predefined notifications can be turned on or off in the user interface.
Design
The following diagram describes the flow of the Notification Engine. The
Notification Engine is built using AR System workflow.
Calling applications pass information into the NTE:SYS:NT Process Control form,
indicating the application, who the notification should go to, and information about
the parent record. The workflow process determines if the notification is for a
group or an individual.
Individual processing gets the users notification preferences, ticket information, a
message from the message catalog, and then send the notification.
Group processing expands the group list to individuals, and then runs the same
individual process as described previously. The key difference is that the expansion
is pushed asynchronously to not have a performance affect on the calling
application, and is sent using escalation processing.
36
Process flow
Assignment
The assignment architecture for the ITSM suite is based on a two-phase concept.
The first phase is assignment of the support group; the second phase is assigning
the support technician using load balancing technology built into the Assignment
Engine.
Design
Phase 1: Support groups

The support group assignment phase is done using AR System workflow on backend tables.
The workflow looks into the CFG:Assignment form to determine the group to
assign, using four different inputs:
Organization
Location
Operational categorization
37
The CFG:Assignemnt form also defines the events in which the assignment should
occur. These events are based on the calling applications assignment needs. For
example, the Change Management application requires assignment for the change
assignee and the change manager.
Assignment rules are partitioned based on the tenancy that has been defined. Each
operating company can have its own set of assignment rules.
Phase 2: Individual Assignment

Individual assignment is done in phase 2, using the Assignment Engine.
Assignment rules are provided to support Number of Tickets Assigned, Round
Robin and Capacity process rules.
Round Robin assigns the record to the next person in line.
38
Number of Tickets Assigned rules assigns the record based on the person who
has the lowest number of records assigned.
Capacity uses a formula of the number of tickets assigned and a capacity factor
to determine total capacity, and assigns the record to the user with the lowest
capacity rating.
Assignment process definition:
The following qualification is used to find the set of people to apply load balancing
rules on:
($Assigned Group ID$ = 'Support Group ID') AND ('Profile
Status' = "Enabled") AND ('Assignment Availability' = "Yes")
AND ('Assignment Availability 2' = "Yes")
This query looks at the CTM:Ppl Search-SupportGrpAssoc form to find the

appropriate list of people based on the above qualification.
39
ERD
Request Form
Phase 2
Phase 1
Assignment Engine
CFG:Assignment
There are two phases in the assignment process. Group assignment is handled
within the application using CFG forms; individual assignment uses the
Assignment Engine.
Group assignment workflow:
Workflow referencing the CFG:Assignment form.
CFG:Assignment has four main areas:

EventType of assignment this assignment record is created for.
AssignmentSupport group that this assignment record would assign the
ticket.
CriteriaCriteria matching the tickets to find the assignment records.
SystemIdentifies if this assignment record is enabled for such systems.
40
On ticket submission and modification, workflow executes to reference the

CFG:Assignment form to find the support group to be assigned, based on
information on the ticket.
Individual assignment:
Before individual routing occurs through the Assignment Engine, a support

group must already be assigned.
The Assignment Engine routes tickets to individuals within the support group
using process rules of Round Robin, Number of Tickets, or Capacity.
Predefined rules and process are included with the product and are not intended
for user configuration (that is, it is a customization activity for professional
services, application administrators, or Assignment Engine administrators).
Each application is preconfigured for the Assignment Engine, using Round

Robin and the following systems rule form:
Incident ManagementHPD:CFG Rules (Configure Incident Rules)
Change ManagementCHG:CFG Rules (Configure Change Rules)
Problem Management, Knowledge, Known ErrorPBM:CFG Rules
(Configure Problem Rules)
Task Management System subsystemTMS:AssignmentConfiguration
On ticket submission or modification, workflow executes to use the Assignment

Engine to perform individual assignment routing, based on the process configured
in the systems respective rule forms.
BMC Remedy Change Management architecture

Change
Management
BMC Atrium CMDB
Task Management
DSL
Cost Subsystem
The Change Management application is designed to establish a standardized change

process to allow IT organizations to make quick decisions on risk, and assess the
impact of changes made to the production environment. The Change Management
features introduce efficiency and increase productivity by minimizing error-prone
processes and providing visibility to key performance indicators (KPIs). Features
also include metrics to determine if established service level agreements (SLAs) are
being met.
ITSM Foundation
SLM
Process flows
Information Technology Infrastructure Library (ITIL) is the foundation for
achieving the goals of the Change Management application. The following process
flow diagram illustrates the union between the ITIL process and Change
Management functionality.
41
C h a n g e M a n a g e m e n t P ro c e s s
e
g
n
a
h
C
r
e
t
s
e
u
q
e
R
e
g
n
a
h
C
r
e
t
n
e
m
e
l
p
m
I
e
e
n
g
i
s
s
A
e
g
n
a
h
C
r
e
t
t
a
M
t
c
e
j
b
u
S
(
1
C hang e
In itiatio n a n d
R ec o rd in g
4
Change
Im p lem e n ta tio n
3
Change
P la n n in g an d
S c h e d u lin g
)
t
r
e
p
x
E
2
R e vie w a n d
A u th o riz e
5
C hang e
C o m p letio n an d
C lo su re
r
e
g
a
n
a
M
e
g
n
a
h
C
e
g
n
a
h
C
r
e
v
o
r
p
p
A
/
t
r
o
p
p
u
S
e
c
i
v
r
e
S
r
e
h
t
O
s
e
s
s
e
c
o
r
P
y
r
e
v
i
l
e
D
P ro b lem
M anagem ent
In c id e n t
M anagem ent
R e q u es t
M anagem ent
C o n fig u ra tio n M a n a g e m e n t
,I
The Change Management process has five primary stages:
Initiate and record
Review and authorize
Plan and schedule
Implement
Complete and close
Each stage can consist of sub-processes to support putting the change on hold or
getting approval to move to the next stage. These sub-processes can be configured
in Change Management to be applicable at each of the primary stages. The
following sections give a brief description of each of the primary stages and the
features that support each stage. See the BMC Remedy IT Service Management 7.0
Configuration Guide for more information about configuring the system and the
BMC Remedy IT Service Management 7.0 Change Management Users Guide for
additional details about features that support each stage of the Change Management
process.
Initiate and record

This is the initial stage of the change management process and focuses on recording
the purpose of the change request, and on obtaining additional required information
needed to classify and route the request.
42
The primary sources of change requests are:
Problem Management, including the known error feature of Problem

Management
Incident Management
Service Request Management
The key features available in Change Management designed to facilitate this stage
of the process include:
Requester console interface
Auto assignment at the group and individual level
Support for multi-tier classification (product and operational catalogs)
Review and authorize

Once the initial request has been submitted, the next logical stage is review and
authorize. The purpose of this stage is for the change manager to assess the change
request, provide any additional information to add more context, and if required
initiate the corresponding approval process. This stage acts as the initial filter to
determine if the change request should continue to the next stage in the process.
The features in Change Management designed to facilitate this stage of the process
include:
Manager console
Risk assessment
Support for relating CIs from BMC Atrium CMDB
Integration to BMC Remedy Approval Server
Request acknowledgement flag
Plan and schedule

Once the change request has been approved for work to begin, the next stage is to
plan resources and schedules to ensure minimal impact to the production
environment. Once the planning and scheduling are complete, the change request is
subject to another approval process.
The features available in Change Management designed to facilitate this stage of
the process include:
Change calendar
Costing (budgeted)
Scheduling
Integration with Approval Server
43
Change templates
Integration to Task Management System

Task templates
Task viewer
Implement
This stage consists of executing against the plan and getting the work done.
The features available in Change Management designed to facilitate this stage of
the process include:
Support console
Task viewer
Costing (actual)
Work info
Complete and close

This is the final stage of a change request and indicates either that the change
request has been completed successfully or that is was canceled. All of the actual
data elements (time, cost, and so on) are rolled up and recorded.
ERDs
Many pieces of information support the change management process. This section
identifies the primary entities that are related to Change Management. First, some
common terms are defined to help classify how information is related to a change
request. You can relate data to a change request in three ways: association, linking,
and lookup.
Associations
Data that is associated is supported by a table that maintains a subset of information
for each record being associated to the change request. This information can come
from a variety of sources and is typically managed in other systems or subsystems.
This information can also be related to more than one change request. For example,
configuration items (CIs) are maintained and managed in the BMC Atrium CMDB.
When CIs are associated to a change request, a subset of information is stored as a
record in an association table and is kept in sync with the original record.
The subset of data typically includes a unique reference to the original record, a
brief description, and the status or equivalent representation of the condition of the
related data item. Again, the characteristic of an association table is that it is a
generic table that can contain related information from a variety of sources. The
following illustration provides an example of how information from three sources
44
(PBM:Problem Investigation, CFG:Broadcast, and TMS:Task forms) can be

represented in an association table.
Change Record
CID: 23
Assocation Table
ASID CID Description Status Other Data
T653 23 Task 12
WIP
X
B21 23 Broadcast 1 Active
Y
B83 23 Broadcast 2 Active
Z
P242 23 Problem A
Open
A
PBM:Prob. Inv.
PID: P242
CFG:Broadcast
BID: B83
BID: B21
TMS: Task
TID: T653
The association table is generally exposed using a table field on the request form.
The following illustration shows the association table in the Relationships tab of the
Change form.
45
Linking
Data that is linked uses foreign keys to establish a relationship to the parent
record. The change request acts as the parent record for most of the information that
is linked to it. This means that the unique change request ID or GUID is stored on
the related records. This is effective when the related data is normalized and
supports a parent child relationship.
Note: A GUID is a globally unique identifier. GUIDs are automatically generated
by the AR System server.
The following diagram illustrates how records in the
CHG:ChangeRequest_AuditLogSystem, CFG:Reminders, and CHG:WorkLog
forms are linked to the Change record by storing the unique change ID of 23 on
each of the related records in the corresponding forms.
Change Record
CID: 23
CHG:CR Audit
AID: 523
Fkey: 23
CFG:Reminders
AID: 284
Fkey: 23
Fkey: 23
RID: 295
Fkey: 23
RID: 841
CHG:WorkLog
WID: 523
Fkey: 23
WID: 284
Fkey: 23
In one case, the change request is the child record of the parent record. In this case,
the unique request ID would be stored as a data item on the corresponding change
request, as shown in the following illustration.
SRM:Request
RID: R46
Change Record
CID: 23
Fkey: R46
The difference between this way of relating information and association is that
there is no additional database table and the table field will contain only
46
information from one source. Despite this difference, a set of linked data will also
be represented in a table field on the Change form, as shown in the following
example.
Lookup
Data that is looked up is pulled into the record by storing a local copy of the
information that is being looked up on the record. In general, this data is not kept in
sync with the original source. However, integrity checks might be performed to
make sure that the data stored on the record is still a legitimate reference. For
example, when categorization information is looked up and stored on the change
request, if the original record is modified such that the categorization information
stored on the change request form is no longer valid, the following error message
appears if you attempt to update this change request:
The operational categorization information is invalid for
the specified company, <company name>. Use the menus to
select this information.
The following diagram illustrates information being looked up from the Categories
table and being stored on the Change record in fields Tier1, Tier2, and Tier3.
47
Change Record
CID: 23
Tier 1: Hardware
Tier 2: Desktop
Tier 3: Disk
Categories
CATID Tier 1
Tier 2
Tier 3
635 Hardware Desktop
Disk
243 Hardware Laptop Memory
902 Hardware Server CPU Card
Associated information ERD

The following items can be related to change requests by way of associations:
Incident Management items
Problem Management items

Investigation records
Known errors
Knowledge entries
Asset Management items

Configuration items
Outages
Other change requests
Definitive Software Library (DSL) items
Software library item
Tasks
Task
Task Group
LDAP
User instance
Group instance
48
Cost information
The following ER diagram illustrates how these primary data elements can be
related to the change request by way of the association forms (shaded).
ERD for CHG:Infrastructure Change - Associations
Incident Management
HPD:Help Desk
Problem Management
PBM:Problem
Investigation
LDAP
PBM:Known Error
TMS:LDAPUser
PBM:Knowledge
Database
TMS:LDAPGroup
Asset Management
AST:Configuration
PDL:Software
LibraryItem
CHG:Associations
AST: CI
Unavailability
CHG:Infrastructure
Change
AST:*
FIN:Costs
FIN:Association
CHG:Infrastructure
Change
TMS:Associations
TMS:Task
TMS:TaskGroup
Linked data
The following items can be linked to change requests:
Auditing
Risk information
Factors
Questions
49
Reminders
Impacted areas
Work-related information
Effort tracking
Tasks
Task
Task Group
User requests
Broadcasts
linked to the change request by the foreign key indicated. Note that in one case, the
change request is linked as a child of the SRM:Request records.
CHG:Change
Request Audit
CHG:ChangeRisk
FactorQuestionL
ookup
CFG:Reminders
CHG:ChangeRisk
Factors
CHG:Impacted
Areas
SRM:Request
Foreign Key:
SRInstanceID
TMS:Task
CHG:Infra.
Change Effort
Log
CHG:WorkLog
Foreign Key:
RootRequestID
CHG:Infrastructure
Change
Foreign Key:
Infrastructure Change ID
TMS:TaskGroup
Foreign Key:
Instance ID
TMS:FlowBuilder
50
TMS:Flow
TMS:SummaryData
CFG:Broadcasts
Data lookup
The following items can be looked up and referenced on change requests:
Operational categories
Tier 1
Tier 2
Tier 3
Product categories
Tier 1
Tier 2
Tier 3
Product Name
Model/Version
Manufacturer
Supporting resources
Requested By
Requested For
Manager
Assignee
Implementer
Locations
Region
Site Group
Site
51
looked up and stored as local data on the change request.
COM:Company
CTM:Support
Group
CTM:People
Requested By
Requested For
Manager
Assignee
Implementer
Operational Category
CHG:Infrastructure
Change
Product Category
Region/Site Group/Site
CFG:Service
Catalog
PCT:Product
Catalog
CTM:Region
SIT:Site Group
SIT:Site
52
Comprehensive ERD
Incident Management
LDAP
HPD:Help Desk
Asset Management
TMS:LDAPUser
AST:Configuration
Problem Management
TMS:LDAPGroup
PBM:Problem
Investigation
AST: CI
Unavailability
PDL:Software
LibraryItem
PBM:Known Error
CHG:Infrastructure
Change
AST:*
PBM:Knowledge
Database
TMS:TaskGroup
FIN:Costs
TMS:Task
FIN:Association
CHG:Associations
TMS:Associations
COM:Company
Requested By
Requested For
Manager
Assignee
Implementer
CTM:Support
Group
CTM:People
CHG:Infrastructure
Change
Foreign Key:
SRInstanceID
SRM:Request
CFG:Service
Catalog
Product Category
PCT:Product
Catalog
Foreign Key:
Infrastructure Change ID
Foreign Key:
Instance ID
Foreign Key:
RootRequestID
CTM:Region
SIT:Site Group
CHG:Change
Request Audit
CFG:Broadcasts
TMS:Flow
TMS:Task
SIT:Site
CHG:ChangeRisk
FactorQuestionL
ookup
CFG:Reminders
CHG:ChangeRisk
Factors
CHG:Impacted
Areas
TMS:FlowBuilder
TMS:TaskGroup
TMS:SummaryData
CHG:Infra.
Change Effort
Log
CHG:WorkLog
53
Main forms
The following table lists the main Change Management forms:
Form name
Type
Description
CHG:ChangeAPDetailSignature
Join
Supports integration to the Approval Server.
CHG:ChangeInterface
Join
Interface form for query and modify operations.
CHG:Associations
Regular
Stored related information.
CHG:ChangeInterface_Create
Regular
Interface form used for create operations.
CHG:CostAllocation
Regular
Supports integration to Cost Management subsystem.
Regular
Primary Change Request form.
CHG:Template
Regular
Change Request Template form.
CHG:WorkLog
Regular
Maintains Work Log entries associated with change

requests.
Change calendar
The CCM change calendar is a high-level console for managing CCM change
activities, intended to be used by enterprise-level CIOs and members of change
approval boards. From the calendar, these users can see a holistic picture of
changes occurring in the enterprise, as well as associated business activities or
events. Some of this information comes from Change Management and other
information through referencing objects in the BMC Atrium CMDB. Aided by
links to investigative and analysis tools, users will be able to better understand the
risk and impact of changes and to plan and make better decisions about changes,
considering the interdependencies that are made more visible through the calendar
console.
The calendars primary view is a calendar-like schedule display that shows a
focused view of related change requests, when they are scheduled to begin and end,
and related business activities and events.
A user can select criteria to limit change requests and business activities to view,
that is, filter the view. By changing these filtering criteria, a user can focus on the
items of interest. High-risk changes are highlighted. A user can drill down from any
change request or business activity to see more detailed information about the item.
This view is primarily for change approval board members.
54
Architectural overview
An architectural diagram and a brief description of the primary components are
included in this document only as a reference for how the data visualization field
must be leveraged to enable this functionality. It is important to note that the
underpinnings of how this functionality works. You should not customize this
functionality.
The change calendar is an AR System application component built with AR System
mechanisms where possible and with custom components where augmenting
functionality is required. The change calendar consists of a primary form and a
number of subsidiary forms for user dialogs and administration. Although the
change calendar is only required to be viewable by a browser client, building on
forms also enables viewing through BMC Remedy User.
The change calendar is intended for members of a change advisory board (CAB),
usually during a CAB meeting. As such, it is not required to scale to large numbers
of concurrent users. However, it must scale in its ability to handle large numbers of
change requests. This influences aspects of the design in an attempt to balance the
needs of users for a useful visual display of change request data with the need to
access all the data with reasonable performance.
55
The change calendar requires functionality not provided by the base AR System
platform. It displays change requests and scheduled business events similar to a
project management application displaying activities and tasks as a Gantt chart. In
this way, it differs from standard calendars found in personal productivity
applications. It can represent requested changes that take multiple days to execute
and show dependencies between changes in a more understandable way using a
Gantt chart representation. The calendar view is an AR System form view in which
the activities schedule and other custom controls are integrated into an
AR System form as a Data Visualization field. The calendar uses a plug-in API.
The Change Calendar plug-in consists of a set of Java and JavaScript components.
The Java components run in the AR System mid tier in the plug-in container as
add-on components running in the same web application context as the mid tier.
The mid tier deployment includes an additional JAR file after the Change
Management application is deployed.
Except for the plug-in interface to the plug-in container, the calendar charting
functionality is written as an embedded web application with no dependencies on
the mid tier other than those exposed through the plug-in container.
56
Browser
Calendar
Client Runtime
Script
AR System mid tier

Plug-in
Container
CCM Calendar
Calendar
Plugin
Request
Dispatcher
CSS Files
JavaScript
Files
BMC Atrium CMDB API
Event
Dispatcher
Renderer
Model
AR API
57
The Change Calendar web tier uses a component-based Model-View-Controller

(MVC) architecture. It consists of several components:
Calendar plug-in
This component provides the glue between the calendar and the AR System
form that contains it. It implements the interface that enables its rendered
content and behavior to be embedded in an AR System form as a Data
Visualization field. This is a new field type in AR System 7.0. Data
Visualization fields that delegate rendering to an associated plug-in registered
with the plug-in service.
Request Dispatcher
The Calendar plug-in delegates work to one of two controllers: Request
Dispatcher and Event Dispatcher. The Request Dispatcher controller dispatches
requests for the calendar view or for associated resources, such as CSS
stylesheet files, JavaScript files, and images. The plug-in delegates handling of
calls by the plug-in container to its processRequest method to a Request
Dispatcher. It acts much as a Servlet: examining the HTTP request, identifying
the action requested, extracting request parameters, and delegating the
rendering of the response to the appropriate view object. This controller
accesses data that matches the request parameters, and encapsulates it in a
model object that it passes to the view for rendering.
Event Dispatcher
The Event Dispatcher controller is delegated to handle events forwarded to the
plug-in by the plug-in container from the plug-ins browser client JavaScript.
Such events are used by the calendar to perform in-place updating of the
HTML page rendered in the Data Visualization field in the host AR System
form. Similar to the Request Dispatcher, the Event Dispatcher controller
retrieves the needed data and passes it as the model to the appropriate view
component for rendering. The Event Dispatcher implements a JavaScript and
XML (AJAX) style of web page updating. However, the format of the data sent
to the web server and returned as structured to be simple and efficient to
process in the browser. A simple structured string is sent from the browser, as
required by the plug-in interface. The return value is a string representation of a
serialized JavaScript object that can be deserialized by script in the browser
receiving the reply.
Renderers
The Request Dispatcher delegates the schedule chart construction, the
thumbnail calendar control, and the activity summary to view objects, which
then implements the renderer interface. View objects, in turn, accesses a model
object to get change request or business event properties. A number of
renderers render just a part of the composite view sent to the browser, such as
header-cells that label each day along the top of the calendar. These can be
thought of as sub-view renderers. Composite view renderers aggregate a set of
sub-views into a complete view (HTML page).
58
Chart model
Model classes encapsulate change request or business event data fetched from
the Change Management database. The model delegates data access to data
source adaptors, which call either the AR System API or the BMC Atrium
CMDB API to access data. All business rules are executed in the model.
Browser client
Think of the V in MVC as consisting of two parts: server-side view
components called renderers, and client-side web page components that proxy
the server-side components. The client runs in a browser and is a combination
of HTML and JavaScript (sometimes called DHTML) that manipulates the
HTML DOM and handles event-driven interactions with the user and the host
Data Visualization field and its owning AR System form. Proxies for serverside view and model objects are implemented in JavaScript. CSS is used
extensively to both lay out the page and to control how it looks. Since the Data
Visualization field that hosts it is implemented as an IFRAME element, a full
page is delivered to the browser.
Executive dashboard
The primary goal of the Change Management Dashboard is to help executive users
understand the trends relating to change configuration management, and to take
appropriate action to balance the flow. A dashboard view presents a set of metrics
or statistics that give a snapshot of the state of the change management process. A
user has a choice of which statistics to view. The user can select criteria that
focuses the view on the desired perspective, and can indicate how far back to look
at the data. Example statistics are the history of planned and unplanned changes
over one or several time ranges, the number of authorized changes over the last
week or month, the success rate of changes made for the last thirty days, and a
summary of costs of changes over the last fifty changes made. The CIO is the
primary user of this dashboard view.
59
CCM Executive Dashboard is developed using AR System Flashboard objects. The
CCM Dashboard is configurable, enabling executive users to select appropriate
flashboards to display on the Change Flashboard screen, along with a time period
that applies to all flashboards. This gives executives the flexibility to see what they
want.
The Change Management Dashboard component consists of three forms:
CFB:CCMFlashboard
This display form is divided into four sections: Overall Health, Customer Data,
Financials, and Operational Efficiency. Each section displays flashboards
related to these categories. The data displayed on the flashboard is gathered
from entries in the CHG:Infrastructure Change form.
CFB:FlashboardData
This is a back-end form used to save flashboard data. This form will save each
flashboard name, and metadata about each flashboard, such as the qualification,
to facilitate dynamic filtering.
CFB:FlashboardUserView
With this form, users can configure the default flashboards that are displayed.
60
Subsystem integration
The following subsystems are used by Change Management:
Requester Console
Cost Management
Service Level Management (SLM)
BMC Atrium CMDB
Requester Console
The requester console provides the front-end interface for users into the Change
Management application.
The integration:
Uses the SRMS framework in the Requester Console to create change requests.
Updates change information using the work log.
Has an interface back from the change to the request that is stored in the
Requester Console.
Updates the status of the request to match the status of the change request, and
makes visible Work Info entries.
The Requester Console interacts with Change Management using the Change
Management interface forms.
Cost Management
Change Management uses the Cost Management subsystem to track costs
associated with Change Requests.
The integration uses the common cost creation dialog box that is provided by the
Cost Management subsystem. The table field on the CHG:Infrastructure Change
form integrates with the FIN:CostAssociatonJoin form to display cost data related
to an incident.
SLM
Change management integrates with the SLM application to provide service level
definitions for resolution and response time for change requests.
When SLM is installed, a tab on the CHG:Infrastructure Change form is enabled,
showing the service targets and milestones that are associated to an Change
Request.
61
In addition to the user interface integration, the Change Management application

also ties into the definition structure of SLM. SLM has a plug-in architecture for
helping users define terms and conditions, and measurements for a service target.
Change Management provides a user interface for this SLM plug-in architecture to
make it simpler for users to build qualifications using a query-by-example (QBE)
model.
BMC Atrium CMDB

Change management integrates to the BMC Atrium CMDB using relationship
tables. From the Change Management user interface, users can search for CIs and
relate CIs to an incident.
62
Interfaces
Interfaces to Change Management include interface forms and web services.
For more information, see the BMC Remedy IT Service Management 7.0
Integrations white paper.
Interface forms
Two interface forms for Change Management support basic create, modify, and
query operations:
CHG:ChangeInterface_Create
This is a regular form and interfaces with the primary Change form,
CHG:Infrastructure Change. This interface form is the integration point for
external systems to create new change requests.
CHG:ChangeInterface
This form is a self-join form of the primary Change Management form,
CHG:Infrastructure Change. This interface form is the integration point for
external systems to query or modify change requests.
These interface forms contain all necessary fields from the base change request
form, CHG:Infrastructure Change, required to support receiving input from an
external source. The command field, z1D_Action, is used where necessary to
invoke the action that is requested by the external system (submit, modify, and
create).
All of these operations can be invoked by accessing these interface forms directly.
Access to these forms has also been expanded to support interactions using web
services.
Web services
The submit, modify, and create operations are also supported using web services.
The following three diagrams illustrate how the create (submit), modify, and
query/query list operations are supported.
Create operation
For a create operation, a record is submitted to the CHG:ChangeInterface_Create

form and the command CREATE is supplied in the zID_Action field along with
any other relevant data values mapped to the exposed data fields. This triggers a
series of filters to process the record and stage it to be submitted to the base change
management form, CHG:Infrastructure Change.
63
After the record has been successfully created in the base Change Management
form, the new ID is returned.
An escalation will clean up and delete old staged create records from the
CHG:Interface_Create table and form.
Modify operation
For modify operations, the self-join form CHG:ChangeInterface is used. The record
ID of the change request to be updated is required.
64
In addition, when using web services to update all of the fields on the Change
Request form must be updated. Any field with a value of Null is set to a Null value.
Query and query list operations
The self-join form CHG:ChangeInterface is also used for the query operation. The
record ID or a query list qualification is required to retrieve either an individual
change request or a list of requests.
65
Permission model
In ITSM 7.0, permissions have two levels: AR System permission groups, such as
Change User, Change Submit, and Change Master, and functional roles. The
AR System permission group is not as relevant for the ITSM applications because
the ITSM applications use the General Access permission group across fields on
the forms. These groups are primarily used to provide functionality that a group can
access. For example, Change Submit will have less functionality compared to
Change User. All functionality based on permissions is implemented through
workflow. Functional roles enable the functionality to be further refined within a
permission group. Again, this is implemented through workflow.
The following example shows the difference between a person having Change User
permission with no functional role compared with having functional roles:
66
If a user has Change User permission with no role, this person has access to almost
everything (including the risk compute button, costing, and the calendar) on the
Change form, but has the following restrictions:
Limited ways to move from one status to the next. This user does not have
access to the states between Request for Change to Scheduled and also cannot
close out the request.
Cannot reassign the change manager and change assignee. Can manually
reassign the change implementer.
Cannot modify the effort logs for the change manager and change assignee, but
can create and delete the entries for change manager and change assignee.
If a user has Change User permission with Change Assignee role, this person has
the following restrictions:
Cannot reassign the change manager. Can manually reassign the change
assignee and implementer.
Cannot modify the effort logs for the change manager, but can create and delete
the entries for the change manager.
A user with Change User permission and a Change Manager role has access to all
functionality.
A Change Master is someone who has the access of a person with Change User
permission and Change Manager functional role across different support groups. A
Change Manager can also define approval mappings and change templates for his
or her support group.
A person with Change User permission (with or without a functional role) can work
only on the change requests that are assigned to his or her support groups. A person
with Change Master permission can work on any change request that he or she can
access, whether or not the change request belongs to the support group that the
request is assigned to.
BMC Remedy Asset Management architecture

Asset
Management
BMC Atrium CMDB
DSL
The Asset Management application lets IT professionals track and manage

enterprise configuration items (CIs)and their changing relationshipsthroughout
the entire asset life cycle. Asset Management tracks contracts, financial costs,
software licenses, outage indicators, and more for the CI information stored within
the BMC Atrium CMDB 2.0 application.
Cost Subsystem
ITSM Foundation
SLM
As part of the BMC Remedy ITSM Suite, Asset Management is integrated with
BMC Remedy Service Desk (which contains the BMC Remedy Incident
Management and BMC Remedy Problem Management applications), BMC
Remedy Change Management, and BMC Service Level Management, and offers
flexibility to support customized business processes.
67
Process flows
ITSM configuration management process overview
1
Configuration
management
planning
2
Configuration
identification
3
Configuration
specifications
4
Configuration control
5
Configuration
audit and
verification
Service support,
service delivery,
and other related processes
Configuration auditor
Asset manager
CMDB
RFC
Asset
Management
Change
Management
Incident
Management
Asset
Management
Incident
Management
Change
Management
Change
Management
2004 BMC Software, Inc. All rights reserved.
User interface
The user interface for Asset Management has two components. Components that
are specific to Asset Management are the user interfaces for the consoles and the
non-BMC Atrium CMDB forms. In addition, a generic user interface is on top of
the BMC Atrium CMDB. This user interface exposes the BMC Atrium CMDB data
to a user interface that connects the BMC Atrium CMDB data to other aspects of
Asset Management and other applications in the ITSM suite.
The BMC Atrium CMDB user interface is provided with all of the ITSM
applications. In the absence of the Asset Management application, this user
interface provides a view into the BMC Atrium CMDB so that CIs can be tracked
and related to other ITSM applications. When Asset Management is installed, the
user interface is extended to also contain links to specific Asset Management
functionality, such as contracts, depreciation, and procurement.
68
User Interface Forms (Joins)
Object1 : AST:ComputerSystem
Join
BMC Atrium CMDB Class Forms

BMC:CORE:BMC_ComputerSystem
Asset Management and the BMC Atrium CMDB

Asset Management is tightly integrated with the BMC Atrium CMDB as the
underlying data model to store details about the configuration items that are being
managed by Asset Management, and their relationships.
The BMC Atrium CMDB supports the concepts of reconciliation IDs and sandbox
functionality. This affects the overall structure of how data flows and is related to
other data in the ITSM suite.
Reconciliation ID
The BMC Atrium CMDB is structured as a model where data can be partitioned
across multiple data sets. For example, one dataset can hold raw data that is
discovered by a discovery tool, and another dataset can hold data that describes
future states of a CI. In each of these datasets you might have a different view of a
CI, and the data being stored about that CI. The BMC Atrium CMDB uses the
reconciliation ID to identify a CI in the same way across multiple datasets. When a
CI is identified by the reconciliation engine, it assigns a reconciliation ID to the CI.
Since the reconciliation ID is the only identifier that can define a particular CI, that
value is used to relate a CI to other data in the ITSM suite, such as incidents,
problems, and change requests. To view a snapshot of a CI in a particular dataset,
the ITSM applications provides mechanisms to define the dataset that a user wants
to view. These mechanisms are included in the query qualification that is used to
find a CI in the BMC Atrium CMDB.
69
Sandbox
Datasets are not only used to store raw discovery data, they are also used in the
system to be a flow through mechanism for updating the golden datasets of CI
data in the BMC Atrium CMDB. This flow through mechanism provides a layer of
control over what data is updated in the golden dataset in the BMC Atrium CMDB.
Reconciliation rules control what data is allowed to be updated and from what
source.
Asset Management provides a way to configure the system so that any updates to
an CI go through the sandbox dataset, and are reconciled against other data in the
system prior to being updated in the golden dataset. This keeps users from updating
data in the Asset Management application that should not be updated in the
production BMC Atrium CMDB.
The flow of the dataset workflow is as follows:
ERD
The Asset Management application key data model components are from the BMC
Atrium CMDB. The BMC Atrium CMDB provides the data model for all of the CIs
tracked by Asset Management.
In addition to the data that is stored and managed in the BMC Atrium CMDB for
CIs, Asset Management also provides additional data tables and structures to track
70
asset-specific data. These include contracts, purchasing, and standard

configurations. Following is a full ERD showing a typical asset interface on top of
the CMDB Computer System class, and how it relates to other data being stored by
Asset Management.
Asset Management full ERD

The BMC Atrium CMDB is built around a core data model with extensions. Asset
Management extends the BMC Atrium CMDB with additional classes and
attributes that are specific to Asset Management. You can find these in the CMDB
Data console by looking at the name spaces. Find the Asset Management
extensions in the CMDB Class Manager. You can see in the following Class
Manager Console that three classes are that are added by Asset Management to the
BMC Atrium CMDB data model.
Class Manager Console
71
Asset Management ERD
UI Joins on top of CMDB
Contracts
1
1
1
CMDB Classes
*
*
AST:ImpactedAreas
AST:AssetSupport
AST:AssetWarranty
AST:CI Unavailability
AST:CMDB Associations
AST:AssetSoftware
*
AST:Schedule Assocations
FIN:CostAssociation
AST:AssetCost
*
AST:WorkInfo
*
AST:Asset Lease
AST:AssetPeople
AST:ScheduleCriteria
FIN:Costs
AST:AssetMaintenance
CTM:People
Integrated Systems
HPD:Help Desk
PBM:Problem Investigation
*
*
PBM:Known Error
TMS:Task
72
Asset Management system forms

Component
Form
Comments
Main Asset Extensions
AST:AssetPeople
Manages relationships
between the CI and the
CTM:People form.
AST:BMC Atrium CMDB Associations
Manages relationships
between CIs and ITSM
forms.
AST:Inventory Transactions
Stores the inventory

transactions.
AST:InventoryQuantity
Stores the inventory

quantity.
AST:CI Unavailability
Tracks outages against a CI

that are scheduled or
unscheduled.
AST:Impacted Areas
Tracks the locations that are

affected by this CI having an
outage.
AST:Schedule Association
Manages the relationships

between a schedule and the
CIs this schedule is for.
AST:Schedule Criteria
Defines the schedules.
AST:Configuration
Defines the standard

configurations.
AST:AUD_AssetAssociations
Association table used to

link standard configurations
to the deployed CIs.
AST:AdditionalData
Lets you add name and

value pairs data to a CI.
AST:AssetLease
Join between the lease

extension and the contract
subsystem to display
leases.
AST:AssetLease_
Lease extension to the

contract subsystem.
AST:AssetMaintenance
Join between the

maintenance extension and
the contract subsystem to
display maintenance
contracts.
73
Component
Form
Comments
AST:AssetMaintenance_
Maintenance extension to
the contract subsystem.
AST:AssetSoftware
Join between the software

license extension and the
contract subsystem to
display software contracts.
AST:AssetSoftware_
Software license extension

to the contract subsystem.
AST:AssetSupport
Join between the support

contract extension and the
display support contracts.
AST:AssetSupport_
Support contract extension

AST:AssetWarranty
Join between the warranty

contract extension and the
display warranty contracts.
AST:AssetWarranty_
Warranty contract extension

AST:AssetCost
Stores depreciation
schedules.
AST:AssetCostDepreciationHeader
Stores the details about the

type of deprecation models
being used.
Asset Purchasing
AST:PurchaseLineItem
Line items for the purchase

orders and requisitions.
Asset Purchasing
AST:PurchaseOrder
The holder of the purchase

order.
Asset Purchasing
AST:PurchaseRequisition
Holds the details on the

purchase requisition.
Asset Purchasing
AST:PurchaseReturn
Holds the return orders.
Software license management

The software license component of Asset Management is designed to automatically
link software instances with the contracts that describe the licenses that have been
purchased for those software instances.
The link is based on the normalization of the software instances by using the
definitive software library (DSL) and the underlying product dictionary that is
74
provided with the DSL. This enforces consistency when software instances
populate the BMC Atrium CMDB.
Contracts are tied to the appropriate DSL entries for the software. When a software
instance is generated, the system checks if there is a contract associated with that
type of software. If so, a relationship is automatically created to that software. The
system also automatically decrements the number of available licenses. If there are
no licenses available, or if a contract is not found for software that requires a
contract, an exception entry is created. The exception entry can then be assigned to
the asset manager to determine a course of action, which might mean purchasing
new licenses, harvesting existing licenses, and so on. The exception is managed by
the system until there are an appropriate number of licenses available to keep the
contract in compliance.
The following diagrams describe the flow and forms that comprise the software
license management component of Asset Management.
PDL:Product Dictionary (Join)

PMVInstance ID
ProductCompanyAssociation Instance ID
AST:ProductDictionarySearch
AST:Contract _PD_Relationship
Product ID
Product Instance ID
Model/Version ID
PMVInstance ID
Contract ID
Contract Instance ID
ProductCompanyAssociation Instance ID
AST:AssetSoftware (Join)
Contract Instance ID
75
Discovery
AST:ConfigLicenseMgmt
BMC:BMC_AssetBase
AST:Contract_PD_Relationship
AST:LicenseMgmtEngine
PDL:Product Dictionary
Contract/Asset
Relationship form
(AST:CMDB
Association)
AST:LicenseMgmtIncludeClass
Contains a list of CI classes that are used by the AST:ConfigLicenseMgmt

form to limit the CI classes processed by the License Management Engine.
The user interface to add to this list is exposed as a table field in the
AST:ConfigLicenseMgmt form.
A list of classes is predefined and shipped with the product.
AST:ConfigLicenseMgmt
Users with Asset Config permission can access this form.
76
Contains configurable rules for the License Management Engine.
It can also be accessed from the Application Administration Console.
The following table describes the fields in this form.

Field
Description
Status
Enables or disables the rule.
Company
Specifies which company uses this rule. A global rule applies for all
companies.
Repository
Specifies the data repository the License Management Engine should use
to for a lookup to match the CIs product categorization. In ITSM 7.0, only
DSL is supported. DHS is included for future implementation.
Include Classes table
Allows for a list of classes to be added to the configuration record. The

License Management Engine processes only CI Classes that are included
in the configuration and ignores classes that are not listed.
Create Exception
When set to Yes, creates an exception record for CIs for which no
matching contracts were found.
DataSetID
Contains the name of the reconciled dataset this rule applies to. If left
NULL, it assumes the rule applies to all datasets.
Notify Group?
Yes or No flag to indicate whether a notification should be sent to the

configured support group when a CI exception has been created. A
notification is sent once per night (escalation process). Only one
notification is sent per configured rule, that is, you might have many CI
exceptions per rule but only one notification is sent for that rule.
77
Field
Description
Support Company,
Support Organization,
Group
Fields to indicate what support group is defined as the notification group

for the given configuration rule.
AST:LicenseMgmtEngine
Back-end form that process incoming software CI records (reconciled) from
BMC:BMC_AssetBase. This form relates the CI to appropriate contracts when
rules in the AST:ConfigLicenseMgmt form are verified.
AST:LicenseMgmtException
A record is created in this back-end form when CIs were not successfully related to
contract. Records are created here only if configured to do so in the
AST:ConfigLicenseMgmt form.
AST:ManageLicenseMgmtException
A join form between the AST:LicenseMgmtException and BMC:BMC_AssetBase
forms. This form serves as the primary user interface for users to manage records
that are unsuccessfully processed by the License Management Engine. This user
interface is accessed from the Asset Management Console by clicking the Manage
Contracts link under General Functions, and then selecting License Management
Exception.
Nightly escalations evaluate records in this form for action:
1. If Status = Completed and Exception Decision = Process CI,
then process the CI through the License Management Engine for relating to a
contract. This action assumes that an asset administrator has made sure that a
licensable product has been linked to a contract so that the License
Management Engine can successfully process the CI.
2. If Status = Completed and Exception Decision = Delete, then the exception is
deleted. This means that the asset administrator has determined that the CI does
not need to have contracts related to it.
Only users with Asset Admin permissions can access this form.
Row-level locking by the Company field has been implemented on this form. The
Company field controls who can see exception records. If you have unrestricted
access defined in the People form, then you can search for all records.
78
Procurement
Asset Management contains a procurement process that handles the full process
from requisition to order, to receiving and returns.
The procurement process starts with a requisition. Requisitions are requests from
users for the things they want to purchase. Attached to a requisition is a set of line
items. These line items define each of the individual items that need to be
purchased. The requisition provides the processes around getting the line items
priced correctly and getting the appropriate approvals needed before orders can be
sent to vendors.
After the requisition is approved and the line items are priced, then the appropriate
orders are automatically generated. The orders are generated based on the vendors
for each of the line items. One order is created for each vendor, with the appropriate
line items attached.
From a data model standpoint, the line items are shared between the requisition and
the orders generated from that requisition.
When orders are received, the line items are updated with the received value, After
all line items are received the order is considered closed. Once all of the orders
generated from a requisition are received, the requisition is considered closed.
79
The main forms that make up the procurement component are:
AST:PurchaseRequisitionHolds the details about the requisition and the

user who is requesting the items. It also "drives" the process for getting the
requisition approved.
AST:PurchaseOrderHolds all of the orders that have been generated.
AST:PurchaseLineItemHolds each of the line items. The line items are

shared between the requisition and the order. The line items also contain the
information about if the item has been received. If ordered in bulk quantities,
the line items show how much has been received and how much is outstanding.
AST:PurchaseReturnHolds any returns that might have been made and

gives the reason why. It helps generate the appropriate documentation for the
vendor to be able to return the item, and also is tracked as part of the order.
AST:PurchaseRequisitonWorkLogContains the work notes that have been

attached to the requisition.
AST:PurchaseRequisition Requisition Instance ID

AST:PurchaseRequisitonWorklog
FK:
AST:PurchaseOrder
1
1
1
FK: Requisition Instance ID
FK: Order Instance ID
AST:PurchaseLineItem
FK: Line Item Instance ID

0..1
AST:PurchaseReturn
0..1
Contracts
Asset Management extends the contract subsystem to provide detailed contract
functionality for Lease, Warranty, Support, Maintenance, and Software License
Management.
Each type of contract also has relationships with the following forms:
80
CTR:ContractPaymentsProvides information about the payments made

against a contract.
AST:WorkLogTracks work notes against a contract.
CTM:PeopleHolds the contacts for a contract.
Relationship table AST:CMDB Associations to the BMC Atrium CMDB

formsLinks contracts to CIs.
Warranty contracts
*
FK: Serveral Companies Names
COM:Company
CTR:ContractPayments
FK: Instance ID
*
AST:WorkLog
FK: Instance ID
*
Child Contracts
AST:AssetWarranty
1
*
*
FK:CompanyName
1
CTM:People
Join Between AST:Warranty_ and CTR:ContractBase

*
*
Reconciliation ID
subsystem
BMC Atrium
CMDB Forms
CTR:ContractBase
Shaded box = Contract subsystem provided
81
Support contracts
COM:Company
FK: Instance ID
*
AST:WorkLog
FK: Instance ID
*
Child Contracts
AST:AssetSupport
1
*
*
CTM:People
FK:CompanyName
1
Join Between AST:Support_ and CTR:ContractBase

*
*
CTR:ContractBase
82
Reconciliation ID
subsystem
CMDB Forms
Lease contracts
COM:Company
FK: Instance ID
*
AST:WorkLog
FK: Instance ID
*
Child Contracts
AST:AssetLease
1
*
CTM:People
FK:CompanyName
1
*
Join Between AST:Lease_ and CTR:ContractBase

*
Reconciliation ID
*
subsystem
Top Package::CMDB Forms
CTR:ContractBase
*
End Of Lease Support
*
In addition to the basic structure of the Support and Warranty contracts, Lease
contracts also have a tie to the Change Management application to provide support
for end of lease activities.
83
Maintenance contracts
*
COM:Company
FK: Instance ID
*
AST:WorkLog
FK: Instance ID
*
Child Contracts
1
*
AST:AssetMaintenance FK:CompanyName
CTM:People
1
*
Join Between AST:Maintenance_ and CTR:ContractBase

*
Reconciliation ID
*
CTR:ContractBase
84
subsystem
Software contracts
COM:Company
FK: Instance ID
*
AST:WorkLog
FK: Instance ID
*
Child Contracts
1
*
AST:AssetMaintenance FK:CompanyName
1
CTM:People
Join Between AST:Maintenance_ and CTR:ContractBase

*
Reconciliation ID
*
CTR:ContractBase
subsystem
AST:Keys and Versions

*
Licenseable Product
AST:Contract PD Relationship
*
Software contracts provide additional relationships to the PDL:ProductDictionary

to represent the normalized product names to link to this contract when they are
entered in the BMC Atrium CMDB. The Software License Management
functionality handles that linkage (see Software License Management section).
Standard configurations
Standard configurations define what type of software or hardware a particular
group is entitled to. The configurations are stored in the AST:Configuration form.
This form has a header component that describes the configuration and a line item
85
component that describes each of the components (hardware or software) that make
up this standard configuration.
Standard configurations functionality is integrated with Change Management to
facilitate the procurement process. The standard configuration can be compared
with what is available in inventory to determine which items are available and
which need to be procured.
Outages
The Asset Management application provides a data model of storing planned or
unplanned outages against a CI. This information is stored in the AST:CI
Unavailability form. Scheduled outages automatically generate time segments in
the AR System Business Time subsystem. This information is then made available
to the change management process and other processes to understand when
scheduled outages have been made against a particular CI.
The outage model is also where Service Level Targets are integrated into the Asset
Management application. Information about service targets that have been defined
for a particular CI and the status of those service targets is shown on the SLM tab.
86
CMDB
Classes
1
*
AST:CI Unavailbility
1
Business Time Shared Entity
87
Schedules
The Asset Management application provides a model for defining two different
types of schedules: Maintenance Schedules and Audit Schedules. The definition
of these schedules defines time periods in which maintenance, or audits need to
be done for a particular CI, or set of CIs. The information about the schedule is
stored in the AST:ScheduleCriteria form. The relationship to the CI is stored in the
AST:Schedule Association form. The schedules also integrate with the Change
Management application to manage the tasks and scheduling of the required
maintenance and audits.
BMC
Atrium
CMDB
classes
*
*
AST:Schedule Association
CHG:Template
1
1
AST:Schedule Criteria
The following subsystems are used by Asset Management:
Service Level Management
88
Cost Management
BMC Atrium CMDB
Cost Management
Asset Management uses the Cost Management subsystem to track costs associated
with CIs.
This integration uses the common cost creation dialog box that is provided by the
Cost Management subsystem. The table fields on CI user interface forms integrate
with the FIN:CostAssociatonJoin form to display cost data related to an CI.
SLM
Asset management integrates with the SLM application to provide service level
definitions for uptime related service targets associated with a CI.
When SLM is installed, a tab is enabled on AST:CI Unavailability form, showing
service targets and milestones that are associated to a CI.
When you define a Service Target against a CI, a user interface shows the values
that are tailored to the integration with Asset Management outages functionality.
89
Interfaces
Asset Management provides a set of interfaces that can be used to integrate with the
Asset Management application. These interfaces include the BMC Atrium CMDB
API, for creating, modifying, and deleting CIs and relationships.
BMC Atrium CMDB API

This API provides a defined and documented interface for creating, modifying, and
deleting configuration items and their relationships.
Interface Forms
AST:PurchaseOrderInterface formProvides the mechanism for querying data in
the Asset Management purchase order system.
Web Services
AST:PurchaseOrderInterface_WS formProvides the web service interface to
query data from Asset Management purchasing forms.
90
Permission model
BMC Atrium CMDB permission model
BMC Atrium CMDB 2.0 provides the following additions.
Addition of two new AR System computed groups for view data in the CMDB.
CMDB Data View.
CMDB Data Change.
Addition of two new AR System roles:
CMDB Data ViewOn every class attribute with View permissions.
CMDB Data ChangeOn every class attribute with Change permissions.
Additional existing permissions:
Read Security (dynamic group)On every class attribute with View

permissions.
Write Security (dynamic group)On every class attribute with Change

permissions.
Assign Group (field 112)On the RequestId with View permissions.
These permissions are mapped to the following roles that are defined for Asset
Management as a deployable application:
Asset Management roles
Asset ViewerRead access to CI data in Asset Management.
Asset UserRead access to CI data in Asset Management with the ability to

modify CI data that has been related to one or more super groups that are
associated to the Asset Management user.
Asset AdministratorRead/write access to CI data in Asset Management.
Purchasing UserRead/write access to purchasing data in Asset Management.
Receiving UserRead/write access to receiving functionality in Asset

Management.
Mapping of Asset Management roles to BMC Atrium

CMDB roles
CMDB Data ViewMapped to Asset Viewer and Asset User.
CMDB Data ChangeMapped to Asset Admin.
Write SecurityMapped to support group permissions.
91
Row-level security
Row-level locking is set at the Company level for all Asset Management forms. All
child records inherit the tenants of the parents associated with them. For individual
CI records, the tenancy is set by the value in the Company field on the CI, and by
the Used by, and Supported By people and groups associated to the CI.
Mapping of Asset Management roles to Asset

Management functions
The following table maps Asset Management roles to Asset Management functions.
Asset
Management
component
Asset
Admin role
Asset User
role
Asset
Viewer
role
Purchasing
User role
Receiving
User role
Manage CIs
Write access
to all CIs and
functions
Read access
Read
access
No access
No access
No
access
from
Asset
Management
console
No access
from Asset
Management
console
No Access
from Asset
Management
console
Write access to
CIs the user
supports.
Includes ability to
create:
Contracts
Configurations
Relationships
Costs
Schedules
Outages
Returns
Activities
Impacted
areas
Manage
Inventory
92
Access to all
inventory
functions
No access from
Asset
Management
console
Asset
Management
component
Asset
Admin role
Asset User
role
Asset
Viewer
role
Purchasing
User role
Receiving
User role
Manage
Contracts
Write access
to all
contracts
No access from
Asset
Management
console
No
access
from
Asset
Management
console
No access
No access
No access
No access
No access
No access
No access
No access
Write access
from CIs the user
supports
Read
access
from CI
forms
Manage
Configurations
Access to all
configuration
functions
No access from
Asset
Management
console
Read access
Write access
from CIs the user
supports
No
access
from
Asset
Management
console
Read
access
Read
access
from CI
forms
Manage Costs
Access to all
cost
functions
No access from
Asset
Management
console
Read access
Write access
from CIs the user
supports
No
access
from
Asset
Management
console
Read
access
Read
access
from CI
forms
Bulk Updates
Access to
bulk update
functions
No access
No
access
93
Asset
Management
component
Asset
Admin role
Asset User
role
Asset
Viewer
role
Purchasing
User role
Receiving
User role
Schedules
Access to all
scheduling
functions
No access from
Asset
Management
console
No
access
from
Asset
Manage
ment
console
No access
No access
Write access
to purchase
requisitions
(including line
items) that
are assigned
to the users
support group
No access
Read access
Write access
from CIs the user
supports
Read
access
Read
access
from CI
forms
Purchasing
Console
No access
No access
No
access
Write access
to purchase
orders
Receiving
Console
No access
No access
No
access
No access
Access to
receiving
functions
BMC Remedy Service Desk architecture

Service Desk enables IT to respond quickly and efficiently to conditions that
disrupt critical services by automating incident and problem management
processes. Service Desk acts as a single point of contact for user requests, usersubmitted incidents, and infrastructure-generated incidents.
High-level process flow

The service desk is made up of two distinct processes under ITIL: the incident
management process and the problem management process.
94
While the incident management process focuses on getting users up and running,
problem management focuses on determining the root cause, and using the change
management process to correcting the root cause of the problem.
End User
Request
Incident
Management
Process
Notified of
Completed Fix
Change
Management
To
Correct
Errors
Known
Error
Management
Problem
Investigation
Notified of
Completed Fix
Notified of
Completed Fix
BMC Remedy Incident Management

Incident
Management
BMC Atrium CMDB
Task Management
Cost Subsystem
ITSM Foundation
SLM
Incident managements primary goal is to get the user back to work as soon as
possible after an incident.
Incidents can enter the system manually or automatically. Users can create
incidents using the Requester Console. The Requester Console provides users a
simple interface for entering and managing their requests. Incident Management
integrates with the Requester Console to provide this interface. Support technicians
at the service desk can also manually enter incidents using the HPD:Help Desk
form. Several functions are provided to make entering incidents easier, including
templates, scripts, and automation.
Incidents can also be created automatically. The Incident Management application
provides integration interfaces that allow external applications to create, modify,
and query data in the Incident Management database. The integration between the
BMC Service Impact Manager and Incident Management is an example of an
95
external application that integrates with Incident Management to generate incidents

based on events in the service model.
Process flows
ITSM auto-detect incident management process overview

<Process Name>
Identification and
recording
(Classification)
<Function>
Yes
Incident
detected
Yes
Incident Auto
Detected?
Incident
closure
Resolution and
recovery
Self correcting?
Incident
Ccosure
No
Identification and
recording
(Classification and
initial support)
No
Investigation and
diagnosis
Incident
Detected
Call to
Service Desk
Resolution /
Workaround
Validation
Web
Self-Help
1
Incident
Detection and
Recording
4
Resolution and
Recovery
Incident
Recorded
2
Classification
and Initial
Support
Event Monitoring
Incident Detected
No Available
Resolution /
Workaround
Resolution /
Workaround
Validated and
Accepted
5
Incident
Closure
Resolution /
Workaround
Found
3
Investigation
and Diagnosis
Other Service Support /

Delivery Processes
Incident
Manager
Incident Queue
Incident Assignee Incident Assignee
Manager
(Tier 2/3/n)
(Tier 1)
(Optional)
Customer
ITSM manual incident management process overview
96
Capacity /
Availability
Management
Request
Management
Change
Management
Problem
Management
Problem
Management
Configuration Management
Service Level Management
Problem
Management
Change
Management
Problem
Management
Design overview
The Incident Management application follows the guidelines described in this
document for how systems should be developed. It is encapsulated in a deployable
application to provide the ability to abstract the permission model and to provide
for licensing.
Main forms
The main forms used in the Incident Management application are:
HPD:Help Desk
This form is the main repository for incidents. All incidents are stored in this form,
and all workflow around the lifecycle of an incident is associated with this form.
This form also provides the main user interface for support technicians who work
the details of an incident.
HPD:Template
The HPD:Template form provides the repository for incident templates. Incident
templates provide the ability to quickly fill in common data for common incident
types.
97
HPD:Template Associations
This form stores the relationships between a template and a CI. Templates provide
functionality to let you relate a template to a particular CI from the BMC Atrium
CMDB. This is useful if the template is against a service CI or a business process
CI.
98
HPD:TemplateSPGAssoc
This form provides the repository for the associations between a template and the
support groups that can use the template. Workflow shows only templates based on
a user being in a support group that is mapped to the templates the user wants to
use.
HPD:Worklog
This form is the repository for work log entries for the Incident Management
application. The tables on the HPD:Help Desk form look up information from this
table.
HPD:Impacted Areas
This form holds the relationship between an incident and the areas affected by the
incident. Impacted areas describe the location from the location structures that are
affected by an incident. This table can be populated by pulling the information from
a related CI, or by adding additional affected areas to the incident.
HPD:Associations
This form is the main association table for the Incident Management application. It
holds the relationships in the context of Incident Management.
The following subsystems are used by Incident Management:
Requester Console
Cost Management
Service Level Management (SLM)
BMC Atrium CMDB
99
Requester Console
The Requester Console provides the front-end interface for users into the Incident
Management application. The integration:
Uses the SRMS framework in the Requester Console to create incidents.
Updates incident information using the work log.
Has an interface back from the incident to the request that is stored in the
Requester Console.
Updates the status of the request to match the status of the incident, and makes
visible Work Info entries.
The following diagram describes the flow from the Requester Console to Incident
Management. The Requester Console interacts with Incident Management using the
Incident Management interface forms.
Requester Console
SRMS framework
C eate
Events
HPD:IncidentInterface_Create
CAI:Events
Get
Application Object
Event
HPD:IncidentInterface
or Set
CAI:EventParams holds the field mapping when

incident communicates with the SRMS framework
HPD:Help Desk
The Task Management System subsystem provides the ability to track specific
tasks that are required to resolve an incident. The integration to TMS provides the
ability to create ad hoc tasks.
From the Incident Management user interface, the integration is to the
TMS:AssocSummaryDataJoin form, which is a join between the TMS:Association
form and the TMS:SummaryData form. See the Task Management System section
for the TSM ERD.
100
Tasks are created in the TMS:Tasks forms. In ITSM 7.0, only integration for ad hoc
tasks is supported.
Service Desk
Incident Management
Problem Management
Ad-hoc creation only

TMS
TMS:Tasks
101
Cost Management
Incident Management uses the Cost Management subsystem to track costs

associated with incidents.
The integration uses the common cost creation dialog box that is provided by the
Cost Management subsystem. The table field on the HPD:Help Desk form
integrates with the FIN:CostAssociatonJoin form to display cost data related to an
incident.
SLM
Incident Management integrates with the SLM application to provide service level
definitions for resolution and response time for incidents.
When SLM is installed, a tab on the HPD:Help Desk form is enabled, showing the
service targets and milestones that are associated to an incident.
102
In addition to the user interface integration, the Incident Management application

also ties in to the definition structure of SLM. SLM has a plug-in architecture for
helping users define terms and conditions, and measurements for a service target.
Incident Management provides a user interface for this SLM plug-in architecture to
make it simpler for users to build qualifications using a query-by-example (QBE)
model.
103
BMC Atrium CMDB
Incident Management integrates with the BMC Atrium CMDB using relationship
tables. From the Incident Management user interface, users can search for CIs and
relate CIs to an incident.
When Asset Management is installed, this integration is extended by prompting
users to create outages against CIs they are relating to the incident. The outage data
is stored in the Asset Management application database, with relationships created
back to the incident.
104
ERD
Change Management
Problem Management
Lookup Data
PBM Problem
:
Investigation
PCT:Product Catalog
PBM Known Error
:
CFG:Service Catalog
SIT:Site
PBM Knowledge
:
Database
HPD:Help
Desk
Asset Management/
CMDB
:
AST: CI
Unavailability
HPD:Association
BMC:*
CMDB Classes
FIN: Costs
FIN: Association
CFG: Broadcast
Association
HPD:Help Desk
Foreign Key:
Request ID
TMS: Associations
(See Note)
(See Note)
CFG: Broadcast
HPD:HelpDesk_AuditLogSystem
CTM:People
CTM:Company
TMS:Task
Foreign Key:
Incident Number
(See Note)
Foreign Key:
Incident Number
HPD:ImpactedAreas
CTM:Support Group
HPD:Work Log
105
CTM:People
Used in various contexts, key back is the login ID
for each of these areas:
- Customer
- Contact
- Owner
- Assingee
- Vendor Contact
CTM:Company
Used in various contexts, key back is the
company name for each of these areas:
- Customer Company
- Contact Company
- Owner Support Company
- Assingee Support Company
- Vendor Company
- Company (also known as the operational
company)
CTM:Support Group
- Owner Support Group
- Assignee Support Group
Interfaces
Incident Management provides a set of interfaces that can be used to integrate with
the Incident Management application. These interfaces include a set of AR System
forms that provide the ability to create, query, and modify incidents. They also
include web services interfaces that are built on top of these forms to provide a
mechanism to interface with the Incident Management application using web
services.
106
The following interface flow diagram shows the basic flow of how an external
application would integrate with Incident Management.
Help desk ticket submit
ITSM
Creates an association
with a CI if a CI name
is specified
External
application
Creates staging
record using Help
Desk Submit web
service
HPD:IncidentInterface
(Staging form)
Processes
incoming
parameters
Association
forms
HPD:Help Desk
Creates Help Desk
record and Work Log
record
HPD:Work Log
Data flow direction
Interface forms
HPD:IncidentInterface_CreateInterfaces with the HPD:Help Desk form

to create incident tickets.
HPD:IncidentInterfaceSelf-join of HPD:Help Desk form for query and

modify operations.
Web services
HelpDesk_QueryList_ServiceQueries for multiple tickets in the

HPD:HelpDesk form.
HelpDesk_Modify_ServiceModifies a ticket in the HPD:HelpDesk form.
HelpDesk_Query_ServiceQueries for tickets in the HPD:HelpDesk form.
HelpDesk_Submit_ServiceSubmits a ticket in the HPD:HelpDesk form.
Licensing model
Incident Management licensing is enabled using the Deployable Application
mechanism in AR System.
107
Incident Management requires the following application-level and user-level

licenses:
Incident Management application license
Incident User fixed or floating user license for modifications on the HPD:Help
Desk form
Financial application license to access costing data
BMC Atrium CMDB application license to access the BMC Atrium CMDB
Permission model
The permission model of the Incident Management application has five basic roles:
Incident Viewer
Incident User
Incident Master
Incident Submitter
Incident Config
BMC Remedy Problem Management

Problem
Management
BMC Atrium CMDB
Cost Subsystem
Problem Management is focused on finding the root cause of an issue in the IT

infrastructure, and working to correct that known error.
Problem Management has three main components:
Knowledge
Problem investigation
Known error management
ITSM Foundation
Solution database
The problem investigation module of Problem Management is focused on
determining the root cause of an infrastructure problem.
The results of a problem investigation are:
108
Known errorsDescribe the root cause.

Knowledge solution entriesDescribe how to work around the issue and
potentially other incidents or problems to investigate.

Known error management uses the results from the problem investigation on the
root cause of an issue and provides the process around determining the fix for the
known error.
A known error management process could have one of the following results:
A change request to implement the desired fix.
Closing the known error as an accepted issue, with updates to the knowledge
database with steps to avoid the issue.
Solutions database
The solutions database provides a simple repository of potential solutions to
infrastructure issues. These might be workarounds or solutions to use in helping
users get around an issue. The data from the solutions database becomes an input
into a full knowledge management system with the use of the full BMC Knowledge
Management solution.
Process flows
Investigation
Initiated
Other Service Support /

Delivery Processes
Problem Manager
Problem Assignee
Requester
ITSM Problem Management Process Overview
3
Problem
Investigation
and Diagnosis
1
Problem
Identification,
Recording and
Classification
8
Knowledge
Identification
and Recording
5
Known Error
Identification
and Recording
4
Problem
Resolution and
Closure
6
Known Error
Classification
and
Assessment
7
Known Error
Resolution and
Closure
9
Knowledge
Validation and
Publication
2
Review
Incident
Management
Incident
Management
Change
Management
Change
Implemented
Incident
Management
Configuration
Management
(Mgmt Reports)
2004 BMC Software, Inc. All rights reserved.
109
Main forms
This section describes the main forms used in Problem Management.
PBM:Problem Investigation
This form is the repository for problem investigations. The problem investigation
lifecycle and processes around problem investigations are driven off this form. This
form is the main user interface for support technicians who work on problem
investigations
PBM:Investigation Associations
This form provides the repository for associations between problem investigations
and other records. It holds the context of the record being displayed.
PBM:Investigation Effort Log
This form provides a repository for the effort that has been put into determining the
root cause of a problem. It tracks the amount of time by user.
PBM:Investigation Work Log

This form provides the repository of work log entries associated with individual
problem investigations.
110
PBM:Known Error
This form is the repository for known error records. The known error management
lifecycle and processes around known errors are driven off this form. This form is
the main user interface for support technicians who work on known errors.
PBM:Known Error Associations
This form provides the repository for associations between known errors and other
records. It holds the context of the record being displayed.
PBM:Known Error Work Log
This form provides the repository of work log entries associated with individual
known errors.
Solutions database
PBM:Solution Database
This form is the repository for solution records. Solution lifecycle and processes
around solutions are driven off this form. It is the main user interface for support
technicians who work on solutions.
PBM:Solutions DB Alias
This form provides the repository for search keywords that are associated with a
particular solution. This information is available from solution search dialog boxes
to allow users to search by keywords.
PBM Solutions DB Associations
This form provides the repository for associations between solutions and other
records. It holds the context of the record being displayed.
111
ERD
Change Management
:Infrastructure
CHG:
:
Change
Problem Management
Lookup Data
PCT:Product Catalog
Incident Management
HPD:
PBM Problem
:
Investigation
Help Desk
PBM Known Error
:
CFG:Service Catalog
PBM
:
SIT:Site
Solution
Database
Asset Management/
CMDB
:
AST: CI
Unavailability
PBM Associations
:
BMC:*
CMDB Classes
FIN: Costs
FIN: Association
PBM:
Problem
Investigation
CFG: Broadcast
Association
Foreign Key:
Request ID
TMS: Associations
(See Note)
(See Note)
CFG: Broadcast
PBM:Problem_AuditLogSystem
CTM:People
CTM:Company
TMS:Task
Foreign Key:
Incident Number
(See Note)
Foreign Key:
Incident Number
112
PBM:ImpactedAreas
CTM:Support Group
PBM:Work Log
CTM:People
- Manager
- Assignee
- Requester
CTM:Company
- Requester Company
- Mannger Support Company
- Vendor Company
company)
CTM:Support Group
- Requester Support Group
- Manager Support Group
113
Change Management
:Infrastructure
CHG:
:
Change
Problem Management
Lookup Data
PCT:Product Catalog
Incident Management
HPD:
PBM Problem
:
Investigation
Help Desk
PBM Known Error
:
CFG:Service Catalog
PBM
:
SIT:Site
Solution
Database
Asset Management/
BMC Atrium CMDB
:
PBM
:
Known Error
Associations
AST: CI
Unavailability
BMC:*
CMDB Classes
FIN: Costs
FIN: Association
PBM: Known Error
CFG: Broadcast
Association
Foreign Key:
Request ID
TMS: Associations
(See Note)
CFG: Broadcast
CTM:People
(See Note)
CTM:Company
(See Note)
CTM:Support Group
TMS:Task
Foreign Key:
Incident Number
114
PBM:Known Error Work Log
CTM:People
- Manager
- Assignee
- Vendor
CTM:Company
- Mannger Support Company
- Vendor Company
company)
CTM:Support Group
- Manager Support Group
115
Change Management
:Infrastructure
CHG:
:
Change
Problem Management
Lookup Data
Incident Management
HPD:
PCT:Product Catalog
PBM Problem
:
Investigation
Help Desk
PBM Known Error
:
CFG:Service Catalog
PBM
:
SIT:Site
Solution
Database
Asset Management/
BMC Atrium CMDB
:
PBM
:
Solution
Associations
AST: CI
Unavailability
BMC:*
CMDB Classes
FIN: Costs
FIN: Association
PBM:
Solution
Database
Foreign Key:
Request ID
Foreign Key:
Assingee
TMS: Associations
CTM:People
Foreign Key:
Assignee Company
CTM:Company
Foreign Key:
Support Group
CTM:Support Group
TMS:Task
Foreign Key:
Incident Number
Interfaces
116
PBM:ProblemInterface_Create
PBM:ProblemInterface
PBM:Solution Work Log
PBM:KnownErrorInterface
PBM:SolutionsInterface
ITSM 7.0 subsystems

This section describes subsystems used by ITSM applications.
Command Automation Interface

The Task Management System (TMS) provides tasking capabilities to the Change
Management, Problem Management, and Incident Management applications, and
integrates with the BMC Configuration Management system using the Common
Automation Interface (CAI). The Service Request Management System (SRMS)
framework support the Requester Console, which is the front-end user interface for
Change Management and Incident Management. TMS and SRMS use the CAI to
communicate with ITSM applications.
The CAI subsystem provides a common infrastructure that can be shared across
applications including ITSM 7.0 applications and BMC Configuration
Management. The functionality of CAI is based on the current implementation for
SRMS framework command events and the requirements of TMS. The CAI
consists of three major blocks that result in event delivery to the target applications.
For ITSM 7.0, CAI is a back-end component that does not provide a front-end user
interface. Additional user dialogs can be created for each integrated component to
push data into the CAI forms.
Overview
This section provides an overview of TMS.
Definition phase: Application registration and command
definition
Application registration defines the integration attributes to the external systems,

such as application name, connection information, and interface form names.
Command definition describes the commands and the command parameters for
each integrated component. For example, the Requester console has defined a set of
commands for interaction with back-end applications. In TMS, a set of commands
is defined for interaction with BMC Configuration Management. In addition, the
CAI can include command parameter mappings to the registered applications.
Construction phase: Instantiation of the command definition
as events
Command events are instantiated based on the command definitions. The event is
constructed using the specific command name, and the command parameter values
are populated by the integrated components. For example, when the SRMS
117
framework needs to create a new back-end application request, it pushes a new

event record with the command name, SRM_OUT_CREATE_APP_REQUEST
(CreateAppRequest). It also pushes the event parameters for template ID and
service request ID using the appropriate run-time values. In TMS, when it needs to
construct a URL string to interact with BMC Configuration Management, TMS
specific workflow creates the appropriate event with the run-time parameter values
and formats the URL string accordingly. CAI provides the form structure and
generic workflow for command instantiation. Each integrating component must
implement the workflow to handle its specific commands.
Execution phase: Event delivery
The mechanism that delivers the command events to the target system depends on
the protocol used. For AR protocol, where the target is another AR System
application, the CAI event plug-in can be used. This plug-in creates the appropriate
records as specified in target information of the event. For URL protocol,
workflow sets the URL string to the appropriate view field for the browser. CAI
provides the generic event plug-in and each integrating component must implement
the workflow to handle the invocation of the plug-in, or use specific workflow for
the delivery. For ITSM 7.0, AR and URL protocols are supported.
Definition
1
Construction
Event Data Values

What
Command Content
How
Execution
5
RuntimeJust Do It
Command
2
ID
App Registry
Name
Protocol
Command
Param
Commands
Direction Op. Type
Parameters
Data Type
Done
Mode
ERD
A diagram of CAI follows that outlines the three phases for outbound commands:
definition, construction, and execution. Each event must have the following field
values:
Command nameName is defined in the command definition, with specific
naming convention.
118
TargetKeyword (SRMS, TMS, APP)APP means back-end application.

SourceKeyword (SRMS, TMS, APP)
Direction (Inbound or Outbound)Outbound means an event sent by SRMS
framework or TMS to APP.
Type (Create, Update, Get)Create means an entry will be created as part of the
event delivery. Update means an entry will be updated; Get means an entry will be
queried.
Depending on the command type, the CAI plug-in will create, update, or query an
entry from the interface form for all outbound commands. In general, the CAI plugin can be used by all events of AR protocol, and is most useful in scenarios where
dynamic fields are used. In ITSM 7.0, the SRMS framework is the only component
that invokes the CAI plug-in. TMS uses all URL-based commands and has
workflow that constructs the URL string based on the event parameters.
119
Definition
2 . Map command paramters for each

registered
1 . Register
CAI : AppRegistry
U1
U2
CAI :CommandParamMappin
InstanceID
AppRegistryName
ApplicationName
ApplicationInstanceID
Protocol
Connection Info
Interface Form Names
AppRegistryName
Command
CommandParam
AppInterfaceFormName
AppFieldName
AppFieldID
ParamType
ParamDataType
0 . Create commands and

command paramters
CAI : Command
U1
Command
Direction
OperationType
SelectionType
CAI :CommandParam
U1
U1
Command
CommandParam
Type
DataType
Mode
Construction
CAI : Event
CAI :EventParam
EventGUID
Event
Source
Target
SourceAppRegistryInstanceI
AOIGUID
TargetConnectionInf
RtnCode
RtnMsgCode
RtnMsg
MaxRetries
RetryCounter
Execution (outbound)
EventGUID
ParmName
ParamValue
ParamAttachmentValue
ParamType
ParamDataType
Push event and run time data to
event params (outbound )
SRMS
framework/TMS
Calls GetEntry to
get event values
Filter API Plug-in

Push event and event
params
App Interface Form
Mapped Param
120
AR System
workflow
Launch
Browser
The inbound events should be created in the event and event param forms by the
back-end applications. Workflow must be implemented to process the command
events by the target application, such as TMS. The workflow qualification should
be based on the values of TargetKeyword and Event.
For example:
TargetKeyword = SRMS
Event = SRMS_IN_APP_REQUEST_RESOLVED
121
The following high-level diagram shows the flow of inbound commands. In this
diagram, the Target is SRMS and the Source is APP, which means a back-end
AR System application.
Definition
2. Map command paramters for each

registered application
1. Register application
CAI:AppRegistry
U1
U2
CAI:CommandParamMapping
InstanceID
AppRegistryName
ApplicationName
ApplicationInstanceID
Protocol
Connection Info
Interface Form Names
AppRegistryName
Command
CommandParam
AppFieldName
AppFieldID
ParamType
ParamDataType
0. Create commands and

command paramters
CAI:CommandParam
CAI:Command
U1
Command
Direction
OperationType
SelectionType
U1
U1
Command
CommandParam
Type
DataType
Mode
Construction
CAI:Event
CAI:EventParam
EventGUID
Event
Source
Target
SourceAppRegistryInstanceID
AOIGUID
TargetConnectionInfo
RtnCode
RtnMsgCode
RtnMsg
MaxRetries
RetryCounter
Execution (outbound)
EventGUID
ParmName
ParamValue
ParamAttachmentValue
ParamType
ParamDataType
Push event and run-time data to
event params (outbound)
SRMS/TMS
Calls GetEntry to
get event values
FilterAPI Plug-in
Push event and event
params
App Interface Form
Mapped Param
122
AR System workflow
Launch
Browser
Component Design
Forms and plug-in

The CAI consists of the following forms and plug-in:
CAI:AppRegistry
CAI:Command
CAI:CommandParam
CAI:Event
CAI:EventParam
CAI:CommandParamsMapping
CAI:DefineCommandParameters
CAI:Plugin Registry
Filter API plug-in, caieventcmd.dll
All forms in CAI are back-end forms and each integrating component must provide
its own user interface for user updates to these forms. TMS contains front-end
forms that use workflow to push TMS data to the CAI:AppRegistry form.
CAI:AppRegistry
This form stores application interface information, such as interface form names,
connection data, and the protocol. Each integrating component, such as TMS, must
provide the user interface and workflow for updates to this form.
CAI:Command, CAI:CommandParam
These forms store command names and command parameters for each integrating
component. There is a one-to-many relationship between a command and a
command parameter. A command parameter cannot be used by more than one
command. Naming conventions must be used to allow generic qualifications for
event process filters, as in the following listed for the SRMS framework and for
TMS.
SRM_IN_[COMMAND_NAME]SRM inbound command.
SRM_OUT_[COMMAND_NAME]SRM outbound command.
TMS_IN_[COMMAND_NAME]TMS inbound command.
TMS_OUT_[COMMAND_NAME]TMS outbound command.
For localization considerations, command parameter names must use all uppercase
letters and with no spaces.
123
CAI:Event, CAI:EventParam
These forms store the event and related parameters. Each integrating component
must implement specific filter workflow to process its specific commands. Guides
should be used whenever possible to minimize undesirable filters being executed.
The following table shows naming standards and workflow order:
Component
Filter prefix name
Filter order range
CAI
CAI:
100-199
SRM
INT:CAISRM:
200-399
TMS
INT:CAITMS:
400-599
CAI
CAI:
900-999
Some exceptions might be required for certain filter order numbers. For example,
some CAI filters might fall between SRM and TMS range.
Each event record has a version number, which allows for compatibility between
different CAI and integrating components versions.
Workflow that processes the event should always set the Return Code field to
indicate success or failure.
This form defines the mapping between the command parameters and the backend
application. It also maps the fields to a command parameter, such as mapping a task
ID from the TMS:Task form, to a parameter in the generated URL. A command
parameter can be mapped to more than one backend application. The
SRMS_OUT_CREATE_APP_REQUEST commands command parameter,
APP_REQUEST_GUID, for example, is used by both Incident Management and
Change Management.
CAI:DefineCommandParameters
This is a front-end form used for adding commands and command parameters. It is
accessed from the Application Administration Console. Choose Foundation >
Advanced Options > Command Automation Interface - Define Command
Parameters.
CAI:Plugin Registry
To increase performance, the private queue and number of threads to be used for
the CAI plug-in are defined using this form. To use this feature, you must define a
private queue using BMC Remedy Administrator, and then update the CAI Plug-in
Registry with the queue number and number of threads.
124
Flow diagram
The following diagram illustrates the flow when interacting with the CAI.
1. Event is created in CAI:Events

form; parameters are pushed to
CAI:EventParams form
6. CAI plugin returns

status to
CAI:Events
form
Service Request
CAI:Events
2. When an entry is
created in the CAI:Events
form, the CAI plug-in is
called
CAI:EventParams
Main Plug-in
code
3. The CAI plug-in

creates an entry in the
request queue and
returns Status =
Running to CAI Events
form
Request queue
4. When a request
is added to the
queue, a signal is
issued to wake up a
thread in the thread
pool to process the
request.
CAI Plug-in
Thread Pool
5. CAI plug-in
creates Change
Request and/or
Incident
HPD:HelpDesk
125
Interfaces
CAI plug-in
The primary purpose of the CAI plug-in is to transmit events to other back-end
applications. Due to the dynamic nature of the field mappings for each command,
and because it is not possible to use workflow to push values to dynamic fields, the
CAI plug-in provides a mechanism to dynamically map data to fields. For example,
the command to create a back-end request consists of dynamic field values that can
be mapped to any field on the back-end interface forms. Additionally, the CAI
plug-in helps address issues that arise with incompatible permission models.
The following inbound and outbound commands are supported by the Filter API:
Command
Direction
Filter API
action
CreateAppRequest
Outbound
CREATE
GetAppRequestInfo
Outbound
GET
CancelAppRequest
Outbound
UPDATE
UpdateAppRequestWorkLog
Outbound
UPDATE
ActivateAppRequest
Outbound
UPDATE
AppRequestInProgress
Inbound
UPDATE
AppRequestResolved
Inbound
UPDATE
AppRequestCancelled
Inbound
UPDATE
UpdateSRWorkLog
Inbound
UPDATE
Decrypt Password
Outbound
DECRYPT
Web services
The web service setup for the CAI is a complex web service, which means it is
made up of multiple components and presented as a single interface. The two CAI
components: CAI:Events and CAI:EventParameters, are defined as a single web
service.
126
The following table summarizes the names of the operations, the base form the
operations function against, and the name and form types of the supporting
AR System forms that serve as the interface to these areas of the CAI.
Base form
Operation description
Operation
name
Interface form*
Form
type
CAI:Events (root)
Query individual event
OpGet
CAI:Events (root)
Regular
CAI::EventParams
Query list of entries
OpGetList
CAI::EventParams
Regular
Create CAI event and CAI

event parameters
Op Create
Note: The web services for these functions are directly connected to the base forms
using an XSD file. In a future release, an abstraction layer will be introduced in
front of these base forms to act as the primary interface for external systems.
This will enable making the maintenance and code updates to enhance
functionality of the CAI transparent to any external integrations. In addition, this
abstraction layer will make it easier to maintain backwards compatibility for
subsequent releases.
Permission model
The CAI has the Command Event Master role, which by default is mapped to the
Command Event Master group, and can be granted to users using the People form.
Only users in this group and AR System administrators can access the CAI forms
and update certain fields on them. For implementation of event error handling,
integrating applications must have the same group and role mapping.
For remote access using AR protocol, the remote AR System login must have
permission to create and update to the interface forms specified in the AppRegistry
form. Similarly, for the back-end application to send inbound commands to the
remote front-end application, such as TMS, the TMS AR System login must have
permission to create records in the event and event parameters forms. See the dataflow diagram for the integration points.
Contract Management
The Contract Management subsystem provides a generic contract for tracking basic
contract information and lifecycle. This system is used by Asset Management and
Service Level Management as a basis for their specific definitions of a contract.
127
ERD
Application specific contracts
Join
Contract Management subsystem

CTR:ContractBase
CTR:ContractAuditLogSystem
Interfaces
The Contract Management subsystem provides the underlying data and process
model for basic contract management. Applications extend the basic data model by
creating a join on top of the CTR:ContractBase form. This join includes a form that
contains data specific to the application and basic contract information.
This structure is used in the Asset Management and BMC Service Level
Management (SLM) applications.
Permission model
Contract Management permission groups are defined as computed groups in the
Group form.
Each Contract permission group is mapped to an Asset permission group to support
the deployable application functionality. To remove specific users from the
computed group, remove the Asset Management groups for each Contract
permission group to make each Contract permission group stand alone.
128
Each Contract Management permission group is mapped to an Asset Management

permission group, as shown in the following table.
Contract
Management
permission group
Asset Management
permission group
Access
Contract View Only
Asset Viewer
Read
Contract Full Access
Asset User, Asset Admin
Write
Contract Administrator (reserved for future use)
N/A
Write
Costing Management
The Costing Management subsystem provides functions required by the ITSM suite
for management of cost data. The costing model has two components: tracking of
costs, and chargeback calculations and reporting.
Each application uses Costing Management to track the costs related to the records
in the application. For example, Incident Management uses Costing Management to
track the various costs associated to incidents.
Asset Management also uses the chargeback functionality in Costing Management.
Chargebacks are roll ups of the costs that have been incurred over a period and
involved in the various cost centers in a company. The chargeback component of
Costing Management generates chargeback entries, lets the financial manager make
appropriate adjustments to the costs, and generates invoices to be sent out to the
individual cost centers.
Costing Management is designed to be completely standalone. The main form,
FIN:Costs, holds individual cost data. The relationships to the main records use
associations in the FIN:Associatons table. Costing Management also provides a join
between the FIN:Costs and FIN:Assocaitons tables to provide the query interface
for use by applications that integrate with the subsystem. This join is used by table
fields in ITSM applications.
The chargeback functionality is enabled by a filter API application. It is driven by
data in the chargeback forms that define the cost centers, how the cost centers are
allocated, and the dates for running chargeback reports. The result of the API run is
a set of chargeback entries. The chargeback functionality provides an adjustment
user interface that is used to adjust the chargeback costs, and a reporting user
interface to run invoices.
The costing forms and workflow are encapsulated in a deployable application. This
provides the ability to license and abstract the roles for the subsystem.
Costing Management has clearly defined interfaces for integration, with a
programmatic interface used for creating and modifying data. Users can also create
129
and update data through a common user interface dialog box. The functionality of
this interface is driven by flags that are passed in. These flags control which
templates are available, the ability to regenerate costs, and the ability to lock down
costs.
Calling System Interaction

Calling
System
Interface Form
Functions:
Creating Automatic Cost Entries
Updating Automatic Costs
Lock Cost Entries
Copy Cost Record
Request 112 update on Associated Costs
130
ERD
Base Data Model
FIN:Association
FIN:Cost
Calling System Form

Calling System Identifier
Cost Record Instance ID
Association Type
Primary
Informational
Allocation
Cost Center
Cost Type
Description
Amount
Units
Date Incurred
Instance ID
FIN:CostAssociationJoin
Filter API
FIN:ChargeBacks
Calling System Table

Identifier
Populated using a filter API

process with cost data and
cost center allocations from
FIN:Cost . Used for chargeback
reporting.
Licensing model
The Costing Management subsystem requires an application-level license. This
license is provided with all ITSM applications. A user license is also required for
the chargeback component of the subsystem. This license is required for making
adjustments to the chargeback functionality.
Permission model
Roles
The roles defined for the costing subsystem are:

ViewerCan only view cost data.
UserCan add costs.
ManagerCan update and manage the chargeback process.
131
Definitive Software Library

The ITIL definition of the Definitive Software Library (DSL) is a library where the
definitive authorized versions of all software Configuration Items (CIs) are stored
and protected. It is a physical library or storage repository where master copies of
software versions are placed. This logical storage area might consist of one or more
physical software libraries or file stores.
In short, the DSL is a repository of authorized and approved software available to
be deployed to the production environment. It contains or provides a reference to
the golden images.
The BMC implementation of the DSL was designed around these principles and is
structured to:
Be the centralized store of authorized software package information.
Ensure consistency between Change Management and Configuration

Management.
Normalize entries in the BMC Atrium CMDB.
Keep asset information in the BMC Atrium CMDB accurate.
The following is the Definitive Software Library Console. It is used to manage the
contents of the DSL.
132
The DSL is instrumental in normalizing the names of software items maintained in
the BMC Atrium CMDB or discovered in the production environment. Acting as
the single source for these names, many components of the ITSM environment
interact with the DSL, as illustrated in the following high-level architecture
diagram.
Change Manager
Change Assignee
System to System
Interaction
Asset Management
Data Interaction
Software License Mgmt

Approvals
Change Management
Change Request
Product Lookup
DSL Reference
Related CI Targets
CMDB
Configuration
Discovery
Definitive
Software
Library
Policy
Manager
Task
Management
System
Command
Automation
Interface
Task Implementer
Deployment
Manager
Common Management Services
Primary components of the DSL

The four primary components of the DSL model are:
Product Dictionary (PD)A Product Dictionary entry represents the

normalized name of an application or software item that has been authorized to
be available for release to the production environment. The normalized name of
an application or software item consists of the product name, manufacturer,
version, and patch.
Associated filesA list of files that are executed or referenced in support of

the application.
Software Library Items (SLIs)Location or storage of media.
Suite definitionApplication suites are bundles of software and can consist of

one or more entries in the Product Dictionary. For example, the Microsoft
Office is suite consists of the software items Word, Excel, PowerPoint, and
Outlook. Suites are represented as entries in the Product Dictionary.
133
The following diagram provides a high-level illustration of how these components

are organized as part of the DSL.
The Definitive Software Library (DSL)

Product Dictionary
Product Name
Version
Patch
Manufacturer
Software Library Item

S/W Library Item
Software
location
Location
information
Information
Suites
Products
related
Related
to a Suite
suite
Files
List of
related
Related
files
Files
The Product Dictionary is the parent object in the DSL. The Software Library Item
to Suite cross-reference and related files table are all children of the Product
Dictionary. A DSL entity is defined by the Product Dictionary record and all the
corresponding related information stored in the Software Library Item, suites, and
files table.
ERDs
The following ER diagram represents the data model of the BMC DSL. The items
in blue are unique to the DSL model. The items in white are part of the ITSM
foundation and are shared by ITSM applications.
134
ModelVersionPatch
-PIID
+PMVIID
+PatchLastBuildIn
1
D
Company
- CIID
+ Company
+ Type
Product
- PIID
+ CIType
+ ProductCat
1
+ ProductCat
2
+ ProductCat
3
Version
-VIID
+ PIID
+ PMV State
+ Product Name
+ Manufacturer
n
n
ProductCompany
-A
PIID
+ CIType
+ ProductCat
1
+ ProductCat
2
+ ProductCat
3
.
1
1
1
ProductModelVersion
- VIID
- PIID
+ CIType
+ ProductCat
1
+ ProductCat
2
+ ProductCat
3
+ PMV State
+ Product Name
+ Manufacturer
ProductDictionary
n
-VIID
-PIID
+CIType
1
+ProductCat
1
+ProductCat
2
+ProductCat
3
+PMV State
+Product Name
+Manufacturer
n
Suite
_PD Lookup
Legend
Foundation Objects
SLI
-SLIIID
+VIID
+Description
+Type
+State
+Location
PV_Files Lookup
+VIID
+FileID
Attachments
-Attachment
+DSL IID
IID
+Description
+Attachment
+SuiteIID
+VIID
Vendor Version
- VVIID
+ Description
+ VersionString
+ ComponentNam
ProductDictionaryPatc
h
-PMVIID
-ProductIID
-PatchIID
-.
-.
-.
n
Files
-FIID
+Name
+FileSize
+CRC
+TimeStamp
PD/DSL Objects
Only required fields are represented
.
The fields to be represented in a Product Dictionary entry depend on the fields

currently in the PCT:Product Catalog form and additional fields needed to support
data from a third-party vendor.
The PCT:ProductCatalog and PCT:Product Model/Version forms include DSL
specific fields. The join of these two records is the intermediate form
PDL:ProductModelVersion.
PDL:ProductDictionary is the join between the PDL:ProductModelVersion and
PCT:ProductCompanyAssociation forms.
PDL:ProductDictionaryPatch is the join between the PDL:ProductDictionary and
PCT:ModelVersionPatch forms.
PCT:ModelVersionPatch is the normalization of the patch information to the
CFG:ModelVersion form.
PDL:ProductDictionaryPatch is the table used to represent the Product Dictionary
entries in the DSL console.
135
PCT:ModelVersionPatch
PK
PCT:Product Catalog
PK
PCT:ProductCompanyAssoc
Instance ID
PK
Add DSL Fields
ProductID
CI Class
ProductCatTier 1
ProductCatTier 2
ProductCatTier 3
Product Name
Manufacturer
Price
Product 's Image
Product Name
Model Version
PatchLastBuildID
MainExeID
MainExeName
InstanceID
ProductIID
Company
JOIN
Origin
IsSuite
JOIN
PDL:ProdDictionaryPatch
PK
PDL:ProductModelVersion
PCT:Product Mod/Version
PK
Add DSL Fields
Instance ID
PMV ID
Product IID
ProdMod Vers
PMV State
Product Name
Manufacturer
PatchLastBuildID
ManufacturerPartNo
GeneralAvailDT
DiscAvailDT
DiscSupportDT
PreReleaseDate
Product ID
PMV ID
ProductIID
ProdModVer
PMV State
ProductName
.....
OS
Locale
Platform
VersionMajor
VersionMinor
VersionBuild
VersionMaint
GUID
OS
Locale
Platform
VersionMajor
VersionMinor
VersionBuild
VersionMaint
ManufacturerID
VersionIID
ProductID
CI Class
ProductCatTier 1
ProductCatTier 2
ProductCatTier 3
ProductName
Manufacturer
ManufacturerID
GUID
OS
Origin
IsSuite
Locale
Platform
PMV State
ProductName
InstanceID
PatchIID
ProductID
CI Class
ProductCatTier 1
ProductCatTier 2
ProductCatTier 3
ProductName
Manufacturer
ManufacturerID
GUID
OS
MainExeID
MainExeName
Origin
IsSuite
Locale
Platform
ProductID
PMV State
ProductName
JOIN
PDL:ProductDictionary
PK
PK
Instance ID
Data example
Model/Version Patch
VIID
Patch
PA1
2.3
V3
PA2
1.0
V1
Product
Company
Association
PatchIID
V2
Company/Manufacturer
PA3
0.0
CIID
Name
State
C0
-Global-
--
C1
...
MS
WA
PIID
Company
VIID
PIID
PatchIID
C2
...
Dell
TX
PD1
-Global-
V2
...
PA1
PA1
PD2
-Global-
V3
PA2
PA2
PD3
-Global-
V1
PA3
PA3
Product Dictionary (Join)

PIID
PD1
PD2
CIID
C1
C1
Origin
rd
3 Party
3rd Party
VIID
PD1
PD2
Product Catalog Base

PIID
ProductDictionaryPatch
(Join)
Name
CIID
V2
Word
C0
V3
Excel
C0
PD3
V1
Outlook
C0
PD4
... ... ... ...

V4
Office
Is Suite
No
No
Product Model/Version
(Join)
PD3
C1
3rd Party
No
PIID
VIID
PD4
C1
3rd Parth
Yes
PD1
V2
C0
Name
Word
PD2
PD3
Model/Version Base
VIID
PIID
PD3
... ... ...
PD1
... ... ...
PD2
4.2
V4
... ... ...

PD4
Office
FIID
SuiteIID
Location
SLI1
...
PA1
Shelf
F3
SLI2
PA2
Shelf
SLI3
PA3
Disk
V2
PDIID
PD4
PIID
F1
VIID
Suite Mapping
SLIID
PD3
V1
3.0
V3
V4
Outlook
4.0
V2
V1
Excel
Version
V1
PD4
F
V3
Files Lookup
... has .../... has ...

PD4
PD2
PD4
PD1
Files
KBVersion
VVID
Version
KB1
1.0
...KB2 .../... has ...

has
1.3
136
Name
File Size
F1
Word.exe
3784
F2
F
Excel.exe
1816
F3
6.0
FIID
Outlk.exe
2590
Interfaces
Three interface tables support submit, modify, and query operations performed by
external systems.
The following are the interface (staging) forms for the DSL:
PDL:SLIInterface_CreateStaging form that interfaces to the

PDL:SoftwareLibraryItem form. This form is used for creating Software
Library Item entries.
PDL:SLIInterfaceSelf-join form of the PDL:SoftwareLibraryItem form. This

form is used for query and modify operations.
PDL:PDInterfaceSelf-join form of the PDL:Product Dictionary form. This

form is used for query and modify operations.
The interface (staging) forms contain all necessary fields from the interface form
that will be input from an external source.
137
Software Library Item submit
ITSM
External
application
Creates staging
record using
Product
Dictionary web
service
PDL:SLIInterface_Create
(staging form)
PDL:SoftwareLibraryItem
Processes
incoming
parameters
Data flow direction
Web services
Web services interfaces allow for programmatic access to the individual
applications and subsystems.
Product Dictionary
The following functions enable web service operations for the PDL:Product
Dictionary form using the PDL:PDInterface interface form:
PD_QueryList_ServiceQueries using a qualification statement for
multiple Product Dictionary entries in the PDL:ProductDictionary form.
PD_QueryListFields_ServiceQueries specifying field values to search on
for multiple Product Dictionary entries in the PDL:ProductDictionary form.
Product Dictionary Patch

The following functions enable web service operations for the PDL:Product
Dictionary Patch form using the PDL:PDPInterface interface form:
PDP_QueryList_ServiceQueries using a qualification statement for
multiple Product Dictionary Patch entries in the
PDL:ProductDictionaryPatch form.
PDP_QueryListFields_ServiceQueries specifying field values to search
on for multiple Product Dictionary patch entries in the
PDL: ProductDictionaryPatch form.
138

The following functions enable web service operations for the
PDL:SoftwareLibraryItem using the PDL:SLIInterface interface form:
SLI_Modify_ServiceModifies a Software Library Item entry in the
PDL:Software Library Item form.
SLI_Query_ServiceQueries for a Software Library Item entry in the
PDL:Software Library Item form.
SLI_QueryList_ServiceQueries using a qualification statement for
multiple Software Library Items in the PDL:Software Library Item form.
SLI_QueryListFields_ServiceQueries specifying fields values to search
on for multiple Software Library Items in the PDL:Software Library Item
form.
The following function enables web service operations for the

PDL:SoftwareLibraryItem using the PDL:SLIInterface_Create interface form:
PDL_SLI_Submit_Service
Creates a Software Library Item entry in the PDL:Software Library Item form.
The following table summarizes web services information:
Base form and type
Operation
description
Patch
Query list of
entries
PD_QueryList_Service
PDL:PDInterface
PD_QueryListFields_Service
Query list of
entries
PDP_QueryList_Service
Query field list
Self-join
Interface form
Query field list
Operation name
PDP_QueryListFields_Service
Create SLI
PDL_SLI_Submit_Service
PDL:SLIInterface_Create
Modify SLI
SLI_Modify_Service
PDL:SLIInterface
Query for
specific SLI
SLI_Query_Service
Query for list

of SLIs
SLI_QueryList_Service
Query field list
SLI_QueryListFields_Service
PDL:PDPInterface
Self-join
PDL:SoftwareLibraryItem
Regular
Self-join
139
Permission model
DSL has the following permissions:
Level 1DSL Administrator: Access to add and modify Product Dictionary

and Software Library Item definitions.
Level 2DSL User: View access to Product Dictionary and Software Library
item definitions.
Requester Console and SRMS framework

The Requester Console is supported by the Service Request Management System
(SRMS) framework, which implements the service request component for
integration to the back-end Change Management and Incident Management ITSM
7.0 applications. The service request entity serves as a bridge and is not designed to
be managed by service desk personnel. It is a slave to the back-end change
request or incident with its lifecycle completely driven by the back-end. The base
form, SRM:Request, is hidden, except for system troubleshooting when it fails to
communicate with the back-end. The Requester Console is the front-end entry point
for users to submit requests.
Requester
Console
Request object
Obj t
SRMS framework
Framework
OR
Change
Management
140
Incident
Management
Requester Console
The Requester Console is a simplified interface for users to submit change requests
and incidents, similar to the Requester interface in ITSM 6.0. This allows users to
submit requests into the system from a single console, without having to directly
access the Change Management or Incident Management consoles. The targeted
audience is non-IT user requesters.
The Requester Console uses the existing framework designed for SRMS, which
provides a structured mechanism to integrate back-end applications, such as
Change Management and Incident Management. A set of user interfaces is targeted
for user requesters to submit, view, and update their requests. It also provides
configuration entry points for the SRMS framework on the Application
Administration Console and exposes the framework Service Request form for
troubleshooting. The Request Console is a separate deployable application, but is
dependent on the SRMS framework and does not function independently. It
requires Change Management or Incident Management to be installed. User
requests are managed completely by the back-end applications in the form of a
change request or an incident. The service request entity is not intended to be
managed by support personnel, except for system trouble-shooting. The Requester
Console is a user interface component to the SRMS framework and the integration
141
components from the back-end applications or other systems, like Service Level
Management (SLM) is to the SRMS framework.
Primary components
This section focuses on the components of the Request Console and their function
in enabling the front-end interactions. Two categories of forms support the
Requester Console: configuration and runtime. Configuration forms are accessed
using the Application Administration Console, and are designed to maintain data
that affects the behavior of the Requester Console. Runtime forms serve two
purposes: as the interface, or to capture data from users when they use the
Requester Console.
Category
Component
Description
Configuration
SRM:ApplicationSettings
Contains records to determine the settings for the

Requester Console and the SRMS framework.
This data includes settings to:
Specify the server tenancy mode.
Allow unknown users.
Supply default submit data for unknown users.
Supply default request ID text.
Enable the Requester Console.
Supply AR System logins for access to Change
Management and Incident Management.
This form has one entry and it can be modified, but not
deleted. No additional entries are allowed.
Configuration
SRM:CFG Rules
Contains records to determine the service request rules by

company. These rules include settings for auto-close,
survey, and individual auto-assignment.
Configuration
SRM:ConsolePreferences
Stores preferences for console behavior.
Configuration
SRM:ConfigSurveyQuestions
Stores the survey questions that are associated to a

request when it reaches the Complete state. A survey
can be set up by Request Type (Incident or Change), and
by Company, including Global, which is applied to all
companies. One to five survey questions can be
configured.
Configuration
Requester
Console:SummaryDefinition
The summary definitions provide the menu items for the

Summary menu in the New Request form. It predefines the
summary text, operational categorization values, and the
type of back-end request (change or incident). These
values are used to create service requests, which then
create the back-end requests, depending on the request
type. Each summary record must be unique by Summary
and Company fields, using filter workflow validation.
142
Category
Component
Description
Runtime
Requester
Console:RequestConsole
Serves as the entry point for users and supports their

primary interactions. It provides the user interface for
submitting and viewing requests.
Runtime
SRM:ServiceRequestWizard
The Request Wizard provides a simplified interface for

users to create and submit a request. This form is a
display-only dialog box in which users provide required
information to complete the request.
Runtime
SRM:Request
The Requester Console submits a record into the SRMS

framework form, SRM:Request, when creating a new
request. The SRMS framework implements the workflow
and logic to create the back-end change request or
incident for the Submit action on the SRM:Request form.
The SRMS framework also synchronizes the data and
status with Change Management or Incident Management.
The Requester Console only displays the information for
the user requesters.
Runtime
SRM:WorkInfo
Contains information associated with the user request,

which could be attachments or general text summaries.
Users can view Work Info entries using buttons on the
Requester Console.
143
Category
Component
Description
Runtime
SRM:Survey
When a request reaches a Complete status, a survey is

generated. Required information from the request is
pushed into the SRM:Survey form to create a new survey.
Filters on the Survey form get the questions from the
SRM:ConfigSurveyQuestions form, based on input
parameters from the SRM:Request form.
Survey data model diagram
1. New request
submitted
2. Creates
incident
4. Completed
request
3. Incident
resolves
Survey
rules
5. Survey sent
SRMS framework
The SRMS framework provides a bridge between the front-end user requests and
the back-end operations. In ITSM 7.0, integrations are implemented to Change
Management and Incident Management. However, the SRMS framework provides
a structure that can be connected to any other open back-end solution.
The design of the SRMS framework is based on the following goals:
Act as a bridge between the Requester Console front-end interface and Change
Management and Incident Management back-end applications.
144
Segment front-end transactions from back-end transactions.
Support synchronization between the front-end interface and back-end object

life-cycle.
Establish a foundation to support integration to back-end systems.

Integrate to Change Management and Incident Management as the back-end
applications.
Provide a mechanism for establishing field mappings between the request
entity and change request or incident, for request creation.
Provide CAI as a bi-directional communication mechanism for back-end
integrations.
Integrate with SLM for requester-focused service level agreements (SLA)

tracking.
The architecture contains the following modules:
SRMS administration
Summary definition
Service request
Associations
Flows
Application object templates
Application object instances
Additional questions and answers.
A simplified model has been implemented for ITSM 7.0. A request maps to a single
back-end application request. A one-to-one relationship between the request and the
back-end object will trigger the fulfillment process. However, the SRMS
framework is architected to support a more comprehensive and flexible model, with
the use of the flow, association, and question components. These components will
be more fully leveraged in a future release of the Service Request Management
solution.
Following is a top-level diagram that shows the dependency and integration points.
Note that Change Management and Incident Management are integrated with the
SRMS framework, but are dependent on the CAI, which is the mechanism that
communicates with the SRMS framework.
One of the primary uses of the SRMS framework in ITSM 7.0 is to provide a means
for bi-directional synchronization between the front-end request and its related
back-end application request. The SRMS framework includes command and
command parameter definitions stored in the CAI:Command and
CAI:CommandParam forms as part of SRMS framework configuration data. These
event commands are used to communicate to the back-end applications for request
creation, updates, and synchronization activity. The type of information being
synchronized includes status updates and work log activities.
145
Change Management and Incident Management integration

Change Management and Incident Management use SRMS framework command
events to communicate to and from the Requester Console using the CAI
component. Areas where these components are used include the following
examples:
From the SRMS framework to:
Create change requests or incident requests.
Send work info entries.
Cancel or reopen requests.
From Change Management and Incident Management to the Requester Console to:
Update request status (In Progress, Completed, Canceled, or Rejected).
Send Work Info entries.
Update request assignee and manager data.
Update SLM response status.
For Outbound commands, the SRMS framework communicates with Change

Management and Incident Management through the interface forms. For Inbound
commands from Change Management and Incident Management, the CAI:Events
and CAI:EventParams forms are used for all updates. However, the service request
interface form is used for inbound create service request commands.
SLM integration
Integration to SLM is linked to the SRMS framework SRM:Request form for SLA
tracking to requesters. Milestone and action templates are provided for notifications
to SLA owners when the goal is close to being missed. SLA owner values come
from the back-end change request (from change managers) or incident (from
incident owners).
Note: The SRM:Request form does not assign owners to the request.
Primary components
The Requester Console and the SRMS framework are divided into three major
areas: configuration, definition, and execution.
146
In the configuration area, summary definitions are set up to communicate with

the back-end application requests. For Change Management 7.0 and Incident
Management 7.0, two system configuration forms must be pre-populated to
work with the Requester Console front-end.
In the definition area, summary definitions are established to determine whether
a change request or incident back-end application request will be instantiated
when the request is submitted. The request object has additional associations to
service level agreements. For more information about definition options, see
the BMC Remedy IT Service Management 7.0 Configuration Guide.
In the execution area, requests for a summary definition are handed off to the
SRMS framework and the back-end application objects are instantiated to
fulfill the request. The application objects are managed by the respective backend application system with their own life cycle. The request has a simple life
cycle with additional associations to service level agreements.
The following table lists the primary components that support the SRMS
framework:
Component
Description
SRM:Request
Request form
SRM:AppTemplateBridge
The Application Object Template stores information about the back-end

application request and acts as a stub in the definition area of the SRMS
framework. It is used to instantiate an Application Object Instance when a
definition is selected as a request during the execution phase.
SRM:AppInstanceBridge
The Application Object Instance is instantiated when a summary definition

is selected as a request. It stores information about the back-end
application request and its status information. The status includes status
values that affect the lifecycle of the service request. The status transition
is triggered by certain actions or events from users or from the system.
This is a back-end form and is accessible only by AR System
administrators.
CAI:AppRegistry
This form is used to register back-end applications that are integrated with
the SRMS framework. It contains the template form name, the request
form name, and connection data, such as server name, login, and
password.
CAI:Commands
Command list form.
CAI:CommandParams
Parameter list form.
To facilitate communication between the SRMS framework and back-end

applications, mappings must be defined between SRMS framework
command parameters and back-end application specific fields. This
mapping is defined per registered application in the Application Registry
for each command parameter.
CAI:Events
The events table is used to communicate SRMS framework related

events, such as back-end application request creation notifications or
status changes.
CAI:EventParams
Stores the parameters for event command instances
srmeventcmd.dll
Event Command Filter API (binary).
Mapping data to the back-end applications is required for the SRMS framework to
create back-end requests and to send update information. All mapping data is
147
shipped with Change Management and Incident Management as part of the system
configuration and should not be changed.
Data is included to:
Register the back-end application with the CAI component

(CAI:AppRegistry)Contains access information to the back-end application.
For AR System applications, it also contains the form names for template,
interface, and instance forms.
Register application fields (SYS:Form Field Selection)Identifies application

fields from the application interface form for question template mappings and
command parameter configuration.
Configure command parameters (CAI:CommandParamsMapping)Maps

fields from the application interface form to SRMS framework command
parameters. The mapping definition is used by the SRMS framework when
sending events to the back-end application interface form. The command
parameter values are copied to the fields specified by the field ID in the
mapping.
Define additional questions (SRM:QuestionTemplate).
Configure question template mapping from SRMS framework fields to backend requests for request submission.
ERDs
In the following ERD diagrams, the arrows point to the form that stores the foreign
keys. For example, ARInstanceID (called out as FK:SRInstanceID) from the
SRM:Request form is stored on the HPD:Help Desk, CHG:Infrastructure Change,
SRM:WorkInfo and SRM:AppInstanceBridge forms. The SolutionRequestID from
the PBM:Solution Database form is stored on the SRM:Request form.
148
PBM:Solution
Database
SRM:Survey
FK:SRInstanceID
FK:SolutionRequestID
RQC:Summary
Definition
FK:TitleInstanceID
FK:Originating_Request_InstanceID
FK:SRInstanceID
SRM:WorkInfo
SRM:Request
FK:SRInstanceID
Requested By
Requested For
Manager
Assignee
CFG:Service
Catalog
HPD:Help Desk
CHG:Infrastructure
Change
COM:Company
CTM:Region
CTM:Support
Group
SIT:Site Group
CTM:People
SIT:Site
149
The following diagram illustrates how the SRM:AppistnaceBridge form is used to

relate event commands with the corresponding request and the change request or
incident records.
FK:SRInstanceID
FK:SR_KnoweldgeDatabaseID
FK:AOIGUID
PBM:Solution
Database
HPD:Help Desk
FK:AppRequestInstanceID
CAI:Events
SRM:Request
CHG:Infrastructure
Change
FK:EventGUID
CAI:EventParams
Integration Flow
The request object is the main artifact associated with the execution phase of
SRMS. A user can submit a request using the Requester Console wizard.
After the request is submitted, based on the selected summary definition, a backend application request is created and the field values are pushed according to
question template mapping. The summary definition defines the summary text,
categorization values, and request type, which is either Change or Incident.
Instantiation
Instantiation refers to creation of back-end requests and related SRMS framework
objects when a request is submitted. When the request is created from the
Requester Console, it is either a Change or Incident request type. By definition,
only one Application Object Instance is created. The Application Object Instance
has a one-to-one relationship to the request and is instantiated on the Submit action.
When a request is submitted and the Request Type is Change or Incident, the
following occurs from filters on Submit action for the SRM:Request form:
1. A lookup of the Change Management or Incident Management application in
the CAI:AppRegistry form is executed by a fixed application instance ID value.
This value is from the SHARE:ApplicationProperties form.
2. An Application Object Instance record is created with the CM or IM registry
instance ID, and SR instance ID with CREATE command and flag ADHOC.
150
ADHOC means create the Application Object Instance and the back-end
request.
3. The Application Object Instance has filters that execute upon the CREATE
command to create the back-end change request or incident. Connection
information and interface form names are looked up in the CAI:AppRegistry
form and copied to the Application Object Instance record.
4. The Event SRM_OUT_CREATE_APP_REQUEST event is created in the
CAI:Event form and relevant values from SR fields and command parameters
are created in the CAI:EventParams form.
5. A filter is executed on the Event form, which triggers the CAI plug-in to send
the event to the back-end application.
6. The CAI plug-in sets the return code and message on the Event record.
If the return code is updated to OK, a filter is executed on the Event form,
which triggers a status change on the Application Object Instance sender to
Created. The Request status is set to Staged. If the application request
requires activation (New Request Activate = Yes), the
SRM_OUT_ACTIVATE_APP_REQUEST event command is created in the
CAI:Event form.
If the return code is updated to Error, a filter is executed on the Event form
that triggers action field on Application Object Instance to
EVENT_ERROR. This triggers the Modify filter on the Application Object
Instance form to set the SR App Event status field to ERROR. Notification
is sent to users in the Request Master group when an error occurs.
The Application Object instance queries secondary forms to build the event
commands. These forms include the CAI:Command,
CAI:CommandParamsMapping, and SRM:QUTJoinSRGJoin forms.
151
The following diagram shows the instantiation process:

Request instantiation diagram
SRM:AppInstanceFlow (NOT
USED in RQC)
Service Request Instance ID
Predecessor Instance ID
Successor Instance ID (AOI)
1. Tells Start Flow to

start work.
SRM:Request
7. Sets return code = <OK, Warning, Error>

Return msg = warning or error msg

SCO Instance ID
2. Create successor AOI
3. Create event
and event
param entries.

AOI Instance ID
Application Registry Instance ID
Flow information
Question-response
linked to service request.
SRM:Service
RequestQuestionAssociation
(NOT USED in RQC)
AOI Instance ID
Question Response Instance ID
When SR status = New;

status reason = AI Creation,
Create the event and event
params.
CAI:Event
Field-value pairs come from

question-response pair.

Question Instance ID
Question
Answer
CAI Plugin
5. CreateEntry to application interface

Field-value pair linked to event
SRM:QuestionResponse
(NOT USED in RQC)
4. FilterAPI invoked
Event Instance ID
Event Type=CreateAppRequest
AOI GUID=<AOI Instance ID>
SRMS Server=<SRMS server name>
App GUID=<Application ID >
App Server=<Application server name>
App Interface form = <App interface form
name>
Source=SRMS
Return code = empty
Return msg = empty
CAI:EventParams
Event Instance ID
Param Name=<field id>
Param Value=
Type=<In, Out Qual>
Data Type=<Character, Attach>
App interface entry field values

come from event params
Application Interface
(ChangeInterface_Create)
6. Submit to application instance

(if app interface != app instance form)
CAI:AppRegistry
Registry Instance ID=
Registry Name=
Description=
App Template Form=
App Template View Form
=
App Instance Form=
App Interaction Form=
Access Mode=<Local, Remote>
Server=
Login/password=
Application Instance
(CHG:Infrastructure Change)
Status Synchronization
The request object uses event commands to synchronize the status with the
application requests. The back-end application must send status-related events to
the SRMS framework by creating entries in the CAI:Events form. Workflow is
implemented in the sample application to illustrate this mechanism.
Interfaces
Create request interface

The SRM:RequestInterface_Create form is a regular form that is an interface form
for the SRM:Request form. It supports external systems in creating new requests
programmatically or by AR System workflow. For example, requests can be
created automatically when a change or incident request is created from the backend application using the SRM:RequestInterface_Create form. A function is
available using Change Management and Incident Management that allows the
back-end support user to generate a request object that is linked to the current
change request or incident. This allows the requester to access their requests from
152
the Requester Console, although the request was submitted from Change
Management or Incident Management support personnel. This is useful for requests
from users who do not have access to Change Management or Incident
Management.
CAI plug-in
The CAI plug-in is used to transmit SRMS framework events to back-end
applications. A plug-in is used due to the dynamic nature of the field mappings for
each command and the potential for incompatible permission models. For example,
the command to create a back-end request consists of dynamic field values that can
be mapped to any field on the back-end interface forms, where it is not possible to
use workflow to push values to dynamic fields. Additionally, if the back-end
application is on a remote server from the front-end application, such as the SRMS
framework, a different AR System login is required for the plug-in to log in to the
remote server. This login information must be specified in the per event record.
Outbound commands (such as CreateAppRequest)
Service Request
SR GUID
Status
Cost
Event
AOI
SR GUID
AOI GUID
App Registry
AOI Status
App Instance GUID
App Instance ID
App Instance Description
App Instance Status
App Instance Cost
2. Create outbound
create entry
8. Notify AOI that
command is done
9. Update event
status=Complete
3. Create the event parameters using

the fields setup from command
configuration and by using responses
to the questions to map the values into
the application interface/instance fields.
Event GUID
Event Command
Event Status
Protocol (AR)
SRMS Server
AOI GUID
Reg App Server
Reg App Interface (Form)
App Instance GUID
Return Code
Return Message (Error)
Event Parameter
Event GUID
Event Parameter GUID
Parameter Name
Parameter Value
4. Call Filter API

7. Return code,
Return message
Filter API
In: Reg App Server, Event
Form, Event Param Form,
Event GUID
Rtn: Return Code, Return
Message
5. AR API Call
App Interface
Template ID
SRMS Server
SR ID
AOI GUID
...
6. Create/update/query
entry in app instance
App Instance
...
SRMS Server
SR ID
AOI GUID
...
153
Permission model
The SRM:Request form has the following permissions:
PublicHidden
Request MasterVisible
SRM:Request contains levels of permissions:
Request Master
Assignee Group
Unrestricted Access
General Access
Submitter
The following tables lists the permission roles and groups for the SRMS framework
and the Requester Console.
Requester Console application permissions
AR System
group or role
Map to group
Comments
Summary
Definition Config
Summary Definition
Config Computed
Provides create, view, and modify access to Requester

Console:SummaryDefinition.
Note: General Access is needed for modify access.
N/A
Summary Definition
Base group for Summary Definition Config Computed.
Requester
Console Config**
Requester Console Config
This group is part of the Request Config Computed

group.
Provides create, view, and modify access to:
SRM:CFG Rules
SRM:Application Settings
SRM:ConfigSurveyOptions
Requester Console:SummaryDefinitions
Menu access to the Administrator Console for the
Requester Console.
154
AR System
group or role
Map to group
Comments
Requester
Console
Master**
Requester Console
Master
This group is part of the Request Master Computed

group.
Provides access to:
View the SRM:Request form for troubleshooting.
CAI Event Dialog and retry events.
Create and view the work log from the Service Request
form.
Request Configuration
General Access
General Access**
Provides access to all general users who require modify

permission.
Unrestricted
Access
Unrestricted Access**
Bypasses row-level access for multi-tenancy. See

Assignee group.
Submitter*
N/A
Provides:
Row-level view access to SRM:Request records
submitted by that user from the Requester Console.
Create and view access to the work log from the
Service Request form.
Assignee Group*
N/A
Provides row-level access based on the Company field.

Applies to summary definitions and broadcast messages.
Public*
N/A
Provides access to the Requester Console and all the

related display forms.
Note: AR System Guest public users have access to global

summary definitions and broadcast messages.
155
SRMS framework application permissions

AR System
group or role
Map to group
Comments
Request Config**
Request Config Computed
Provides create, view, and modify access to:

SRM:CFG Rules
SRM:Application Settings
SRM:ConfigSurveyOptions
Requester Console:SummaryDefinitions
Menu access to Application Administration Console for
Requester Console.

N/A
Request Config
Base group for Request Config Computed. Also part of

the Summary Definition Computed group.
Request
Master**
Request Master
Computed
Provides access to:

View the SRM:Request form for troubleshooting.
The CAI Event Dialog and retry events.
Create and view the work log from the Service Request
form.
Request configuration.
N/A
Request Master
Base group for Request Master Computed. Also part of

the Command Event Master Computed group.
General Access
General Access
Provides access to all general users who require modify

permission.
Unrestricted
Access
Unrestricted Access
Bypasses row-level access for multi-tenancy. See

Assignee Group.
Submitter*
N/A
Provides row-level access to SRM:Request records

submitted by that user ($USER$).
Assignee Group*
N/A
Provides row-level access based on the Company field.

Applies to SRM:Request records.
Public*
N/A
Provides general access. Access granted to this group is

granted to all users.
*Public, Submitter and Assignee Group are implied AR System groups; no Group
or Role entries are required.
**General Access and Unrestricted Access are foundation AR System groups.
These groups are shipped with the Foundation application.
156
SRMS framework computed groups

The SRMS framework uses computed groups for Request Config and Request
Master permissions so users can be granted Requester Console permissions instead
of using SRMS permissions directly.
Computed group
Comments
Request Config Computed
Computed group for Request Config

Equals Request Config or Requester
Console Config
Request Master Computed
Computed group for Request Master

Equals Request Master or Requester
Console Master
Requester Console computed groups

The Requester Console has one computed group for summary definition
configuration. This is set up to allow granting of summary definition permission to
Change Config or Incident Config permission indirectly.
Computed group
Comments
Summary Definition Config

Computed
Computed group for Summary Definition

Config.
Equals Summary Definition Config or
Request Config or Change Config or
Incident Config.

The primary goal of the Task Management System (TMS) subsystem is to provide
a mechanism to support repeatable processes. The result is improved productivity,
reduction in novice errors, and a clear way to define business processes.
The Task Management System introduced in ITSM 7.0 significantly enhances the
capability of the task operation of previous releases. In addition to the predecessor
and successor relationship, TMS supports branching and multiple paths, along with
data exchange between tasks. TMS also supports integration with external systems,
primarily using the Command Automation Interface (CAI) subsystem.
The following sections present the architectural structure of TMS. See the BMC
Remedy Task Management System 7.0 Administrators Guide for information about
user features, configuration, and administration of the system.
157
The fundamental building blocks of TMS can be divided into two primary areas:
Definition and Execution/Runtime. Definition consists of templates that are
leveraged during runtime. When a template is selected to be executed, the template
and associated templates that are grouped with it are instantiated as a single unit.
This results in a single runtime instance of that template group. Following are
descriptions of the primary definition and runtime components of TMS.
Definition
Definition consists of a Container object task group, associations, flows, and

templates that establish the relationships and hierarchy between corresponding task
templates.
Component
Description
Task Group templates
The Container object is the parent object that manages related associations
and flows of its children objects.
Association templates
Associations define the task templates that are related to or grouped under the
Task Group template.
Task templates
Task templates define the purpose of tasks.
Flow templates
Flows determine the sequence and dependencies between the associated

task templates.
Execution/Runtime
Execution consists of the Container Object task group, associations, and flows that
establish the relationships and hierarchy between corresponding tasks. The process
to transform a task group template (the definition phase) to a task group (the
execution phase) is called instantiation. Therefore, the corresponding entities for
the templates defined during runtime are task groups, tasks, flows, and associations.
The Variable pool is a structure that facilitates information passing between tasks
and flows.
The following diagram provides a high-level view that illustrates typical
relationships among the TMS components previously defined.
158
Flows
Associations
Container
Object
Container
Object
Data Flows
Task Group
Container
[0]
Task Group
Template
[0]
OR
Application Object
Instance
Application Object
Template
Task
[A]
Task
Template
[A]
Application Object
Template
AND
Application Object
Instance
Application Object
Template
Task
Template
[B]
Task
[C]
Task
[B]
Task
Template
[C]
Application Object
Instance
Application Object
Template
Task
[D]
Task
Template
[D]
Name
Variable Pool
Application Object
Instance
Value
Scope
Location
Contact
Phone
Closed Tasks
Sunnyvale
Local
TBD
2
Feature Set
Related Items
Automated Tasks
Launch
Pass data betweenAOIs
Reference Other Form
Shared Work
Local
System
Instantiation
To facilitate planning for the task process, all tasks and task groups defined in the
definition are created in advance after a task group template is selected from the
definition set. This model is referred to as Instantiation.
In the Instantiation model, all potential tasks, task groups, and flows defined
between them are created in advance. This approach allows task owners to review
the whole process before the execution phase.
159
Definition
Execution
Task Group Template 1
TaskTemplate 1
F1
Task Template 2a
Task Group 1
F2
Task 1
F1
Task Template 2b
F2
Task 2a
F4
F3
Task Template 3a
TaskTemplate 3b
Task 2b
F4
F3
Task 3a
Task 3b
F6
F5
F6
F5
Task Template 4
All templates in this task group template are configured to be

executed in the order of flow F1 to F6.
Task 4
All tasks and task group and flow created in advance with
Status = Staged and State = Inactive
Parent Object starts the task process by activating the initial
task or task group.
The process remains inactive (Status = Staged AND State = Inactive), and no
work can be performed on these tasks except adding or changing the task attributes
such as the description, name, classification, and so on. The parent object starts the
process by activating the initial tasks or task groups.
The order of execution between tasks and task groups is enforced by the defined
flow. The successor tasks or task groups are activated (State = Active) when the
predecessor tasks and task group are completed.
160
Execution
Task Group 1
Task 1
F1
F2
Task 2a
Task 2b
F4
F3
Task 3a
Task 3b
F6
F5
Task 4
The first task or task group is activated and ready for agent
to work on while others are locked until the predecessors
are completed.
The defined flow between tasks and task group drives the process of activating or
marking bypass of the next or successor, tasks or tasks groups. Bypass is a
status that indicates a task did not execute because the flow is defined so the task or
task group were not required, and therefore not executed.
161
Execution
Task Group 1
Task 1
Closed/Success
F1
F2
Task 2a
Closed/Success
Task 2b
Closed/Failure
F4
F3
Task 3a
Closed/Success
Task 3b
Bypaased
F6
F5
Task 4
Closed/Success
Task 1 completed successfully.

Task 2a, and 2b are activated. 2a success, but 2b failed.
Task 3a, activated then closed/success, then task 4 activated.
Task 3b is marked bypassed, because Task 2b failed.
Association model
The Association model defines relationships between major entities. Associations
in TMS are ordered in a parent-child relationship. The associations are stored in
two tables: Association Template (definition), and Association (runtime). The [n-n]
reference indicates a many-to-many relationship. The [1 n] reference indicates a
one to many relationship.
The following associations are stored in the Associate Template table:
[n-n] Application Parent template to Task Group template.

An Application Parent template (for example, a change request template) can
be associated to multiple Task Group templates. An example is a change
request template having a planned task group template, an execute task group
template, and a verification task group template.
162
[n-n] Task Group template to Task Group template. In this case, the first one is
the parent and the second one is the child.
[n-n] Task Group template to Task template.
The following associations are stored in Associate table:
[1-n] Application Parent instance to Task Group.

Note: An example of an Application Parent Instance is a change request.
[n-n] Task Group to Task Group. In this case, the first one is the parent and the
second one is the child.
Note: This is an n-n relationship because a Task Group can be the parent of one
or more Task Groups and also a child of one or more Task Groups.
[1-n] Task Group to Task.
On foreign keys:
The Task Group has a foreign key to the Parent Application instance.
The Task has a foreign key to the Parent Application instance.
An association entry for these relationships on the Association table and foreign
keys are needed because foreign keys are used for a quick lookup and to support
direction, while the association entries are used to facilitate navigation.
163
AT1
AT3
AT2
164
ASSOC1
ASSOC3
ASSOC2
Dependency model: flow mechanism

The flow mechanism defines the sequence and dependency between task templates
within a task group template, and between tasks within a task group.
Flow is a configuration process to determine how a task or task group is carried out
at runtime. For example, tasks and tasks groups can be carried out sequentially or
simultaneously.
Flow is defined based on the association between a task and task group. Flow
cannot be established if there is no association. In other words, association is
what other instances are related to current instance, and flow is how these
instances are executed.
A flow consists of one or more flow relationship records. Each flow relationship
record is capped by an inbound and outbound task object. The task object is either a
task template (definition), task (runtime), task group template (definition), or a task
group (runtime). The inbound task object to a flow relationship record is called the
predecessor. The outbound task object to a flow relationship record is called the
successor.
When you define a task group template, you can establish how the associated task
group template and task templates relate to one another. This is called flow, and
determines the sequence in which task groups and tasks are generated at runtime.
A task or task group can be executed simultaneously or sequentially. When the
flow is defined as sequence, all predecessors must be completed before the
successor task or task group can start.
The flow is also determined by the outcome of the predecessor. The resulting
output can be stored in the variables. The values in these variables can then be used
by workflow to decide the behavior of the flow. For more information, see the
following Data exchange model: variable pool section.
For example, in the following illustration the flow, represented by the diamond,
indicates that if Task 1 is flagged as successful, then Task 2 is activated. Otherwise,
Task 3 is activated.
Task 1
Success
Fail
Task 2 Task 3
165
Task Group
Task 1
Task Group
Task 2
Task 1
Task 2
Task 3
Example 1
Task 3
Example 2
The flow in Example 1 indicates that Task 1 and Task 2 could be started
simultaneously, and Task 3 will be started only when both Task 1 and Task 2
complete.
The flow in Example 2 shows all three tasks are in sequence. Task 1 needs to
complete before Task 2 can start. Task 3 will start only when Task 2 completes.
The execution order between task and task group is known as flow, which dictates
how the task or task group are executed at runtime. The flow configuration is
evaluated along with other advance settings, such as conditions, actions, and
behavior, when the task is completed (State = closed, success, failed, or canceled).
These advanced settings are an integral part of TMS and can be complex to
configure if you need to apply a more simple model to transition between tasks. For
example, in the previous versions of the ITSM applications, the primary model for
transitioning between tasks was simply specifying an order in which the tasks
would execute. ITSM 7.0 has a model called Sequencing that focuses on setting
the order in which tasks are executed. This is only an abstraction of the advanced
settings. The flow objects are used but the sequencing model establishes a strict
definition of how the flow objects should be configured.
To clearly distinguish these two approaches of defining how tasks and task groups
flow, Sequencing (Basic) and Standard (Advanced) modes are used. The Advanced
mode exposes all the flow configuration options, whereas the Basic mode is defined
as sequencing.
166
Sequencing (Basic) mode

In the Sequencing mode, users do not have to define the flow between tasks or task
groups. Instead a sequence number is used to specify the order in which tasks or
tasks groups are executed. Using the sequence number allows users to define the
ordering between tasks quickly, without going deeply into TMS to create the flow
for tasks.
For example, change request users can add three tasks from the list in a task
template, and then specify the order in which they execute as 1, 2, and 3. This is
equivalent to configuring a successor and predecessor model as
Start Task1 Task2 Task3. Task1 will execute first, followed by Task2, and
finishing with Task3.
The sequence for each task or task group entered by users is converted to a flow
definition in TMS. In the previous example, when three tasks are ordered as 1, 2, 3,
three flows are created automatically as follows:
Flow#1 : Start
Task1
Flow#2: Task1
Task2
Flow#3. Task2
Task 3
In the order that the tasks and task groups are executed, there is no functional
difference between this flow definition and the sequence model implemented in
previous versions of ITSM. To apply a strict sequencing model, certain
configuration settings are fixed.
The Sequencing (Basic) mode has the following fixed settings on the flow object
that cannot be changed:
Evaluate if Predecessor Failure? No
Evaluate if Predecessor Canceled? Yes
Flow to Successor when All Complete
With these settings, all tasks and task groups in the same sequence must be
completed before the tasks or task groups in the next level in the sequence can
begin. For example, in the following illustration, task 4, 5, and 6 (at sequence level
2) are activated only if Task 1 and Task 2 (at sequence level 1) are completed.
Sequence 1
Task 1, Task 2
Sequence 2
Task 4, Task 5, Task 6
Sequence 3
167
Default sequence
When the task or task group is added, the default sequence is the next available
sequence level. For example, in the illustration that follows, if a Task 10 is added to
the list of existing tasks, then it would be set at sequence level 4.
Sequence 1
Task 1, Task 2
Sequence 2
Sequence 3
Sequence 4
Task 10
Changing the sequence
After a task is added, you can change the ordering using the sequence number.
Increasing the sequence number moves the task down the list. Decreasing the
sequence number moves the task up the list.
During runtime, the following rules make sure of the integrity of the process flow:
The sequence cannot move to a prior sequence level that is completed.
The sequence level cannot be changed on an active or completed task.
You can change the sequence number using the up and down buttons, or by setting
the sequence number directly in the corresponding column on the table field.
Note: Passing data values between Tasks or Task Groups is not supported while in
the Sequencing (Basic) mode. The system does not stop users from setting the
variable for a task or task group while in this mode. There is, however, no
assurance that this will work because the sequence can be changed, and the logic
for passing the data and variables between them might no longer be valid.
During definition phase, sequence and dependency information is stored in the
Flow template. During the execution phase, the association information is stored in
a separate Flow table.
168
Data exchange model: variable pool

The variable pool is a way for tasks to exchange data. This allows tasks to return
information and have the information passed to other tasks. Unlimited named
variables can be defined in a central repository of variables (or variable pool). The
named variables can be attached to a task group template, task template, flow
template, task group, or a task and flow. These attached entities can access the
variable values and assign values to the variables. Data exchange occurs when the
169
same variable is shared among these entities, such as a task group template, task
template, flow template, and so on.
In the configuration phase for variables, an administrator defines the variable that
will be used by the system. The variable definition consists of the variable name
and scope.
Variable scope
Definition
Local
The variable is available to the parent application

instance.
Global
The variable is available across different parent

application instances.
System
The variable is available to the parent application

instance, but is managed and maintained by the system.
When the variable is defined, it can be mapped to the task group template, task
template, and the flow template.
When the variable is instantiated, it will contain the data value, in addition to the
name and scope definition. These variables can be mapped to the task group, task,
and flow.
These variable definitions are stored in the Variable Template form. The
instantiated variable is stored in the Variable form.
Both defined and instantiated mappings for variables are stored in the Variable
Mapping form. A variable mapping has a direction characteristic of inbound or
outbound. When the instantiated variable is mapped to a task, the task reads an
inbound variable when work is about to begin for a task. When a task is finished, it
writes the value of the mapped outbound variable to the variable pool.
170
171
Complete example
During instantiation of a task group template, the task group and associated tasks
are created, based on the task group template definition. The flows and variables for
the tasks are also created.
172
ERD
Following is the entity relationship diagram for TMS.
173
Interfaces
In TMS, the TMS:TaskInterface interface form supports performing updates and
queries of a task by external systems. This form is a self-join of the main task form
(TMS:Task).
Web services
Associated data of the main Task form is exposed using web services. In addition to
the TMS:TaskInterface Task interface form, the TMS:WorkInfo and
TMS:Relationships regular forms are also exposed using the web services interface.
The interface structure consists of three components: the parent object and two
child objects. The parent object is represented by the TMS:TaskInterface form. The
associated child objects are Work Info and Related Items. In web services, these
three objects are rendered and presented as a single entity using the complex
mapping definition based on an XSD file. This single web services entity supports
the following primary interface operations:
Objects
Operation
Scope
Function name
Task
Update
Individual
UpdateTaskOnly
Query
Individual
QueryTaskOnly
Update Related
Individual Work Info
UpdateTaskAndWorkInfo
Update Related
Multiple Work Info
UpdateTaskAndWorkinfo
Create Related
Individual Work Info
UpdateTaskAndWorkinfo
Query Related
Multiple Work Info
QueryTaskPlusWorkInfo
Task and
Relationships
Query Related
Multiple
Relationships
QueryTaskPlusRelationships
Task,
Relationships,
and Work Info
Query Related
Multiple
Relationships and
Work Info
QueryTaskPlusRelationshipsAndWorkInfo
Task and Work

Info
174
Permission model
TMS has four levels of accessibility:
Task Administrator (level 1)Controls template definition, with access to all

tasks and task groups.
Task Manager (level 2)Can perform task implementer functions and also
instantiate task group templates and task templates from the parent object. Can
also create and update all tasks that are associated with the parent object.
Task Implementer (level 3)Can update and work on tasks that are assigned to
him or her.
Task Viewer (level 4)Can view tasks in read-only mode.
175
Backmatter.fm Page 17 Sunday, October 15, 2006 11:47 AM
Backmatter.fm Page 18 Sunday, October 15, 2006 11:47 AM
*34756*
*34756*
*34756*
*34756*
*65743*

Remedy Architecture

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Remedy Architecture

Transféré par

Droits d'auteur :

Formats disponibles

BMC Remedy IT Service Management 7.

Copyright 19912006 BMC Software, Inc. All rights reserved.

BMC Software, Inc.

Associated information ERD .......................................................................... 48

Process flows................................................................................................. 109

Interfaces ....................................................................................................... 174

BMC Remedy Service Desk

BMC Remedy Change Management

BMC Remedy Asset Management

Command Automation Interface

Definitive Software Library (DSL)

Requester Console and SRMS framework

Task Management System (TMS)

ITSM suite description

Features and benefits

Translate business objectives into IT services by facilitating a dialog to define

Increase the responsiveness of IT organizations to the business by providing

Integrate real-time IT and business impact information, including route cause

Provide visibility into your infrastructure

Quickly discover which underlying IT resources are causing business service

Manage IT and service information at an enterprise scale with secure

Allow for the identification of chronic bottlenecks and service-impacting

Provide real-time event consolidation, processing, and integration with existing

Enhance customer satisfaction

Facilitate the creation and maintenance of a service model by not only

Enable staff with interactive notification, escalation, and resolution capabilities

Define, measure, and manage the quality of service experienced by a group of

ITSM suite architecture

Service Desk process

Change management process

BMC Atrium CMDB, to handle targeting of CIs for changes, and

BMC Atrium CMDB, to integrate the change management process with

Asset and Configuration Management process

Back-office primary systems

Examples of subsystems include Task Management System, Costing Management,

BMC Atrium CMDB

BMC Atrium CMDB

BMC Atrium CMDB

BMC Atrium CMDB

An application or system provides a higher level theme of functionality that is

Subsystems are self-contained, modular, and extendable systems of functionality,

A subsystem in development is architected and designed to be modular and support

Segments of workflow and forms can be easily leveraged to perform a common

The foundation is comprised of infrastructure workflow and reference data. These

Common application models

Definition of entry points

Ability to import and export as a whole component

Incident Management (licensed)

Problem Management (licensed)

Change Management (licensed)

Asset Management (licensed)

Costing Management (licensed)

Task Management System

Definitive Software Library (DSL)

Change Management Dashboards (licensed)

Application Administration Console

Foundation sub-elements, such as message boxes and so on

Abstraction using roles

Predefined permission groups to support the roles

User access using support groups

Abstractions using roles

ViewerProvides the ability to view data in a system or subsystem, but not to

UserProvides the ability to modify data, based on support group access.

MasterProvides the ability to modify any record.