Professional Documents
Culture Documents
BMC® Remedy® IT Service Management 7.0 Archetecture
BMC® Remedy® IT Service Management 7.0 Archetecture
Architecture
October 2006
Copyright 1991–2006 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.
3
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
4
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
5
Process flows................................................................................................. 109
Main forms .................................................................................................... 110
ERD............................................................................................................... 112
Interfaces ....................................................................................................... 116
6
Interfaces ....................................................................................................... 174
Web services ................................................................................................. 174
Permission model .......................................................................................... 175
7
8
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
9
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).
10
• 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.
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.
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.
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.
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.
• 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 handle targeting of CIs for changes, and
understanding their relationships with other CIs and business services.
• BMC Atrium CMDB, to integrate the change management process with
Configuration Management for pushing changes to the infrastructure.
12
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.
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.
13
General Flow… Primary ITSM
Apps
End
Users Supporting
Applications
Request
Console
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 subsystem’s function, without embedding functionality from other applications
that use its services.
Request
End User
Console
SRMS Framework
CAI
ITSM Foundation
Primary Systems
Foundation
Subsystem Subsystem [DSL] [CAI]
Location CAI ITSM Foundation ITSM Foundation
Organization
People ITSM Foundation
Support Groups
Categorizations
Notification Engine
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
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.
• 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.
Systems
• 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-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.
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.
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.
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.
19
For example, the following computed group is used to define including all users for
each application in the Cost User role.
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
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.
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 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.
• 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
24
Overview console
(contains table pointing to
Vendor form)
Vendor form
(based on
SHR:ARDBCForm)
ARDBC plug-in
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
HPD:Associations Target
Incident Target Request
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:
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.
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.
• Sites identify unique physical locations and are associated with one or more
companies.
• The Company field and Site field are required on all ticket forms.
• Workflow can be defined to any level of the Location structure.
28
ERD
SIT:Site Alias
* 1111 * *
*
*
COM:Company
11
1
* *
29
Organization
Organization describes the role the company component plays in the foundation.
ERD
* 1 1
11
*
* * *
* 1 11 1 *
1
CTM:Support Group Assignments *
CTM:Support Group On-Call
*
*
CFG:Approver Lookup
SIT:Site Alias
* 11 * *
30
N
1
COM:Company Alias COM:Company
N 1 1
Company Alias Company
Company ID Company ID
Primary Alias Company Type
1
N N N
SIT:Site
SIT:Site Group Logical Site SIT:Site Company
Site ID (system generated)
Assoc Association
N 1 N N
Address Details (comprised of):
Company Company
Street
Site Group Region
Country
Site Group Type ("Logical") Site Group
State/Province
Site ID Site ID
City
Zip/Potal Code
Time Zone N
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 individual’s contact information, their organization, and
location structures information.
31
ERD
Site Financials
- Cost centers (multiples)
- A person belongs to a Company and location - Hourly rate, Accounting code
- A Support Staff belongs to a Support Group
CI Associations
Permission Groups - associate to CIs with type: uses,
- for Support Staff only manages, supports, owns
- allows users access to various
modules
Approval Mapping
Login and Licensing - for Support Staff only
- Approval mapping for Change and
Information User Change Management
- stores Login ID and password
- Fixed/Floating/Read license Notification Preference
- for Support Staff only
- System pre-defined and User-
defined notification preference
based on events
Application Permissions
CTM:People
1 *
Data Access
1
*
* *
* *
* * * *
*
CTM:People Worklog CTM:Support Group Association AST:AssetPeople FIN:CostCenterAssociation CTM:People Permission Groups NTE:CFG-NotificationEvents
* 1 1 *
1 1 *
CTM:SupportGroup
FIN:ConfigCostCentersRepository User
CMDB
Combination of Support Group and Person ID Classes
CTM:SupportGroupFunctionalRole
32
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.
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 P
33
Support Group ERD
COM:Company
* 1 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
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
Product categorization
1 *
1 *
* *
PCT:ProductModelVersionPatch
Operational categorization
1 *
35
CFG:Service Catalog
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.
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.
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 back-
end tables.
The workflow looks into the CFG:Assignment form to determine the group to
assign, using four different inputs:
• Organization
• Location
• Operational categorization
• Product 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.
• Number of Tickets Assigned rules assigns the record based on the person who
has the lowest number of records assigned.
• Round Robin assigns the record to the next person in line.
• 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.
38
Assignment process definition:
The following qualification is used to find the set of people to apply load balancing
rules on:
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.
40
Individual assignment:
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
r
e
e
g t 1
n s
e
u C hang e
a
h q In itiatio n a n d
C e R ec o rd in g
R
re
e tn
g e 4
n m
a Change
h le
C p Im p lem e n ta tio n
m
I
e
e r
n te 3
g ta
i
s M )t Change
s r
e P la n n in g an d
A tc p
e S c h e d u lin g
g je
b
x
E 5
n u 2 C hang e
a
h S R e vie w a n d
C ( C o m p letio n an d
A u th o riz e C lo su re
re
g
a
n
a
M
e
g
n
a
h
C
e re
g v
n o
a
h r
p
C p
A
/
tr s
o e
p s
p s P ro b lem In c id e n t R e q u es t
u e
S c M anagem ent M anagem ent M anagem ent
e o
c r
P
i
v
r y
re
e
S v
r li C o n fig u ra tio n M a n a g e m e n t
e
h e
D
t
O
,I .
42
The primary sources of change requests are:
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
• 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.
• Support console
• Task viewer
• Costing (actual)
• Work info
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.
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 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
48
The following ER diagram illustrates how these primary data elements can be
related to the change request by way of the association forms (shaded).
HPD:Help Desk
Problem Management
PBM:Problem
Investigation
LDAP
PBM:Known Error
TMS:LDAPUser
PBM:Knowledge
TMS:LDAPGroup Database
Asset Management
AST:Configuration
PDL:Software
LibraryItem
AST: CI
CHG:Associations
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
The following ER diagram illustrates how these primary data elements can be
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 CFG:Reminders
ookup
SRM:Request
CHG:ChangeRisk CHG:Impacted
Factors Areas
CHG:Infra.
Foreign Key: Change Effort
SRInstanceID Log CFG:Broadcasts
TMS:Task CHG:WorkLog
TMS:TaskGroup
Foreign Key:
Instance ID
50
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
The following ER diagram illustrates how these primary data elements can be
looked up and stored as local data on the change request.
CTM:Support
COM:Company CTM:People
Group
Requested By
Requested For
Manager
Assignee
Implementer
Operational Category
CFG:Service
Catalog
CHG:Infrastructure
Change PCT:Product
Product Category
Catalog
Region/Site Group/Site
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 AST:*
CHG:Infrastructure
Change
PBM:Knowledge
Database TMS:TaskGroup
FIN:Costs
TMS:Task
COM:Company
Requested By CTM:Support
Requested For Group
Manager
Assignee
Implementer
CTM:People
Product Category
PCT:Product
Catalog
Region/Site Group/Site
SIT:Site Group
CHG:Change CFG:Broadcasts TMS:Flow TMS:Task
Request Audit
SIT:Site
CHG:ChangeRisk
FactorQuestionL CFG:Reminders
ookup TMS:FlowBuilder
TMS:TaskGroup
CHG:ChangeRisk CHG:Impacted
Factors Areas
TMS:SummaryData
CHG:Infra.
Change Effort CHG:WorkLog
Log
53
Main forms
The following table lists the main Change Management forms:
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.
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 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
Plug-in
Container
CCM Calendar
Calendar
Plugin
Request Event
Dispatcher Dispatcher
JavaScript
Files
Model
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-in’s 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 server-
side 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
Architectural overview
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.
• 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.
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.
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.
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.
67
Process flows
CMDB
Asset manager
1
2 3
Configuration 4
Configuration Configuration
management Configuration control
identification specifications
planning
5
Configuration
audit and
verification
Configuration auditor
and other related processes
RFC
Service support,
service delivery,
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:CORE:BMC_ComputerSystem
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.
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.
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.
71
Asset Management ERD
Contracts
1
* 1
1 AST:AssetWarranty
* *
*
* * * * *
AST:Asset Lease
AST:Schedule Assocations FIN:CostAssociation AST:AssetCost AST:WorkInfo AST:AssetPeople
1 * *
AST:AssetMaintenance
1 * *
Integrated Systems
HPD:Help Desk
PBM:Problem Investigation
* PBM:Known Error
*
CHG:Infrastructure Change
TMS:Task
72
Asset Management system forms
Main Asset Extensions AST:Impacted Areas Tracks the locations that are
affected by this CI having an
outage.
73
Component Form Comments
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.
AST:Contract _PD_Relationship
Product ID
Product Instance ID AST:AssetSoftware (Join)
Model/Version ID
PMVInstance ID Contract Instance ID
Contract ID
Contract Instance ID
ProductCompanyAssociation 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
• Contains configurable rules for the License Management Engine.
• Users with Asset Config permission can access this form.
• It can also be accessed from the Application Administration Console.
76
The following table describes the fields in this form.
Field Description
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 CI’s 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, Fields to indicate what support group is defined as the notification group
Support Organization, for the given configuration rule.
Group
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.
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:
1 *
1 1
FK: Order Instance ID FK: Requisition Instance ID
* *
0..1 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
• CTM:People—Holds the contacts for a contract.
• Relationship table AST:CMDB Associations to the BMC Atrium CMDB
forms—Links contracts to CIs.
Warranty contracts
* * *
*
81
Support contracts
* * *
*
82
Lease contracts
* * *
*
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
* * *
*
84
Software contracts
* * *
*
* AST:CMDB AssociationsReconciliation ID
«subsystem»
* Top Package::CMDB Forms
* *
CTR:ContractBase
AST:Keys and Versions
Licenseable Product
* *
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.
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
AST:CI Unavailbility
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
1 1
AST:Schedule Criteria
Subsystem integration
The following subsystems are used by Asset Management:
• Cost Management
• Service Level Management
• BMC Atrium CMDB
88
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 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.
Interface Forms
AST:PurchaseOrderInterface form—Provides the mechanism for querying data in
the Asset Management purchase order system.
Web Services
AST:PurchaseOrderInterface_WS form—Provides the web service interface to
query data from Asset Management purchasing forms.
90
Permission model
Addition of two new AR System computed groups for view data in the CMDB.
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.
• Contracts
• Configurations
• Relationships
• Costs
• Schedules
• Outages
• Returns
• Activities
• Impacted
areas
Manage Access to all No access from No No access No Access
Inventory inventory Asset access from Asset from Asset
functions Management from Management Manage-
console Asset console ment
Manage- console
ment
console
92
Asset Asset Asset User Asset Purchasing Receiving
Management Admin role role Viewer User role User role
component role
Read
access
from CI
forms
93
Asset Asset Asset User Asset Purchasing Receiving
Management Admin role role Viewer User role User role
component role
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
Change
Incident Known Management
Problem
Management Error To
Investigation
Process Management Correct
Errors
95
external application that integrates with Incident Management to generate incidents
based on events in the service model.
Process flows
Identification and
recording Investigation and Resolution and Incident
No
(Classification and diagnosis recovery Ccosure
initial support)
Resolution /
Customer
Incident Web
Workaround
Detected Self-Help
Validation
Incident Assignee Incident Assignee
1
Call to Incident
(Tier 1)
2 Resolution /
Classification Workaround
and Initial No Available Found
Support Resolution /
Event Monitoring Workaround 3
Incident Detected Investigation
and Diagnosis
Incident Queue
(Optional)
Manager
Manager
Incident
Other Service Support /
Delivery Processes
Capacity /
Request Change Problem Problem Problem Change Problem
Availability
Management Management Management Management Management Management Management
Management
Configuration Management
96
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.
Subsystem integration
The following subsystems are used by Incident Management:
• Requester Console
• Task Management System
• 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:
Get HPD:IncidentInterface
Application Object
Event or Set
100
Tasks are created in the TMS:Tasks forms. In ITSM 7.0, only integration for ad hoc
tasks is supported.
Service Desk
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.
104
ERD
Change Management
CHG:Infrastructure Change
Problem Management
PCT:Product Catalog
CFG:Service Catalog
PBM: Knowledge
HPD:Help
SIT:Site Database
Desk
Asset Management/
CMDB
:
CTM:People Organization
AST: CI
HPD:Association Unavailability
BMC:*
CMDB Classes
CFG: Broadcast
FIN: Costs FIN: Association HPD:Help Desk Association
CFG: Broadcast
TMS:Task
Foreign Key:
Incident Number HPD:ImpactedAreas
Foreign Key:
Incident Number 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
Used in various contexts, key back is the login ID
for each of these areas:
- 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.
ITSM
Creates an association Association
External forms
application with a CI if a CI name
is specified
HPD:Work Log
Interface forms
• HPD:IncidentInterface_Create—Interfaces with the HPD:Help Desk form
to create incident tickets.
Web services
• HelpDesk_QueryList_Service—Queries for multiple tickets 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:
Permission model
The permission model of the Incident Management application has five basic roles:
• Incident Viewer
• Incident User
• Incident Master
• Incident Submitter
• Incident Config
Problem investigation
The problem investigation module of Problem Management is focused on
determining the root cause of an infrastructure problem.
108
Known error management
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:
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
ITSM Problem Management Process Overview
Requester
Investigation
Initiated
Problem Assignee
3
8
Problem
5 Knowledge
Investigation
Known Error Identification
and Diagnosis
Identification and Recording
and Recording
6
9
Known Error
Knowledge
Classification
1 4 Validation and
and 7
Problem Problem Publication
Assessment Known Error
Identification, Resolution and
Resolution and
Recording and
Problem Manager
Closure
Classification Closure
2
Review
Other Service Support /
Delivery Processes
Change
Incident Incident Change Implemented Incident
Management Management Management Management
Configuration
Management
(Mgmt Reports)
109
Main forms
This section describes the main forms used in Problem Management.
Problem investigation
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.
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.
This form provides the repository of work log entries associated with individual
problem investigations.
110
Known error management
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.
This form provides the repository for associations between known errors and other
records. It holds the context of the record being displayed.
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.
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
CFG:Service Catalog
Solution
PBM:
Database
SIT:Site
Asset Management/
CMDB
:
CTM:People Organization
AST: CI
PBM: Associations
Unavailability
BMC:*
CMDB Classes
Problem
PBM: CFG: Broadcast
FIN: Costs FIN: Association Investigation Association
CFG: Broadcast
TMS:Task
Foreign Key:
Incident Number PBM:ImpactedAreas
Foreign Key:
PBM:Work Log
Incident Number
112
CTM:People
Used in various contexts, key back is the login ID
for each of these areas:
- Manager
- Assignee
- Requester
CTM:Company
Used in various contexts, key back is the
company name for each of these areas:
- Requester Company
- Mannger Support Company
- Assingee Support Company
- Vendor Company
- Company (also known as the operational
company)
CTM:Support Group
Used in various contexts, key back is the login ID
for each of these areas:
- Requester Support Group
- Assignee Support Group
- Manager Support Group
113
Change Management
:Infrastructure
CHG::
Change
Problem Management
CFG:Service Catalog
Solution
PBM:
Database
SIT:Site
Asset Management/
BMC Atrium CMDB
:
CTM:People Organization
BMC:*
CMDB Classes
TMS:Task
Foreign Key:
Incident Number PBM:Known Error Work Log
114
CTM:People
Used in various contexts, key back is the login ID
for each of these areas:
- Manager
- Assignee
- Vendor
CTM:Company
Used in various contexts, key back is the
company name for each of these areas:
- Mannger Support Company
- Assingee Support Company
- Vendor Company
- Company (also known as the operational
company)
CTM:Support Group
Used in various contexts, key back is the login ID
for each of these areas:
- Assignee Support Group
- Manager Support Group
115
Change Management
:Infrastructure
CHG::
Change
Problem Management
CFG:Service Catalog
Solution
PBM:
Database
SIT:Site
Asset Management/
BMC Atrium CMDB
:
CTM:People Organization
Solution AST: CI
PBM:
Associations Unavailability
BMC:*
CMDB Classes
Solution
PBM:
FIN: Costs FIN: Association Database
Foreign Key:
CTM:Company
Assignee Company
TMS:Task
Foreign Key:
CTM:Support Group
Support Group
Foreign Key:
Incident Number PBM:Solution Work Log
Interfaces
• PBM:ProblemInterface_Create
• PBM:ProblemInterface
116
• PBM:KnownErrorInterface
• PBM:SolutionsInterface
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.
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.
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.
1 Event
What Data Values 3 Command
HowContent 5 RuntimeJust
Command
Do It
2 4
App Registry
ID Name Protocol
Commands
Command Direction Op. Type
Parameters
Done
Param Data Type 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:
118
TargetKeyword (SRMS, TMS, APP)—APP means back-end application.
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 plug-
in 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
1 . Register registered
U1 InstanceID AppRegistryName
U2 AppRegistryName Command
ApplicationName CommandParam
ApplicationInstanceID AppInterfaceFormName
Protocol AppFieldName
Connection Info AppFieldID
Interface Form Names ParamType
ParamDataType
0 . Create commands and
command paramters
CAI :CommandParam
CAI : Command
U1 Command U1 Command
U1 CommandParam
Direction
OperationType Type
SelectionType DataType
Mode
Calls GetEntry to
Execution (outbound) get event values
AR System
Filter API Plug-in workflow
Mapped Param
120
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.
U1 InstanceID AppRegistryName
U2 AppRegistryName Command
ApplicationName CommandParam
ApplicationInstanceID AppInterfaceFormName
Protocol AppFieldName
Connection Info AppFieldID
Interface Form Names ParamType
ParamDataType
0. Create commands and
command paramters
CAI:Command CAI:CommandParam
U1 Command U1 Command
Direction U1 CommandParam
OperationType Type
SelectionType DataType
Mode
CAI:Event Construction
CAI:EventParam
EventGUID
Event
Source EventGUID
Target ParmName
SourceAppRegistryInstanceID ParamValue
AOIGUID ParamAttachmentValue
AppInterfaceFormName ParamType
TargetConnectionInfo ParamDataType
RtnCode
RtnMsgCode Push event and run-time data to
RtnMsg event params (outbound)
MaxRetries
RetryCounter
SRMS/TMS
Calls GetEntry to
Execution (outbound) get event values
Mapped Param
122
Component Design
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.
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:
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.
CAI:CommandParamsMapping
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 command’s 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.
CAI:Events
2. When an entry is
created in the CAI:Events
form, the CAI plug-in is
called
CAI:EventParams
4. When a request
3. The CAI plug-in
is added to the
creates an entry in the
queue, a signal is
request queue and
issued to wake up a
returns Status =
thread in the thread
Running to CAI Events
pool to process the
form
Main Plug-in request. CAI Plug-in
Request queue
code Thread Pool
5. CAI plug-in
creates Change
Request and/or
Incident
HPD:HelpDesk
CHG:Infrastructure Change
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:
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.
Operation Form
Base form Operation description name Interface form* type
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 data-
flow 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:ContractPayments
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.
128
Each Contract Management permission group is mapped to an Asset Management
permission group, as shown in the following table.
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.
The costing forms and workflow are encapsulated in a deployable application. This
provides the ability to license and abstract the roles for the subsystem.
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
Interface Form
Functions:
Creating Automatic Cost Entries
Updating Automatic Costs
Lock Cost Entries
Copy Cost Record
Request 112 update on Associated Costs
130
ERD
FIN:Association
Filter API
FIN:CostAssociationJoin
FIN:ChargeBacks
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:
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.
The BMC implementation of the DSL was designed around these principles and is
structured to:
132
Architectural overview
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 Request
• Product Lookup
• DSL Reference
• Related CI Targets
CMDB
Configuration
Discovery
Definitive
Software
Library
Policy Deployment
Task Manager Manager
Management
System
Command
Automation Common Management Services
Task Implementer Interface
133
The following diagram provides a high-level illustration of how these components
are organized as part of the DSL.
• Product Name
• Version Software
S/W Library
Library
Item
Item
• Patch
Software
• Manufacturer
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
Company -PIID
1 +PMVIID
- CIID ProductCompany . ProductDictionaryPatc SLI
+PatchLastBuildIn 1
+ Company -A
PIID D h
-PMVIID -SLIIID
+ Type nn 1
+ CIType -ProductIID +VIID
+ ProductCat1 -PatchIID +Description
+ ProductCat2 ProductDictionary -. +Type
+ ProductCat3 n -. 1 n +State
-VIID
-. +Location
-PIID
+CIType
n 1
Product 1 +ProductCat1
+ProductCat2 1 1
- PIID ProductModelVersion
1 +ProductCat3
+ CIType - VIID +PMV State
+ ProductCat1 n n
- PIID +Product Name
+ ProductCat2
+ CIType 1 +Manufacturer
+ ProductCat3 PV_Files Lookup
+ ProductCat1 Attachments
+ ProductCat2 +VIID -Attachment
+ ProductCat3 +FileID +DSL
IID IID
n
+ PMV State +Description
+ Product Name +Attachment
+ Manufacturer
n
Version
-VIID
n
+ PIID n n
+ PMV State
+ Product Name
+ Manufacturer Suite_PD Lookup Files
+SuiteIID -FIID
+VIID +Name
+FileSize
Legend +CRC
Vendor Version
+TimeStamp
- VVIID Foundation Objects
+ Description
+ VersionString PD/DSL Objects
+ ComponentNam
Only required fields are represented
.
135
PCT:ModelVersionPatch
PK Instance ID
PCT:Product Catalog PCT:ProductCompanyAssoc Product Name
PK Instance ID PK InstanceID Model Version PDL:ProdDictionaryPatch
PatchLastBuildID
ProductID Add DSL Fields MainExeID PK PatchIID
ProductIID
CI Class Company MainExeName
ProductCatTier 1 ProductID
ProductCatTier 2 CI Class
Origin JOIN JOIN JOIN ProductCatTier 1
ProductCatTier 3
IsSuite ProductCatTier 2
Product Name
Manufacturer ProductCatTier 3
Price ProductName
Product 's Image PDL:ProductDictionary Manufacturer
ManufacturerID
PK VersionIID GUID
PDL:ProductModelVersion OS
ProductID MainExeID
PCT:Product Mod/Version Add DSL Fields PK InstanceID CI Class MainExeName
ProductCatTier 1 Origin
PK Instance ID Product ID ProductCatTier 2 IsSuite
PMV ID ProductCatTier 3 Locale
PMV ID GUID ProductIID ProductName Platform
Product IID OS ProdModVer Manufacturer ProductID
ProdMod Vers Locale PMV State ManufacturerID PMV State
PMV State Platform ProductName GUID ProductName
Product Name VersionMajor ..... OS
Manufacturer VersionMinor OS Origin
PatchLastBuildID VersionBuild Locale IsSuite
ManufacturerPartNo VersionMaint Platform Locale
GeneralAvailDT ManufacturerID VersionMajor Platform
DiscAvailDT VersionMinor PMV State
DiscSupportDT VersionBuild ProductName
PreReleaseDate VersionMaint
Data example
Model/Version Patch
136
Interfaces
Three interface tables support submit, modify, and query operations performed by
external systems.
The following are the interface (staging) forms for the DSL:
137
Software Library Item submit
ITSM
External
application
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_Service—Queries using a qualification statement for
multiple Product Dictionary entries in the PDL:ProductDictionary form.
• PD_QueryListFields_Service—Queries 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_Service—Queries using a qualification statement for
multiple Product Dictionary Patch entries in the
PDL:ProductDictionaryPatch form.
• PDP_QueryListFields_Service—Queries specifying field values to search
on for multiple Product Dictionary patch entries in the
PDL: ProductDictionaryPatch form.
138
• Software Library Item
The following functions enable web service operations for the
PDL:SoftwareLibraryItem using the PDL:SLIInterface interface form:
• SLI_Modify_Service—Modifies a Software Library Item entry in the
PDL:Software Library Item form.
• SLI_Query_Service—Queries for a Software Library Item entry in the
PDL:Software Library Item form.
• SLI_QueryList_Service—Queries using a qualification statement for
multiple Software Library Items in the PDL:Software Library Item form.
• SLI_QueryListFields_Service—Queries 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:
Operation
Base form and type description Operation name Interface form
139
Permission model
DSL has the following permissions:
Requester
Console
Request object
Obj t
SRMS framework
Framework
OR
Change Incident
Management Management
140
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.
Architectural overview
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.
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 Requester The summary definitions provide the menu items for the
Console:SummaryDefinition 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 Serves as the entry point for users and supports their
Console:RequestConsole primary interactions. It provides the user interface for
submitting and viewing requests.
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.
143
Category Component Description
4. Completed 3. Incident
request 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.
144
• 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.
Architectural overview
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
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.
• 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
146
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 back-
end 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: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.
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.
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.
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
SRM:AppInstanceBridge
PBM:Solution
Database
SRM:Survey
FK:SRInstanceID
FK:SolutionRequestID FK:Originating_Request_InstanceID
FK:SRInstanceID
CFG:Service
COM:Company CTM:Region
Catalog
CTM:Support
SIT:Site Group
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 SRM:Request
PBM:Solution
SRM:AppInstanceBridge FK:SR_KnoweldgeDatabaseID
Database
FK:AOIGUID
HPD:Help Desk
FK:AppRequestInstanceID CHG:Infrastructure
CAI:Events 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 back-
end 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
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:
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:
3. Create event
SRM:AppInstanceBridge and event CAI:Event 4. FilterAPI invoked
param entries.
Service Request Instance ID Event Instance ID
AOI Instance ID Event Type=CreateAppRequest
Application Registry Instance ID AOI GUID=<AOI Instance ID>
Flow information SRMS Server=<SRMS server name>
App GUID=<Application ID >
App Server=<Application server name>
Question-response
When SR status = New; App Interface form = <App interface form
linked to service request.
status reason = AI Creation, name>
Create the event and event Source=SRMS
SRM:Service CAI Plugin
params. Return code = empty
RequestQuestionAssociation Return msg = empty
(NOT USED in RQC)
AOI Instance ID
Question Response Instance ID
5. CreateEntry to application interface
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
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
Service Request
SR GUID
Status
Cost
Event
AOI Filter API
In: Reg App Server, Event
Event GUID
SR GUID 4. Call Filter API Form, Event Param Form,
Event Command
AOI GUID Event GUID
2. Create outbound Event Status 7. Return code,
App Registry Rtn: Return Code, Return
create entry Protocol (AR) Return message
AOI Status Message
SRMS Server
App Instance GUID 8. Notify AOI that AOI GUID
App Instance ID command is done Reg App Server
App Instance Description Reg App Interface (Form) 5. AR API Call
App Instance Status 9. Update event App Instance GUID
App Instance Cost status=Complete Return Code
Return Message (Error) App Interface
App Instance
...
SRMS Server
SR ID
AOI GUID
...
153
Permission model
The SRM:Request form has the following permissions:
• Public—Hidden
• Request Master—Visible
• 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
Summary Summary Definition Provides create, view, and modify access to Requester
Definition Config Config Computed Console:SummaryDefinition.
N/A Summary Definition Base group for Summary Definition Config Computed.
Requester Requester Console Config This group is part of the Request Config Computed
Console Config** 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.
Note: General Access is needed for modify access.
154
AR System Map to group Comments
group or role
Requester Requester Console This group is part of the Request Master Computed
Console Master group.
Master**
Provides access to:
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
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.
Note: General Access is needed for modify access.
N/A Request Config Base group for Request Config Computed. Also part of
the Summary Definition Computed group.
General Access General Access Provides access to all general users who require modify
permission.
Assignee Group* N/A Provides row-level access based on the Company field.
Applies to SRM:Request records.
*Public, Submitter and Assignee Group are implied AR System groups; no Group
or Role entries are required.
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.
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.
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 Administrator’s Guide for information about
user features, configuration, and administration of the system.
157
Architectural overview
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.
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.
158
Flows
Associations
Container
Container
Object
Object
Data Flows
Task Group
Task Group Container
Template [0]
[0]
Application Object
OR
Application Object Instance
Template
Task
Task [A]
Template
[A]
AND
Application Object Application Object
Application Object Application Object Instance Instance
Template Template
Task Task
Task Task [B] [C]
Template Template
[B] [C]
Feature Set
Application Object
Application Object
Instance
• Related Items
Template • Automated Tasks
Task
Task • Launch
[D]
Template • Pass data betweenAOI’s
[D] • Reference Other Form
• Shared Work
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
Task Group 1
TaskTemplate 1 F2
F1 F1 Task 1 F2
F4 F3
F4 F3
F5 F6
F5 F6
Task Template 4
Task 4
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
F1 Task 1 F2
Task 2a Task 2b
F4 F3
Task 3a Task 3b
F5 F6
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
F1 F2
Closed/Success
Task 2a Task 2b
Closed/Success Closed/Failure
F4 F3
Task 3a Task 3b
Closed/Success Bypaased
F5 F6
Task 4
Closed/Success
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.
162
The following associations are stored in Associate table:
• [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.
• 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 ASSOC1 ASSOC3
AT2 ASSOC2
164
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.
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 Group
Task 1 Task 2
Task 1
Task 2
Task 3 Task 3
Example 1 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:
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:
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 4 Task 10
During runtime, the following rules make sure of the integrity of the process flow:
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.
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.
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:
174
Permission model
TMS has four levels of accessibility:
175
Backmatter.fm Page 17 Sunday, October 15, 2006 11:47 AM
Backmatter.fm Page 18 Sunday, October 15, 2006 11:47 AM
*65743*
*65743*
*65743*
*65743*
*65743*