BMC® Remedy® IT Service Management 7.0
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
[email protected]. If you have comments or suggestions about this documentation, contact Information Development by email at
[email protected]. This edition applies to version 7.0 of the licensed program.
BMC Software, Inc.
www.bmc.com
Contents Introduction ............................................................................................................. 9 ITSM suite description........................................................................................ 9 Features and benefits....................................................................................... 10 ITSM suite architecture.................................................................................... 11 Service Desk process....................................................................................... 11 Change management process .......................................................................... 12 Asset and Configuration Management process ............................................... 13 Conceptual architecture................................................................................... 14 Architecture philosophy .................................................................................. 15 Common application models........................................................................... 17 Foundation architecture ....................................................................................... 27 Reference data ................................................................................................... 27 Infrastructure model ........................................................................................ 27 Foundation components.................................................................................... 27 Company ......................................................................................................... 28 Location .......................................................................................................... 28 Organization.................................................................................................... 30 People.............................................................................................................. 31 Support groups ................................................................................................ 33 Categorization ................................................................................................. 34 Notification Engine ......................................................................................... 36 Assignment...................................................................................................... 37 BMC Remedy Change Management architecture ............................................. 41 Process flows ...................................................................................................... 41 Initiate and record ........................................................................................... 42 Review and authorize...................................................................................... 43 Plan and schedule............................................................................................ 43 Implement ....................................................................................................... 44 Complete and close ......................................................................................... 44 ERDs................................................................................................................... 44 Associations .................................................................................................... 44 Linking ............................................................................................................ 46 Lookup ............................................................................................................ 47
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 BMC Remedy Asset Management architecture ................................................. 67 Process flows ...................................................................................................... 68 User interface..................................................................................................... 68 Asset Management and the BMC Atrium CMDB.......................................... 69 Reconciliation ID ............................................................................................ 69 Sandbox........................................................................................................... 70 ERD .................................................................................................................... 70 Asset Management full ERD .......................................................................... 71 Asset Management system forms ..................................................................... 73 Software license management .......................................................................... 74 AST:LicenseMgmtIncludeClass ..................................................................... 76 AST:ConfigLicenseMgmt............................................................................... 76 AST:LicenseMgmtEngine............................................................................... 78 AST:LicenseMgmtException.......................................................................... 78 AST:ManageLicenseMgmtException............................................................. 78
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 BMC Remedy Service Desk architecture ............................................................ 94 High-level process flow ..................................................................................... 94 BMC Remedy Incident Management .............................................................. 95 Process flows................................................................................................... 96 Design overview.............................................................................................. 97 Main forms ...................................................................................................... 97 Subsystem integration ..................................................................................... 99 ERD............................................................................................................... 105 Interfaces ....................................................................................................... 106 Licensing model ............................................................................................ 107 Permission model .......................................................................................... 108 BMC Remedy Problem Management............................................................ 108 Problem investigation.................................................................................... 108 Known error management............................................................................. 109 Solutions database......................................................................................... 109
5
Process flows................................................................................................. 109 Main forms .................................................................................................... 110 ERD............................................................................................................... 112 Interfaces ....................................................................................................... 116 ITSM 7.0 subsystems........................................................................................... 117 Command Automation Interface ................................................................... 117 Overview ....................................................................................................... 117 ERD............................................................................................................... 118 Interfaces ....................................................................................................... 126 Permission model .......................................................................................... 127 Contract Management .................................................................................... 127 ERD............................................................................................................... 128 Interfaces ....................................................................................................... 128 Permission model .......................................................................................... 128 Costing Management ...................................................................................... 129 ERD............................................................................................................... 131 Licensing model ............................................................................................ 131 Permission model .......................................................................................... 131 Definitive Software Library ........................................................................... 132 Architectural overview.................................................................................. 133 Primary components of the DSL................................................................... 133 ERDs ............................................................................................................. 134 Interfaces ....................................................................................................... 137 Web services ................................................................................................. 138 Permission model .......................................................................................... 140 Requester Console and SRMS framework.................................................... 140 Requester Console......................................................................................... 141 SRMS framework.......................................................................................... 144 Task Management System.............................................................................. 157 Architectural overview.................................................................................. 158 Instantiation................................................................................................... 159 Association model......................................................................................... 162 Dependency model: flow mechanism ........................................................... 165 Sequencing (Basic) mode.............................................................................. 167 Data exchange model: variable pool ............................................................. 169 Complete example......................................................................................... 172 ERD............................................................................................................... 173
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
ITSM suite description The BMC Remedy IT Service Management product portfolio streamlines the processes around IT service desk, asset management, change management, and service level management, and also enables you to link your business services and IT infrastructure to help you manage the impact of technology changes on business and business changes on technology—in real time and into the future. In addition, you can define and measure service levels, understand and optimize the user experience, balance current and future infrastructure investments, and view
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).
Features and benefits With the BMC Remedy IT Service Management product portfolio, you can: Align business and IT
•
Translate business objectives into IT services by facilitating a dialog to define what the business needs, and get agreement on the specific services and service levels that IT will deliver to address those needs.
•
Manage assets to optimize business value by making sure your assets are supporting business-critical IT services, according to agreed-upon service levels.
•
Increase the responsiveness of IT organizations to the business by providing dynamic service views and service models showing how a single event can impact crucial business services.
•
Based on business needs and priorities, proactively manage service levels for mission critical services delivered by IT operations through real-time management of service level agreements.
•
Integrate real-time IT and business impact information, including route cause data, into incident tickets for improved user value.
Provide visibility into your infrastructure
•
Rapidly discover what physical and logical elements (servers, routers, switches, databases, gateways, web servers, application servers) and dependencies that comprise an application infrastructure.
•
Quickly discover which underlying IT resources are causing business service slow downs or outages.
•
Manage IT and service information at an enterprise scale with secure distributed roles and responsibilities.
•
Allow for the identification of chronic bottlenecks and service-impacting problems and workflow processes.
•
Provide real-time event consolidation, processing, and integration with existing tools and help desks, and notification for consolidated control across the entire IT computing enterprise.
Enhance customer satisfaction
•
10
Facilitate the creation and maintenance of a service model by not only discovering the components and relationships of enterprise application infrastructures, but also by watching for changes and proposing updates to the service models accordingly.
•
Enable staff with interactive notification, escalation, and resolution capabilities using remote devices to make sure IT and business issues are addressed quickly and efficiently.
•
Show how the IT assets and staff resources perform against contracted service levels.
•
Define, measure, and manage the quality of service experienced by a group of users.
ITSM suite architecture The ITSM suite is designed with an overall architecture in mind. Each application in the suite must work as a standalone application, and also must integrate seamlessly and provide additional value when other products in the suite are installed. The diagram that follows describes that typical data flow supported by the ITSM suite. Users initiate the process using the Requester Console. The Requester Console lets users pick what they want to ask for without understanding if the fulfillment mechanism for that request is an incident or a change request. Depending on what a user asks for, the Requester Console routes the request to the incident management process or the change management process.
Service Desk process The Service Desk process includes the process flows required to resolve outages and keep the customer working at the appropriate level, as defined by the companies’ Service Level Agreements (SLAs). Two processes support the Service Desk: Incident Management and Problem Management. When starting at the Requester Console, the incident management process is one branch the flow can go through. Incident Management 7.0 is compliant with the ITIL definition of being a process whose main purpose is to get the user back up and running. To support that concept there are several interactions that help achieve that goal. If the Service Level Management (SLM) application is installed, Service Level Agreements (SLAs) and Operational Level Agreements (OLAs) can get attached to the incident, based on who is making the request, the urgency of the issue, and the business services that are being affected by the issue. Incident Management uses the knowledge database to provide the technician working the issues with information about like issues that might help resolve the problem as quickly as possible. Incident Management also comes with, and tightly integrates with the BMC® Atrium™ CMDB, to provide a repository for the configuration items (CIs) in the organization. CIs can be related to the incident to indicate where the issue is
11
happening. You can use the BMC Service Impact manager to look at possible root causes, and to determine the level of response and resolution required. While the incident management process is designed to resolve outages and get the customer working as quickly as possible; for some issues, a root cause might not be determined. For those issues, a problem investigation can be initiated. The problem investigation provides the constructs for determining the root cause, tracking it as a known error, and making determinations if the error is something that should be corrected in the environment using a change request, or if a work-around can be provided that can be used instead. Incident Management and Problem Management can also be processes initiated outside of a requester. For example, Incident Management can be integrated with the BMC Service Impact Manager or the BMC Event Manager to automatically generate incidents based on events in the infrastructure. For an integration with Service Impact Manager, the event can be correlated to the business services that are being affected, and generate incidents with the appropriate CIs related for resolution. Problem Management can also be initiated using a proactive problem management approach, where the environment is viewed for trends by reporting. Problem investigations are then generated.
Change management process The change management process manages changes in the infrastructure. They can be large scale changes such as upgrading a set of vital systems, or smaller changes such as setting up new employees. The change management process is designed to be open to handle the many different types of processes that an organization might have. The process includes three layers of approvals that use the BMC Remedy Action Request System® (AR System) Approval Server as the engine to manage approvals. The change management process also integrates with the time management functionality in the underlying AR System platform to view conflicts between a scheduled change and other changes in the organization. Integrations that the change management process uses include:
12
•
BMC Service Impact Manager, to provide an insight into the risk of making a change, and the systems and business processes that will be affected.
•
BMC Atrium CMDB, to 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.
Asset and Configuration Management process The combination of the BMC Atrium CMDB and the Asset Management application provides the model for doing Asset and Configuration Management within it the ITSM suite. The configuration management process provides the model for maintaining the Configuration Items (CIs) that are important to the business, and controlling the updates that have occurred to those CIs in the Change Management process. Asset Management processes provide mechanisms to manage schedules, contracts, procurement, depreciation, and chargebacks. Primary integrations with Asset Management are at the BMC Atrium CMDB level. BMC Discovery solutions populate the BMC Atrium CMDB with information about the CIs in the infrastructure, and their relationships. The BMC Atrium CMDB also provides a federated integration model to link CIs to other applications, such as the BMC Service Impact Manager and other third-party products. Diagram of the ITSM suite architecture
13
Primary ITSM Apps
General Flow… End Users
Supporting Applications
Request Console
Change Management
Service Level Management
Incident Management
Asset Management
DSL
Problem Management
Knowledge
(Known Error)
BMC Atrium CMDB
Problem Management (Investigation)
Conceptual architecture The overall architecture of the ITSM suite can be separated into three layers: •
User subsystem
•
Back-office primary systems
•
Supporting subsystems
The top layer consists of systems that provide the interface to users, such as the Requester Console. The Requester Console is designed as a subsystem for users to create requests that interface with a back-office system, such as Incident Management or Change Management The back-office primary systems are the main applications: Incident Management, Change Management, Problem Management, and Asset Management. These systems contain logic and user interfaces specific to those application areas.
14
The final layer consists of supporting subsystems. This common set of subsystems supports the back-office systems. Subsystems contain generic logic that is specific to a subsystem’s function, without embedding functionality from other applications that use its services.
Back Office Primary Systems
End User Subsystem
Examples of subsystems include Task Management System, Costing Management, Contract Management, and so on.
Request Console SRMS Framework CAI ITSM Foundation
Change Management
Asset Management
Incident Management
Problem Management
BMC Atrium CMDB
BMC Atrium CMDB
BMC Atrium CMDB
BMC Atrium CMDB
Task Management
DSL
Task Management
Cost Subsystem
DSL
Cost Subsystem
Cost Subsystem
ITSM Foundation
Cost Subsystem
ITSM Foundation
ITSM Foundation
Knowledge
SLM
SLM
ITSM Foundation
Supporting Subsystems
SLM
ITSM Foundation Location Organization People Support Groups Categorizations Notification Engine
Task Management Subsystem
Cost Management Subsystem
Definitive Software Library [DSL]
CAI
ITSM Foundation
ITSM Foundation
Common Automation Interaction [CAI]
ITSM Foundation
Architecture philosophy Definitions of architectural concepts are key to a successful enterprise application development. They provide the guiding principals for how applications are designed and developed. The ITSM 7.0 suite of applications follows a strict set of principals based on a component development model. The following types of architectural structures are used in the ITSM 7.0 suite: •
Systems
•
Subsystems
15
•
Subsystem candidates
•
Shared components
•
Foundation elements
Systems
An application or system provides a higher level theme of functionality that is functional by itself, and can in part be made up of and supported by several subsystems. Examples include Change Management, Asset Management, Incident Management, and so on. Subsystems
Subsystems are self-contained, modular, and extendable systems of functionality, with well-defined and documented interfaces designed to support higher level systems. Examples include Task Management System, Approval Server, Assignment Engine, and so on. Subsystem candidates
A subsystem in development is architected and designed to be modular and support the characteristics of being a subsystem but without currently meeting the required rules of being a subsystem. The required rules for a subsystem include fully developed interfaces encapsulation as a deployable application, and so on. A subsystem candidate is the first stage of becoming a formal subsystem to be leveraged in a current release. An example is the Service Request Management System (SRMS) framework. Shared components
Segments of workflow and forms can be easily leveraged to perform a common operation. A shared component serves as a template for a foundation of functionality that will serve as a child to a parent system or subsystem. Examples include Yes and No prompt dialog boxes, message confirmation dialog boxes, the advanced qualification bar, and so on. Foundation elements
The foundation is comprised of infrastructure workflow and reference data. These are they primary components that are shared across the applications in the ITSM suite. These are analogues the key structures that make up a building. You need to have a strong foundation to build on. The foundational elements in the ITSM suite make up the key structural and data elements that are needed to build strong enterprise applications. Reference data Shared required data structures can be leveraged across different systems. Examples include categorization, company data, multi-tenancy model, and ITSM system forms.
16
Infrastructure model The infrastructure model can be thought of as the plumbing structure of how things fit together. Examples include the Notification Engine, association model, Deployable Application structure, tenancy model, and so on.
Common application models Deployable application structure
The AR System platform provides the structural component used in the ITSM 7.0 applications to define the deployable application architectural structure. Deployable applications provide functions that support a component architectural model. These functions are covered in following sections: •
Licensing enforcement
•
Encapsulation of permissions
•
Definition of entry points
•
Ability to import and export as a whole component
Deployable applications are used to wrap each of the different systems and subsystems that are provided in ITSM 7.0 applications. Deployable applications contain the following systems and subsystems: Systems •
Incident Management (licensed)
•
Problem Management (licensed)
•
Change Management (licensed)
•
Asset Management (licensed)
Subsystems •
Costing Management (licensed)
•
Task Management System
•
Definitive Software Library (DSL)
•
Change Management Dashboards (licensed)
•
Application Administration Console
•
Reporting Console
•
Requester Console
Helper •
Foundation elements
17
•
Foundation sub-elements, such as message boxes and so on
•
Site
•
Company
•
Product catalog
Licensing model
The licensing model has been extended in ITSM 7.0 to add application-level licenses and user-level licenses. All licenses in the ITSM 7.0 suite of applications are enabled by the deployable application model described previously. Application-level licenses Application licenses provide access to the forms that make up an application. If an application-level license is not applied to the AR System server, the forms are not accessible using user clients. This makes user licensing a requirement for importing data into the applications. Application-level licenses are enabled for the main applications provided in the ITSM suite. In addition, application-level licenses are required for the Change Management Dashboard and the Costing Management subsystems. User-level licenses ITSM 7.0 supports Fixed and Floating licensing models for users of the licensed applications. The ITSM suite supports a model that requires a license (in addition to any required permissions) to modify records in the application. There are no license requirements for submitting data into the system; however, there are permission requirements. Fixed licensing is a named license that gets assigned to a particular user. Floating licensing is a pool of licenses that is assigned to a set of users. Users take up tokens when they log in to an application, and hold on to those tokens while they are working with the forms in that application. Tokens are released when a user logs off or a system timeout is reached. Permission model
The ITSM suite has built a specific philosophy into how the model was designed for the ITSM suite. Main concepts defined include: •
Abstraction using roles
•
Common roles • Viewer • User
18
• Master • Administrator •
Predefined permission groups to support the roles
•
User access using support groups
•
Functional roles
Abstractions using roles Roles are provided by the AR System deployable application model. Roles are defined within the context of a deployable application. Forms and client-side workflow in a deployable application have roles defined for permissions instead of physical permission groups that users are assigned to. Permissions are enabled for a user by mapping the physical permission groups that are provided with the applications to the roles that the permission groups should belong to. By doing this the underlying systems and subsystems can change and control their permission models without affecting how other applications integrate with them. This also allows other applications outside of the ITSM suite to integrate with ITSM systems and subsystems. Customers can also build their own sets of permissions groups to map into the systems and subsystems. Common roles To simplify and provide commonality amongst the applications, each system and subsystem provides a common set of roles. The system or subsystem can extend these roles for other specific purposes as needed. The common roles are: •
Viewer—Provides the ability to view data in a system or subsystem, but not to modify data.
•
User—Provides the ability to modify data, based on support group access.
•
Master—Provides the ability to modify any record.
•
Administrator—Provides the ability to configure the system or subsystem.
Predefined permission groups To support this model, the applications provide predefined explicit permission groups that map to roles for each of the systems and subsystems. Also, as shipped, these permission groups are also mapped to the appropriate roles that are needed from the underlying subsystems. For example, all roles that require costing data access are mapped to the Financial User role. This predefined configuration makes it simpler to configure permissions in the application, while still providing the underlying control. To enable an easy mapping mechanism, the AR System computed group is used. Computed groups let you define which groups make up the definition of a group.
19
For example, the following computed group is used to define including all users for each application in the Cost User role.
User access using support groups Support groups play a primary role in the permission model for ITSM 7.0. If a user is a member of a user role, the definition of what records they can modify is based on if that record has been assigned to one of their support groups. For example, if users are in the Incident User role and are members of the Hardware support group, they can only modify incidents that are assigned to the Hardware support group. They can view other incidents, but they will not be able to modify those incidents. Functional roles Functional roles are not permission groups, but are enforced by workflow. For example, the Manager or Approver role within a support group provides additional privileges within the application functions. Based on your support group, you can have different functional roles. For example, in the Hardware support group, someone can be defined as a manager, but in the Software support group that person might just be a member. Multi-tenancy model
Multi-tenancy defines who has access to what data on a row-level basis. For example, in a service provider environment a single application might be used by multiple companies, with the data for each company hidden from other companies using that application.
20
In ITSM 7.0, multi-tenancy is defined using companies. Companies are defined as operating companies, and users are associated to these operating companies to define their access rights. A user is associated to a company through the People form, shown here:
A user can manage multiple companies by adding more companies to the Access Restrictions list. If a user needs to manage all companies, access can be set to Unrestricted. Implementation of multi-tenancy The services provided by the AR System platform are primary to the implementation of multi-tenancy. AR System enables you to control access to data based on permission groups, and determine if those permission groups have access to individual rows of data. This implementation uses a special set of fields that hold the list of permission groups that have access to a row. The ITSM suite uses field ID 112 to enable this feature, although other field IDs are available on the AR System server and are used by the BMC Atrium CMDB. This special field 112 is populated on main application forms based on the companies that are picked to access that record. For example, when you select the contact and classification companies on the Incident form, workflow updates field 112 values with the group IDs that have been assigned to those companies. For child records, such as the tasks or costs associated to an incident, the tenancy information is passed down from the parent.
21
After field 112 is populated, any query to AR System displays only rows of data that a user has permissions to, based on their permissions, and the permissions in field 112. Integration model
One of the main architectural requirements for the ITSM suite is that all systems and subsystems must provide defined interfaces for integration purposes. These interfaces abstract the applications that integrate with the systems and subsystems from the inner workings and from differences in versions. The common model for interface forms is to use display-only forms to manage the creation of records and relationships, and to use join forms to manage queries and modify actions. BMC strongly recommends that all integrations to Incident Management, Problem Management, Change Management, Task Management System, and Costing Management go through the provided interface forms. This will abstract any future integration from underlying changes to those systems and subsystems. In addition to the interface forms, web services are provided for most of the applications. The web services interfaces are a layer on top of the interface forms, and provide basic create, modify, and query capability to the applications and subsystems. For more information about using interface forms and web services, see BMC Remedy IT Service Management 7.0 Integrations white paper. Console structures
Consoles are the main user interface to the ITSM 7.0 applications. Two types of consoles are provided: application-specific consoles that provide application specific functionality, and common consoles that are used across applications. Each ITSM application has a console that is focused on the support technician and a console for the manager. The main difference between these role-based consoles is the layout and the addition of high-level overviews for managers using of graphs and charts. The common consoles include an overview console that combines assigned work from all applications into one view, and a requester console that is focused on the users. Application consoles Each application console has two views. One focused on the support technician, and one on the manager. In addition, the Change Management console also provides the ability to change the support console to focus the work on tasks or change requests.
22
Overview Console The overview console provides a view of work assigned across multiple applications. For example, if users wants to see all incidents, problems, and tasks assigned to them, they can view them in the overview console. This implementation uses an ARDBC AR System plug-in to provide a consolidated view of all assigned work from data sources in multiple applications without using replication of data or complex SQL views that bypass APIs. The plug-in architecture is data-driven. Configuration forms define how the plug-in is set, including which forms to query, which fields to map to the table field, and a ARDBC form that performs the query. ARDBC plug-in data setup: •
SHR:ARDBCForms
•
SHR:ARDBC_OverviewConsoleTemplate
•
SHR:ARDBCFields
Ticket types: •
Change
•
Incident
•
Problem Investigation
•
Known Error
•
Knowledge
•
CI Unavailability
•
Purchase Requisition
23
ARDBC plug-in initialization process ARDBC plug-in is loaded by the AR System server. This triggers the ARDBC initialization functions to run.
ARDBC plug-in queries SHR:ARDBCForms to get a list of forms available for use with this plugin, and caches this information.
ARDBC plug-in queries SHR:ARDBCnumLookup form to get status mapping between ConsolidatedStatus on Vendor form and individual forms.
For each form, ARDBC plug-in queries SHR:ARDBCCFields form to get a list of fields to retrieve from each form, and the mapping of those fields to the Vendor form. This information is also cached.
24
Overview console (contains table pointing to Vendor form) 1. Query vendor form to populate a table on the console
6. Results are displayed in the table
Vendor form (based on SHR:ARDBCForm)
5. ARDBC plug-in consolidates results lists and returns vales to Vendor form
2. Querying vendor form triggers ARDBC plug-in
ARDBC plug-in
3. ARDBC plug-in uses cached information on forms to consolidate and field mappings from these forms to the Vendor form ARDBC plug-in also constructs a qualification for each form to query, based on field mapping configuration information
4. ARDBC plug-in queries forms and retrieves results
HPD:Helpdesk CHG:Infrastructure Change TMS:Task
Relationship Model
All ITSM 7.0 applications use the same basic structure for relationships between each application. The structure is based on each application having a relationship table that shows information in the context of that application while looking out to the other applications it is integrating with. When a relationship is created between two applications, two relationship records are created, one in each of the applications relationship tables, showing the context from that application to the other application.
25
Incident
HPD:Associations
Target
Target Request
Work Info model Work logs are components used to track work history. They replace the work diary fields that were used in previous versions of the ITSM applications.
Each work entry is stored as a separate record in an AR System form. This approach allows for easier reporting and searching of the Work Info entries associated with any particular record. Each Work Info entry can contain up to five different attachments. The attachments can be associated with the work notes, which results in the attachments being tied to the record. This provides context to the attachments, and makes it easier to find them. It also allows for unlimited attachments to be associated to any particular record. The work log system also allows for locking records, making records public or hidden, and categorizing the records. On a per-application basis, each application uses a separate work log form, but uses the same structure and workflow around the form. This offloads the processing of Work Info records to forms that are specific to each application.
26
Foundation architecture The ITSM Foundation contains data structures and services that are common to all applications in the ITSM suite. The Foundation consists of two different concepts: reference data and the infrastructure model. Think of the foundation as the architecture of a building. The infrastructure model is analogous to the pipes and electrical wiring, while the reference data is analogous to the things flowing through the pipes and wires, such as water and electricity. Consider the following definitions and examples of foundation components in the context of how the ITSM applications are built.
Reference data Data structures and subsystems are shared by many different systems. This data is central to the running of the application. Examples include People, Companies, Categories, and so on.
Infrastructure model Think of the infrastructure model as the plumbing structure, as how things fit together. Examples include the Notification Engine, association model, Deployable Application structure, tenancy model, and so on.
Foundation components The ITSM foundation provides a repository for the following data structures used by each ITSM application: •
Company (tenancy definition and external company definition)
•
Organization
•
Location
•
People
•
Support groups
•
Categorization
27
Company Company is a primary data structure in the ITSM foundation. This structure has the following two main purposes: Tenancy definition
Tenancy refers to how data and rules are partitioned within the ITSM applications. For example, a company might have two different business units that use the Incident Management application. Each business unit has its own definitions of data, categorizations, assignment rules and approval rules, and wants to make sure that this data is not intermixed. Tenancy allows you to define the partitions between the two business units and enforce the data level permissions around who can access what data. In this example, a company would be created for each business unit to define the desired partitioning of rules and data. So, a primary function of the company data structure in the ITSM Foundation is to define those tenants to be used by the ITSM applications. This function of company is used to define both how the application will partition the data, and the rules for the application, based on different distinct users of the application. Business units are one example of partitioning. If you need to partition the data and the rules of the applications, based on individual business units, then different companies would be defined for each business unit. External company definition
You can also use the company definition to define other types of companies that are used in the application, such as manufacturers, suppliers, and so on, as defined and used in the Asset Management application.
Location The location structure within the ITSM applications has a four-tired data model, where the second and third tires can be optional (the fourth tier, however, is required). In effect, the data model can be two, three, or four tiers. The Company field makes up the first tier, Region is the second tier, and Site Group is the third tier, and Site is the forth tier (where Sites are physical locations with mailing addresses such as buildings). It is important to note that when creating the location structures, the regions and site groups will be used to group sites within a company. Therefore, it is important to have a list of the sites within a company, and then determine if regions and site groups will be required to arrange the sites in an organized manner that can be used for reporting purposes.
28
•
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.
ERD SIT:Site Alias * SIT:Site Group Logical Assoc
SIT:Site *
1111
SIT:Site Company Association *
*
SIT:Site Zone (Deprecated)
* *
* COM:Company
*
11 1
CTM:Region
* SIT:Site Group
29
Organization Organization describes the role the company component plays in the foundation. ERD COM:Company Alias
COM:Company *
1
1 11
*
*
*
*
CTM:Region
SIT:Site Group
CTM:People Organization
*
1
CTM:Support Group Shift *
CTM:Support Group
1
CTM:Support Group Alias 11 1
*
1 *
CTM:Support Group Assignments
CTM:Support Group On-Call * CFG:Approver Lookup
*
SIT:Site Alias * 1
SIT:Site Group Logical Assoc *
SIT:Site Zone (Deprecated)
30
*
11
SIT:Site
SIT:Site Company Association *
*
N 1
COM:Company
COM:Company Alias N
1
Company Alias Company ID Primary Alias
1
Company Company ID Company Type
1 N
N
Company Region Site Group Site Group Type
Company Region
N
Company Organizarion Department
N
Support Group Shift Name Support Group ID
CTM: Support Group Alias N
CTM:Support Group 1
CTM:Support Group Assignments
CTM:People Organization
SIT:Site Group
CTM:Region
CTM:Support Group Shift
N
Company Support Organization Support Group Support Group ID Support Group Role
Support Group Alias Support Group ID Primary Alias 1
CTM:Support Group On-Call
< Business Holidays Tag > < Business Workdays Tag >
N
Default Assignment Group ID Support Group ID
Support Group ID On-Call Paging Type Pager Service Provider
1
N
N
CFG:Approver Lookup SIT:Site Alias
Pager E-mail Remedy Login ID Business Holidays Tag Business Workdays Tag
Approver Login ID Approval Type Approval For
N Site Alias Site ID Primary Alias
Pager Phone Number (comprised of): CC Pager Area Pager Local Pager PIN Pager
SIT:Site Site Site ID (system generated)
SIT:Site Group Logical Assoc N Company Site Group Site Group Type ("Logical") Site ID
SIT:Site Zone (ITSP 4.0) DEPRECATED IN 7.0
N
1
Address Details (comprised of): Street Country State/Province City Zip/Potal Code Time Zone
N
N
SIT:Site Company Association Company Region Site Group Site ID N
1
Site Zone Site ID
People The People structure within the ITSM applications includes several forms that are primarily accessed through the CTM:People form. The main form (or parent form), People, is used to store an individual’s contact information, their organization, and location structures information.
31
ERD Support Group Functional Roles - for Support Staff only - e.g. Change Manager, Support Group Manager
Company
Region
Organization
Support Organization
Site Group
Department
Support Group
Attributes - General Information: Name, VIP - IT/Skills, Access IDs, Travel Profiles
Financials
Site
- Cost centers (multiples) - Hourly rate, Accounting code
- A person belongs to a Company and location - A Support Staff belongs to a Support Group
CI Associations
Permission Groups
- associate to CIs with type: uses, manages, supports, owns
- for Support Staff only - allows users access to various modules
Approval Mapping - for Support Staff only - Approval mapping for Change and User Change Management
Login and Licensing Information - stores Login ID and password - Fixed/Floating/Read license
Notification Preference - for Support Staff only - System pre-defined and Userdefined notification preference based on events
* Application Permissions
CTM:People 1
* 1
Data Access
* *
*
CTM:People Worklog
* CTM:Support Group Association
*
* AST:AssetPeople
*
1
*
*
* FIN:CostCenterAssociation
CTM:People Permission Groups
1
*
* CTM:SupportGroup
1
1 FIN:ConfigCostCentersRepository
Combination of Support Group and Person ID
CTM:SupportGroupFunctionalRole
32
CMDB Classes
* User
*
NTE:CFG-NotificationEvents
Support groups Support groups play an important role in the ITSM 7.0 application infrastructure. They are used to define groupings of back-office staff, based on their skills. Support groups are also used as the initial assignment for a incident, problem, or change request. •
The Support structure can differ from the organization structure.
•
A support staff member can belong to many support groups.
•
Vendor support groups can be defined to support external assignment of tickets.
•
The Support Group role must be specified for information only; there is no associated workflow.
ERD
From a data model standpoint, the Support Group model is based on the COM:Company form to hold the support company data, and the CTM:SupportGroup form to hold the definition of the support group. The relationships are defined using query menus on the CTM:SupportGroup form. The Organization value is an attribute on the CTM:SupportGroup form. The menu that displays the organizational values performs a query against the CTM:Support Group form to display the available organizations.
Support company
Organization Support group
P
33
Support Group ERD COM:Company
1
* 1
CTM:Support Group Shift *
CTM:Support Group
1
CTM:Support Group Alias 11 1
*
1 CTM:Support Group Assignments
*
CTM:Support Group On-Call * CFG:Approver Lookup
*
CTM:SupportGroup form
Categorization The categorization structure in ITSM 7.0 is primary to many different functions. Categorization structures are broken into two distinct components: operational categorization and product categorization.
34
Operational c ategorization The operational categorization structure is a three-tier structure defined for categorization of what work is being done for a particular incident, problem, known error, change request, or task. This structure is also used to qualify reporting in the system, qualify how groups and support staff get assigned, and routing of approvals. Product categorization ERD
Product categorization PCT:Product Catalog
PCT:ProductAlias 1
*
1 * *
* PCT:ProductCompanyAssociation
PCT:Product Model/Version
1 * PCT:ProductModelVersionPatch
Operational categorization CFG:Service Catalog
CFG:Service Catalog Association 1
*
35
CFG:Service Catalog
Categorization ID Categorization Tier 1 Categorization Tier 2 Categorization Tier 3 Description Status
CFG:Service Catalog Assoc 1
N
Categorization ID Company Status
Notification Engine The Notification Engine provides a back-end workflow model for defining which notifications should be sent, based on different events in the application. Support staff use the NTE:CFG-NotificationPreferences form to define which notifications they want to receive. This is exposed on the People form. Included predefined notifications can be turned on or off in the user interface. Design
The following diagram describes the flow of the Notification Engine. The Notification Engine is built using AR System workflow. Calling applications pass information into the NTE:SYS:NT Process Control form, indicating the application, who the notification should go to, and information about the parent record. The workflow process determines if the notification is for a group or an individual. Individual processing gets the user’s notification preferences, ticket information, a message from the message catalog, and then send the notification. Group processing expands the group list to individuals, and then runs the same individual process as described previously. The key difference is that the expansion is pushed asynchronously to not have a performance affect on the calling application, and is sent using escalation processing.
36
Process flow
Assignment The assignment architecture for the ITSM suite is based on a two-phase concept. The first phase is assignment of the support group; the second phase is assigning the support technician using load balancing technology built into the Assignment Engine. Design
Phase 1: Support groups The support group assignment phase is done using AR System workflow on backend tables. The workflow looks into the CFG:Assignment form to determine the group to assign, using four different inputs: •
Organization
•
Location
•
Operational categorization
•
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.
Phase 2: Individual Assignment Individual assignment is done in phase 2, using the Assignment Engine. Assignment rules are provided to support Number of Tickets Assigned, Round Robin and Capacity process rules.
38
•
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.
Assignment process definition:
The following qualification is used to find the set of people to apply load balancing rules on: ($Assigned Group ID$ = 'Support Group ID') AND ('Profile Status' = "Enabled") AND ('Assignment Availability' = "Yes") AND ('Assignment Availability 2' = "Yes")
This query looks at the CTM:Ppl Search-SupportGrpAssoc form to find the appropriate list of people based on the above qualification.
39
ERD
Request Form
Phase 2 Phase 1
Assignment Engine CFG:Assignment
There are two phases in the assignment process. Group assignment is handled within the application using CFG forms; individual assignment uses the Assignment Engine. Group assignment workflow: •
Workflow referencing the CFG:Assignment form.
•
CFG:Assignment has four main areas: • Event—Type of assignment this assignment record is created for. • Assignment—Support group that this assignment record would assign the ticket. • Criteria—Criteria matching the tickets to find the assignment records. • System—Identifies if this assignment record is “enabled” for such systems.
•
40
On ticket submission and modification, workflow executes to reference the CFG:Assignment form to find the support group to be assigned, based on information on the ticket.
Individual assignment: •
Before individual routing occurs through the Assignment Engine, a support group must already be assigned.
•
The Assignment Engine routes tickets to individuals within the support group using process rules of Round Robin, Number of Tickets, or Capacity.
•
Predefined rules and process are included with the product and are not intended for user configuration (that is, it is a customization activity for professional services, application administrators, or Assignment Engine administrators).
•
Each application is preconfigured for the Assignment Engine, using Round Robin and the following system’s rule form: • Incident Management—HPD:CFG Rules (Configure Incident Rules) • Change Management—CHG:CFG Rules (Configure Change Rules) • Problem Management, Knowledge, Known Error—PBM:CFG Rules (Configure Problem Rules) • Task Management System subsystem—TMS:AssignmentConfiguration
On ticket submission or modification, workflow executes to use the Assignment Engine to perform individual assignment routing, based on the process configured in the system’s respective rule forms.
BMC Remedy Change Management architecture Change Management BMC Atrium CMDB Task Management DSL Cost Subsystem
The Change Management application is designed to establish a standardized change process to allow IT organizations to make quick decisions on risk, and assess the impact of changes made to the production environment. The Change Management features introduce efficiency and increase productivity by minimizing error-prone processes and providing visibility to key performance indicators (KPIs). Features also include metrics to determine if established service level agreements (SLAs) are being met.
ITSM Foundation SLM
Process flows Information Technology Infrastructure Library (ITIL) is the foundation for achieving the goals of the Change Management application. The following process flow diagram illustrates the union between the ITIL process and Change Management functionality.
41
C h a n g e M a n a g e m e n t P ro c e s s e g n a h C
r e t s e u q e R
e g n a h C
re tn e m le p m I
e e n g i s s A e g n a h C
r te ta M tc je b u S (
1 C hang e In itiatio n a n d R ec o rd in g
4 Change Im p lem e n ta tio n
3 Change P la n n in g an d S c h e d u lin g
)t r e p x E
2 R e vie w a n d A u th o riz e
5 C hang e C o m p letio n an d C lo su re
re g a n a M e g n a h C e g n a h C
re v o r p p A
/ tr o p p u S e c i v r e S r e h t O
s e s s e c o r P y re v li e D
P ro b lem M anagem ent
In c id e n t M anagem ent
R e q u es t M anagem ent
C o n fig u ra tio n M a n a g e m e n t
,I
.
The Change Management process has five primary stages:
•
Initiate and record
•
Review and authorize
•
Plan and schedule
•
Implement
•
Complete and close
Each stage can consist of sub-processes to support putting the change on hold or getting approval to move to the next stage. These sub-processes can be configured in Change Management to be applicable at each of the primary stages. The following sections give a brief description of each of the primary stages and the features that support each stage. See the BMC Remedy IT Service Management 7.0 Configuration Guide for more information about configuring the system and the BMC Remedy IT Service Management 7.0 Change Management User’s Guide for additional details about features that support each stage of the Change Management process.
Initiate and record This is the initial stage of the change management process and focuses on recording the purpose of the change request, and on obtaining additional required information needed to classify and route the request.
42
The primary sources of change requests are: •
Problem Management, including the known error feature of Problem Management
•
Incident Management
•
Service Request Management
The key features available in Change Management designed to facilitate this stage of the process include: •
Requester console interface
•
Auto assignment at the group and individual level
•
Support for multi-tier classification (product and operational catalogs)
Review and authorize Once the initial request has been submitted, the next logical stage is review and authorize. The purpose of this stage is for the change manager to assess the change request, provide any additional information to add more context, and if required initiate the corresponding approval process. This stage acts as the initial filter to determine if the change request should continue to the next stage in the process. The features in Change Management designed to facilitate this stage of the process include: •
Manager console
•
Risk assessment
•
Support for relating CIs from BMC Atrium CMDB
•
Integration to BMC Remedy Approval Server
•
Request acknowledgement flag
Plan and schedule Once the change request has been approved for work to begin, the next stage is to plan resources and schedules to ensure minimal impact to the production environment. Once the planning and scheduling are complete, the change request is subject to another approval process. The features available in Change Management designed to facilitate this stage of the process include: •
Change calendar
•
Costing (budgeted)
•
Scheduling
•
Integration with Approval Server
43
•
Change templates
•
Integration to Task Management System • Task templates • Task viewer
Implement This stage consists of executing against the plan and getting the work done. The features available in Change Management designed to facilitate this stage of the process include: •
Support console
•
Task viewer
•
Costing (actual)
•
Work info
Complete and close This is the final stage of a change request and indicates either that the change request has been completed successfully or that is was canceled. All of the actual data elements (time, cost, and so on) are rolled up and recorded.
ERDs Many pieces of information support the change management process. This section identifies the primary entities that are related to Change Management. First, some common terms are defined to help classify how information is related to a change request. You can relate data to a change request in three ways: association, linking, and lookup.
Associations Data that is associated is supported by a table that maintains a subset of information for each record being associated to the change request. This information can come from a variety of sources and is typically managed in other systems or subsystems. This information can also be related to more than one change request. For example, configuration items (CIs) are maintained and managed in the BMC Atrium CMDB. When CIs are associated to a change request, a subset of information is stored as a record in an association table and is kept in sync with the original record. The subset of data typically includes a unique reference to the original record, a brief description, and the status or equivalent representation of the condition of the related data item. Again, the characteristic of an association table is that it is a generic table that can contain related information from a variety of sources. The following illustration provides an example of how information from three sources
44
(PBM:Problem Investigation, CFG:Broadcast, and TMS:Task forms) can be represented in an association table.
Change Record CID: 23
Assocation Table ASID CID Description Status Other Data T653 23 Task 12 WIP X B21 23 Broadcast 1 Active Y B83 23 Broadcast 2 Active Z P242 23 Problem A Open A
PBM:Prob. Inv. PID: P242
CFG:Broadcast BID: B83 BID: B21
TMS: Task TID: T653 The association table is generally exposed using a table field on the request form. The following illustration shows the association table in the Relationships tab of the Change form.
45
Linking Data that is “linked” uses foreign keys to establish a relationship to the parent record. The change request acts as the parent record for most of the information that is linked to it. This means that the unique change request ID or GUID is stored on the related records. This is effective when the related data is normalized and supports a parent child relationship. Note: A GUID is a globally unique identifier. GUIDs are automatically generated by the AR System server. The following diagram illustrates how records in the CHG:ChangeRequest_AuditLogSystem, CFG:Reminders, and CHG:WorkLog forms are linked to the Change record by storing the unique change ID of 23 on each of the related records in the corresponding forms.
Change Record CID: 23
CHG:CR Audit AID: 523
Fkey: 23
CFG:Reminders
AID: 284
Fkey: 23
Fkey: 23
RID: 295
Fkey: 23
RID: 841
CHG:WorkLog WID: 523
Fkey: 23
WID: 284
Fkey: 23
In one case, the change request is the child record of the parent record. In this case, the unique request ID would be stored as a data item on the corresponding change request, as shown in the following illustration.
SRM:Request RID: R46
Change Record CID: 23
Fkey: R46
The difference between this way of relating information and association is that there is no additional database table and the table field will contain only
46
information from one source. Despite this difference, a set of linked data will also be represented in a table field on the Change form, as shown in the following example.
Lookup Data that is “looked up” is pulled into the record by storing a local copy of the information that is being looked up on the record. In general, this data is not kept in sync with the original source. However, integrity checks might be performed to make sure that the data stored on the record is still a legitimate reference. For example, when categorization information is looked up and stored on the change request, if the original record is modified such that the categorization information stored on the change request form is no longer valid, the following error message appears if you attempt to update this change request: The operational categorization information is invalid for the specified company,
. Use the menus to select this information.
The following diagram illustrates information being looked up from the Categories table and being stored on the Change record in fields Tier1, Tier2, and Tier3.
47
Change Record CID: 23
Tier 1: Hardware Tier 2: Desktop Tier 3: Disk
Categories CATID Tier 1 Tier 2 Tier 3 635 Hardware Desktop Disk 243 Hardware Laptop Memory 902 Hardware Server CPU Card
Associated information ERD The following items can be related to change requests by way of associations: • Incident Management items •
Problem Management items • Investigation records • Known errors • Knowledge entries
•
Asset Management items • Configuration items • Outages
•
Other change requests
•
Definitive Software Library (DSL) items
•
Software library item
•
Tasks • Task • Task Group
•
LDAP • User instance • Group instance
•
48
Cost information
The following ER diagram illustrates how these primary data elements can be related to the change request by way of the association forms (shaded). ERD for CHG:Infrastructure Change - Associations
Incident Management HPD:Help Desk
Problem Management PBM:Problem Investigation
LDAP PBM:Known Error TMS:LDAPUser
PBM:Knowledge Database
TMS:LDAPGroup
Asset Management AST:Configuration PDL:Software LibraryItem CHG:Associations
AST: CI Unavailability
CHG:Infrastructure Change AST:*
FIN:Costs
FIN:Association
CHG:Infrastructure Change
TMS:Associations
TMS:Task
TMS:TaskGroup
Linked data The following items can be “linked” to change requests: •
Auditing
•
Risk information • Factors • Questions
49
•
Reminders
•
Impacted areas
•
Work-related information
•
Effort tracking
•
Tasks • Task • Task Group
•
User requests
•
Broadcasts
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 ookup
CFG:Reminders
CHG:ChangeRisk Factors
CHG:Impacted Areas
SRM:Request
Foreign Key: SRInstanceID
TMS:Task
CHG:Infra. Change Effort Log
CHG:WorkLog
Foreign Key: RootRequestID
CHG:Infrastructure Change
Foreign Key: Infrastructure Change ID
TMS:TaskGroup
Foreign Key: Instance ID
TMS:FlowBuilder
50
TMS:Flow
TMS:SummaryData
CFG:Broadcasts
Data lookup The following items can be “looked up” and referenced on change requests: •
Operational categories • Tier 1 • Tier 2 • Tier 3
•
Product categories • Tier 1 • Tier 2 • Tier 3 • Product Name • Model/Version • Manufacturer
•
Supporting resources • Requested By • Requested For • Manager • Assignee • Implementer
•
Locations • Region • Site Group • Site
51
The following ER diagram illustrates how these primary data elements can be looked up and stored as local data on the change request.
COM:Company
CTM:Support Group
CTM:People
Requested By Requested For Manager Assignee Implementer
Operational Category
CHG:Infrastructure Change Product Category
Region/Site Group/Site
CFG:Service Catalog
PCT:Product Catalog
CTM:Region
SIT:Site Group
SIT:Site
52
Comprehensive ERD Incident Management LDAP HPD:Help Desk Asset Management
TMS:LDAPUser
AST:Configuration Problem Management TMS:LDAPGroup PBM:Problem Investigation
AST: CI Unavailability
PDL:Software LibraryItem PBM:Known Error
CHG:Infrastructure Change
AST:*
PBM:Knowledge Database
TMS:TaskGroup
FIN:Costs TMS:Task
FIN:Association
CHG:Associations
TMS:Associations COM:Company
Requested By Requested For Manager Assignee Implementer
CTM:Support Group
CTM:People
CHG:Infrastructure Change
Foreign Key: SRInstanceID
SRM:Request
Operational Category
CFG:Service Catalog
Product Category PCT:Product Catalog Region/Site Group/Site Foreign Key: Infrastructure Change ID
Foreign Key: Instance ID
Foreign Key: RootRequestID
CTM:Region
SIT:Site Group CHG:Change Request Audit
CFG:Broadcasts
TMS:Flow
TMS:Task SIT:Site
CHG:ChangeRisk FactorQuestionL ookup
CFG:Reminders
CHG:ChangeRisk Factors
CHG:Impacted Areas
TMS:FlowBuilder
TMS:TaskGroup
TMS:SummaryData CHG:Infra. Change Effort Log
CHG:WorkLog
53
Main forms The following table lists the main Change Management forms: Form name
Type
Description
CHG:ChangeAPDetailSignature
Join
Supports integration to the Approval Server.
CHG:ChangeInterface
Join
Interface form for query and modify operations.
CHG:Associations
Regular
Stored related information.
CHG:ChangeInterface_Create
Regular
Interface form used for create operations.
CHG:CostAllocation
Regular
Supports integration to Cost Management subsystem.
CHG:Infrastructure Change
Regular
Primary Change Request form.
CHG:Template
Regular
Change Request Template form.
CHG:WorkLog
Regular
Maintains Work Log entries associated with change requests.
Change calendar The CCM change calendar is a high-level console for managing CCM change activities, intended to be used by enterprise-level CIOs and members of change approval boards. From the calendar, these users can see a holistic picture of changes occurring in the enterprise, as well as associated business activities or events. Some of this information comes from Change Management and other information through referencing objects in the BMC Atrium CMDB. Aided by links to investigative and analysis tools, users will be able to better understand the risk and impact of changes and to plan and make better decisions about changes, considering the interdependencies that are made more visible through the calendar console. The calendars primary view is a calendar-like schedule display that shows a focused view of related change requests, when they are scheduled to begin and end, and related business activities and events. A user can select criteria to limit change requests and business activities to view, that is, filter the view. By changing these filtering criteria, a user can focus on the items of interest. High-risk changes are highlighted. A user can drill down from any change request or business activity to see more detailed information about the item. This view is primarily for change approval board members.
54
Architectural overview An architectural diagram and a brief description of the primary components are included in this document only as a reference for how the data visualization field must be leveraged to enable this functionality. It is important to note that the underpinnings of how this functionality works. You should not customize this functionality. The change calendar is an AR System application component built with AR System mechanisms where possible and with custom components where augmenting functionality is required. The change calendar consists of a primary form and a number of subsidiary forms for user dialogs and administration. Although the change calendar is only required to be viewable by a browser client, building on forms also enables viewing through BMC Remedy User. The change calendar is intended for members of a change advisory board (CAB), usually during a CAB meeting. As such, it is not required to scale to large numbers of concurrent users. However, it must scale in its ability to handle large numbers of change requests. This influences aspects of the design in an attempt to balance the needs of users for a useful visual display of change request data with the need to access all the data with reasonable performance.
55
The change calendar requires functionality not provided by the base AR System platform. It displays change requests and scheduled business events similar to a project management application displaying activities and tasks as a Gantt chart. In this way, it differs from standard calendars found in personal productivity applications. It can represent requested changes that take multiple days to execute and show dependencies between changes in a more understandable way using a Gantt chart representation. The calendar view is an AR System form view in which the activities schedule and other custom “controls” are integrated into an AR System form as a Data Visualization field. The calendar uses a plug-in API. The Change Calendar plug-in consists of a set of Java and JavaScript components. The Java components run in the AR System mid tier in the plug-in container as add-on components running in the same web application context as the mid tier. The mid tier deployment includes an additional JAR file after the Change Management application is deployed. Except for the plug-in interface to the plug-in container, the calendar charting functionality is written as an embedded web application with no dependencies on the mid tier other than those exposed through the plug-in container.
56
Browser Calendar Client Runtime Script
AR System mid tier Plug-in Container
CCM Calendar Calendar Plugin
Request Dispatcher
CSS Files
JavaScript Files
BMC Atrium CMDB API
Event Dispatcher
Renderer
Model
AR API
57
The Change Calendar web tier uses a component-based Model-View-Controller (MVC) architecture. It consists of several components: •
Calendar plug-in This component provides the glue between the calendar and the AR System form that contains it. It implements the interface that enables its rendered content and behavior to be embedded in an AR System form as a Data Visualization field. This is a new field type in AR System 7.0. Data Visualization fields that delegate rendering to an associated plug-in registered with the plug-in service.
•
Request Dispatcher The Calendar plug-in delegates work to one of two controllers: Request Dispatcher and Event Dispatcher. The Request Dispatcher controller dispatches requests for the calendar view or for associated resources, such as CSS stylesheet files, JavaScript files, and images. The plug-in delegates handling of calls by the plug-in container to its processRequest method to a Request Dispatcher. It acts much as a Servlet: examining the HTTP request, identifying the action requested, extracting request parameters, and delegating the rendering of the response to the appropriate view object. This controller accesses data that matches the request parameters, and encapsulates it in a model object that it passes to the view for rendering.
•
Event Dispatcher The Event Dispatcher controller is delegated to handle events forwarded to the plug-in by the plug-in container from the plug-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 serverside view and model objects are implemented in JavaScript. CSS is used extensively to both lay out the page and to control how it looks. Since the Data Visualization field that hosts it is implemented as an IFRAME element, a full page is delivered to the browser.
Executive dashboard The primary goal of the Change Management Dashboard is to help executive users understand the trends relating to change configuration management, and to take appropriate action to balance the flow. A dashboard view presents a set of metrics or statistics that give a snapshot of the state of the change management process. A user has a choice of which statistics to view. The user can select criteria that focuses the view on the desired perspective, and can indicate how far back to look at the data. Example statistics are the history of planned and unplanned changes over one or several time ranges, the number of authorized changes over the last week or month, the success rate of changes made for the last thirty days, and a summary of costs of changes over the last fifty changes made. The CIO is the primary user of this dashboard view.
59
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. The Change Management Dashboard component consists of three forms: •
CFB:CCMFlashboard This display form is divided into four sections: Overall Health, Customer Data, Financials, and Operational Efficiency. Each section displays flashboards related to these categories. The data displayed on the flashboard is gathered from entries in the CHG:Infrastructure Change form.
•
CFB:FlashboardData This is a back-end form used to save flashboard data. This form will save each flashboard name, and metadata about each flashboard, such as the qualification, to facilitate dynamic filtering.
•
CFB:FlashboardUserView With this form, users can configure the default flashboards that are displayed.
60
Subsystem integration The following subsystems are used by Change Management: •
Requester Console
•
Cost Management
•
Service Level Management (SLM)
•
BMC Atrium CMDB
Requester Console The requester console provides the front-end interface for users into the Change Management application. The integration: •
Uses the SRMS framework in the Requester Console to create change requests.
•
Updates change information using the work log.
•
Has an interface back from the change to the request that is stored in the Requester Console.
•
Updates the status of the request to match the status of the change request, and makes visible Work Info entries.
The Requester Console interacts with Change Management using the Change Management interface forms.
Cost Management Change Management uses the Cost Management subsystem to track costs associated with Change Requests. The integration uses the common cost creation dialog box that is provided by the Cost Management subsystem. The table field on the CHG:Infrastructure Change form integrates with the FIN:CostAssociatonJoin form to display cost data related to an incident.
SLM Change management integrates with the SLM application to provide service level definitions for resolution and response time for change requests. When SLM is installed, a tab on the CHG:Infrastructure Change form is enabled, showing the service targets and milestones that are associated to an Change Request.
61
In addition to the user interface integration, the Change Management application also ties into the definition structure of SLM. SLM has a plug-in architecture for helping users define terms and conditions, and measurements for a service target. Change Management provides a user interface for this SLM plug-in architecture to make it simpler for users to build qualifications using a query-by-example (QBE) model.
BMC Atrium CMDB Change management integrates to the BMC Atrium CMDB using relationship tables. From the Change Management user interface, users can search for CIs and relate CIs to an incident.
62
Interfaces Interfaces to Change Management include interface forms and web services. For more information, see the BMC Remedy IT Service Management 7.0 Integrations white paper.
Interface forms Two interface forms for Change Management support basic create, modify, and query operations: •
CHG:ChangeInterface_Create This is a regular form and interfaces with the primary Change form, CHG:Infrastructure Change. This interface form is the integration point for external systems to create new change requests.
•
CHG:ChangeInterface This form is a self-join form of the primary Change Management form, CHG:Infrastructure Change. This interface form is the integration point for external systems to query or modify change requests.
These interface forms contain all necessary fields from the base change request form, CHG:Infrastructure Change, required to support receiving input from an external source. The command field, z1D_Action, is used where necessary to invoke the action that is requested by the external system (submit, modify, and create). All of these operations can be invoked by accessing these interface forms directly. Access to these forms has also been expanded to support interactions using web services.
Web services The submit, modify, and create operations are also supported using web services. The following three diagrams illustrate how the create (submit), modify, and query/query list operations are supported. Create operation
For a create operation, a record is submitted to the CHG:ChangeInterface_Create form and the command CREATE is supplied in the zID_Action field along with any other relevant data values mapped to the exposed data fields. This triggers a series of filters to process the record and stage it to be submitted to the base change management form, CHG:Infrastructure Change.
63
After the record has been successfully created in the base Change Management form, the new ID is returned. An escalation will clean up and delete old staged create records from the CHG:Interface_Create table and form. Modify operation
For modify operations, the self-join form CHG:ChangeInterface is used. The record ID of the change request to be updated is required.
64
In addition, when using web services to update all of the fields on the Change Request form must be updated. Any field with a value of Null is set to a Null value. Query and query list operations
The self-join form CHG:ChangeInterface is also used for the query operation. The record ID or a query list qualification is required to retrieve either an individual change request or a list of requests.
65
Permission model In ITSM 7.0, permissions have two levels: AR System permission groups, such as Change User, Change Submit, and Change Master, and functional roles. The AR System permission group is not as relevant for the ITSM applications because the ITSM applications use the General Access permission group across fields on the forms. These groups are primarily used to provide functionality that a group can access. For example, Change Submit will have less functionality compared to Change User. All functionality based on permissions is implemented through workflow. Functional roles enable the functionality to be further refined within a permission group. Again, this is implemented through workflow. The following example shows the difference between a person having Change User permission with no functional role compared with having functional roles:
66
If a user has Change User permission with no role, this person has access to almost everything (including the risk compute button, costing, and the calendar) on the Change form, but has the following restrictions: •
Limited ways to move from one status to the next. This user does not have access to the states between Request for Change to Scheduled and also cannot close out the request.
•
Cannot reassign the change manager and change assignee. Can manually reassign the change implementer.
•
Cannot modify the effort logs for the change manager and change assignee, but can create and delete the entries for change manager and change assignee.
If a user has Change User permission with Change Assignee role, this person has the following restrictions: •
Cannot reassign the change manager. Can manually reassign the change assignee and implementer.
•
Cannot modify the effort logs for the change manager, but can create and delete the entries for the change manager.
A user with Change User permission and a Change Manager role has access to all functionality. A Change Master is someone who has the access of a person with Change User permission and Change Manager functional role across different support groups. A Change Manager can also define approval mappings and change templates for his or her support group. A person with Change User permission (with or without a functional role) can work only on the change requests that are assigned to his or her support groups. A person with Change Master permission can work on any change request that he or she can access, whether or not the change request belongs to the support group that the request is assigned to.
BMC Remedy Asset Management architecture Asset Management BMC Atrium CMDB DSL
The Asset Management application lets IT professionals track and manage enterprise configuration items (CIs)—and their changing relationships—throughout the entire asset life cycle. Asset Management tracks contracts, financial costs, software licenses, outage indicators, and more for the CI information stored within the BMC Atrium CMDB 2.0 application.
Cost Subsystem ITSM Foundation SLM
As part of the BMC Remedy ITSM Suite, Asset Management is integrated with BMC Remedy Service Desk (which contains the BMC Remedy Incident Management and BMC Remedy Problem Management applications), BMC Remedy Change Management, and BMC Service Level Management, and offers flexibility to support customized business processes.
67
Process flows ITSM configuration management process overview
1 Configuration management planning
2 Configuration identification
3 Configuration specifications
4 Configuration control
5 Configuration audit and verification
Service support, service delivery, and other related processes
Configuration auditor
Asset manager
CMDB
RFC
Asset Management
Change Management
Incident Management
Asset Management
Incident Management
Change Management
Change Management
© 2004 BMC Software, Inc. All rights reserved.
User interface The user interface for Asset Management has two components. Components that are specific to Asset Management are the user interfaces for the consoles and the non-BMC Atrium CMDB forms. In addition, a generic user interface is on top of the BMC Atrium CMDB. This user interface exposes the BMC Atrium CMDB data to a user interface that connects the BMC Atrium CMDB data to other aspects of Asset Management and other applications in the ITSM suite. The BMC Atrium CMDB user interface is provided with all of the ITSM applications. In the absence of the Asset Management application, this user interface provides a view into the BMC Atrium CMDB so that CIs can be tracked and related to other ITSM applications. When Asset Management is installed, the user interface is extended to also contain links to specific Asset Management functionality, such as contracts, depreciation, and procurement.
68
User Interface Forms (Joins)
Object1 : AST:ComputerSystem
Join
BMC Atrium CMDB Class Forms BMC:CORE:BMC_ComputerSystem
Asset Management and the BMC Atrium CMDB Asset Management is tightly integrated with the BMC Atrium CMDB as the underlying data model to store details about the configuration items that are being managed by Asset Management, and their relationships. The BMC Atrium CMDB supports the concepts of reconciliation IDs and sandbox functionality. This affects the overall structure of how data flows and is related to other data in the ITSM suite.
Reconciliation ID The BMC Atrium CMDB is structured as a model where data can be partitioned across multiple data sets. For example, one dataset can hold raw data that is discovered by a discovery tool, and another dataset can hold data that describes future states of a CI. In each of these datasets you might have a different view of a CI, and the data being stored about that CI. The BMC Atrium CMDB uses the reconciliation ID to identify a CI in the same way across multiple datasets. When a CI is identified by the reconciliation engine, it assigns a reconciliation ID to the CI. Since the reconciliation ID is the only identifier that can define a particular CI, that value is used to relate a CI to other data in the ITSM suite, such as incidents, problems, and change requests. To view a snapshot of a CI in a particular dataset, the ITSM applications provides mechanisms to define the dataset that a user wants to view. These mechanisms are included in the query qualification that is used to find a CI in the BMC Atrium CMDB.
69
Sandbox Datasets are not only used to store raw discovery data, they are also used in the system to be a flow through mechanism for updating the “golden” datasets of CI data in the BMC Atrium CMDB. This flow through mechanism provides a layer of control over what data is updated in the golden dataset in the BMC Atrium CMDB. Reconciliation rules control what data is allowed to be updated and from what source. Asset Management provides a way to configure the system so that any updates to an CI go through the sandbox dataset, and are reconciled against other data in the system prior to being updated in the golden dataset. This keeps users from updating data in the Asset Management application that should not be updated in the production BMC Atrium CMDB. The flow of the dataset workflow is as follows:
ERD The Asset Management application key data model components are from the BMC Atrium CMDB. The BMC Atrium CMDB provides the data model for all of the CIs tracked by Asset Management. In addition to the data that is stored and managed in the BMC Atrium CMDB for CIs, Asset Management also provides additional data tables and structures to track
70
asset-specific data. These include contracts, purchasing, and standard configurations. Following is a full ERD showing a typical asset interface on top of the CMDB Computer System class, and how it relates to other data being stored by Asset Management.
Asset Management full ERD The BMC Atrium CMDB is built around a core data model with extensions. Asset Management extends the BMC Atrium CMDB with additional classes and attributes that are specific to Asset Management. You can find these in the CMDB Data console by looking at the name spaces. Find the Asset Management extensions in the CMDB Class Manager. You can see in the following Class Manager Console that three classes are that are added by Asset Management to the BMC Atrium CMDB data model. Class Manager Console
71
Asset Management ERD
UI Joins on top of CMDB
Contracts
1
1 1 1
CMDB Classes
* *
1
*
AST:ImpactedAreas
AST:AssetSupport
1
AST:AssetWarranty
*
AST:CI Unavailability
AST:CMDB Associations AST:AssetSoftware *
*
AST:Schedule Assocations
*
FIN:CostAssociation
*
AST:AssetCost
* AST:WorkInfo
*
*
*
1
*
*
FIN:Costs
AST:Asset Lease
AST:AssetPeople
1
AST:ScheduleCriteria
*
AST:AssetMaintenance
CTM:People
Integrated Systems HPD:Help Desk
PBM:Problem Investigation
* *
PBM:Known Error
*
CHG:Infrastructure Change
TMS:Task
72
Asset Management system forms Component
Form
Comments
Main Asset Extensions
AST:AssetPeople
Manages relationships between the CI and the CTM:People form.
Main Asset Extensions
AST:BMC Atrium CMDB Associations
Manages relationships between CIs and ITSM forms.
Main Asset Extensions
AST:Inventory Transactions
Stores the inventory transactions.
Main Asset Extensions
AST:InventoryQuantity
Stores the inventory quantity.
Main Asset Extensions
AST:CI Unavailability
Tracks outages against a CI that are scheduled or unscheduled.
Main Asset Extensions
AST:Impacted Areas
Tracks the locations that are affected by this CI having an outage.
Main Asset Extensions
AST:Schedule Association
Manages the relationships between a schedule and the CIs this schedule is for.
Main Asset Extensions
AST:Schedule Criteria
Defines the schedules.
Main Asset Extensions
AST:Configuration
Defines the standard configurations.
Main Asset Extensions
AST:AUD_AssetAssociations
Association table used to link standard configurations to the deployed CIs.
Main Asset Extensions
AST:AdditionalData
Lets you add name and value pairs data to a CI.
Main Asset Extensions
AST:AssetLease
Join between the lease extension and the contract subsystem to display leases.
Main Asset Extensions
AST:AssetLease_
Lease extension to the contract subsystem.
Main Asset Extensions
AST:AssetMaintenance
Join between the maintenance extension and the contract subsystem to display maintenance contracts.
73
Component
Form
Comments
Main Asset Extensions
AST:AssetMaintenance_
Maintenance extension to the contract subsystem.
Main Asset Extensions
AST:AssetSoftware
Join between the software license extension and the contract subsystem to display software contracts.
Main Asset Extensions
AST:AssetSoftware_
Software license extension to the contract subsystem.
Main Asset Extensions
AST:AssetSupport
Join between the support contract extension and the contract subsystem to display support contracts.
Main Asset Extensions
AST:AssetSupport_
Support contract extension to the contract subsystem.
Main Asset Extensions
AST:AssetWarranty
Join between the warranty contract extension and the contract subsystem to display warranty contracts.
Main Asset Extensions
AST:AssetWarranty_
Warranty contract extension to the contract subsystem.
Main Asset Extensions
AST:AssetCost
Stores depreciation schedules.
Main Asset Extensions
AST:AssetCostDepreciationHeader
Stores the details about the type of deprecation models being used.
Asset Purchasing
AST:PurchaseLineItem
Line items for the purchase orders and requisitions.
Asset Purchasing
AST:PurchaseOrder
The holder of the purchase order.
Asset Purchasing
AST:PurchaseRequisition
Holds the details on the purchase requisition.
Asset Purchasing
AST:PurchaseReturn
Holds the return orders.
Software license management The software license component of Asset Management is designed to automatically link software instances with the contracts that describe the licenses that have been purchased for those software instances. The link is based on the normalization of the software instances by using the definitive software library (DSL) and the underlying product dictionary that is
74
provided with the DSL. This enforces consistency when software instances populate the BMC Atrium CMDB. Contracts are tied to the appropriate DSL entries for the software. When a software instance is generated, the system checks if there is a contract associated with that type of software. If so, a relationship is automatically created to that software. The system also automatically decrements the number of available licenses. If there are no licenses available, or if a contract is not found for software that requires a contract, an exception entry is created. The exception entry can then be assigned to the asset manager to determine a course of action, which might mean purchasing new licenses, harvesting existing licenses, and so on. The exception is managed by the system until there are an appropriate number of licenses available to keep the contract in compliance. The following diagrams describe the flow and forms that comprise the software license management component of Asset Management.
PDL:Product Dictionary (Join) PMVInstance ID ProductCompanyAssociation Instance ID
AST:ProductDictionarySearch
AST:Contract _PD_Relationship Product ID Product Instance ID Model/Version ID PMVInstance ID Contract ID Contract Instance ID ProductCompanyAssociation Instance ID
AST:AssetSoftware (Join) Contract Instance ID
75
Discovery
AST:ConfigLicenseMgmt
BMC:BMC_AssetBase
AST:Contract_PD_Relationship
AST:LicenseMgmtEngine
PDL:Product Dictionary
Contract/Asset Relationship form (AST:CMDB Association)
AST:LicenseMgmtIncludeClass •
Contains a list of CI classes that are used by the AST:ConfigLicenseMgmt form to limit the CI classes processed by the License Management Engine.
•
The user interface to add to this list is exposed as a table field in the AST:ConfigLicenseMgmt form.
•
A list of classes is predefined and shipped with the product.
AST:ConfigLicenseMgmt
76
•
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.
The following table describes the fields in this form. Field
Description
Status
Enables or disables the rule.
Company
Specifies which company uses this rule. A global rule applies for all companies.
Repository
Specifies the data repository the License Management Engine should use to for a lookup to match the 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, Support Organization, Group
Fields to indicate what support group is defined as the notification group for the given configuration rule.
AST:LicenseMgmtEngine Back-end form that process incoming software CI records (reconciled) from BMC:BMC_AssetBase. This form relates the CI to appropriate contracts when rules in the AST:ConfigLicenseMgmt form are verified.
AST:LicenseMgmtException A record is created in this back-end form when CIs were not successfully related to contract. Records are created here only if configured to do so in the AST:ConfigLicenseMgmt form.
AST:ManageLicenseMgmtException A join form between the AST:LicenseMgmtException and BMC:BMC_AssetBase forms. This form serves as the primary user interface for users to manage records that are unsuccessfully processed by the License Management Engine. This user interface is accessed from the Asset Management Console by clicking the Manage Contracts link under General Functions, and then selecting License Management Exception. Nightly escalations evaluate records in this form for action: 1. If Status = Completed and Exception Decision = Process CI, then process the CI through the License Management Engine for relating to a contract. This action assumes that an asset administrator has made sure that a licensable product has been linked to a contract so that the License Management Engine can successfully process the CI. 2. If Status = Completed and Exception Decision = Delete, then the exception is deleted. This means that the asset administrator has determined that the CI does not need to have contracts related to it. Only users with Asset Admin permissions can access this form. Row-level locking by the Company field has been implemented on this form. The Company field controls who can see exception records. If you have unrestricted access defined in the People form, then you can search for all records.
78
Procurement Asset Management contains a procurement process that handles the full process from requisition to order, to receiving and returns. The procurement process starts with a requisition. Requisitions are requests from users for the things they want to purchase. Attached to a requisition is a set of line items. These line items define each of the individual items that need to be purchased. The requisition provides the processes around getting the line items priced correctly and getting the appropriate approvals needed before orders can be sent to vendors. After the requisition is approved and the line items are priced, then the appropriate orders are automatically generated. The orders are generated based on the vendors for each of the line items. One order is created for each vendor, with the appropriate line items attached. From a data model standpoint, the line items are shared between the requisition and the orders generated from that requisition. When orders are received, the line items are updated with the received value, After all line items are received the order is considered closed. Once all of the orders generated from a requisition are received, the requisition is considered closed.
79
The main forms that make up the procurement component are: •
AST:PurchaseRequisition—Holds the details about the requisition and the user who is requesting the items. It also "drives" the process for getting the requisition approved.
•
AST:PurchaseOrder—Holds all of the orders that have been generated.
•
AST:PurchaseLineItem—Holds each of the line items. The line items are shared between the requisition and the order. The line items also contain the information about if the item has been received. If ordered in bulk quantities, the line items show how much has been received and how much is outstanding.
•
AST:PurchaseReturn—Holds any returns that might have been made and gives the reason why. It helps generate the appropriate documentation for the vendor to be able to return the item, and also is tracked as part of the order.
•
AST:PurchaseRequisitonWorkLog—Contains the work notes that have been attached to the requisition.
AST:PurchaseRequisitionFK: Requisition Instance IDAST:PurchaseRequisitonWorklog
AST:PurchaseOrder
1 1
*
1 FK: Requisition Instance ID
FK: Order Instance ID
*
*
AST:PurchaseLineItem
FK: Line Item Instance ID 0..1
AST:PurchaseReturn
0..1
Contracts Asset Management extends the contract subsystem to provide detailed contract functionality for Lease, Warranty, Support, Maintenance, and Software License Management. Each type of contract also has relationships with the following forms:
80
•
CTR:ContractPayments—Provides information about the payments made against a contract.
•
AST:WorkLog—Tracks work notes against a contract.
•
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 *
FK: Serveral Companies Names
COM:Company
CTR:ContractPayments
FK: Instance ID *
AST:WorkLog
FK: Instance ID *
Child Contracts
*
*
AST:AssetWarranty 1 *
* FK:CompanyName 1
CTM:People
*
Join Between AST:Warranty_ and CTR:ContractBase *
AST:CMDB Associations *
Reconciliation ID
*
*
«subsystem» BMC Atrium CMDB Forms
CTR:ContractBase
Shaded box = Contract subsystem provided
81
Support contracts
*
FK: Serveral Companies Names
COM:Company
CTR:ContractPayments
FK: Instance ID *
AST:WorkLog
FK: Instance ID *
Child Contracts
*
*
AST:AssetSupport 1 *
* CTM:People
FK:CompanyName 1
*
Join Between AST:Support_ and CTR:ContractBase *
AST:CMDB Associations *
CTR:ContractBase
Shaded box = Contract subsystem provided
82
Reconciliation ID
*
*
«subsystem» CMDB Forms
Lease contracts FK: Serveral Companies Names
*
COM:Company
CTR:ContractPayments
FK: Instance ID *
AST:WorkLog
FK: Instance ID *
Child Contracts
*
*
*
AST:AssetLease 1 *
CTM:People
FK:CompanyName 1 *
Join Between AST:Lease_ and CTR:ContractBase *
AST:CMDB AssociationsReconciliation ID *
*
«subsystem» Top Package::CMDB Forms
*
CTR:ContractBase * End Of Lease Support
CHG:Infrastructure Change *
Shaded box = Contract subsystem provided
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 *
FK: Serveral Companies Names
COM:Company
CTR:ContractPayments
FK: Instance ID *
AST:WorkLog
FK: Instance ID *
Child Contracts
1 *
*
*
*
AST:AssetMaintenance FK:CompanyName
CTM:People
1 *
Join Between AST:Maintenance_ and CTR:ContractBase *
AST:CMDB AssociationsReconciliation ID *
CTR:ContractBase
Shaded box = Contract subsystem provided
84
*
*
«subsystem» Top Package::CMDB Forms
Software contracts
FK: Serveral Companies Names
*
COM:Company
CTR:ContractPayments
FK: Instance ID *
AST:WorkLog
FK: Instance ID *
Child Contracts
1 *
*
*
*
AST:AssetMaintenance FK:CompanyName 1
CTM:People
*
Join Between AST:Maintenance_ and CTR:ContractBase *
AST:CMDB AssociationsReconciliation ID *
CTR:ContractBase
*
*
«subsystem» Top Package::CMDB Forms
AST:Keys and Versions *
Licenseable Product PDL:Product Dictionary
AST:Contract PD Relationship *
*
Shaded box = Contract subsystem provided
Software contracts provide additional relationships to the PDL:ProductDictionary to represent the normalized product names to link to this contract when they are entered in the BMC Atrium CMDB. The Software License Management functionality handles that linkage (see Software License Management section).
Standard configurations Standard configurations define what type of software or hardware a particular group is entitled to. The configurations are stored in the AST:Configuration form. This form has a header component that describes the configuration and a line item
85
component that describes each of the components (hardware or software) that make up this standard configuration. Standard configurations functionality is integrated with Change Management to facilitate the procurement process. The standard configuration can be compared with what is available in inventory to determine which items are available and which need to be procured.
Outages The Asset Management application provides a data model of storing planned or unplanned outages against a CI. This information is stored in the AST:CI Unavailability form. Scheduled outages automatically generate time segments in the AR System Business Time subsystem. This information is then made available to the change management process and other processes to understand when scheduled outages have been made against a particular CI. The outage model is also where Service Level Targets are integrated into the Asset Management application. Information about service targets that have been defined for a particular CI and the status of those service targets is shown on the SLM tab.
86
CMDB Classes
1 * AST:CI Unavailbility
1
1 Business Time Shared Entity
87
Schedules The Asset Management application provides a model for defining two different types of schedules: Maintenance Schedules and Audit Schedules. The definition of these schedules defines time periods in which maintenance, or audits need to be done for a particular CI, or set of CIs. The information about the schedule is stored in the AST:ScheduleCriteria form. The relationship to the CI is stored in the AST:Schedule Association form. The schedules also integrate with the Change Management application to manage the tasks and scheduling of the required maintenance and audits.
BMC Atrium CMDB classes * * AST:Schedule Association
CHG:Template 1
1
1
1 AST:Schedule Criteria
Subsystem integration The following subsystems are used by Asset Management:
88
•
Cost Management
•
Service Level Management
•
BMC Atrium CMDB
Cost Management
Asset Management uses the Cost Management subsystem to track costs associated with CIs. This integration uses the common cost creation dialog box that is provided by the Cost Management subsystem. The table fields on CI user interface forms integrate with the FIN:CostAssociatonJoin form to display cost data related to an CI. SLM
Asset management integrates with the SLM application to provide service level definitions for uptime related service targets associated with a CI. When SLM is installed, a tab is enabled on AST:CI Unavailability form, showing service targets and milestones that are associated to a CI.
When you define a Service Target against a CI, a user interface shows the values that are tailored to the integration with Asset Management outages functionality.
89
Interfaces Asset Management provides a set of interfaces that can be used to integrate with the Asset Management application. These interfaces include the BMC Atrium CMDB API, for creating, modifying, and deleting CIs and relationships.
BMC Atrium CMDB API This API provides a defined and documented interface for creating, modifying, and deleting configuration items and their relationships.
Interface Forms AST:PurchaseOrderInterface 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 BMC Atrium CMDB permission model BMC Atrium CMDB 2.0 provides the following additions. Addition of two new AR System computed groups for view data in the CMDB. •
CMDB Data View.
•
CMDB Data Change.
Addition of two new AR System roles: •
CMDB Data View—On every class attribute with View permissions.
•
CMDB Data Change—On every class attribute with Change permissions.
Additional existing permissions: •
Read Security (dynamic group)—On every class attribute with View permissions.
•
Write Security (dynamic group)—On every class attribute with Change permissions.
•
Assign Group (field 112)—On the RequestId with View permissions.
These permissions are mapped to the following roles that are defined for Asset Management as a deployable application:
Asset Management roles •
Asset Viewer—Read access to CI data in Asset Management.
•
Asset User—Read access to CI data in Asset Management with the ability to modify CI data that has been related to one or more super groups that are associated to the Asset Management user.
•
Asset Administrator—Read/write access to CI data in Asset Management.
•
Purchasing User—Read/write access to purchasing data in Asset Management.
•
Receiving User—Read/write access to receiving functionality in Asset Management.
Mapping of Asset Management roles to BMC Atrium CMDB roles •
CMDB Data View—Mapped to Asset Viewer and Asset User.
•
CMDB Data Change—Mapped to Asset Admin.
•
Write Security—Mapped to support group permissions.
91
Row-level security Row-level locking is set at the Company level for all Asset Management forms. All child records inherit the tenants of the parents associated with them. For individual CI records, the tenancy is set by the value in the Company field on the CI, and by the Used by, and Supported By people and groups associated to the CI.
Mapping of Asset Management roles to Asset Management functions The following table maps Asset Management roles to Asset Management functions. Asset Management component
Asset Admin role
Asset User role
Asset Viewer role
Purchasing User role
Receiving User role
Manage CIs
Write access to all CIs and functions
Read access
Read access
No access
No access
No access from Asset Management console
No access from Asset Management console
No Access from Asset Management console
Write access to CIs the user supports. Includes ability to create: • Contracts • Configurations • Relationships • Costs • Schedules • Outages • Returns • Activities • Impacted areas
Manage Inventory
92
Access to all inventory functions
No access from Asset Management console
Asset Management component
Asset Admin role
Asset User role
Asset Viewer role
Purchasing User role
Receiving User role
Manage Contracts
Write access to all contracts
No access from Asset Management console
No access from Asset Management console
No access
No access
No access
No access
No access
No access
No access
No access
Write access from CIs the user supports
Read access from CI forms Manage Configurations
Access to all configuration functions
No access from Asset Management console Read access Write access from CIs the user supports
No access from Asset Management console Read access Read access from CI forms
Manage Costs
Access to all cost functions
No access from Asset Management console Read access Write access from CIs the user supports
No access from Asset Management console Read access Read access from CI forms
Bulk Updates
Access to bulk update functions
No access
No access
93
Asset Management component
Asset Admin role
Asset User role
Asset Viewer role
Purchasing User role
Receiving User role
Schedules
Access to all scheduling functions
No access from Asset Management console
No access from Asset Manage ment console
No access
No access
Write access to purchase requisitions (including line items) that are assigned to the user’s support group
No access
Read access Write access from CIs the user supports
Read access Read access from CI forms
Purchasing Console
No access
No access
No access
Write access to purchase orders Receiving Console
No access
No access
No access
No access
Access to receiving functions
BMC Remedy Service Desk architecture Service Desk enables IT to respond quickly and efficiently to conditions that disrupt critical services by automating incident and problem management processes. Service Desk acts as a single point of contact for user requests, usersubmitted incidents, and infrastructure-generated incidents.
High-level process flow The service desk is made up of two distinct processes under ITIL: the incident management process and the problem management process.
94
While the incident management process focuses on getting users up and running, problem management focuses on determining the root cause, and using the change management process to correcting the root cause of the problem. End User Request
Incident Management Process
Notified of Completed Fix
Change Management To Correct Errors
Known Error Management
Problem Investigation
Notified of Completed Fix
Notified of Completed Fix
BMC Remedy Incident Management Incident Management BMC Atrium CMDB Task Management Cost Subsystem ITSM Foundation SLM
Incident management’s primary goal is to get the user back to work as soon as possible after an incident. Incidents can enter the system manually or automatically. Users can create incidents using the Requester Console. The Requester Console provides users a simple interface for entering and managing their requests. Incident Management integrates with the Requester Console to provide this interface. Support technicians at the service desk can also manually enter incidents using the HPD:Help Desk form. Several functions are provided to make entering incidents easier, including templates, scripts, and automation. Incidents can also be created automatically. The Incident Management application provides integration interfaces that allow external applications to create, modify, and query data in the Incident Management database. The integration between the BMC Service Impact Manager and Incident Management is an example of an
95
external application that integrates with Incident Management to generate incidents based on events in the service model.
Process flows
ITSM auto-detect incident management process overview Identification and recording (Classification)
Yes
Incident detected
Self correcting?
Incident Auto Detected?
Yes
Incident closure
Resolution and recovery
Incident Ccosure
No
Identification and recording (Classification and initial support)
No
Investigation and diagnosis
Incident Detected
Call to Service Desk
Resolution / Workaround Validation
Web Self-Help
1 Incident Detection and Recording
4 Resolution and Recovery
Incident Recorded 2 Classification and Initial Support Event Monitoring Incident Detected
No Available Resolution / Workaround
Resolution / Workaround Validated and Accepted
5 Incident Closure
Resolution / Workaround Found 3 Investigation and Diagnosis
Other Service Support / Delivery Processes
Incident Manager
Incident Queue Incident Assignee Incident Assignee Manager (Tier 2/3/n) (Tier 1) (Optional)
Customer
ITSM manual incident management process overview
96
Capacity / Availability Management
Request Management
Change Management
Problem Management
Problem Management
Configuration Management Service Level Management
Problem Management
Change Management
Problem Management
Design overview The Incident Management application follows the guidelines described in this document for how systems should be developed. It is encapsulated in a deployable application to provide the ability to abstract the permission model and to provide for licensing.
Main forms The main forms used in the Incident Management application are: HPD:Help Desk
This form is the main repository for incidents. All incidents are stored in this form, and all workflow around the lifecycle of an incident is associated with this form. This form also provides the main user interface for support technicians who work the details of an incident.
HPD:Template
The HPD:Template form provides the repository for incident templates. Incident templates provide the ability to quickly fill in common data for common incident types.
97
HPD:Template Associations
This form stores the relationships between a template and a CI. Templates provide functionality to let you relate a template to a particular CI from the BMC Atrium CMDB. This is useful if the template is against a service CI or a business process CI.
98
HPD:TemplateSPGAssoc
This form provides the repository for the associations between a template and the support groups that can use the template. Workflow shows only templates based on a user being in a support group that is mapped to the templates the user wants to use.
HPD:Worklog
This form is the repository for work log entries for the Incident Management application. The tables on the HPD:Help Desk form look up information from this table. HPD:Impacted Areas
This form holds the relationship between an incident and the areas affected by the incident. Impacted areas describe the location from the location structures that are affected by an incident. This table can be populated by pulling the information from a related CI, or by adding additional affected areas to the incident. HPD:Associations
This form is the main association table for the Incident Management application. It holds the relationships in the context of Incident Management.
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: •
Uses the SRMS framework in the Requester Console to create incidents.
•
Updates incident information using the work log.
•
Has an interface back from the incident to the request that is stored in the Requester Console.
•
Updates the status of the request to match the status of the incident, and makes visible Work Info entries.
The following diagram describes the flow from the Requester Console to Incident Management. The Requester Console interacts with Incident Management using the Incident Management interface forms. Requester Console
SRMS framework C eate Events
HPD:IncidentInterface_Create
CAI:Events Get
Application Object Event
HPD:IncidentInterface
or Set
CAI:EventParams holds the field mapping when incident communicates with the SRMS framework
HPD:Help Desk
Task Management System
The Task Management System subsystem provides the ability to track specific tasks that are required to resolve an incident. The integration to TMS provides the ability to create ad hoc tasks. From the Incident Management user interface, the integration is to the TMS:AssocSummaryDataJoin form, which is a join between the TMS:Association form and the TMS:SummaryData form. See the Task Management System section for the TSM ERD.
100
Tasks are created in the TMS:Tasks forms. In ITSM 7.0, only integration for ad hoc tasks is supported.
Service Desk
Incident Management
Problem Management
Ad-hoc creation only TMS
TMS:Tasks
101
Cost Management
Incident Management uses the Cost Management subsystem to track costs associated with incidents. The integration uses the common cost creation dialog box that is provided by the Cost Management subsystem. The table field on the HPD:Help Desk form integrates with the FIN:CostAssociatonJoin form to display cost data related to an incident. SLM
Incident Management integrates with the SLM application to provide service level definitions for resolution and response time for incidents. When SLM is installed, a tab on the HPD:Help Desk form is enabled, showing the service targets and milestones that are associated to an incident.
102
In addition to the user interface integration, the Incident Management application also ties in to the definition structure of SLM. SLM has a plug-in architecture for helping users define terms and conditions, and measurements for a service target. Incident Management provides a user interface for this SLM plug-in architecture to make it simpler for users to build qualifications using a query-by-example (QBE) model.
103
BMC Atrium CMDB
Incident Management integrates with the BMC Atrium CMDB using relationship tables. From the Incident Management user interface, users can search for CIs and relate CIs to an incident. When Asset Management is installed, this integration is extended by prompting users to create outages against CIs they are relating to the incident. The outage data is stored in the Asset Management application database, with relationships created back to the incident.
104
ERD
Change Management
CHG:Infrastructure Change
Problem Management
Lookup Data
PBM: Problem Investigation
PCT:Product Catalog PBM: Known Error
CFG:Service Catalog
SIT:Site
PBM: Knowledge Database
HPD:Help Desk
Asset Management/ CMDB :
CTM:People Organization
AST: CI Unavailability
HPD:Association
BMC:* CMDB Classes
FIN: Costs
FIN: Association
CFG: Broadcast Association
HPD:Help Desk
Foreign Key: Request ID
TMS: Associations
(See Note)
(See Note)
CFG: Broadcast
HPD:HelpDesk_AuditLogSystem
CTM:People
CTM:Company
TMS:Task
Foreign Key: Incident Number
(See Note)
Foreign Key: Incident Number
HPD:ImpactedAreas
CTM:Support Group
HPD:Work Log
105
CTM:People Used in various contexts, key back is the login ID for each of these areas: - Customer - Contact - Owner - Assingee - Vendor Contact
CTM:Company Used in various contexts, key back is the company name for each of these areas: - Customer Company - Contact Company - Owner Support Company - Assingee Support Company - Vendor Company - Company (also known as the operational company) CTM:Support Group 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.
Help desk ticket submit
ITSM Creates an association with a CI if a CI name is specified
External application
Creates staging record using Help Desk Submit web service
HPD:IncidentInterface (Staging form) Processes incoming parameters
Association forms
HPD:Help Desk Creates Help Desk record and Work Log record HPD:Work Log
Data flow direction
Interface forms
•
HPD:IncidentInterface_Create—Interfaces with the HPD:Help Desk form to create incident tickets.
•
HPD:IncidentInterface—Self-join of HPD:Help Desk form for query and modify operations.
Web services
•
HelpDesk_QueryList_Service—Queries for multiple tickets in the HPD:HelpDesk form.
•
HelpDesk_Modify_Service—Modifies a ticket in the HPD:HelpDesk form.
•
HelpDesk_Query_Service—Queries for tickets in the HPD:HelpDesk form.
•
HelpDesk_Submit_Service—Submits a ticket in the HPD:HelpDesk form.
Licensing model Incident Management licensing is enabled using the Deployable Application mechanism in AR System.
107
Incident Management requires the following application-level and user-level licenses: •
Incident Management application license
•
Incident User fixed or floating user license for modifications on the HPD:Help Desk form
•
Financial application license to access costing data
•
BMC Atrium CMDB application license to access the BMC Atrium CMDB
Permission model The permission model of the Incident Management application has five basic roles: •
Incident Viewer
•
Incident User
•
Incident Master
•
Incident Submitter
•
Incident Config
BMC Remedy Problem Management Problem Management BMC Atrium CMDB Cost Subsystem ITSM Foundation Knowledge
Problem Management is focused on finding the root cause of an issue in the IT infrastructure, and working to correct that known error. Problem Management has three main components: •
Problem investigation
•
Known error management
•
Solution database
Problem investigation The problem investigation module of Problem Management is focused on determining the root cause of an infrastructure problem. The results of a problem investigation are:
108
•
Known errors—Describe the root cause.
•
Knowledge solution entries—Describe how to work around the issue and potentially other incidents or problems to investigate.
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: •
A change request to implement the desired fix.
•
Closing the known error as an accepted issue, with updates to the knowledge database with steps to avoid the issue.
Solutions database The solutions database provides a simple repository of potential solutions to infrastructure issues. These might be workarounds or solutions to use in helping users get around an issue. The data from the solutions database becomes an input into a full knowledge management system with the use of the full BMC Knowledge Management solution.
Process flows
Investigation Initiated
Other Service Support / Delivery Processes
Problem Manager
Problem Assignee
Requester
ITSM Problem Management Process Overview
3 Problem Investigation and Diagnosis
1 Problem Identification, Recording and Classification
8 Knowledge Identification and Recording
5 Known Error Identification and Recording
4 Problem Resolution and Closure
6 Known Error Classification and Assessment
7 Known Error Resolution and Closure
9 Knowledge Validation and Publication
2 Review
Incident Management
Incident Management
Change Management
Change Implemented
Incident Management
Configuration Management (Mgmt Reports)
© 2004 BMC Software, Inc. All rights reserved.
109
Main forms This section describes the main forms used in Problem Management. 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. PBM:Investigation Effort Log This form provides a repository for the effort that has been put into determining the root cause of a problem. It tracks the amount of time by user.
PBM:Investigation Work Log This form provides the repository of work log entries associated with individual problem investigations.
110
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. PBM:Known Error Associations This form provides the repository for associations between known errors and other records. It holds the context of the record being displayed. PBM:Known Error Work Log This form provides the repository of work log entries associated with individual known errors. Solutions database
PBM:Solution Database This form is the repository for solution records. Solution lifecycle and processes around solutions are driven off this form. It is the main user interface for support technicians who work on solutions. PBM:Solutions DB Alias This form provides the repository for search keywords that are associated with a particular solution. This information is available from solution search dialog boxes to allow users to search by keywords. PBM Solutions DB Associations This form provides the repository for associations between solutions and other records. It holds the context of the record being displayed.
111
ERD Change Management :Infrastructure CHG:: Change
Problem Management
Lookup Data
PCT:Product Catalog
Incident Management
HPD:
PBM: Problem Investigation
Help Desk PBM: Known Error
CFG:Service Catalog PBM:
SIT:Site
Solution Database Asset Management/ CMDB :
CTM:People Organization
AST: CI Unavailability
PBM: Associations
BMC:* CMDB Classes
FIN: Costs
FIN: Association
PBM:
Problem Investigation
CFG: Broadcast Association
Foreign Key: Request ID
TMS: Associations
(See Note)
(See Note)
CFG: Broadcast
PBM:Problem_AuditLogSystem
CTM:People
CTM:Company
TMS:Task
Foreign Key: Incident Number
(See Note)
Foreign Key: Incident Number
112
PBM:ImpactedAreas
CTM:Support Group
PBM:Work Log
CTM:People 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
Lookup Data
PCT:Product Catalog
Incident Management
HPD:
PBM: Problem Investigation
Help Desk PBM: Known Error
CFG:Service Catalog
PBM:
SIT:Site
Solution Database Asset Management/ BMC Atrium CMDB :
CTM:People Organization
PBM:
Known Error Associations
AST: CI Unavailability
BMC:* CMDB Classes
FIN: Costs
FIN: Association
PBM: Known Error
CFG: Broadcast Association
Foreign Key: Request ID
TMS: Associations
(See Note)
CFG: Broadcast
PBM:Problem_AuditLogSystem
CTM:People
(See Note)
CTM:Company
(See Note)
CTM:Support Group
TMS:Task
Foreign Key: Incident Number
114
PBM:Known Error Work Log
CTM:People 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
Lookup Data
Incident Management
HPD:
PCT:Product Catalog
PBM: Problem Investigation
Help Desk PBM: Known Error
CFG:Service Catalog
PBM:
SIT:Site
Solution Database Asset Management/ BMC Atrium CMDB :
CTM:People Organization
PBM:
Solution Associations
AST: CI Unavailability
BMC:* CMDB Classes
FIN: Costs
FIN: Association
PBM:
Solution Database
Foreign Key: Request ID
Foreign Key: Assingee
TMS: Associations
PBM:Problem_AuditLogSystem
CTM:People
Foreign Key: Assignee Company
CTM:Company
Foreign Key: Support Group
CTM:Support Group
TMS:Task
Foreign Key: Incident Number
Interfaces
116
•
PBM:ProblemInterface_Create
•
PBM:ProblemInterface
PBM:Solution Work Log
•
PBM:KnownErrorInterface
•
PBM:SolutionsInterface
ITSM 7.0 subsystems This section describes subsystems used by ITSM applications.
Command Automation Interface The Task Management System (TMS) provides tasking capabilities to the Change Management, Problem Management, and Incident Management applications, and integrates with the BMC Configuration Management system using the Common Automation Interface (CAI). The Service Request Management System (SRMS) framework support the Requester Console, which is the front-end user interface for Change Management and Incident Management. TMS and SRMS use the CAI to communicate with ITSM applications. The CAI subsystem provides a common infrastructure that can be shared across applications including ITSM 7.0 applications and BMC Configuration Management. The functionality of CAI is based on the current implementation for SRMS framework command events and the requirements of TMS. The CAI consists of three major blocks that result in event delivery to the target applications. For ITSM 7.0, CAI is a back-end component that does not provide a front-end user interface. Additional user dialogs can be created for each integrated component to push data into the CAI forms.
Overview This section provides an overview of TMS. Definition phase: Application registration and command definition
Application registration defines the integration attributes to the external systems, such as application name, connection information, and interface form names. Command definition describes the commands and the command parameters for each integrated component. For example, the Requester console has defined a set of commands for interaction with back-end applications. In TMS, a set of commands is defined for interaction with BMC Configuration Management. In addition, the CAI can include command parameter mappings to the registered applications. Construction phase: Instantiation of the command definition as events
Command events are instantiated based on the command definitions. The event is constructed using the specific command name, and the command parameter values are populated by the integrated components. For example, when the SRMS
117
framework needs to create a new back-end application request, it pushes a new event record with the command name, SRM_OUT_CREATE_APP_REQUEST (CreateAppRequest). It also pushes the event parameters for template ID and service request ID using the appropriate run-time values. In TMS, when it needs to construct a URL string to interact with BMC Configuration Management, TMS specific workflow creates the appropriate event with the run-time parameter values and formats the URL string accordingly. CAI provides the form structure and generic workflow for command instantiation. Each integrating component must implement the workflow to handle its specific commands. Execution phase: Event delivery
The mechanism that delivers the command events to the target system depends on the protocol used. For “AR” protocol, where the target is another AR System application, the CAI event plug-in can be used. This plug-in creates the appropriate records as specified in target information of the event. For “URL” protocol, workflow sets the URL string to the appropriate view field for the browser. CAI provides the generic event plug-in and each integrating component must implement the workflow to handle the invocation of the plug-in, or use specific workflow for the delivery. For ITSM 7.0, AR and URL protocols are supported. Definition 1
Construction
Event What Data Values
3
Command HowContent
Execution 5
RuntimeJust Command Do It
4
2 ID
App Registry Name Protocol
Command
Param
Commands Direction Op. Type
Parameters Data Type
Done Mode
ERD A diagram of CAI follows that outlines the three phases for outbound commands: definition, construction, and execution. Each event must have the following field values: Command name—Name is defined in the command definition, with specific naming convention.
118
TargetKeyword (SRMS, TMS, APP)—APP means back-end application. SourceKeyword (SRMS, TMS, APP) Direction (Inbound or Outbound)—Outbound means an event sent by SRMS framework or TMS to APP. Type (Create, Update, Get)—Create means an entry will be created as part of the event delivery. Update means an entry will be updated; Get means an entry will be queried. Depending on the command type, the CAI plug-in will create, update, or query an entry from the interface form for all outbound commands. In general, the CAI plugin can be used by all events of AR protocol, and is most useful in scenarios where dynamic fields are used. In ITSM 7.0, the SRMS framework is the only component that invokes the CAI plug-in. TMS uses all URL-based commands and has workflow that constructs the URL string based on the event parameters.
119
Definition
2 . Map command paramters for each registered
1 . Register CAI : AppRegistry
U1 U2
CAI :CommandParamMappin
InstanceID AppRegistryName ApplicationName ApplicationInstanceID Protocol Connection Info Interface Form Names
AppRegistryName Command CommandParam AppInterfaceFormName AppFieldName AppFieldID ParamType ParamDataType
0 . Create commands and command paramters CAI : Command
U1
Command Direction OperationType SelectionType
CAI :CommandParam
U1 U1
Command CommandParam Type DataType Mode
Construction
CAI : Event CAI :EventParam EventGUID Event Source Target SourceAppRegistryInstanceI AOIGUID AppInterfaceFormName TargetConnectionInf RtnCode RtnMsgCode RtnMsg MaxRetries RetryCounter
Execution (outbound)
EventGUID ParmName ParamValue ParamAttachmentValue ParamType ParamDataType Push event and run time data to event params (outbound )
SRMS framework/TMS Calls GetEntry to get event values
Filter API Plug-in Push event and event params App Interface Form
Mapped Param
120
AR System workflow Launch
Browser
The inbound events should be created in the event and event param forms by the back-end applications. Workflow must be implemented to process the command events by the target application, such as TMS. The workflow qualification should be based on the values of TargetKeyword and Event. For example: TargetKeyword = SRMS Event = SRMS_IN_APP_REQUEST_RESOLVED
121
The following high-level diagram shows the flow of inbound commands. In this diagram, the “Target” is SRMS and the “Source” is APP, which means a back-end AR System application. Definition
2. Map command paramters for each registered application
1. Register application CAI:AppRegistry
U1 U2
CAI:CommandParamMapping
InstanceID AppRegistryName ApplicationName ApplicationInstanceID Protocol Connection Info Interface Form Names
AppRegistryName Command CommandParam AppInterfaceFormName AppFieldName AppFieldID ParamType ParamDataType
0. Create commands and command paramters CAI:CommandParam CAI:Command
U1
Command Direction OperationType SelectionType
U1 U1
Command CommandParam Type DataType Mode
Construction
CAI:Event CAI:EventParam EventGUID Event Source Target SourceAppRegistryInstanceID AOIGUID AppInterfaceFormName TargetConnectionInfo RtnCode RtnMsgCode RtnMsg MaxRetries RetryCounter
Execution (outbound)
EventGUID ParmName ParamValue ParamAttachmentValue ParamType ParamDataType Push event and run-time data to event params (outbound)
SRMS/TMS
Calls GetEntry to get event values
FilterAPI Plug-in Push event and event params App Interface Form
Mapped Param
122
AR System workflow Launch
Browser
Component Design
Forms and plug-in The CAI consists of the following forms and plug-in: •
CAI:AppRegistry
•
CAI:Command
•
CAI:CommandParam
•
CAI:Event
•
CAI:EventParam
•
CAI:CommandParamsMapping
•
CAI:DefineCommandParameters
•
CAI:Plugin Registry
•
Filter API plug-in, caieventcmd.dll
All forms in CAI are back-end forms and each integrating component must provide its own user interface for user updates to these forms. TMS contains front-end forms that use workflow to push TMS data to the CAI:AppRegistry form. CAI:AppRegistry This form stores application interface information, such as interface form names, connection data, and the protocol. Each integrating component, such as TMS, must provide the user interface and workflow for updates to this form. CAI:Command, CAI:CommandParam These forms store command names and command parameters for each integrating component. There is a one-to-many relationship between a command and a command parameter. A command parameter cannot be used by more than one command. Naming conventions must be used to allow generic qualifications for event process filters, as in the following listed for the SRMS framework and for TMS. SRM_IN_[COMMAND_NAME]—SRM inbound command. SRM_OUT_[COMMAND_NAME]—SRM outbound command. TMS_IN_[COMMAND_NAME]—TMS inbound command. TMS_OUT_[COMMAND_NAME]—TMS outbound command. For localization considerations, command parameter names must use all uppercase letters and with no spaces.
123
CAI:Event, CAI:EventParam These forms store the event and related parameters. Each integrating component must implement specific filter workflow to process its specific commands. Guides should be used whenever possible to minimize undesirable filters being executed. The following table shows naming standards and workflow order: Component
Filter prefix name
Filter order range
CAI
CAI:
100-199
SRM
INT:CAISRM:
200-399
TMS
INT:CAITMS:
400-599
CAI
CAI:
900-999
Some exceptions might be required for certain filter order numbers. For example, some CAI filters might fall between SRM and TMS range. Each event record has a version number, which allows for compatibility between different CAI and integrating components versions. Workflow that processes the event should always set the Return Code field to indicate success or failure. 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.
1. Event is created in CAI:Events form; parameters are pushed to CAI:EventParams form
6. CAI plugin returns status to CAI:Events form
Service Request
CAI:Events 2. When an entry is created in the CAI:Events form, the CAI plug-in is called CAI:EventParams
Main Plug-in code
3. The CAI plug-in creates an entry in the request queue and returns Status = Running to CAI Events form Request queue
4. When a request is added to the queue, a signal is issued to wake up a thread in the thread pool to process the request.
CAI Plug-in Thread Pool
5. CAI plug-in creates Change Request and/or Incident
HPD:HelpDesk
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: Command
Direction
Filter API action
CreateAppRequest
Outbound
CREATE
GetAppRequestInfo
Outbound
GET
CancelAppRequest
Outbound
UPDATE
UpdateAppRequestWorkLog
Outbound
UPDATE
ActivateAppRequest
Outbound
UPDATE
AppRequestInProgress
Inbound
UPDATE
AppRequestResolved
Inbound
UPDATE
AppRequestCancelled
Inbound
UPDATE
UpdateSRWorkLog
Inbound
UPDATE
Decrypt Password
Outbound
DECRYPT
Web services
The web service setup for the CAI is a “complex” web service, which means it is made up of multiple components and presented as a single interface. The two CAI components: CAI:Events and CAI:EventParameters, are defined as a single web service.
126
The following table summarizes the names of the operations, the base form the operations function against, and the name and form types of the supporting AR System forms that serve as the interface to these areas of the CAI.
Base form
Operation description
Operation name
Interface form*
Form type
CAI:Events (root)
Query individual event
OpGet
CAI:Events (root)
Regular
CAI::EventParams
Query list of entries
OpGetList
CAI::EventParams
Regular
Create CAI event and CAI event parameters
Op Create
Note: The web services for these functions are directly connected to the base forms using an XSD file. In a future release, an abstraction layer will be introduced in front of these base forms to act as the primary interface for external systems. This will enable making the maintenance and code updates to enhance functionality of the CAI transparent to any external integrations. In addition, this abstraction layer will make it easier to maintain backwards compatibility for subsequent releases.
Permission model The CAI has the Command Event Master role, which by default is mapped to the Command Event Master group, and can be granted to users using the People form. Only users in this group and AR System administrators can access the CAI forms and update certain fields on them. For implementation of event error handling, integrating applications must have the same group and role mapping. For remote access using AR protocol, the remote AR System login must have permission to create and update to the interface forms specified in the AppRegistry form. Similarly, for the back-end application to send inbound commands to the remote front-end application, such as TMS, the TMS AR System login must have permission to create records in the event and event parameters forms. See the dataflow diagram for the integration points.
Contract Management The Contract Management subsystem provides a generic contract for tracking basic contract information and lifecycle. This system is used by Asset Management and Service Level Management as a basis for their specific definitions of a contract.
127
ERD Application specific contracts
Join
Contract Management subsystem CTR:ContractBase
CTR: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. Each Contract permission group is mapped to an Asset permission group to support the deployable application functionality. To remove specific users from the computed group, remove the Asset Management groups for each Contract permission group to make each Contract permission group stand alone.
128
Each Contract Management permission group is mapped to an Asset Management permission group, as shown in the following table. Contract Management permission group
Asset Management permission group
Access
Contract View Only
Asset Viewer
Read
Contract Full Access
Asset User, Asset Admin
Write
Contract Administrator (reserved for future use)
N/A
Write
Costing Management The Costing Management subsystem provides functions required by the ITSM suite for management of cost data. The costing model has two components: tracking of costs, and chargeback calculations and reporting. Each application uses Costing Management to track the costs related to the records in the application. For example, Incident Management uses Costing Management to track the various costs associated to incidents. Asset Management also uses the chargeback functionality in Costing Management. Chargebacks are roll ups of the costs that have been incurred over a period and involved in the various cost centers in a company. The chargeback component of Costing Management generates chargeback entries, lets the financial manager make appropriate adjustments to the costs, and generates invoices to be sent out to the individual cost centers. Costing Management is designed to be completely standalone. The main form, FIN:Costs, holds individual cost data. The relationships to the main records use associations in the FIN:Associatons table. Costing Management also provides a join between the FIN:Costs and FIN:Assocaitons tables to provide the query interface for use by applications that integrate with the subsystem. This join is used by table fields in ITSM applications. The chargeback functionality is enabled by a filter API application. It is driven by data in the chargeback forms that define the cost centers, how the cost centers are allocated, and the dates for running chargeback reports. The result of the API run is a set of chargeback entries. The chargeback functionality provides an adjustment user interface that is used to adjust the chargeback costs, and a reporting user interface to run invoices. The costing forms and workflow are encapsulated in a deployable application. This provides the ability to license and abstract the roles for the subsystem. Costing Management has clearly defined interfaces for integration, with a programmatic interface used for creating and modifying data. Users can also create
129
and update data through a common user interface dialog box. The functionality of this interface is driven by flags that are passed in. These flags control which templates are available, the ability to regenerate costs, and the ability to lock down costs.
Calling System Interaction Calling System
Interface Form Functions: Creating Automatic Cost Entries Updating Automatic Costs Lock Cost Entries Copy Cost Record Request 112 update on Associated Costs
130
ERD Base Data Model FIN:Association FIN:Cost
Calling System Form Calling System Identifier Cost Record Instance ID Association Type Primary Informational Allocation
Cost Center Cost Type Description Amount Units Date Incurred Instance ID
FIN:CostAssociationJoin
Filter API
FIN:ChargeBacks
Calling System Table Identifier
Populated using a filter API process with cost data and cost center allocations from FIN:Cost . Used for chargeback reporting.
Licensing model The Costing Management subsystem requires an application-level license. This license is provided with all ITSM applications. A user license is also required for the chargeback component of the subsystem. This license is required for making adjustments to the chargeback functionality.
Permission model Roles
The roles defined for the costing subsystem are: Viewer—Can only view cost data. User—Can add costs. Manager—Can update and manage the chargeback process.
131
Definitive Software Library The ITIL definition of the Definitive Software Library (DSL) is a library where the definitive authorized versions of all software Configuration Items (CIs) are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This logical storage area might consist of one or more physical software libraries or file stores. In short, the DSL is a repository of authorized and approved software available to be deployed to the production environment. It contains or provides a reference to the “golden images.” The BMC implementation of the DSL was designed around these principles and is structured to: •
Be the centralized store of authorized software package information.
•
Ensure consistency between Change Management and Configuration Management.
•
Normalize entries in the BMC Atrium CMDB.
•
Keep asset information in the BMC Atrium CMDB accurate.
The following is the Definitive Software Library Console. It is used to manage the contents of the DSL.
132
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 Manager Change Assignee
System to System Interaction
Asset Management
Data Interaction
• Software License Mgmt • Approvals •…
Change Management Change Request • Product Lookup • DSL Reference • Related CI Targets
CMDB Configuration Discovery Definitive Software Library Policy Manager
Task Management System Command Automation Interface
Task Implementer
Deployment Manager
Common Management Services
Primary components of the DSL The four primary components of the DSL model are: •
Product Dictionary (PD)—A Product Dictionary entry represents the normalized name of an application or software item that has been authorized to be available for release to the production environment. The normalized name of an application or software item consists of the product name, manufacturer, version, and patch.
•
Associated files—A list of files that are executed or referenced in support of the application.
•
Software Library Items (SLIs)—Location or storage of media.
•
Suite definition—Application suites are bundles of software and can consist of one or more entries in the Product Dictionary. For example, the Microsoft Office is suite consists of the software items Word, Excel, PowerPoint, and Outlook. Suites are represented as entries in the Product Dictionary.
133
The following diagram provides a high-level illustration of how these components are organized as part of the DSL.
The Definitive Software Library (DSL) Product Dictionary • • • •
Product Name Version Patch Manufacturer
Software S/W Library Library Item Item Software Location location Information information Suites Products Related related to a Suite suite Files List of Related related Files files
The Product Dictionary is the parent object in the DSL. The Software Library Item to Suite cross-reference and related files table are all children of the Product Dictionary. A DSL entity is defined by the Product Dictionary record and all the corresponding related information stored in the Software Library Item, suites, and files table.
ERDs The following ER diagram represents the data model of the BMC DSL. The items in blue are unique to the DSL model. The items in white are part of the ITSM foundation and are shared by ITSM applications.
134
ModelVersionPatch -PIID +PMVIID +PatchLastBuildIn 1 D
Company - CIID + Company + Type
1
Product - PIID + CIType + ProductCat1 + ProductCat2 + ProductCat3
Version -VIID + PIID + PMV State + Product Name + Manufacturer
nn
ProductCompany -A PIID + CIType + ProductCat1 + ProductCat2 + ProductCat3
. 1
n
1 1
ProductModelVersion - VIID - PIID + CIType + ProductCat1 + ProductCat2 + ProductCat3 + PMV State + Product Name + Manufacturer
1
n
ProductDictionary n -VIID -PIID +CIType 1 +ProductCat1 +ProductCat2 +ProductCat3 +PMV State +Product Name +Manufacturer
n
n Suite_PD Lookup
Legend Foundation Objects
SLI
1
n
-SLIIID +VIID +Description +Type +State +Location
1
1
n
n
PV_Files Lookup +VIID +FileID
Attachments -Attachment +DSL IID IID +Description +Attachment
n
+SuiteIID +VIID Vendor Version - VVIID + Description + VersionString + ComponentNam
ProductDictionaryPatc h -PMVIID -ProductIID -PatchIID -. -. -.
n Files -FIID +Name +FileSize +CRC +TimeStamp
PD/DSL Objects Only required fields are represented .
The fields to be represented in a Product Dictionary entry depend on the fields currently in the PCT:Product Catalog form and additional fields needed to support data from a third-party vendor. The PCT:ProductCatalog and PCT:Product Model/Version forms include DSL specific fields. The join of these two records is the intermediate form PDL:ProductModelVersion. PDL:ProductDictionary is the join between the PDL:ProductModelVersion and PCT:ProductCompanyAssociation forms. PDL:ProductDictionaryPatch is the join between the PDL:ProductDictionary and PCT:ModelVersionPatch forms. PCT:ModelVersionPatch is the normalization of the patch information to the CFG:ModelVersion form. PDL:ProductDictionaryPatch is the table used to represent the Product Dictionary entries in the DSL console.
135
PCT:ModelVersionPatch PK PCT:Product Catalog PK
PCT:ProductCompanyAssoc
Instance ID
PK Add DSL Fields
ProductID CI Class ProductCatTier 1 ProductCatTier 2 ProductCatTier 3 Product Name Manufacturer Price Product 's Image
Product Name Model Version PatchLastBuildID MainExeID MainExeName
InstanceID ProductIID Company
JOIN
Origin IsSuite
JOIN
PDL:ProdDictionaryPatch PK
PDL:ProductModelVersion PCT:Product Mod/Version
PK
Add DSL Fields
Instance ID PMV ID Product IID ProdMod Vers PMV State Product Name Manufacturer PatchLastBuildID ManufacturerPartNo GeneralAvailDT DiscAvailDT DiscSupportDT PreReleaseDate
Product ID PMV ID ProductIID ProdModVer PMV State ProductName ..... OS Locale Platform VersionMajor VersionMinor VersionBuild VersionMaint
GUID OS Locale Platform VersionMajor VersionMinor VersionBuild VersionMaint ManufacturerID
VersionIID ProductID CI Class ProductCatTier 1 ProductCatTier 2 ProductCatTier 3 ProductName Manufacturer ManufacturerID GUID OS Origin IsSuite Locale Platform PMV State ProductName
InstanceID
PatchIID ProductID CI Class ProductCatTier 1 ProductCatTier 2 ProductCatTier 3 ProductName Manufacturer ManufacturerID GUID OS MainExeID MainExeName Origin IsSuite Locale Platform ProductID PMV State ProductName
JOIN
PDL:ProductDictionary PK
PK
Instance ID
Data example Model/Version Patch
Company/Manufacturer Product Company Association
PD1 PD2
Patch
PA1
2.3
V3
PA2
1.0
V1
PA3
0.0
Name
State
C0
-Global-
--
C1
... MS
WA
PIID
Company
VIID
PIID
PatchIID
C2
... Dell
TX
PD1
-Global-
V2
... PA1
PA1
PD2
-Global-
V3
PA2
PA2
PD3
-Global-
V1
PA3
PA3
CIID C1 C1
Origin rd
3 Party 3rd Party
PIID
VIID
Name
CIID
PD1 PD2
V2
Word
C0
V3
Excel
C0
PD3
V1
Outlook
C0
PD4
... ... ... ... V4 Office
Is Suite No No
Product Model/Version (Join)
C1
3rd Party
No
PIID
VIID
Name
PD4
C1
3rd Parth
Yes
PD1
V2
Word
PD2 PD3 Model/Version Base VIID
ProductDictionaryPatch (Join)
Product Dictionary (Join)
PD3
PIID
Version
V1
PD3
4.0
V2
...PD1 ... ...
3.0
V3
...PD2 ... ...
4.2
V4
...PD4 ... ...
6.0
PD4
F V3 V1 V4
Excel Outlook Office
C0 Software Library Item
Files Lookup VIID Suite Mapping SuiteIID
PDIID
PD4
PD3
FIID
SLIID
PIID
Location
F1
SLI1
... PA1
Shelf
F3
SLI2
PA2
Shelf
SLI3
PA3
Disk
V2 V1
... has .../... has ... PD4 PD2 PD4
PD1 Files
KBVersion VVID
Version
KB1
1.0
...KB2 has .../... has 1.3 ...
136
PatchIID
V2
CIID
Product Catalog Base PIID
VIID
FIID
Name
File Size
F1
Word.exe
3784
F2
F Excel.exe
1816
F3
Outlk.exe
2590
Interfaces Three interface tables support submit, modify, and query operations performed by external systems. The following are the interface (staging) forms for the DSL: •
PDL:SLIInterface_Create—Staging form that interfaces to the PDL:SoftwareLibraryItem form. This form is used for creating Software Library Item entries.
•
PDL:SLIInterface—Self-join form of the PDL:SoftwareLibraryItem form. This form is used for query and modify operations.
•
PDL:PDInterface—Self-join form of the PDL:Product Dictionary form. This form is used for query and modify operations.
The interface (staging) forms contain all necessary fields from the interface form that will be input from an external source.
137
Software Library Item submit
ITSM External application
Creates staging record using Product Dictionary web service
PDL:SLIInterface_Create (staging form)
PDL:SoftwareLibraryItem
Processes incoming parameters
Data flow direction
Web services Web services interfaces allow for programmatic access to the individual applications and subsystems. •
Product Dictionary The following functions enable web service operations for the PDL:Product Dictionary form using the PDL:PDInterface interface form: • PD_QueryList_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:
Base form and type PDL:Product Dictionary Self-join
PDL:Product Dictionary Patch
Operation description
Operation name
Interface form
Query list of entries
PD_QueryList_Service
PDL:PDInterface
Query field list
PD_QueryListFields_Service
Query list of entries
PDP_QueryList_Service
Query field list
PDP_QueryListFields_Service
Create SLI
PDL_SLI_Submit_Service
PDL:SLIInterface_Create
Modify SLI
SLI_Modify_Service
PDL:SLIInterface
Query for specific SLI
SLI_Query_Service
Query for list of SLIs
SLI_QueryList_Service
Query field list
SLI_QueryListFields_Service
PDL:PDPInterface
Self-join
PDL:SoftwareLibraryItem Regular Self-join
139
Permission model DSL has the following permissions: •
Level 1—DSL Administrator: Access to add and modify Product Dictionary and Software Library Item definitions.
•
Level 2—DSL User: View access to Product Dictionary and Software Library item definitions.
Requester Console and SRMS framework The Requester Console is supported by the Service Request Management System (SRMS) framework, which implements the service request component for integration to the back-end Change Management and Incident Management ITSM 7.0 applications. The service request entity serves as a bridge and is not designed to be managed by service desk personnel. It is a “slave” to the back-end change request or incident with its lifecycle completely driven by the back-end. The base form, SRM:Request, is hidden, except for system troubleshooting when it fails to communicate with the back-end. The Requester Console is the front-end entry point for users to submit requests.
Requester Console Request object Obj t SRMS framework Framework
OR Change Management
140
Incident Management
Requester Console The Requester Console is a simplified interface for users to submit change requests and incidents, similar to the Requester interface in ITSM 6.0. This allows users to submit requests into the system from a single console, without having to directly access the Change Management or Incident Management consoles. The targeted audience is non-IT user requesters.
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. Category
Component
Description
Configuration
SRM:ApplicationSettings
Contains records to determine the settings for the Requester Console and the SRMS framework. This data includes settings to: • Specify the server tenancy mode. • Allow unknown users. • Supply default submit data for unknown users. • Supply default request ID text. • Enable the Requester Console. • Supply AR System logins for access to Change Management and Incident Management. This form has one entry and it can be modified, but not deleted. No additional entries are allowed.
Configuration
SRM:CFG Rules
Contains records to determine the service request rules by company. These rules include settings for auto-close, survey, and individual auto-assignment.
Configuration
SRM:ConsolePreferences
Stores preferences for console behavior.
Configuration
SRM:ConfigSurveyQuestions
Stores the survey questions that are associated to a request when it reaches the “Complete” state. A survey can be set up by Request Type (Incident or Change), and by Company, including Global, which is applied to all companies. One to five survey questions can be configured.
Configuration
Requester Console:SummaryDefinition
The summary definitions provide the menu items for the Summary menu in the New Request form. It predefines the summary text, operational categorization values, and the type of back-end request (change or incident). These values are used to create service requests, which then create the back-end requests, depending on the request type. Each summary record must be unique by Summary and Company fields, using filter workflow validation.
142
Category
Component
Description
Runtime
Requester Console:RequestConsole
Serves as the entry point for users and supports their primary interactions. It provides the user interface for submitting and viewing requests.
Runtime
SRM:ServiceRequestWizard
The Request Wizard provides a simplified interface for users to create and submit a request. This form is a display-only dialog box in which users provide required information to complete the request.
Runtime
SRM:Request
The Requester Console submits a record into the SRMS framework form, SRM:Request, when creating a new request. The SRMS framework implements the workflow and logic to create the back-end change request or incident for the Submit action on the SRM:Request form. The SRMS framework also synchronizes the data and status with Change Management or Incident Management. The Requester Console only displays the information for the user requesters.
Runtime
SRM:WorkInfo
Contains information associated with the user request, which could be attachments or general text summaries. Users can view Work Info entries using buttons on the Requester Console.
143
Category
Component
Description
Runtime
SRM:Survey
When a request reaches a “Complete” status, a survey is generated. Required information from the request is pushed into the SRM:Survey form to create a new survey. Filters on the Survey form get the questions from the SRM:ConfigSurveyQuestions form, based on input parameters from the SRM:Request form. Survey data model diagram 1. New request submitted
2. Creates incident
4. Completed request
3. Incident resolves
Survey rules
5. Survey sent
SRMS framework The SRMS framework provides a bridge between the front-end user requests and the back-end operations. In ITSM 7.0, integrations are implemented to Change Management and Incident Management. However, the SRMS framework provides a structure that can be connected to any other open back-end solution. The design of the SRMS framework is based on the following goals:
144
•
Segment front-end transactions from back-end transactions.
•
Act as a bridge between the Requester Console front-end interface and Change Management and Incident Management back-end applications.
•
Support synchronization between the front-end interface and back-end object life-cycle.
•
Establish a foundation to support integration to back-end systems. • Integrate to Change Management and Incident Management as the back-end applications. • Provide a mechanism for establishing field mappings between the request entity and change request or incident, for request creation. • Provide CAI as a bi-directional communication mechanism for back-end integrations.
•
Integrate with SLM for requester-focused service level agreements (SLA) tracking.
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 Change Management and Incident Management use SRMS framework command events to communicate to and from the Requester Console using the CAI component. Areas where these components are used include the following examples: From the SRMS framework to: •
Create change requests or incident requests.
•
Send work info entries.
•
Cancel or reopen requests.
From Change Management and Incident Management to the Requester Console to: •
Update request status (In Progress, Completed, Canceled, or Rejected).
•
Send Work Info entries.
•
Update request assignee and manager data.
•
Update SLM response status.
For Outbound commands, the SRMS framework communicates with Change Management and Incident Management through the interface forms. For Inbound commands from Change Management and Incident Management, the CAI:Events and CAI:EventParams forms are used for all updates. However, the service request interface form is used for inbound create service request commands. SLM integration Integration to SLM is linked to the SRMS framework SRM:Request form for SLA tracking to requesters. Milestone and action templates are provided for notifications to SLA owners when the goal is close to being missed. SLA owner values come from the back-end change request (from change managers) or incident (from incident owners). Note: The SRM:Request form does not assign owners to the request. Primary components
The Requester Console and the SRMS framework are divided into three major areas: configuration, definition, and execution.
146
•
In the configuration area, summary definitions are set up to communicate with the back-end application requests. For Change Management 7.0 and Incident Management 7.0, two system configuration forms must be pre-populated to work with the Requester Console front-end.
•
In the definition area, summary definitions are established to determine whether a change request or incident back-end application request will be instantiated when the request is submitted. The request object has additional associations to
service level agreements. For more information about definition options, see the BMC Remedy IT Service Management 7.0 Configuration Guide. •
In the execution area, requests for a summary definition are “handed off” to the SRMS framework and the back-end application objects are instantiated to fulfill the request. The application objects are managed by the respective backend application system with their own life cycle. The request has a simple life cycle with additional associations to service level agreements.
The following table lists the primary components that support the SRMS framework: Component
Description
SRM:Request
Request form
SRM:AppTemplateBridge
The Application Object Template stores information about the back-end application request and acts as a stub in the definition area of the SRMS framework. It is used to instantiate an Application Object Instance when a definition is selected as a request during the execution phase.
SRM:AppInstanceBridge
The Application Object Instance is instantiated when a summary definition is selected as a request. It stores information about the back-end application request and its status information. The status includes status values that affect the lifecycle of the service request. The status transition is triggered by certain actions or events from users or from the system. This is a back-end form and is accessible only by AR System administrators.
CAI:AppRegistry
This form is used to register back-end applications that are integrated with the SRMS framework. It contains the template form name, the request form name, and connection data, such as server name, login, and password.
CAI:Commands
Command list form.
CAI:CommandParams
Parameter list form.
CAI:CommandParamsMapping
To facilitate communication between the SRMS framework and back-end applications, mappings must be defined between SRMS framework command parameters and back-end application specific fields. This mapping is defined per registered application in the Application Registry for each command parameter.
CAI:Events
The events table is used to communicate SRMS framework related events, such as back-end application request creation notifications or status changes.
CAI:EventParams
Stores the parameters for event command instances
srmeventcmd.dll
Event Command Filter API (binary).
Mapping data to the back-end applications is required for the SRMS framework to create back-end requests and to send update information. All mapping data is
147
shipped with Change Management and Incident Management as part of the system configuration and should not be changed. Data is included to: •
Register the back-end application with the CAI component (CAI:AppRegistry)—Contains access information to the back-end application. For AR System applications, it also contains the form names for template, interface, and instance forms.
•
Register application fields (SYS:Form Field Selection)—Identifies application fields from the application interface form for question template mappings and command parameter configuration.
•
Configure command parameters (CAI:CommandParamsMapping)—Maps fields from the application interface form to SRMS framework command parameters. The mapping definition is used by the SRMS framework when sending events to the back-end application interface form. The command parameter values are copied to the fields specified by the field ID in the mapping.
•
Define additional questions (SRM:QuestionTemplate).
•
Configure question template mapping from SRMS framework fields to backend requests for request submission.
ERDs
In the following ERD diagrams, the arrows point to the form that stores the foreign keys. For example, ARInstanceID (called out as FK:SRInstanceID) from the SRM:Request form is stored on the HPD:Help Desk, CHG:Infrastructure Change, SRM:WorkInfo and SRM:AppInstanceBridge forms. The SolutionRequestID from the PBM:Solution Database form is stored on the SRM:Request form.
148
PBM:Solution Database
SRM:AppInstanceBridge
SRM:Survey FK:SRInstanceID FK:SolutionRequestID
RQC:Summary Definition
FK:TitleInstanceID
FK:Originating_Request_InstanceID
FK:SRInstanceID
SRM:WorkInfo
SRM:Request FK:SRInstanceID Region/Site Group/Site
Operational Category Requested By Requested For Manager Assignee
CFG:Service Catalog
HPD:Help Desk CHG:Infrastructure Change
COM:Company
CTM:Region
CTM:Support Group
SIT:Site Group
CTM:People
SIT:Site
149
The following diagram illustrates how the SRM:AppistnaceBridge form is used to relate event commands with the corresponding request and the change request or incident records.
FK:SRInstanceID
SRM:AppInstanceBridge
FK:SR_KnoweldgeDatabaseID
FK:AOIGUID
PBM:Solution Database
HPD:Help Desk FK:AppRequestInstanceID
CAI:Events
SRM:Request
CHG:Infrastructure Change
FK:EventGUID
CAI:EventParams
Integration Flow
The request object is the main artifact associated with the execution phase of SRMS. A user can submit a request using the Requester Console wizard. After the request is submitted, based on the selected summary definition, a backend application request is created and the field values are pushed according to question template mapping. The summary definition defines the summary text, categorization values, and request type, which is either Change or Incident. Instantiation Instantiation refers to creation of back-end requests and related SRMS framework objects when a request is submitted. When the request is created from the Requester Console, it is either a Change or Incident request type. By definition, only one Application Object Instance is created. The Application Object Instance has a one-to-one relationship to the request and is instantiated on the Submit action. When a request is submitted and the Request Type is Change or Incident, the following occurs from filters on Submit action for the SRM:Request form: 1. A lookup of the Change Management or Incident Management application in the CAI:AppRegistry form is executed by a fixed application instance ID value. This value is from the SHARE:ApplicationProperties form. 2. An Application Object Instance record is created with the CM or IM registry instance ID, and SR instance ID with CREATE command and flag ADHOC.
150
ADHOC means create the Application Object Instance and the back-end request. 3. The Application Object Instance has filters that execute upon the CREATE command to create the back-end change request or incident. Connection information and interface form names are looked up in the CAI:AppRegistry form and copied to the Application Object Instance record. 4. The Event SRM_OUT_CREATE_APP_REQUEST event is created in the CAI:Event form and relevant values from SR fields and command parameters are created in the CAI:EventParams form. 5. A filter is executed on the Event form, which triggers the CAI plug-in to send the event to the back-end application. 6. The CAI plug-in sets the return code and message on the Event record. • If the return code is updated to OK, a filter is executed on the Event form, which triggers a status change on the Application Object Instance sender to Created. The Request status is set to Staged. If the application request requires activation (New Request Activate = Yes), the SRM_OUT_ACTIVATE_APP_REQUEST event command is created in the CAI:Event form. • If the return code is updated to Error, a filter is executed on the Event form that triggers action field on Application Object Instance to EVENT_ERROR. This triggers the Modify filter on the Application Object Instance form to set the SR App Event status field to ERROR. Notification is sent to users in the Request Master group when an error occurs. The Application Object instance queries secondary forms to build the event commands. These forms include the CAI:Command, CAI:CommandParamsMapping, and SRM:QUTJoinSRGJoin forms.
151
The following diagram shows the instantiation process: Request instantiation diagram SRM:AppInstanceFlow (NOT USED in RQC) Service Request Instance ID SRM:AppInstanceBridge Predecessor Instance ID Successor Instance ID (AOI)
1. Tells Start Flow to start work.
SRM:Request
7. Sets return code = Return msg = warning or error msg
Service Request Instance ID SCO Instance ID 2. Create successor AOI
SRM:AppInstanceBridge
3. Create event and event param entries.
Service Request Instance ID AOI Instance ID Application Registry Instance ID Flow information Question-response linked to service request. SRM:Service RequestQuestionAssociation (NOT USED in RQC) AOI Instance ID Question Response Instance ID
When SR status = New; status reason = AI Creation, Create the event and event params.
CAI:Event
Field-value pairs come from question-response pair.
Service Request Instance ID Question Instance ID Question Answer
CAI Plugin
5. CreateEntry to application interface Field-value pair linked to event
SRM:QuestionResponse (NOT USED in RQC)
4. FilterAPI invoked
Event Instance ID Event Type=CreateAppRequest AOI GUID= SRMS Server= App GUID= App Server= App Interface form = Source=SRMS Return code = empty Return msg = empty
CAI:EventParams Event Instance ID Param Name= Param Value= Type= Data Type=
App interface entry field values come from event params Application Interface (ChangeInterface_Create)
6. Submit to application instance (if app interface != app instance form)
CAI:AppRegistry Registry Instance ID= Registry Name= Description= App Template Form= App Template View Form= App Instance Form= App Interaction Form= Access Mode= Server= Login/password=
Application Instance (CHG:Infrastructure Change)
Status Synchronization The request object uses event commands to synchronize the status with the application requests. The back-end application must send status-related events to the SRMS framework by creating entries in the CAI:Events form. Workflow is implemented in the sample application to illustrate this mechanism. Interfaces
Create request interface The SRM:RequestInterface_Create form is a regular form that is an interface form for the SRM:Request form. It supports external systems in creating new requests programmatically or by AR System workflow. For example, requests can be created automatically when a change or incident request is created from the backend application using the SRM:RequestInterface_Create form. A function is available using Change Management and Incident Management that allows the back-end support user to generate a request object that is linked to the current change request or incident. This allows the requester to access their requests from
152
the Requester Console, although the request was submitted from Change Management or Incident Management support personnel. This is useful for requests from users who do not have access to Change Management or Incident Management. CAI plug-in The CAI plug-in is used to transmit SRMS framework events to back-end applications. A plug-in is used due to the dynamic nature of the field mappings for each command and the potential for incompatible permission models. For example, the command to create a back-end request consists of dynamic field values that can be mapped to any field on the back-end interface forms, where it is not possible to use workflow to push values to dynamic fields. Additionally, if the back-end application is on a remote server from the front-end application, such as the SRMS framework, a different AR System login is required for the plug-in to log in to the remote server. This login information must be specified in the per event record. Outbound commands (such as CreateAppRequest) Service Request SR GUID Status Cost
Event
AOI SR GUID AOI GUID App Registry AOI Status App Instance GUID App Instance ID App Instance Description App Instance Status App Instance Cost
2. Create outbound create entry 8. Notify AOI that command is done 9. Update event status=Complete
3. Create the event parameters using the fields setup from command configuration and by using responses to the questions to map the values into the application interface/instance fields.
Event GUID Event Command Event Status Protocol (AR) SRMS Server AOI GUID Reg App Server Reg App Interface (Form) App Instance GUID Return Code Return Message (Error)
Event Parameter Event GUID Event Parameter GUID Parameter Name Parameter Value
4. Call Filter API 7. Return code, Return message
Filter API In: Reg App Server, Event Form, Event Param Form, Event GUID Rtn: Return Code, Return Message
5. AR API Call
App Interface … Template ID SRMS Server SR ID AOI GUID ... 6. Create/update/query entry in app instance App Instance ... SRMS Server SR ID AOI GUID ...
153
Permission model
The SRM:Request form has the following permissions: •
Public—Hidden
•
Request Master—Visible
SRM:Request contains levels of permissions: •
Request Master
•
Assignee Group
•
Unrestricted Access
•
General Access
•
Submitter
The following tables lists the permission roles and groups for the SRMS framework and the Requester Console. Requester Console application permissions AR System group or role
Map to group
Comments
Summary Definition Config
Summary Definition Config Computed
Provides create, view, and modify access to Requester Console:SummaryDefinition. Note: General Access is needed for modify access.
N/A
Summary Definition
Base group for Summary Definition Config Computed.
Requester Console Config**
Requester Console Config
This group is part of the Request Config Computed group. Provides create, view, and modify access to: • SRM:CFG Rules • SRM:Application Settings • SRM:ConfigSurveyOptions • Requester Console:SummaryDefinitions Menu access to the Administrator Console for the Requester Console.
Note: General Access is needed for modify access.
154
AR System group or role
Map to group
Comments
Requester Console Master**
Requester Console Master
This group is part of the Request Master Computed group. Provides access to: • View the SRM:Request form for troubleshooting. • CAI Event Dialog and retry events. • Create and view the work log from the Service Request form. • Request Configuration
General Access
General Access**
Provides access to all general users who require modify permission.
Unrestricted Access
Unrestricted Access**
Bypasses row-level access for multi-tenancy. See Assignee group.
Submitter*
N/A
Provides: • Row-level view access to SRM:Request records submitted by that user from the Requester Console. • Create and view access to the work log from the Service Request form.
Assignee Group*
N/A
Provides row-level access based on the Company field. Applies to summary definitions and broadcast messages.
Public*
N/A
Provides access to the Requester Console and all the related display forms.
Note: AR System Guest public users have access to global summary definitions and broadcast messages.
155
SRMS framework application permissions AR System group or role
Map to group
Comments
Request Config**
Request Config Computed
Provides create, view, and modify access to: • SRM:CFG Rules • SRM:Application Settings • SRM:ConfigSurveyOptions • Requester Console:SummaryDefinitions Menu access to Application Administration Console for Requester Console.
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.
Request Master**
Request Master Computed
Provides access to: • View the SRM:Request form for troubleshooting. • The CAI Event Dialog and retry events. • Create and view the work log from the Service Request form. • Request configuration.
N/A
Request Master
Base group for Request Master Computed. Also part of the Command Event Master Computed group.
General Access
General Access
Provides access to all general users who require modify permission.
Unrestricted Access
Unrestricted Access
Bypasses row-level access for multi-tenancy. See Assignee Group.
Submitter*
N/A
Provides row-level access to SRM:Request records submitted by that user ($USER$).
Assignee Group*
N/A
Provides row-level access based on the Company field. Applies to SRM:Request records.
Public*
N/A
Provides general access. Access granted to this group is granted to all users.
*Public, Submitter and Assignee Group are implied AR System groups; no Group or Role entries are required. **General Access and Unrestricted Access are foundation AR System groups. These groups are shipped with the Foundation application.
156
SRMS framework computed groups The SRMS framework uses computed groups for Request Config and Request Master permissions so users can be granted Requester Console permissions instead of using SRMS permissions directly. Computed group
Comments
Request Config Computed
Computed group for Request Config Equals Request Config or Requester Console Config
Request Master Computed
Computed group for Request Master Equals Request Master or Requester Console Master
Requester Console computed groups The Requester Console has one computed group for summary definition configuration. This is set up to allow granting of summary definition permission to Change Config or Incident Config permission indirectly. Computed group
Comments
Summary Definition Config Computed
Computed group for Summary Definition Config. Equals Summary Definition Config or Request Config or Change Config or Incident Config.
Task Management System The primary goal of the Task Management System (TMS) subsystem is to provide a mechanism to support repeatable processes. The result is improved productivity, reduction in novice errors, and a clear way to define business processes. The Task Management System introduced in ITSM 7.0 significantly enhances the capability of the task operation of previous releases. In addition to the predecessor and successor relationship, TMS supports branching and multiple paths, along with data exchange between tasks. TMS also supports integration with external systems, primarily using the Command Automation Interface (CAI) subsystem. The following sections present the architectural structure of TMS. See the BMC Remedy Task Management System 7.0 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.
Task templates
Task templates define the purpose of tasks.
Flow templates
“Flows” determine the sequence and dependencies between the associated task templates. Execution/Runtime
Execution consists of the Container Object task group, associations, and flows that establish the relationships and hierarchy between corresponding tasks. The process to transform a task group template (the definition phase) to a task group (the execution phase) is called instantiation. Therefore, the corresponding entities for the templates defined during runtime are task groups, tasks, flows, and associations. The Variable pool is a structure that facilitates information passing between tasks and flows. The following diagram provides a high-level view that illustrates typical relationships among the TMS components previously defined.
158
Flows Associations
Container Object
Container Object
Data Flows
Task Group Container [0]
Task Group Template [0]
OR Application Object Instance
Application Object Template
Task [A]
Task Template [A]
Application Object Template
AND Application Object Instance
Application Object Template
Task Template [B]
Task [C]
Task [B]
Task Template [C]
Application Object Instance
Application Object Template
Task [D]
Task Template [D]
Variable Pool
Application Object Instance
Name
Value
Scope
Location Contact Phone Closed Tasks
Sunnyvale
Local
TBD 2
Local System
Feature Set • Related Items • Automated Tasks • Launch • Pass data betweenAOI’s • 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
TaskTemplate 1
F1
Task Template 2a
Task Group 1
F2
Task 1
F1
Task Template 2b
F4
F3
Task Template 3a
TaskTemplate 3b
Task 2a
Task 2b
F4
F3
Task 3a
Task 3b
F6
F5
F6
F5 Task Template 4
All templates in this task group template are configured to be executed in the order of flow F1 to F6.
F2
Task 4
All tasks and task group and flow created in advance with Status = “Staged” and State = “Inactive” Parent Object starts the task process by activating the initial task or task group.
The process remains inactive (Status = “Staged” AND State = “Inactive”), and no work can be performed on these tasks except adding or changing the task attributes such as the description, name, classification, and so on. The parent object starts the process by activating the initial tasks or task groups. The order of execution between tasks and task groups is enforced by the defined flow. The successor tasks or task groups are activated (State = “Active”) when the predecessor tasks and task group are completed.
160
Execution Task Group 1
Task 1
F1
F2
Task 2a
Task 2b
F4
F3
Task 3a
Task 3b
F6
F5
Task 4
The first task or task group is activated and ready for agent to work on while others are locked until the predecessors are completed.
The defined flow between tasks and task group drives the process of activating or marking “bypass” of the next or “successor,” tasks or tasks groups. Bypass is a status that indicates a task did not execute because the flow is defined so the task or task group were not required, and therefore not executed.
161
Execution Task Group 1
Task 1 Closed/Success
F1
F2
Task 2a Closed/Success
Task 2b Closed/Failure
F4
F3
Task 3a Closed/Success
Task 3b Bypaased
F6
F5 Task 4 Closed/Success
Task 1 completed successfully. Task 2a, and 2b are activated. 2a success, but 2b failed. Task 3a, activated then closed/success, then task 4 activated. Task 3b is marked bypassed, because Task 2b failed.
Association model The Association model defines relationships between major entities. Associations in TMS are ordered in a parent-child relationship. The associations are stored in two tables: Association Template (definition), and Association (runtime). The [n-n] reference indicates a many-to-many relationship. The [1 – n] reference indicates a one to many relationship. The following associations are stored in the Associate Template table: •
[n-n] Application Parent template to Task Group template. An Application Parent template (for example, a change request template) can be associated to multiple Task Group templates. An example is a change request template having a planned task group template, an execute task group template, and a verification task group template.
162
•
[n-n] Task Group template to Task Group template. In this case, the first one is the parent and the second one is the child.
•
[n-n] Task Group template to Task template.
The following associations are stored in Associate table: •
[1-n] Application Parent instance to Task Group. Note: An example of an Application Parent Instance is a change request.
•
[n-n] Task Group to Task Group. In this case, the first one is the parent and the second one is the child. Note: This is an n-n relationship because a Task Group can be the parent of one or more Task Groups and also a child of one or more Task Groups.
•
[1-n] Task Group to Task.
On foreign keys: •
The Task Group has a foreign key to the Parent Application instance.
•
The Task has a foreign key to the Parent Application instance.
An association entry for these relationships on the Association table and foreign keys are needed because foreign keys are used for a quick lookup and to support direction, while the association entries are used to facilitate navigation.
163
AT1
AT3 AT2
164
ASSOC1
ASSOC3 ASSOC2
Dependency model: flow mechanism The flow mechanism defines the sequence and dependency between task templates within a task group template, and between tasks within a task group. Flow is a configuration process to determine how a task or task group is carried out at runtime. For example, tasks and tasks groups can be carried out sequentially or simultaneously. Flow is defined based on the association between a task and task group. Flow cannot be established if there is no association. In other words, association is “what” other instances are related to current instance, and flow is “how” these instances are executed. A flow consists of one or more flow relationship records. Each flow relationship record is capped by an inbound and outbound task object. The task object is either a task template (definition), task (runtime), task group template (definition), or a task group (runtime). The inbound task object to a flow relationship record is called the predecessor. The outbound task object to a flow relationship record is called the successor. When you define a task group template, you can establish how the associated task group template and task templates relate to one another. This is called flow, and determines the sequence in which task groups and tasks are generated at runtime. A task or task group can be executed simultaneously or sequentially. When the flow is defined as sequence, all predecessors must be completed before the successor task or task group can start. The flow is also determined by the outcome of the predecessor. The resulting output can be stored in the variables. The values in these variables can then be used by workflow to decide the behavior of the flow. For more information, see the following “Data exchange model: variable pool” section. For example, in the following illustration the flow, represented by the diamond, indicates that if Task 1 is flagged as successful, then Task 2 is activated. Otherwise, Task 3 is activated. Task 1
Success
Fail
Task 2 Task 3
165
Task Group
Task 1
Task Group
Task 2
Task 1
Task 2
Task 3
Example 1
Task 3
Example 2
The flow in Example 1 indicates that Task 1 and Task 2 could be started simultaneously, and Task 3 will be started only when both Task 1 and Task 2 complete. The flow in Example 2 shows all three tasks are in sequence. Task 1 needs to complete before Task 2 can start. Task 3 will start only when Task 2 completes. The execution order between task and task group is known as flow, which dictates how the task or task group are executed at runtime. The flow configuration is evaluated along with other advance settings, such as conditions, actions, and behavior, when the task is completed (State = closed, success, failed, or canceled). These advanced settings are an integral part of TMS and can be complex to configure if you need to apply a more simple model to transition between tasks. For example, in the previous versions of the ITSM applications, the primary model for transitioning between tasks was simply specifying an order in which the tasks would execute. ITSM 7.0 has a model called “Sequencing” that focuses on setting the order in which tasks are executed. This is only an abstraction of the advanced settings. The flow objects are used but the sequencing model establishes a strict definition of how the flow objects should be configured. To clearly distinguish these two approaches of defining how tasks and task groups flow, Sequencing (Basic) and Standard (Advanced) modes are used. The Advanced mode exposes all the flow configuration options, whereas the Basic mode is defined as sequencing.
166
Sequencing (Basic) mode In the Sequencing mode, users do not have to define the flow between tasks or task groups. Instead a sequence number is used to specify the order in which tasks or tasks groups are executed. Using the sequence number allows users to define the ordering between tasks quickly, without going deeply into TMS to create the flow for tasks. For example, change request users can add three tasks from the list in a task template, and then specify the order in which they execute as 1, 2, and 3. This is equivalent to configuring a successor and predecessor model as StartÆTask1ÆTask2ÆTask3. Task1 will execute first, followed by Task2, and finishing with Task3. The sequence for each task or task group entered by users is converted to a flow definition in TMS. In the previous example, when three tasks are ordered as 1, 2, 3, three flows are created automatically as follows: Flow#1 : Start Æ Task1 Flow#2: Task1 Æ Task2 Flow#3. Task2 Æ Task 3 In the order that the tasks and task groups are executed, there is no functional difference between this flow definition and the sequence model implemented in previous versions of ITSM. To apply a strict sequencing model, certain configuration settings are fixed. The Sequencing (Basic) mode has the following fixed settings on the flow object that cannot be changed: •
Evaluate if Predecessor Failure? “No”
•
Evaluate if Predecessor Canceled? “Yes”
•
Flow to Successor when “All Complete”
With these settings, all tasks and task groups in the same sequence must be completed before the tasks or task groups in the next level in the sequence can begin. For example, in the following illustration, task 4, 5, and 6 (at sequence level 2) are activated only if Task 1 and Task 2 (at sequence level 1) are completed. Sequence 1
Task 1, Task 2
Sequence 2
Task 4, Task 5, Task 6
Sequence 3
Task 7, Task 8, Task 9
167
Default sequence
When the task or task group is added, the default sequence is the next available sequence level. For example, in the illustration that follows, if a Task 10 is added to the list of existing tasks, then it would be set at sequence level 4. Sequence 1
Task 1, Task 2
Sequence 2
Task 4, Task 5, Task 6
Sequence 3
Task 7, Task 8, Task 9
Sequence 4
Task 10
Changing the sequence
After a task is added, you can change the ordering using the sequence number. Increasing the sequence number moves the task down the list. Decreasing the sequence number moves the task up the list. During runtime, the following rules make sure of the integrity of the process flow: •
The sequence cannot move to a prior sequence level that is completed.
•
The sequence level cannot be changed on an active or completed task.
You can change the sequence number using the up and down buttons, or by setting the sequence number directly in the corresponding column on the table field. Note: Passing data values between Tasks or Task Groups is not supported while in the Sequencing (Basic) mode. The system does not stop users from setting the variable for a task or task group while in this mode. There is, however, no assurance that this will work because the sequence can be changed, and the logic for passing the data and variables between them might no longer be valid. During definition phase, sequence and dependency information is stored in the Flow template. During the execution phase, the association information is stored in a separate Flow table.
168
Data exchange model: variable pool The variable pool is a way for tasks to exchange data. This allows tasks to return information and have the information passed to other tasks. Unlimited named variables can be defined in a central repository of variables (or variable pool). The named variables can be attached to a task group template, task template, flow template, task group, or a task and flow. These attached entities can access the variable values and assign values to the variables. Data exchange occurs when the
169
same variable is shared among these entities, such as a task group template, task template, flow template, and so on. In the configuration phase for variables, an administrator defines the variable that will be used by the system. The variable definition consists of the variable name and scope. Variable scope
Definition
Local
The variable is available to the parent application instance.
Global
The variable is available across different parent application instances.
System
The variable is available to the parent application instance, but is managed and maintained by the system.
When the variable is defined, it can be mapped to the task group template, task template, and the flow template. When the variable is instantiated, it will contain the data value, in addition to the name and scope definition. These variables can be mapped to the task group, task, and flow. These variable definitions are stored in the Variable Template form. The instantiated variable is stored in the Variable form. Both defined and instantiated mappings for variables are stored in the Variable Mapping form. A variable mapping has a direction characteristic of inbound or outbound. When the instantiated variable is mapped to a task, the task reads an inbound variable when work is about to begin for a task. When a task is finished, it writes the value of the mapped outbound variable to the variable pool.
170
171
Complete example During instantiation of a task group template, the task group and associated tasks are created, based on the task group template definition. The flows and variables for the tasks are also created.
172
ERD Following is the entity relationship diagram for TMS.
173
Interfaces In TMS, the TMS:TaskInterface interface form supports performing updates and queries of a task by external systems. This form is a self-join of the main task form (TMS:Task).
Web services Associated data of the main Task form is exposed using web services. In addition to the TMS:TaskInterface Task interface form, the TMS:WorkInfo and TMS:Relationships regular forms are also exposed using the web services interface. The interface structure consists of three components: the parent object and two child objects. The parent object is represented by the TMS:TaskInterface form. The associated child objects are Work Info and Related Items. In web services, these three objects are rendered and presented as a single entity using the “complex” mapping definition based on an XSD file. This single web services entity supports the following primary interface operations: Objects
Operation
Scope
Function name
Task
Update
Individual
UpdateTaskOnly
Query
Individual
QueryTaskOnly
Update Related
Individual Work Info
UpdateTaskAndWorkInfo
Update Related
Multiple Work Info
UpdateTaskAndWorkinfo
Create Related
Individual Work Info
UpdateTaskAndWorkinfo
Query Related
Multiple Work Info
QueryTaskPlusWorkInfo
Task and Relationships
Query Related
Multiple Relationships
QueryTaskPlusRelationships
Task, Relationships, and Work Info
Query Related
Multiple Relationships and Work Info
QueryTaskPlusRelationshipsAndWorkInfo
Task and Work Info
174
Permission model TMS has four levels of accessibility: •
Task Administrator (level 1)—Controls template definition, with access to all tasks and task groups.
•
Task Manager (level 2)—Can perform task implementer functions and also instantiate task group templates and task templates from the parent object. Can also create and update all tasks that are associated with the parent object.
•
Task Implementer (level 3)—Can update and work on tasks that are assigned to him or her.
•
Task Viewer (level 4)—Can view tasks in read-only mode.
175
Backmatter.fm Page 17 Sunday, October 15, 2006 11:47 AM
Backmatter.fm Page 18 Sunday, October 15, 2006 11:47 AM
*65743* *65743* *65743* *65743* *65743*
