Integration Guide For IBM Tivoli Service Request Manager V7.1 3.1 Sg247580

User Manual: 3.1

Open the PDF directly: View PDF PDF.
Page Count: 292 [warning: Documents this large are best viewed by clicking the View PDF Link!]

ibm.com/redbooks
Integration Guide for
IBM Tivoli Service
Request Manager V7.1
Vasfi Gucer
Welson Tadeau Barbosa
Maamar Ferkoun
Kannan Kidambhi
Marc Lambert
Reynaldo Mincov
Richard Noppert
Uday Pradeep
Insider’s guide for Tivoli Service
Request Manager integrations
Covers integration best
practices and architecture
Includes demonstration
scenarios
Front cover
Integration Guide for IBM Tivoli Service Request
Manager V7.1
September 2008
International Technical Support Organization
SG24-7580-00
© Copyright International Business Machines Corporation 2008. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
First Edition (September 2008)
This edition applies to IBM Tivoli Service Request Manager Version 7, Release 1, Modification 0.
Note: Before using this information and the product it supports, read the information in
“Notices” on page xv.
© Copyright IBM Corp. 2008. All rights reserved. iii
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Chapter 1. Integration benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Integration requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Process Management and Operation Management products integration . . 2
1.3 Benefits of integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Integration scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Integration with event management solutions. . . . . . . . . . . . . . . . . . . 8
1.4.2 Integration with other service desk solutions . . . . . . . . . . . . . . . . . . . 9
1.4.3 Integration with other solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2. Integration components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 IBM Tivoli Directory Integrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1 TDI architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 AssemblyLines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.4 Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.5 EventHandlers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 TDI component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Supported platform and compatibility matrix . . . . . . . . . . . . . . . . . . . 28
2.2.2 Hardware and software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Planning to deploy TDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Installation scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 Installation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Integration Framework or MEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.1 Integration Framework overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
iv Integration Guide for IBM Tivoli Service Request Manager V7.1
2.4.3 Integration Framework components . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.4 Integration enhancements and changes from V6.x to V7.1 . . . . . . . 86
2.4.5 Sample scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Chapter 3. Event management integration . . . . . . . . . . . . . . . . . . . . . . . . 105
3.1 Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.2 IBM TEC integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.2.3 Predefined scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.2.4 Steps for implementing TEC integration . . . . . . . . . . . . . . . . . . . . . 114
3.2.5 Installing the non-TME logfile adapter. . . . . . . . . . . . . . . . . . . . . . . 114
3.2.6 Installing TDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.2.7 Editing the mxe.properties file (optional). . . . . . . . . . . . . . . . . . . . . 116
3.2.8 Installing the SRM rulebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.2.9 Starting the TDI server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.2.10 Ticket synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.3 IBM Tivoli Netcool/Omnibus integration (preview) . . . . . . . . . . . . . . . . . 130
3.3.1 Event workflow (outbound) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.3.2 Event workflow (inbound) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Chapter 4. Service Desk Tool integration . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.1 Introduction to integration landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.2 Integration scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.3 Service Desk integration planning and installation . . . . . . . . . . . . . . . . . 139
4.3.1 Installation instructions for the HP ServiceCenter connector . . . . . 141
4.3.2 HP Service Desk configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.3.3 TDI properties configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.4 Scenario window flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Chapter 5. IBM Tivoli Identity Manager integration . . . . . . . . . . . . . . . . . 167
5.1 TIM introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.2 Installation and configuration procedure . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.2.1 Software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.2.2 Installation and configuration procedure for integration . . . . . . . . . 171
Chapter 6. CCMDB integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.1 CCMDB overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.1.1 Tivoli SRM and CCMDB integration . . . . . . . . . . . . . . . . . . . . . . . . 189
6.2 Change Management integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.2.1 Installing CCMDB on top of SRM scenario . . . . . . . . . . . . . . . . . . . 190
Contents v
6.3 Working with SRM and CCMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Chapter 7. Lotus Sametime integration . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.1 Sametime overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.2 Sametime in the context of Tivoli SRM . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3 Sametime installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3.2 SRM configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.3.3 Sametime server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.3.4 Sametime instant messaging with Tivoli SRM . . . . . . . . . . . . . . . . 209
7.4 Service desk scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Chapter 8. Computer Telephony integration. . . . . . . . . . . . . . . . . . . . . . . 217
8.1 CTI functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
8.2 CTI installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
8.3 CTI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
8.3.1 Custom lookup configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.4 Using your CTI implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.4.1 Changing the URL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.4.2 CTI buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
8.4.3 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
8.5 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.5.1 Log files and debug information . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.5.2 CTI Java applet did not load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.5.3 CTI Java applet failed to load successfully . . . . . . . . . . . . . . . . . . . 242
Chapter 9. High availability best practices . . . . . . . . . . . . . . . . . . . . . . . . 245
9.1 Accuracy and availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
9.2 Event Management integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
9.2.1 TEC considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
9.2.2 TDI considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
9.2.3 Multiple service desks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
vi Integration Guide for IBM Tivoli Service Request Manager V7.1
© Copyright IBM Corp. 2008. All rights reserved. vii
Figures
1-1 Logical component overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1-2 Event management integration data flow . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1-3 Password reset integration solution flow. . . . . . . . . . . . . . . . . . . . . . . . . . 12
1-4 CTI process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2-1 Integration possibilities using TDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2-2 AssemblyLines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2-3 Connector puzzle pieces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2-4 Add Connectors to the AssemblyLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2-5 AssemblyLine puzzle pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2-6 TDI components: the node, the interpreter, and the connector . . . . . . . . 28
2-7 Compatibility matrix: Architecture and operating systems supported . . . . 29
2-8 IBM TDI 6.1.1 menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2-9 TDI user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2-10 Integration Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2-11 Integration Framework overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2-12 Integration Framework for data exchange . . . . . . . . . . . . . . . . . . . . . . . 41
2-13 Integration Framework for OMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2-14 Integration Framework for UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2-15 Object structure service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2-16 Object Structures interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2-17 Publish channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2-18 Publish channel interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2-19 Invocation channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2-20 Invocation channel interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2-21 Asynchronous Enterprise Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2-22 Synchronous Enterprise Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2-23 Enterprise Services interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2-24 Web services library interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2-25 Endpoints interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2-26 External systems interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2-27 LMO interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2-28 Integration modules interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2-29 Launch in Context interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2-30 Message Tracking interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2-31 Message Reprocessing interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2-32 Invocation Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2-33 Object Structure Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2-34 Enterprise Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
viii Integration Guide for IBM Tivoli Service Request Manager V7.1
2-35 Standard Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2-36 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2-37 Web Services Library application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2-38 Web Services Library architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2-39 Enabling JMS queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2-40 Object Structure application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2-41 Creating a new Enterprise Services record. . . . . . . . . . . . . . . . . . . . . . . 96
2-42 Creating a Web service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2-43 Selecting the enterprise service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2-44 Web Service deployed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2-45 Wsdl definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3-1 The components that take part in the integration . . . . . . . . . . . . . . . . . . 109
3-2 Communication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3-3 TDI architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3-4 Automated logfile adapter configuration window. . . . . . . . . . . . . . . . . . . 116
3-5 New rule set created and activate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3-6 Configuration required to establish the communication (1 of 2) . . . . . . . 125
3-7 Configuration required to establish the communication (2 of 2) . . . . . . . 126
3-8 Event with severity “Fatal”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3-9 Run AssemblyLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3-10 The incident is generated within Tivoli SRM . . . . . . . . . . . . . . . . . . . . . 130
3-11 Outbound event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3-12 Inbound event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3-13 Netcool/Omnibus event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3-14 Incident created by automation in Tivoli SRM. . . . . . . . . . . . . . . . . . . . 133
4-1 Integration types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4-2 Tivoli SRM V7.1 and HP ServiceCenter integration environment . . . . . . 140
4-3 AssemblyLine configuration: Querying HP ServiceCenter database . . . 142
4-4 AssemblyLine configuration: Disabling the SRM ticket generation . . . . . 143
4-5 Opening of the integration scenarios, known as an AssemblyLine. . . . . 157
4-6 Running AssemblyLine manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
4-7 Opening the incident application within SRM . . . . . . . . . . . . . . . . . . . . . 160
4-8 Opening the incident created from HP ServiceCenter . . . . . . . . . . . . . . 161
5-1 Start center window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5-2 System properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5-3 Enterprise Applications window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5-4 Map modules to servers window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5-5 Classpath entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5-6 ChangePassword Workflow Extension modified to create Maximo tickets. .
184
6-1 CCMDB Welcome window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6-2 Language selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6-3 Upgrade window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figures ix
6-4 TADDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6-5 Run Configuration Step window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6-6 Summary window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6-7 Pre-Installation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6-8 Problem window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6-9 Open change option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6-10 Change ticket number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6-11 Related Tickets panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
7-1 Installing Sametime integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
7-2 Installing Sametime integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7-3 Installing Sametime integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7-4 Properties configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7-5 System Properties (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7-6 System Properties (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7-7 System Properties (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7-8 Sametime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
7-9 Incident raised. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
7-10 Open IM connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
7-11 Enter the password for the IM application. . . . . . . . . . . . . . . . . . . . . . . 212
7-12 IM connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
7-13 Away status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
7-14 Chat window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
7-15 Sametime session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
7-16 Close connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
7-17 Connection closed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
8-1 Deployment engine system check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
8-2 Package validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
8-3 Package validation results when already installed . . . . . . . . . . . . . . . . . 222
8-4 Package validation results when not installed yet. . . . . . . . . . . . . . . . . . 223
8-5 License agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
8-6 Required credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
8-7 Maximo Database credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
8-8 WebSphere credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
8-9 Validating middleware credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8-10 Package options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
8-11 Pre-Install Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
8-12 Deployment progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
8-13 System Properties configuration example. . . . . . . . . . . . . . . . . . . . . . . 233
8-14 Start Center with CTI solution active. . . . . . . . . . . . . . . . . . . . . . . . . . . 235
8-15 CTI status before login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
8-16 CTI status after login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8-17 CTI login credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8-18 CTI set user status to ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
x Integration Guide for IBM Tivoli Service Request Manager V7.1
8-19 CTI status set to ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8-20 Incoming call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8-21 Incoming call accepted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8-22 New Service Request (SR) using CTI. . . . . . . . . . . . . . . . . . . . . . . . . . 238
8-23 Mute call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8-24 Muted call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8-25 Resume call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8-26 End call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8-27 Perform after-call work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8-28 Performing after-call work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8-29 Stop performing after-call work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8-30 CTI set user status to ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8-31 CTI status set to ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8-32 CTI logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8-33 CTI logout options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8-34 Java Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
9-1 TEC integrated with Tivoli SRM for high availability . . . . . . . . . . . . . . . . 247
9-2 TDI high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
© Copyright IBM Corp. 2008. All rights reserved. xi
Tables
1-1 Client value/benefits: ISM V7.1 Service Desk integration . . . . . . . . . . . . 10
2-1 Integration Framework for data exchange components . . . . . . . . . . . . . . 40
2-2 Integration Framework for OMP components . . . . . . . . . . . . . . . . . . . . . . 42
2-3 Predefined endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2-4 EJB handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2-5 FLATFILE handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2-6 HTTP handler properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2-7 IFACETABLE handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2-8 JMS handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2-9 WEBSERVICE handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2-10 XMLFILE handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2-11 CMDLINE handler properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2-12 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2-13 Return value tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2-14 Predefined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2-15 Assigned attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2-16 Dynamic attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2-17 Inbound message status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2-18 Outbound message status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2-19 Message statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3-1 Action performed for a particular event status . . . . . . . . . . . . . . . . . . . . 112
3-2 Action resolving the service request or the incident record. . . . . . . . . . . 113
3-3 Action closing the event record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4-1 Supported versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4-2 Adding the API database attributes to fields . . . . . . . . . . . . . . . . . . . . . . 146
4-3 Adding the API database attribute fields . . . . . . . . . . . . . . . . . . . . . . . . . 146
4-4 Adding the API database attributes to fields . . . . . . . . . . . . . . . . . . . . . . 147
4-5 Adding the API database attributes to fields . . . . . . . . . . . . . . . . . . . . . . 147
4-6 Adding the API database attributes to fields . . . . . . . . . . . . . . . . . . . . . . 147
4-7 Adding the API database attributes to fields . . . . . . . . . . . . . . . . . . . . . . 148
4-8 MXE properties store in TDI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5-1 Installation and configuration procedure for integration . . . . . . . . . . . . . 171
5-2 Steps to perform on Tivoli SRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5-3 Configuring TIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8-1 System Properties changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
xii Integration Guide for IBM Tivoli Service Request Manager V7.1
© Copyright IBM Corp. 2008. All rights reserved. xiii
Examples
2-1 Windows example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2-2 UNIX example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2-3 Example of an error xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2-4 Request xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
2-5 Response xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3-1 TECInReadQueue assembly line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3-2 Files required to add the ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3-3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3-4 Output of the Run command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4-1 Jar files required for the HP ServiceCenter connector . . . . . . . . . . . . . . 141
4-2 mxe.properties file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4-3 mxetdi.cmd file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4-4 Link added within the HP ServiceCenter record . . . . . . . . . . . . . . . . . . . 150
4-5 PeregrineIncident in AssemblyLine output . . . . . . . . . . . . . . . . . . . . . . . 158
4-6 Peregrine IncidentOUT AssemblyLine output . . . . . . . . . . . . . . . . . . . . . 162
5-1 Maximo Workflow Extension Properties . . . . . . . . . . . . . . . . . . . . . . . . . 183
5-2 Scriptframework.properties: Add a line . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5-3 Text to be added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8-1 Custom lookup example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
9-1 SYSTEM STORE section one. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
9-2 SYSTEM STORE section two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
9-3 Solution.properties file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
xiv Integration Guide for IBM Tivoli Service Request Manager V7.1
© Copyright IBM Corp. 2008. All rights reserved. xv
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
xvi Integration Guide for IBM Tivoli Service Request Manager V7.1
Trademarks
BM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are
marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols
indicate U.S. registered or common law trademarks owned by IBM at the time this information was
published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at “Copyright and trademark information” at:
http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX®
Cloudscape®
DB2®
Domino®
Enterprise Asset Management®
HACMP™
IBM®
Lotus Notes®
Lotus®
Maximo®
MQSeries®
Netcool/OMNIbus™
Netcool®
Notes®
Redbooks®
Redbooks (logo) ®
Sametime®
Tivoli Enterprise Console®
Tivoli®
TME®
WebSphere®
The following terms are trademarks of other companies:
Rad, and Portable Document Format (PDF) are either registered trademarks or trademarks of Adobe
Systems Incorporated in the United States, other countries, or both.
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation
and/or its affiliates.
SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other
countries.
EJB, Enterprise JavaBeans, J2EE, Java, JavaBeans, JavaScript, JDBC, JVM, Solaris, Sun, Sun Java, and
all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries,
or both.
Internet Explorer, Microsoft, SQL Server, Windows, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
© Copyright IBM Corp. 2008. All rights reserved. xvii
Preface
IBM® Tivoli® Service Request Manager V7.1 provides a unified and integrated
approach for handling all aspects of service requests to enable a one-touch IT
service experience, backed up by an optimized delivery and support process. It
is a powerful solution that closely aligns business and IT operations to improve IT
service support and delivery performance.
This IBM Redbooks® publication presents an integration guide for IBM Tivoli
Service Request Manager V7.1. We describe all major integration scenarios,
such as:
򐂰Event management
򐂰IBM Lotus® Sametime® Connect
򐂰Change and Configuration Management Database
򐂰Third-party Service Desk programs, such as HP Service Center
򐂰Computer Telephony Interface
򐂰IBM Tivoli Identity Manager
This book helps you design and create a solution to integrate IBM Tivoli Service
Request Manager V7.1 with other products to provide an Information Technology
Infrastructure Library (ITIL®)-based integrated solution for your client
environments.
The team that wrote this book
This book was produced by a team of specialists from around the world working
at the International Technical Support Organization (ITSO), Austin Center.
Vasfi Gucer is an IBM Certified Consultant IT Specialist at the ITSO Austin
Center. He started working for the ITSO in January 1999 and has been writing
IBM Redbooks publications since. He has more than 15 years of experience in
teaching and implementing systems management, networking hardware, and
distributed platform software. He has worked on various Tivoli client projects as a
Systems Architect and Consultant. Vasfi is also a Certified Tivoli Consultant.
xviii Integration Guide for IBM Tivoli Service Request Manager V7.1
Welson Tadeau Barbosa is a Certified Sr. IT Specialist and IBM IT Specialist
board member, Pre-Sales Specialist in IBM Brazil. He holds a degree in Data
Processing, with post graduation work in Business Administration. He has 12
years of experience in IT of which nine years were in Tivoli. He is responsible for
technical pre-sales in the financial sector in Brazil, which includes banks and
insurance companies. His background is in Tivoli Performance and Availability
products along with ISM family products.
Maamar Ferkoun is a Senior Product Professional with the IBM worldwide
Software Advanced Technology group. He is based in IBM China and Hong
Kong and has over 20 years experience in the IT industry among which over 10
years were with IBM. He holds a degree in computer science, an EXIN ITIL
Manager, and a COBIT certification. Maamar began his career in IBM as a
software field engineer engaged across the Asia Pacific region. His area of
expertise covers the service management product portfolio and best practices.
Kannan Kidambhi is a Computer Application graduate from Madras University
INDIA. He is presently working in IBM Tivoli Software labs, India, as a Tivoli
Consultant. He has over 10 years of experience in Support, Administration,
Consultation, and Implementation in the areas of IT Infrastructure Management
and IT Service Management. Kannan has certifications in the following areas:
ITIL Foundation, Sun™ Certified System Administrator, Cisco Certified Network
Administrator, Microsoft® Certified System Engineer, and IBM Certified Tivoli
Monitoring 6.1 Deployment Professional.
Marc Lambert has been employed with IBM for 13 years. During this time, he
has been working for five years with most of the system management tools within
the Tivoli portfolio. These five years have been followed by being a Senior IT
Specialist to implement different Service Management Tools, such as
HP-Peregrine, BMC Remedy, and Magic. In the last two years, he mostly has
been working as an IT Architect for this particular field of business of Service
Management.
Reynaldo Mincov is an IT Specialist at IBM Brazil, São Paulo. He joined IBM in
1999 where he has been working with IT Service Management tools and ITIL. He
has implemented HP/Peregrine in many client accounts, and he is currently
engaged in several Tivoli Service Request Manager (Maximo®) projects,
including Service Provider.
Richard Noppert is a Solution Architect at MACS BV in the Netherlands. He
holds a degree in Computer Science and has 14 years of experience in IT,
focussing on system design, project implementation, and system management.
He is a Certified Tivoli Consultant with expertise in service management, ITIL
processes, and project management. He is currently engaged in several Tivoli
Service Desk implementation projects in Europe.
Preface xix
Uday Pradeep is a Solutions Consultant - Asset and Service Management with
Birlasoft, Inc., USA. His skills include Tivoli Asset Management IT, Tivoli Service
Request Management Solutions, Tivoli Maximo Enterprise Asset Management®,
and is ITIL Foundation-Certified. He is an engineer in Computer Science and has
expertise in the areas of envisaging solutions around the Tivoli suite of products.
His current focus area is implementing innovative integrations around Tivoli TAM
and SM solutions for multiple clients and establishing best practices benchmarks
for rollouts.
Thanks to the following people for their contributions to this project:
Renee’ Johnson
International Technical Support Organization, Austin Center
Pandian Athirajan, Russ Babbitt, John Christena, Boris Dozortsev, Allen Gilbert,
Praveen Hirsave, Mohammad Kamruzzoha, Eric Lund, Trevor Livingston, Tara
Marshburn, Ramachandran Puthukode, Tom Sarasin, Nisha Singh, Jedd Weise,
Mark Williams, Doug Wood, Lisa Wood
IBM USA
Fabio Silva Carvalho, Leucir Marin Junior
IBM Brazil
Jonathan Lawder, Andrew Stevenson
IBM UK
Become a published author
Join us for a two- to six-week residency program. Help write a book dealing with
specific products or solutions, while getting hands-on experience with
leading-edge technologies. You will have the opportunity to team with IBM
technical professionals, IBM Business Partners, and clients.
Your efforts will help increase product acceptance and client satisfaction. As a
bonus, you will develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
xx Integration Guide for IBM Tivoli Service Request Manager V7.1
Comments welcome
Your comments are important to us.
We want our books to be as helpful as possible. Send us your comments about
this book or other IBM Redbooks publications in one of the following ways:
򐂰Use the online Contact us review IBM Redbooks publication form found at:
ibm.com/redbooks
򐂰Send your comments in an e-mail to:
redbooks@us.ibm.com
򐂰Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
© Copyright IBM Corp. 2008. All rights reserved. 1
Chapter 1. Integration benefits
This chapter discusses the benefits of integration. We provide an overview of
several possible (preconfigured and prepackaged) integrations. We do not cover
all possible integrations. However, we include the best practices for the most
common solutions in a service desk environment.
This chapter discusses the following topics:
򐂰Integration requirements on page 2
򐂰Process Management and Operation Management products integration on
page 2
򐂰Benefits of integration on page 5
򐂰Integration scenarios on page 7
1
2 Integration Guide for IBM Tivoli Service Request Manager V7.1
1.1 Integration requirements
In the world of IT, finding one solution that handles the business requirements of
the whole company is virtually impossible. Integration is necessary for the
following reasons:
򐂰Specific functions of financial processes
򐂰Complex financial processes
򐂰IT processes and their alignment
Earlier versions of Tivoli Service Request Manager (SRM) use the Maximo
Enterprise Adapter (MEA) to connect to third-party solutions. However, these
versions require a lot of manual configurations, and using several IT specialists
is not an easy task.
The Tivoli SRM V7.1 has an integration module, which is called the integration
toolkit. The integration toolkit is part of the content that is being delivered to
support the IBM Service Management (ISM) 7.1. It is an easy way to build a data
level integration with any application hosted in Maximo by taking advantage of
Tivoli Directory Integrator (TDI) capabilities. The toolkit extends standard MEA
architecture by using ISM/Maximo object structures on one end and TDI
connectors on the external end. Clients include Tivoli Enterprise Console®
(TEC), Omnibus, and Tivoli Identity Manager (TIM).
1.2 Process Management and Operation Management
products integration
There are two types of Tivoli SRM integration:
򐂰Process Management products (PMPs)
򐂰Operation Management products (OMPs)
To understand this better, refer to Figure 1-1 on page 3. It outlines a logical
component overview for the Tivoli SRM solution and all related products.
Chapter 1. Integration benefits 3
Figure 1-1 Logical component overview
TPAP
Process Management Products
Operational Management
Products
4 Integration Guide for IBM Tivoli Service Request Manager V7.1
Let us start with the bottom layer, OMP. OMPs automate tasks to address
application or business service operational management challenges. These
products help optimize performance, availability of business-critical applications,
and IT infrastructure support. They also help ensure confidentiality and data
integrity of information assets while protecting and maximizing the utility and
availability of your e-business data.
OMPs can be implemented quickly to address immediate, specific IT challenges.
As you implement a more comprehensive IT Service Management solution,
these products can also integrate into the IT Service Management Platform and
be utilized by IT PMPs.
Examples of OMPs are IBM TEC, IBM TIM, and HP Service Center. The majority
of these integrations use the MEA and Tivoli TDI services. Refer to Chapter 2,
“Integration components” on page 17 for an in-depth discussion of MEA and TDI.
A PMP (or application) is a system for managing process executions. Think of a
process request as a ticket with a written note on it that is forwarded to various
people (or entities) to perform various actions and, in the end, result in the
objective of the process.
PMPs are applications that provide custom predefined implementations of best
practice processes to help clients integrate and automate IT management
processes across organizational silos, improving productivity and efficiency.
Tivoli SRM and Tivoli Change and Configuration Management Database
(CCMDB) are examples of PMPs.
PMPs focus on providing implementations of best practice processes as
workflows with roles, tasks, user interfaces, and integration modules stored in
the process database. In addition, they provide the ability to adapt the predefined
implementation to match the client’s unique process and workflow requirements;
allowing clients to capture and implement their current processes as workflows.
Clients are also able to evolve to Information Technology Infrastructure Library
(ITIL)-defined best practices over time. PMPs also provide the ability to monitor
and report process status and execution; showing business owners process
bottlenecks within an organization, and providing the opportunity to improve and
enhance their processes. The IBM IT PMP bridge organizational silos, automate,
and integrate IT management.
Chapter 1. Integration benefits 5
The TPAP provides the platform to run the applications (incident management,
problem management, change management, and so on). The TPAP is the
foundation layer of the ISM process. TPAP is also known as Base Services,
which you might still find in certain menus after installation. TPAP provides rich
tooling for configuring process flows, user interfaces, and process artifacts for
the PMPs implemented on top of it. TPAP provides the integration platform for all
PMPs. For an in-depth discussion about TPAP, refer to Chapter 2, “IBM Tivoli
SRM architecture” of the IBM Redbooks publication, Implementing IBM Tivoli
Service Request Manager V7.1 Service Desk, SG24-7579.
1.3 Benefits of integration
The advantages of integration with third-party solutions or other external
solutions are:
򐂰Having one primary location where data is stored and maintained, while you
still have the option to exchange and use the data in other solutions.
򐂰Exchanging data using automated integration requires less manual
interaction and reduces costs.
򐂰Exchanging data using automated integration requires less manual
interaction and reduces the number of errors.
򐂰Exchanging data using automated integration takes care of data
synchronization, enforcing data integrity.
When implementing a synchronized solution, the result is an environment where
shared data looks the same for all consuming applications. This is because
changes are propagated throughout the synchronized network of systems,
molded in transit to fit the needs of each consumer. Each data source is kept
up-to-date, maintaining the illusion of a single, common repository. Each
application accesses its data in an optimal manner, utilizing the repository to its
full potential without creating problems for the other applications.
Synchronization strategies are increasingly chosen for deploying new IT
systems. For identity management, this is usually a centralized, or metadirectory
style synchronization, where a high speed store (such as a directory) is used to
publish the enterprise view of its data. This approach has a number of
advantages:
򐂰Security requirements vary from system to system, and they can change over
time. A good repository (such as a directory) provides fine-grained control
over how each piece of data is secured. Certain repositories provide group
management features as well. These tools enable you to sculpt the enterprise
security profile.
6 Integration Guide for IBM Tivoli Service Request Manager V7.1
򐂰Each new IT deployment can be made on an optimal platform instead of
shoe-horned between existing systems into an uninviting infrastructure.
Applications live in individually suited environments bridged by metadirectory
synchronization services.
򐂰If the availability and performance requirements are not met by a system
(past, existing, or new), it can be left in place and synchronize its contents to
a new repository with the required profile, or multiple repositories to scale.
򐂰A metadirectory uncouples the availability of your data from its underlying
data sources. It cuts the cord, making it easier to maintain uptime on
enterprise data.
򐂰Disruption of IT operations and services must be managed and minimized.
Fortunately, the metadirectory network of synchronized systems evolves over
time in managed steps. Branches are added or pruned as required. TDI is
designed for infrastructure gardening.
The introduction of the integration toolkit, TDI included, provides significant
advantages in different areas. It not only makes configuration of an integration
easier and more flexible, but reduces the need for specific code development.
Several advantages of the integration toolkit include:
򐂰Connector communication can be set up from a simple configuration window:
– Drag-n-Drop attribute mapping
– Easily customizable mapping using simple mapping or Java™ Script
򐂰Extends standard MEA architecture:
– Uses ISM/Maximo object structures on one end
– Uses TDI connectors on the external end
򐂰Easy maximo connector configuration
򐂰No need for creating SOAP clients to communicate with Maximo
򐂰Eliminates the need to write communication code
򐂰Many integrations can be built with only a small amount of Java Script
򐂰Integration solutions built with TDI are easily extended to support changes in
data model:
– Most connectors support auto discover of the target data model
– TDI includes an easy to use visual configuration editor for building and
modifying data mappings
򐂰Maximo connector can be used in unlimited assembly line configurations
򐂰Supports reliability features to prevent the loss of incoming ticket data
Chapter 1. Integration benefits 7
򐂰Maximo connector supports multiple Maximo servers
򐂰More than two dozen predefined connectors for handling data I/O
򐂰Logging support in all connectors and Java Script mapping
򐂰TDI connectors exist for many common protocols and data sources,
including:
–Maximo
– Web Service, Java Database Connectivity (JDBC™), Lightweight
Directory Access Protocol (LDAP), Remedy, HTTP, Really Simple
Syndication (RSS), International Development Markup Language (IDML),
and many more
򐂰It is reusable:
– Custom TDI connectors that you build for your product adds to the value of
your product:
• TDI is the standard integration tool for field services
• TDI is the strategic integration tool both for ISM and the data
integration initiative
– Utilized common integration architecture supported by ISM
– Connectors are fairly interchangeable, so an integration can be cloned
with a new connector to create an integration with a new target. For
example, a connector to integrate OMNIbus with Maximo can be cloned to
provide an integration between OMNIbus and Remedy.
1.4 Integration scenarios
The integration architecture of Tivoli SRM makes it possible to connect to any
third-party solution. It is created based on several industry standards, as well as
TDI. The architecture of Tivoli SRM provides a robust integration platform.
In the following chapters, we discuss a number of possible integration scenarios,
such as:
򐂰Event management products or Event Generators
򐂰Third-party Service Desk tooling, such as HP Service Center
򐂰TIM
򐂰Computer telephony integration
򐂰Sametime and instant messaging
򐂰CCMDB
8 Integration Guide for IBM Tivoli Service Request Manager V7.1
1.4.1 Integration with event management solutions
Any service, or incident request, can originate from different sources, for
instance:
򐂰A self-service user generates a new self-service request; no plausible
solution is found in the knowledge base.
򐂰A service desk agent is taking your call; the agent can register a request
manually.
򐂰An automated event generating the request, detected by your event
management solution.
We are interested in automated events to synchronize with Tivoli SRM.
Integrating Tivoli SRM with Event Management solutions is probably the most
obvious integration we can think of. Out-of-the-box integrations exist for
customers using:
򐂰Tivoli Netview
򐂰Tivoli Monitoring
򐂰TEC
򐂰Netcool® Omnibus
The integration allows service desk tickets (service requests) to open
automatically based on predefined rules when an event arrives. The benefit is
that the integration saves time by assisting in the automation of a common
operator task.
Chapter 1. Integration benefits 9
During normal operation, the integration allows data to flow between the TDI and
an Object Server in the form of Event Integration Facility (EIF) messages. The
Tivoli EIF is a toolkit that expands event types and system information that you
can monitor. Event adapters monitor managed resources and send events to the
Event Management product or other applications. You can use the Tivoli EIF to
develop your own adapters that are tailored to your network environment and
your specific needs. Figure 1-2 shows the flow of data between an Object Server
and Tivoli SRM through the various components of Event Management
integration with Tivoli SRM.
Figure 1-2 Event management integration data flow
For more details about how to install, configure, and manage Service Desk
integrations, refer to Chapter 3, “Event management integration” on page 105.
1.4.2 Integration with other service desk solutions
Most clients already have a type of ISM solution in place. Typically, a new ISM
product requires replacing the existing ISM product, or Tivoli ISM products
coexisting and inter-operating with past ISM products. The Service Desk
integration provides the necessary tools to support migration from past ISM
products and the interoperability of Tivoli ISM solutions with past ISM products.
ISM Service Desk integration is a complex topic. There are a variety of Service
Desk products being used today. Most Service Desks are customized by their
users. Different clients focus on different areas of integration.
10 Integration Guide for IBM Tivoli Service Request Manager V7.1
ISM provides a Service Desk integration toolkit that includes integration
examples and documentation. Peregrine and Remedy examples are available
and described in the following chapters. You can extend the examples to create
new integration points.
To build a complete solution, the predefined code must be extended to:
򐂰Handle any customization to either the third-party Service Desk or the IBM
Service Desk data model for the objects addressed by the base solution.
򐂰The predefined code must be cloned and modified to handle objects required
by the base solution that are not covered by the base code.
Table 1-1 shows the benefits of ISM V7.1 Service Desk integration.
Table 1-1 Client value/benefits: ISM V7.1 Service Desk integration
Capability Benefits
TDI connector for Maximo 򐂰Integrates Maximo into the TDI family. Functions
as an extension to the MEA bringing drag and
drop data mapping and other TDI features to
Maximo.
򐂰Can be used with most MEAs/Business objects.
򐂰Many uses beyond Service Desk integration. Can
be used in conjunction with any standard TDI
connector. Examples include EIF connector for
event integration and XML for knowledge import.
TDI assembly lines 򐂰Provides predefined integration for most common
Service Desk and CMDB business objects.
򐂰Near real-time, bi-directional symbolization of
data.
򐂰Can be easily customized to accommodate
changes and extensions to the data model.
򐂰Can be easily cloned to integrate other business
objects.
Incident/problem application 򐂰Provides ticket management applications for
Tivoli SRM without requiring the third-party
Service Desk.
򐂰Operations personnel do not need to launch a
third-party Service Desk for basic tasks.
򐂰Supports creating, managing, and viewing
relationships between tickets and other Tivoli
SRM objects.
Chapter 1. Integration benefits 11
For more details about how to install, configure, and manage Service Desk
integrations, refer to Chapter 4, “Service Desk Tool integration” on page 135.
1.4.3 Integration with other solutions
You can probably think of several other integrations to learn, but to describe all
possible scenarios is impossible. We selected and described a few of the
existing and useful integrations in more detail.
Identity management
Several interpretations of identity management are developed in the IT industry.
Computer scientists now associate the phrase, quite restrictively, with the
management of user credentials and how users might log on to an online
system. You can consider identity management as the management of
information (as held in a directory) that represents items identified in real life
(users, devices, services, and so forth).
The self-service password reset is defined as any process or technology that
allows users who have either forgotten their password, or triggered an intruder
lock-out, to authenticate with an alternate factor and repair their own problem
without calling the help desk. It is a common feature in identity management
software and often bundled in the same software package as a password
synchronization capability.
Typically, users who have forgotten their password launch a self-service
application from an extension to their workstation login prompt, using their own or
another user’s Web browser, or through a telephone call. Users establish their
identity without using their forgotten or disabled password by answering a series
of personal questions, using a hardware authentication token, responding to a
password notification e-mail, or less often, by providing a biometric sample.
Users can then either specify a new unlocked password or ask that a randomly
generated one be provided.
Launch in context 򐂰Provides launch based on external keys in
synchronized data objects from the Tivoli SRM to
an external Service Desk, and from an external
Service Desk to Tivoli SRM.
Capability Benefits
12 Integration Guide for IBM Tivoli Service Request Manager V7.1
Self-service password reset expedites problem resolution for users after the fact
and thus reduces help desk call volume. It can also be used to ensure that
password problems are only resolved after adequate user authentication,
eliminating an important weakness of many help desks: social engineering
attacks, where an intruder calls the help desk, pretends to be the intended victim
user, claims that the password is forgotten, and asks for a new password.
IBM TIM helps enterprises strengthen and automate internal controls governing
user access rights. It provides a secure, automated, and policy-based solution
that helps effectively manage user privileges across heterogeneous IT
resources.
The integration of TIM and SRM is used to identity and manage password resets.
Figure 1-3 shows the solution flow used.
Figure 1-3 Password reset integration solution flow
TIM creates a Service Desk ticket every time a password reset (change) is
performed by TIM. The ticket is created and closed if the password reset is
successful. The ticket is created and left open if the password reset fails.
The integration uses the TIM Self Care UI (also referred to as Judith UI or End
User UI) or TIM console UI to perform the password reset. Installing the
integration makes sure the Maximo Logon page Forgot Your Password link is
redirected to the TIM Self Care UI. TIM manages the Maximo native registry or
WinAD LDAP registry.
Chapter 1. Integration benefits 13
For more details about how to install, configure, and manage identity
management integrations, refer to Chapter 5, “IBM Tivoli Identity Manager
integration” on page 167.
Computer telephony integration
Computer telephony integration (CTI) is the name given to the merger of
traditional telecommunications (PBX) equipment with computers and computer
applications. The use of Caller ID to automatically retrieve client information from
a database is an example of a CTI application. It is also used to explain the
connection between a computer and a telephone switch, which allows recording
and using information obtained by telephone access. For example, CTI enables
activities, such as dial-up registration, and fax-back.
CTI solutions are often used in call center environments, but can be used in a
service desk environment. Integrating the CTI solution with your service desk
solution reduces the number of manual steps for operators, but it increases the
speed of handling for any operator even more, reducing the average call time.
CTI is new to Tivoli SRM. It has features that enables your telephony system to
interact with Tivoli SRM. CTI allows you to populate Tivoli SRM records and
fields with mapped information based on lookup information provided by the CTI
system. Figure 1-4 on page 14 shows a simple process flow to open a ticket,
based on information provided by the CTI system.
14 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 1-4 CTI process flow
You can also control your CTI solution from the Tivoli SRM user interface,
creating a single application for all service desk-related activities.
For more details about how to install, configure, and use the existing CTI
integrations, refer to Chapter 8, “Computer Telephony integration” on page 217.
Sametime and instant messaging
Communication has always been a keyword in many organizations. For a service
desk analyst, communication is one of the most important aspects of the job.
Several tools are available for an analyst to communicate with clients, such as
the obvious e-mail and telephony. In recent years, many companies introduced
other tools to support mostly internal communication, known as instant
messaging.
Sametime is the IBM Lotus product for instant messaging, which now has a
predefined integration with Tivoli SRM. It allows a service desk analyst, or IT
specialist, to initiate contact with a Tivoli SRM user, based on the Sametime
status (which can be found in the user information on the request) and chat
functions provided by Sametime.
Chapter 1. Integration benefits 15
For more details about how to install, configure, and use the existing Instant
Messaging integrations, refer to Chapter 7, “Lotus Sametime integration” on
page 201.
CCMDB integration
It is not the most obvious integration, but you can call an installation of Tivoli
SRM and CCMDB on the same base services an integration.
CCMDB provides information to help the Service Desk team isolate the source of
the problem more quickly. Suppose a switch that is used for production goes
down, and the affected users are calling the help desk. By looking at the
applications and servers that are down (affected configuration items (CIs) in
CCMDB terminology), a Service Desk person, or a Specialist, can understand
that they are all related with a certain switch (through the CI relationship
information provided by CCMDB). They can also see that this switch has caused
problems before, and after a closer analysis, they can understand that the
software or firmware on this switch is back-level. All this information is provided
by the CCMDB. At this point, they can start a change request to upgrade the
switch software or firmware. This change request is reviewed by the Change
Manager or the change review board to analyze the impact of the change (again
using the CCMDB, looking at the CIs affected), and after the change is
authorized, it is implemented.
All these are ITIL processes, and by integrating your help desk processes with
configuration and change management processes, you greatly increase the
efficiently of these processes.
For more details about how to install and use CCMDB PMPs on top of Tivoli
SRM, refer to Chapter 6, “CCMDB integration” on page 187.
Remote control
Remote control or Remote administration refers to any method of controlling a
computer from a remote location. Software that allows remote administration is
becoming increasingly common and is often used when it is difficult or
impractical to be physically near a system to use it.
Any computer with an Internet connection, TCP/IP, or on a local area network
can be remotely administered. For non-malicious administration, the user must
install or enable server software on the host system in order to be viewed. Then,
the user or client can access the host system from another computer using the
installed software.
The IBM product delivered for this purpose is Tivoli Remote Control (TRC). Tivoli
SRM is shipped with a light version of TRC, enabling a service desk agent to
take over the user desktop from within Tivoli SRM and solve incidents as quickly
16 Integration Guide for IBM Tivoli Service Request Manager V7.1
as possible. If a service desk agent can solve incidents quickly using remote
control, there is no need to transfer requests to a second line. Remote control
can also be used to gather more information about the request to open a second
line so that an IT specialist can quickly solve an incident. The requester is not
required to provide technical details. Using TRC can make your key performance
indicators (KPIs) look better than ever.
© Copyright IBM Corp. 2008. All rights reserved. 17
Chapter 2. Integration components
This chapter discusses integration components that are available in IBM Tivoli
Service Request Manager (SRM) V7.1.
This chapter discusses the following topics:
򐂰IBM Tivoli Directory Integrator on page 18
򐂰TDI component on page 27
򐂰Planning to deploy TDI on page 30
򐂰Integration Framework or MEA on page 35
2
18 Integration Guide for IBM Tivoli Service Request Manager V7.1
2.1 IBM Tivoli Directory Integrator
IBM Tivoli Directory Integrator (TDI) is a generic data integration tool that is used
to address problems that require custom coding and more resources than
traditional integration tools. It is designed to move, transform, harmonize,
propagate, and synchronize data across otherwise incompatible systems.
TDI can be used in conjunction with the deployment of integration with the IBM
Tivoli SRM product to provide a feed from multiple Service Desk Systems, such
as HP Service Desk and Remedy Service Desk. TDI can also function as a
custom adapter to integrate with network monitoring tools, such as Tivoli
Enterprise Console (TEC) and Netcool Omnibus.
A TDI Connector provides access to anything else for which there is a TDI
connector available. There is a large set of over 20 existing connectors. As
shipped, it can synthesize data from many feeds at a time. TDI provides a visual
drag and drop data mapping environment, and it provides JavaScript™ for data
mapping and transforms. Figure 2-1 on page 19 shows additional types of
integration that are made possible by using TDI, but they are not covered in this
book.
Integrations are available as a TDI-unified adapter, and they can be used with
minor adjustments.These scenarios are further expanded later in this book.
Regardless of the scenario, it is essential to gain a full understanding of the
environment. Understanding the environment allows you to document the
solution. Typically, understanding the environment is accomplished by the
development of a series of use cases that are designed to clarify the business
needs and refine the solution through an iterative process that ultimately
provides you with a complete list of documented customer business
requirements.
Integration problems are all about communication and are typically broken down
into three parts:
򐂰The systems and devices that communicate
򐂰The flow of data between these systems
򐂰The trigger of events when the data flow occurs
Chapter 2. Integration components 19
Figure 2-1 Integration possibilities using TDI
2.1.1 TDI architecture
TDI architecture consists of the elements of a communications scenario that can
be described as data sources:
򐂰Data repositories, systems, and devices that talk to each other. For example:
– An enterprise directory that you are implementing or trying to maintain
– Your customer relationship management (CRM) application
– The office phone system
– An access database with a list of company equipment and who owns the
equipment
20 Integration Guide for IBM Tivoli Service Request Manager V7.1
򐂰Data sources represent a wide variety of systems and repositories. For
example:
– Databases:
•IBM DB2®
•Oracle®
– SQL Server® directories:
• iPlanet
• IBM Directory Server
• Domino®
• eDirectory
• ActiveDirectory
– Directory services
Exchange
– Files:
• Extensible Markup Language (XML)
• Lightweight Directory Access Protocol (LDAP)
• LDAP Directory Interchange Format (LDIF)
• SOAP documents
• Specially formatted e-mail
Data sources also represent any number of interfacing mechanisms that internal
systems and external business partners use to communicate with your
information assets and services: data flows and events.
Data flows are the threads of communication and their content. They are usually
drawn as arrows that point in the direction of data movement. Each data flow
represents a dialogue between two or more systems.
However, for a conversation to be meaningful to all participants, everyone
involved must understand what is being communicated. You can probably count
on the data sources representing their data content in multiple ways. One system
might represent a telephone number as textual information, including the dashes
and parentheses that are used to make the number easier to read. Another
system might store them as numerical data. If these two systems are to
communicate about this data, the information must be translated during the
conversation. Furthermore, the information in one source might not be complete
and might need to be augmented with attributes from other data sources. In
addition, only parts of the data in the flow might be relevant to receiving systems.
Chapter 2. Integration components 21
A data flow must include the mapping, filtering, and transformation of information,
shifting its context from input sources to that of the destination systems.
Events can be described as the circumstances dictate, when one set of data
sources communicates with another set, for example, when an employee is
added, updated, or deleted from the human resources (HR) system. Another
example is when the access control system detects a keycard being used in a
restricted area. You can base an event on a calendar or a clock-based timer; for
example, start communications every 10 minutes or at 12:00 midnight on
Sundays. An event can also be a manually initiated one-off event, such as
populating a directory or washing the data in a system.
Events are usually tied to a data source and are related to data flows that are
triggered when the specified set of circumstances arise. Each element is handled
by TDI components:
򐂰Connectors: Connectors are components that connect to and access data in
a data source. For example, we use a Java Database Connectivity (JDBC)
Connector to read and write to an SQL database, while an LDAP Connector
allows us to access a directory. Certain types of data sources do not store
data as structured objects (records, entries, and so on); they use bytestreams
instead. Two examples are data over IP and flat files.
򐂰Parsers: Parsers turn bytestreams into structured information or structured
information into bytestreams. The data flows are implemented by clicking one
or more Connectors together (associating Connectors with Parsers where
necessary).
򐂰EventHandlers: EventHandlers can be configured to pick up change
notifications in connected systems (such as directories or Post Office Protocol
Version 3 (POP3)/Internet Message Access Protocol (MAP) mailboxes) and
then dispatch these events to the designated AssemblyLines.
The architecture of TDI is divided into two parts:
򐂰The core system where most of the system functions are provided. The TDI
core handles log files, error detection and dispatching, and data flow
execution parameters. The core system is also where your customized
configuration and business logic are maintained.
򐂰The components, which serve to hide the complexity of the technical details of
the data systems and formats with which you want to work. TDI provides you
with three types of components: Connectors, Parsers, and EventHandlers.
Because the components are wrapped by core functions that handle
integration flow control and customization, the components themselves can
remain small and lightweight. For example, if you want to implement your own
Parser, you only have to provide two functions: one function for interpreting
the structure of an incoming bytestream and one function for adding structure
22 Integration Guide for IBM Tivoli Service Request Manager V7.1
to an outgoing bytestream. If you look in the jars subdirectory of TDI, you see
how lightweight the standard components are, which makes them easy to
create and extend.
This core/component design makes TDI easily extensible. It also means that you
can rapidly build the framework of your solutions by selecting the relevant
components and clicking them into place. Components are interchangeable and
can be swapped out without affecting the customized logic and the configured
behavior of your data flows. Therefore, you can build integration solutions that
are quickly augmented and extended, while keeping them less vulnerable to
changes in the underlying infrastructure.
2.1.2 AssemblyLines
The data flow arrows in the diagram (Figure 2-1 on page 19) represent
AssemblyLines in TDI, which work in a similar fashion to real-world industrial
assembly lines.
Real-world assembly lines are made up of a number of specialized machines that
differ in both function and construction, but they have one significant attribute in
common: They can be linked together to form a continuous path from the input
sources to the output.
An assembly line generally has one or more input units that are designed to
accept whatever raw materials are needed for production. These ingredients are
processed and merged together. Sometimes, by-products are extracted from the
line along the way. At the end of the production line, the finished goods are
delivered to the waiting output units.
If a production crew receives an order to produce something else, they break the
line down, keeping the machines that are still relevant to the new order. The new
units are connected in the right places, the line is adjusted, and production starts
again. The TDI AssemblyLines work in much the same way.
The TDI AssemblyLines receive information from various input units, perform
operations on this input, and then, convey the finished product through output
units. TDI AssemblyLines work on one item at a time, for example, one data
record, directory entry, registry key, and so forth. Refer to Figure 2-2 on page 23.
Chapter 2. Integration components 23
Figure 2-2 AssemblyLines
Data attributes from the connected input sources are accumulated in a Java
bucket (called the work object). Scripts can be added to work with this
information: verifying data content, computing new attributes and values, as well
as changing existing attributes and values, until the data is ready for delivery
from the line into one or more output data sources.
The input and output units of an TDI AssemblyLine are called Connectors, and
each Connector is linked into a data store. Connectors tie the data flow to the
outside world and are also where data transformation and aggregation take
place. you can layer your business, security, and identity management logic
through the Connectors.
2.1.3 Connectors
Connectors are similar to puzzle pieces that click together, while at the same
time, they link to a specific data source, as shown in Figure 2-3 on page 24.
Each time that you select one of these puzzle pieces and add it to an
AssemblyLine, you must:
1. Choose the Connector type.
2. Assign the Connector to its role in the data flow.
This is called the Connector mode, and it tells the TDI how to use the
Connector:
– An input Connector iterates through or looks up information in its source.
– An output Connector inserts, updates, or deletes data in the connected
system or device.
24 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-3 Connector puzzle pieces
You can change the type and the mode of a Connector to meet changes in your
infrastructure or in the goals of your solution. If you plan for these changes, the
rest of the AssemblyLine, including data transformations and filtering, is not
impacted. Therefore, it is important to treat each Connector as a black box that
either delivers data into the mix or extracts part of it to send to a data source. The
more independent each Connector is, the easier it is to augment and maintain
your solution.
By making your Connectors as autonomous as possible, you can also readily
transfer them to your Connector Library and reuse them to create new solutions
more quickly, even sharing them with other Connectors. Using the TDI library
feature also makes maintaining and enhancing your Connectors easier, because
you only have to update the Connector template in your library, and all of the
AssemblyLines that are derived from this template inherit these enhancements.
When you are ready to put your solution to serious work, you can reconfigure
your library Connectors to connect to the production data sources instead of
those data sources in your test environment, and you can move your solution
from lab to live deployment in minutes.
To include new data into the flow, add the relevant Connector to the
AssemblyLine. Refer to Figure 2-4 on page 25.
Note: You might think that these puzzle pieces are rendered incorrectly and
that data must flow from above, and then, flow down to the receiving data
sources. But anyone who has ever tried to implement an integration solution
knows that data does not tend to flow on its own. Data must be pulled out of
input sources and then pushed into the output destinations, which is where
Connectors excel.
Chapter 2. Integration components 25
Figure 2-4 Add Connectors to the AssemblyLine
IBM TDI provides a library of Connectors from which to choose, such as LDAP,
JDBC, Microsoft Windows® NT4 Domain, Lotus Notes®, and POP3/IMAP. And if
you cannot find the Connector that you want, you can extend an existing
Connector by overriding any or all of its functions by using one of the leading
scripting languages, including JavaScript, VBScript, and PerlScript. You can also
create your own Connector either with a scripting language inside of the Script
Connector wrapper or by using Java or C/C++.
Furthermore, TDI supports most transport protocols and mechanisms, such as
TCP/IP, FTP, HTTP, and Java Message Service (JMS)/message queuing (MQ),
with or without Secure Sockets Layer (SSL) or other encryption mechanisms to
secure the information flow.
For more information about scripting languages and about how to create your
own scripting language, refer to the IBM Directory Integrator 6.1.1: Reference
Guide, SC32-2566.
2.1.4 Parsers
TDI handles unstructured data, such as text files or bytestreams coming over an
IP port, quickly and simply by passing the bytestream through one or more
Parsers. Parsers are another type of TDI component, and the system ships with
a variety of Parsers, including LDAP Directory Interchange Format (LDIF),
Directory Services Markup Language (DSML), XML, comma-separated values
(CSV), and fixed-length field. And, you can extend and modify Parsers in the
same way that you can extend and modify Connectors, as well as create your
own Parsers.
26 Integration Guide for IBM Tivoli Service Request Manager V7.1
Continuing with the previous example, the next step is to identify the data
sources. Because the input data source is a text file in comma-separated value
format, you use the File System Connector paired with the CSV Parser. You use
a File System Connector for output as well, but this time, choose the XML Parser
to format the file as an XML document. First, we look at the AssemblyLine using
the puzzle pieces, as shown in Figure 2-5.
Figure 2-5 AssemblyLine puzzle pieces
2.1.5 EventHandlers
EventHandlers are the third and last type of TDI component and provide
functions for building real-time integration solutions.
Note: We created the examples in this book on a UNIX® platform and use the
UNIX path name conventions. In order for your solution to be platform
independent, use the forward slash (/) instead of the backward slash character
(\) in your path names. For example, examples/Tutorial/Tutorial1.cfg works
with both Windows and UNIX/Linux®.
Chapter 2. Integration components 27
Like Connectors, EventHandlers can have data source intelligence that allows
them to connect to a system or service and wait for an event notification.
Examples are the Mailbox EventHandler, which can detect when new messages
arrive in a POP3 or IMAP mailbox, and the LDAP EventHandler, which can catch
changes made to a directory. When an event occurs, the EventHandler stores the
specifics of the event, then performs logic, and starts the AssemblyLines
according to the condition or action rules that you set up.
Sometimes you can also use Connectors to capture events, such as the JMS
(MQ) Connector or the LDAP Changelog Connector. You can configure both of
these Connectors to wait until new data appears and then retrieve it. However,
because the EventHandler operates in its own thread, you can use
EventHandlers to dispatch events to multiple AssemblyLines, which provides a
cleaner and more straightforward method of filtering and handling multiple types
of events from the same source (for example, SOAP or Web services calls). You
can also configure EventHandlers for auto start, which means that if you start up
a server with Config, these EventHandlers are immediately activated. Auto start
saves you from having to specifically name the AssemblyLines to run in the
command line parameters to the server.
2.2 TDI component
The connection between these components can be established either
unidirectionally or bidirectionally to keep your system or record synchronized.
Refer to Figure 2-6 on page 28. If the connector for an external application has
not been developed by IBM, you have the ability to develop your own connector
by using another type of language, such as JavaScript.
TDI is divided into three internal components:
򐂰Node: This component is the heart of the system, which allows you to
configure, communicate, and exchange data in various modes between two
systems.
򐂰Interpreter: This component is the function, which allows you to map various
fields together. Also, you can write script in JavaScript to make your data
exchange process more flexible.
򐂰Connector: This component allows you to establish a connection to the
third-party application to facilitate the data exchange between two
components.
28 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-6 TDI components: the node, the interpreter, and the connector
Many ready-to-use connectors are available to provide the exchanged
information between various products.
2.2.1 Supported platform and compatibility matrix
One of the most important points for this type of integration is the ability to define
which platform and operating system are supported before proceeding to the
installation. Refer to Figure 2-7 on page 29.
Tivoli
Enterprise
Console
Tivoli
Service
Request
Manager
External
Service
Desk
NODE
Tivoli Directory Integrator
External External
Integration Object
(M E A)
Create/Update
TEC Event
Update
TEC Event
Create/Update
Ticket
Update
Ticket
CONNECTOR
TEC
CONNECTOR
SRM
INTERPRETER
CONNECTOR
HP-Peregrine / Remedy
Create/Update
Ticket
Update
Ticket
Web Services Integration
Web Services Integration
Note: Make sure that your actual infrastructure is within these components to
ensure the continuity of your support contract.
Chapter 2. Integration components 29
Figure 2-7 Compatibility matrix: Architecture and operating systems supported
2.2.2 Hardware and software prerequisites
This section provides TDI installation prerequisites.
2000 Professional*
2000 Server Std Edit.
2000 Adv. Server
XP Pro*
2003 Server - Std Ed.
2003 Server - Ent. Edit.
AIX 5L 5.2 (MP 5200-08)
AIX 5L 5.3 (MP 5300-03)
HP-UX11iv2 (11.23)
RedHat Enterprise Linux ES / AS 3.0
RedHat Enterprise
Linux ES / AS 4.0 32 bit / 64 bit
SLES 9 (32 bit / 64 bit)
SLES 10 (32 bit / 64 bit
Red Flag Data Center 5.0 SPI / Aisan
i
2.0 SP1
Microsoft Windows
Intel IA32 - 32 Bit 999999
Microsoft Windows
AMD64/EMT64 - 64 Bit 99
IBM (Non-Admin installs not
supported) 99
HP-UX PA-RISC 9
HP-UX Itanium 9
Linux Intel IA 32 9999 9
Linux AMD64/EMT64 999
Linux on Power (pSeries,
iSeries, OpenPower, and
JS20 Blades)
9999
30 Integration Guide for IBM Tivoli Service Request Manager V7.1
Hardware prerequisites
The installation procedure requires 450 Mb disk space during the installation.
Disk space requirements by platform for a typical installation are:
򐂰Windows (32-bit and 64-bit): 341 MB
򐂰Linux (32-bit and 64-bit): 413 MB
򐂰AIX®: 342 MB
򐂰Solaris™: 453 MB
򐂰HP-UX: 562 MB
Disk space requirements by platform for a custom installation in which all
components are selected are:
򐂰Windows (32-bit and 64-bit): 564 MB
򐂰Solaris: 773 MB
򐂰HP-UX: 858 MB
Software prerequisites
The administrative workstation is not used for daily operations, although it is an
important SRM support component for administrative activities.
2.3 Planning to deploy TDI
Before installing TDI, you need to understand the interaction between the TDI
component connectors and the third-party applications with which you expect to
exchange data.
We have included various types of scenarios that you might encounter when
implementing TDI.
2.3.1 Installation scenarios
The first scenario is integrating an event management product, such as Tivoli
Enterprise Console (TEC). At any time, a server, network, or any other type of
event can be generated and must be managed within this console.
Assume that this scenario uses the default value that is provided by TEC where a
ticket in Tivoli SRM is created for each Critical event generated. When this ticket
is closed, this information is updated in TEC to synchronize the open ticket and
the open event. This type of integration is required to ensure the integrity of the
generated data.
Chapter 2. Integration components 31
The second part of this integration in this scenario consists of keeping two
Service Desk operations synchronized. The first part consists of the Tivoli SRM,
and the second part consists of HP ServiceCenter V6.1.
2.3.2 Installation procedure
In this section, we focus on the installation of the TDI application, which allows
you to develop, configure, and define the mapping between two components. We
do not discuss the integration scenarios here.
For event management integration scenarios, refer to Chapter 3, “Event
management integration” on page 105. For third-party service desk integration,
refer to Chapter 4, “Service Desk Tool integration” on page 135.
The latest version of TDI that is available at this time is V6.1.1. Prior to installing
the application, make sure that:
򐂰You copy the installation files from the IBM Tivoli SRM Integration Toolkit
image to a temporary directory on the computer where you want to install TDI.
򐂰You have enough disk space left, as shown in the prerequisites.
򐂰You have Administrator’s rights on the Windows server or the Windows
machine.
Note: At this time, as shipped, only HP ServiceCenter V6.1 is supported. For
any other version, you must modify the assembly line configuration within the
connector configuration.
Important: Use the procedure (command line installation) that is described in
this section rather than the TDI product documentation to install a TDI
environment that supports the integration of Tivoli SRM with event
management, third-party service desk integration, and so forth.
If you install TDI using the TDI V6.1.1 Launchpad (as described in the TDI
manuals), several installation parameters that are necessary for Tivoli SRM
integration are not available during the installation.
For general information about IBM TDI, refer to the product documentation at:
http://publib.boulder.ibm.com/tividd/td/IBMDirectoryIntegrator6.1.1.
html
32 Integration Guide for IBM Tivoli Service Request Manager V7.1
Complete the following steps to install TDI:
1. At a command prompt, change to the directory where the installation files are
located.
2. Run the installation command that is appropriate for your platform:
–Windows:
installTDI.cmd -silent tdi_home tdi_working_dir "srm_host
[srm_host2 srm_host3 ...]" tec_log_file_adapter_home Y | N
–Linux or AIX:
./installTDI.sh -silent tdi_home tdi_working_dir \"srm_host
[srm_host2 srm_host3 ...]\" tec_log_file_adapter_home Y | N
The descriptions of the parameters are:
-silent: Specifies to install the product in silent mode,
where the installation is performed with no user
interaction.
tdi_home: Specifies the directory where you want to install the
TDI binary files. Specify any directory. The
directory that you specify is created for you if it
does not exist.
tdi_working_dir: Specifies the directory where you want to install the
TDI files that are required by the products that are
supported for integration with Tivoli SRM. Specify
any directory.
srm_host [srm_host2 srm_host3 ...]:
Specifies the hostname or IP address of one or
more servers that host Tivoli SRM. Specify the fully
qualified host name with the HTTP listener port of
the supporting application server. (Port number
9080 is typically used for a WebSphere®
Application Server.) Be sure to enclose these
arguments in double quotes ("), including the
escape character (\) for UNIX, as shown in the
command syntax.
Note: Typically, the working directory is a subdirectory of the tdi_home
directory. The directory that you specify is created for you if it does not
exist.
Chapter 2. Integration components 33
tec_log_file_adapter_home:
Specifies the full directory path where you installed,
or plan to install, the TEC non-TME logfile adapter
on this computer. The non-TME logfile adapter
supports the integration of Tivoli SRM with TEC.
Y | N : Specifies whether you want to use a common
queue in a multiple TDI server environment. The
default is Y (yes).
3. Repeat the preceding steps on each computer where you want to install TDI.
Example 2-1 specifies that you want the TDI server to connect to two Tivoli SRM
servers (tsrm1 and tsrm2). No logfile adapter is specified (na).
Example 2-1 Windows example
installTDI.cmd -silent C:\TDI C:\TDI\work "tsrm1.itso.ibm.com:9080
tsrm2.itso.ibm.com:9080" na Y
The UNIX command in Example 2-2 specifies a single Tivoli SRM Server (TSRM)
and the location of the logfile adapter on the TDI server.
Example 2-2 UNIX example
./installTDI.sh -silent /opt/TDI /opt/TDI/work
\"tsrm.itso.ibm.com:9080\" /opt/IBM/Tivoli/tec/nonTME Y
Note: At the time of writing this book, there was a defect in the
installTDI command. Although srm_host(s) is specified in the silent
install, this parameter is not used during the execution of the command.
You have to manually update the mxe.properties or TDI config file to
specify the hostname or IP address of the servers that host Tivoli SRM.
This is expected to be corrected in a later fixpack.
Note: If you do not plan to integrate with TEC, or you do not know the
location of the TEC logfile adapter, enter any valid character or
character string for this parameter. For example, enter a dot (.) or any
word (na). After installation, you can edit a properties file
(mxe.properties) on the TDI server to specify the location of the TEC
logfile adapter.
34 Integration Guide for IBM Tivoli Service Request Manager V7.1
Post-installation verification
This section verifies that the installation is complete:
1. If the following component is in the All Programs folder, it confirms the
success of the installation. Refer to Figure 2-8 on page 34.
2. Select Start → All Programs → IBM TDI 6.1.1:
– Start Config Editor
– Uninstall IBM TDI 6.1.1.
Figure 2-8 IBM TDI 6.1.1 menu
3. To complete the post-installation check, launch the TDI as shown in
Figure 2-8 by selecting Start Config Editor, as shown in Figure 2-9.
Figure 2-9 TDI user interface
Chapter 2. Integration components 35
2.4 Integration Framework or MEA
This section provides information about Integration Framework, which is one
component of the Service Desk Integration Toolkit. In Maximo V6.x, the
integration application is referred to as MEA. Now, in Tivoli SRM V7.1, MEA is
referred to as the Integration Framework. In this section, we discuss:
򐂰Overview of Integration Framework
򐂰Architecture
򐂰Integration Framework components
򐂰Cluster configuration
򐂰Integration enhancements and changes from Version 6.x to 7.1
򐂰Sample scenario
2.4.1 Integration Framework overview
Integration Framework is a set of applications to help you integrate the system
with your framework applications. You also can create business flows between
the system and the other framework applications.
Integration Framework comes embedded with the Tivoli SRM installation.
Figure 2-10 shows how to access the Integration application from the Web user
interface.
To access the integration application, complete the follow steps:
1. Log on to an account with integration privileges.
2. Open the integration application by selecting Go To → Integration.
36 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-10 Integration Framework
Operational Management Products (OMPs) are individual external products that
you can use to implement Logical Management Operations (LMOs). Tivoli
Application Dependency Discovery Manager (TADDM), Tivoli Provisioning
Manager (TPM), and Tivoli Configuration Manager (TCM) are examples of
OMPs. You can bring OMPs into the system from the IBM Tivoli Application
Dependency Discovery Manager (TADDM) using the Integration Composer.
OMPs are artifacts within the system that can exist when there is no OMP.
The key features of the Integration Framework include:
򐂰Predefined content to assist in implementing integration requirements in a
timely manner. This content is a comprehensive set of outbound (Channels)
and inbound (Services) integration interfaces that are available to use
immediately.
򐂰Applications to configure, predefine, and to create new integration definitions.
򐂰Applications to facilitate the customization of predefined content using a
processing rule engine, Java, and Extensible Stylesheet Language
Transformations (XSLT).
򐂰Support for multiple communication modes, including:
Chapter 2. Integration components 37
–Web services
– HTTP
–JMS
– Database interface tables
– XML/flat files
򐂰Event-based, batch, program-initiated, and user-initiated processing of
outbound and inbound messages.
򐂰Load and performance scalability using JMS queues.
򐂰Support for clustered environments that reduce system downtime, increase
system availability, and improve system performance.
򐂰Support for user interface (UI)-based integration, including the context-based
launching of external applications.
򐂰Support for integration to OMPs.
򐂰Support for bulk export of data using user-defined SQL query.
򐂰Support for bulk importing of XML or flat files.
򐂰Dynamic XML schema generation for all integration interfaces.
38 Integration Guide for IBM Tivoli Service Request Manager V7.1
򐂰Dynamic generation of Web services Interoperability (WS-I) compliant Web
services, including Web Service Definition Language (WSDL).
򐂰Provides the concept of an adapter that is used to group related integration
artifacts. You can configure and deploy adapters for enterprise connectivity
with various systems. Each adapter can have its own interface and delivery
mode. Preconfigured adapters for Oracle and SAP® are available as add-ons.
2.4.2 Architecture
This section describes the architecture of Integration Framework processing. The
Integration Framework facilitates bidirectional data exchange between the
system and external applications in a real-time or batch mode. Through the
Integration Framework, you can exchange data synchronously and
asynchronously using a variety of communication protocols. Refer to
Figure 2-11.
Figure 2-11 Integration Framework overview
Chapter 2. Integration components 39
You can implement the system within a cluster of application servers, and
integration services can run across the cluster.
The Integration Framework also provides features that support integration with
OMPs, such as Tivoli Provisioning Manager. You also can use a system
application UI to launch an external application UI. The following sections
describes:
򐂰Integration Framework for data exchange
򐂰Integration Framework for OMP integration
򐂰Integration Framework for UI integration
Integration Framework for data exchange
Through the Integration Framework, you can send and receive XML messages
between the system and external applications. The Integration Framework
provides the following capabilities:
򐂰Build, transform, and customize message content
򐂰Send and receive messages using multiple protocols, including:
–Web services
– Hypertext Transfer Protocol (HTTP)
–JMS
򐂰Exchange data synchronously and asynchronously
򐂰Exchange event-based messages
򐂰Batch import and export messages
The Integration Framework components that support data integration are shown
in Table 2-1 on page 40.
40 Integration Guide for IBM Tivoli Service Request Manager V7.1
Table 2-1 Integration Framework for data exchange components
Figure 2-12 on page 41 illustrates the Integration Framework for data exchange.
Component Description
Object structures Define message content
Services Receive data into the system
Channels Send data out of the system
External systems Define external applications and services
that integrate with the system
Communication Modes you use to communicate with
external applications. Modes include Web
services, HTTP, Enterprise JavaBeans™
(EJB™), and flat files.
Events The business object events that you use
to initiate data exchange. Events include
data import, data export, and record status
changes, that is, work order approvals.
Web services Query or send transactions to the
Integration Framework.
Content System-provided content that is
configured to enable integration.
Chapter 2. Integration components 41
Figure 2-12 Integration Framework for data exchange
Integration Framework for OMP integration
OMPs are external products (to the system) that provide services for
configuration items (CIs), such as a server that runs applications. PMPs are
system applications and processes that use OMPs to automate IT-related
services. Such services include software deployment on CIs.
OMP integration takes place through a series of system calls and invocations. A
PMP calls an Integration Module (IM), which in turn communicates with the OMP
to perform a Logical Management Operation (LMO). With this framework,
actions, such as software deployment, can be automated where the PMP
initiates the IM to invoke the OMP to perform such actions.
Through the Integration Framework, IMs are configured to support specific LMOs
and OMPs. As part of the IM, an EndPoint/Handler is configured to identify the
communication protocol (HTTP, Web service) that IM uses to invoke the OMP.
The IM can map the service response so it is returned to the PMP. The service
response then can be processed in multiple ways. The service can open a
response in a UI application or save the response data to the application
database.
42 Integration Guide for IBM Tivoli Service Request Manager V7.1
OMPs can also choose to integrate in an assisted, (non-automated) approach by
using the Integration Framework.
The Integration Framework components that the IMs and PMPs use for OMP
integration are shown in Table 2-2.
Table 2-2 Integration Framework for OMP components
Figure 2-13 illustrates the Integration Framework for OMP.
Figure 2-13 Integration Framework for OMP
Component Description
LMO Define the actions that the IM supports for
an OMP.
Integration modules (IMs) Define the configurations and the
relationships to LMOs and OMPs.
Actions Use to implement an automated (no user
interaction) or semi-automated (user
initiates from a UI application) invocation
of an IM/OMP by a PMP. You can initiate
actions from UI Applications, Escalations,
and Workflows.
Chapter 2. Integration components 43
Integration Framework for UI integration
The Integration Framework provides a mechanism for you to launch from a
system application UI to an external application UI. You can define the context to
facilitate the landing into your wanted external application interface. For example,
you can configure in the system to launch and to display a specific part number in
an external application. The Integration Framework supports URL substitutions
of any values (part number) of any system business object.
You can use OMP-specific features when you launch to an OMP application UI.
Features include retrieving the registered host name of the OMP and a CI Source
token for the OMP. Refer to Figure 2-14.
You also can launch into a system UI from an external application (Land in
Context).
Figure 2-14 Integration Framework for UI
2.4.3 Integration Framework components
This section describes individual Integration Framework components and
features. Familiarity with framework components is essential when using the
Integration Framework application. The following components are described in
this section:
򐂰Object structures
򐂰Publish Channels
򐂰Invocation channels
򐂰Enterprise Services
򐂰Web services library
44 Integration Guide for IBM Tivoli Service Request Manager V7.1
򐂰Endpoints
򐂰External systems
򐂰LMO
򐂰Integration modules
򐂰Launch in context
򐂰Message tracking
򐂰Message reprocessing
Object structures
An object structure (OS) is the common data layer that the Integration
Framework uses for all outbound and inbound application data processing. An
OS consists of one or more business objects that make up the content of an XML
message. You can use the message content of a single OS to support
bidirectional inbound and outbound messages.
An OS can have the same object more than one time in its definition. Objects
must have a reference to a valid parent/child relationship within the system. The
OS has a Definition Class (Java) that you can code to perform logic, such as
filtering for outbound messages. For inbound messages, you can use an OS
Processing Class (Java) to invoke specific business object logic. The logic is
beyond the normal insert, update, and delete Integration Framework processing.
The OS is the building block of the Integration Framework that lets integration
applications perform the following functions:
򐂰Publish and query application data
򐂰Add, update, and delete application data
򐂰Import and export application data
In addition to being a building block, you can use the OS as a service to support
inbound message processing. You can invoke the OS service as a Web service,
as an EJB, or through HTTP. The object structure service supports system data
updates, as well as data queries outside of the system. Refer to Figure 2-15 on
page 45.
Note: Several components are specific, depending on your integration type,
such as Integration Framework for data exchange, OMPs (OPMs), and UI.
Chapter 2. Integration components 45
Figure 2-15 Object structure service
To access the OS application (Figure 2-16), select Go → Integration → Object
Structures.
Figure 2-16 Object Structures interface
46 Integration Guide for IBM Tivoli Service Request Manager V7.1
Publish channels
A publish channel is the pipeline for sending data asynchronously from the
system to an external system. Refer to Figure 2-17.
The following events trigger publish channel processing:
򐂰Object events (insert, update, and delete)
򐂰Application-initiated calls
򐂰Workflow calls
򐂰Data export
Figure 2-17 Publish channel
The content of a publish channel data structure is based on the associated object
structure. When you trigger publish channel processing, the Integration
Framework builds the XML message based on the object structure. The system
then moves the message through multiple processing layers before dropping the
message into a queue and releasing the initiator of the transaction.
The processing layers are:
Processing rules Use the Integration Framework rule engine to filter and
transform XML messages. You can also implement rules
through the publish channel application.
User exit Use to filter and transform data and implement business
logic. You can use this class as part of an installation or
customization process.
Note: Each processing layer is optional.
Chapter 2. Integration components 47
Processing class Is a Java class that is used to filter and transform data and
implement business logic. Oracle and SAP Adapters
provide processing classes to support product integration.
XSL map Is an XSLT style sheet that is used to transform data and
map the XML message to another format.
When the system drops the message into the queue, a polling thread (system
cron task) picks up the message and sends it to an external system through the
endpoint. The endpoint identifies the protocol that the system uses to send data,
such as HTTP or Web service. The endpoint also identifies the property values
that are specific to that endpoint, such as the URL, user name, and password.
To access the Publish Channel application (Figure 2-18), select Go →
Integration → Publish Channel.
Figure 2-18 Publish channel interface
Invocation channels
A service-oriented architecture (SOA) environment enables the use of external
services to process data from multiple sources. Invocation channels support this
generic SOA capability by enabling the system to call an external service
synchronously. The system also returns the response of the service back to the
caller for subsequent processing.
48 Integration Guide for IBM Tivoli Service Request Manager V7.1
For example, you can use an external system to calculate a tax amount for a
product that you are purchasing. Configure an invocation channel to call the
external tax service. The channel takes the returned tax amount and saves the
value in the system database.
The initiation of an invocation channel is implemented through an action class
that calls an invocation channel. Refer to Figure 2-19. You can implement an
action through the following means:
򐂰A user interface control (within an application)
򐂰Workflow routing
򐂰Escalation
Figure 2-19 Invocation channel
You can only initiate an invocation channel through an action class. The system
call is synchronous (no JMS queue), and a response can be returned from the
service to the caller.
The content of an invocation channel data structure is based on the associated
object structure. When you trigger invocation channel processing, the Integration
Framework builds the XML message based on the object structure. The system
then moves the message through multiple processing layers (optional) before
calling the external service.
Note: Each processing layer is optional.
Chapter 2. Integration components 49
The processing layers are:
User exit Is used to filter and transform data and implement
business logic. You can use this class as part of an
installation or customization process.
Processing class Is a Java class used to filter and transform data and
implement business logic. Oracle and SAP Adapters
provide processing classes to support product integration.
XSL map Is an XSLT style sheet that is used to transform data and
map the XML message to another format.
After the message goes through the processing layers, the Integration
Framework uses the endpoint to call the external service. The endpoint identifies
the protocol that the system uses to send data, such as HTTP or Web service.
The endpoint also identifies the property values that are specific to that endpoint,
such as the URL, user name, and password.
To access the Invocation Channel application (Figure 2-20), select Go →
Integration → Invocation Channel.
Figure 2-20 Invocation channel interface
50 Integration Guide for IBM Tivoli Service Request Manager V7.1
Enterprise service
The enterprise service is a pipeline for querying system data and importing data
into the system from an external system. You can configure the enterprise
service to process data synchronously (no queue) or asynchronously (through a
queue as shown in Figure 2-21). The enterprise service can use multiple
protocols, such as Web services and HTTP.
Figure 2-21 Asynchronous Enterprise Services
The synchronous enterprise service processes data without a queue, as shown
in Figure 2-22 on page 51.
Chapter 2. Integration components 51
Figure 2-22 Synchronous Enterprise Services
The enterprise service has processing layers to transform data and to apply
business processing rules before the data reaches the system objects. The
Integration Framework builds the XML message based on the object structure.
The XML message must be in the format of the object structure so the system
can process it successfully.
The processing layers are:
Processing rules Use the Integration Framework rule engine to filter and
transform XML messages.
User exit Use to filter and transform data and and implement
business logic. You can use this class as part of an
installation or customization process.
Processing class Is a Java class that is used to filter and transform data and
implement business logic. Oracle and SAP Adapters
provide processing classes to support product integration.
XSL map Is an XSLT style sheet that is used to transform data and
map the XML message to another format.
To access the Enterprise Services application, (Figure 2-23 on page 52), select
Go → Integration → Enterprise Services.
Note: Each processing layer is optional.
52 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-23 Enterprise Services interface
Web Services Library
External applications, Enterprise Service Bus (ESB), and Business Process
Execution Language (BPEL) processes use Web services to query or send
transactions to the Integration Framework. The Integration Framework provides
three types of Web services:
򐂰Object structure service
򐂰Enterprise service
򐂰Standard service
You can invoke these services as an EJB or HTTP.
When deploying Web services, the system generates a schema and Web
services description language (WSDL) file that you can access through a URL.
Optionally, a Universal Description, Discovery, and Integration (UDDI) registry is
updated for each deployed service.
Chapter 2. Integration components 53
The Integration Framework supports the following Web services:
򐂰Object Structure Web service: Created from an object structure. Object
structure Web services do not provide a processing layer that is available to
Enterprise Services. An object structure Web service supports five operations
through its WSDL:
–Create
–Delete
– Query
– Sync
– Update
򐂰Enterprise Web service: Created from an enterprise service. Enterprise
Services provide exit processing and optional JMS support. The Integration
Framework creates individual enterprise Web services for the operation
defined in an enterprise service (one operation per service). The operations
supported in an object structure service are also supported in an enterprise
Web service. You can deploy an enterprise Web service to use a JMS queue
(asynchronous process) or to bypass the JMS queue (synchronous process).
򐂰Standard Web service: Created from methods defined in application services.
The methods must be annotated in the application service to be available for
Web service implementation. The Integration Framework links the input and
output parameters of the methods to the WSDL operations.
To access the Web services library application (Figure 2-24 on page 54), select
Go → Integration → Web Services Library.
54 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-24 Web services library interface
Endpoints
Endpoints and their handlers facilitate the routing of outbound messages from
the outbound JMS queue to its destination or from an invocation channel directly
to its destination. The endpoint and handler combination contains the protocol
client and the necessary data to identify the specifics of communicating with that
destination, such as a URL.
The outbound queue cron task process or invocation channel invokes the
handler and passes the message body and the metadata properties to it. The
handler uses the metadata properties to determine the external system (for a
publish channel message only) and override values for the configured endpoint
properties. The handler then sends the data to the destination specified by the
endpoint with which the handler is associated (Table 2-3 on page 55).
An endpoint represents an application component to which the system delivers
outbound transactions. The system provides the following predefined endpoints.
Chapter 2. Integration components 55
Table 2-3 Predefined endpoints
The configuration of an endpoint involves the definition of the endpoint, the
association of a handler to the endpoint, and setting the handler properties, if
any, for that endpoint.
An endpoint is an instance of a handler with specific properties that the handler
needs in order to connect and send outbound data.
You can use the predefined handlers or create new handlers that enable physical
entities, such as File Transfer Protocol (FTP) servers, for which predefined
handlers do not exist. You must define the handler before you define the
endpoint. You configure endpoints and handlers in the Endpoints application.
To access the Endpoints application (Figure 2-25 on page 56), select Go →
Integration → EndPoint.
Endpoint Handler Description
MXFLATFILE FLATFILE Writes flat files to a
previously specified
directory location
MXIFACETABLE IFACETABLE Writes outbound
transactions to local
interface tables
MXXMLFILE XMLFILE Writes XML files to a
previously specified
directory location
MXCMDLINE CMDLINE Implements the CMDL
handler, takes a command
and an endpoint as input,
and uses the SSH protocol
to securely invoke the
command on the target
system and return the
results
56 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-25 Endpoints interface
Handlers
In this section, we describe the predefined handlers and their required and
optional properties. The system provides the following predefined handler types,
which you can access through the Select Action menu in the Endpoints
application:
򐂰EJB
򐂰FLATFILE
򐂰HTTP
򐂰IFACETABLE
򐂰JMS
򐂰WEBSERVICE
򐂰XMLFILE
򐂰CMDLINE
Chapter 2. Integration components 57
The EJB handler is a Java component that delivers system data (Table 2-4) to an
EJB executing on the local application server or on a remote application server.
Table 2-4 shows the EJB handler’s properties.
Table 2-4 EJB handler properties
Note: If the EJB is on a remote application server, the remote and home
classes of the EJB must be available on the local application server. For more
information, refer to the documentation for your application server.
Property Description
CONTEXTFACTORY This required property specifies a Java
Two Platform, Enterprise Edition (J2EE™)
context. Refer to the documentation for
your application server for the name of the
default context factory.
EJBEXIT Property This optional property is used for
customization. It specifies the fully
qualified name of a custom Java class that
implements the EJBExit interface. If you
do not specify a value for this property, the
system executes the default exit,
DefaultEJBExit, which attempts to resolve
the EJB’s method signature and
parameters.
JNDINAME This required property specifies the name
by which the EJB is registered in the
application server Java Naming and
Directory Interface (JNDI) tree.
METHODNAME This required property specifies the public
business method exposed by the EJB that
is invoked through this handler.
PROVIDERURL This required property specifies the URL
that provides access to the EJB
component.
USERNAME and PASSWORD If access to the EJB requires a user name
and password, these properties specify
those values. The user name must match
the value that was configured during the
definition of Users and Groups in the
application server.
58 Integration Guide for IBM Tivoli Service Request Manager V7.1
The FLATFILE handler converts outbound data from the queue into a flat file
and writes it to a directory whose location is configurable. Flat files contain ASCII
data in the form of rows and columns. Each line of text constitutes one row, and a
separator separates each column in the row.
The FLATFILE handler encodes outbound flat files in the standard UTF-8 format,
and the Data Import mechanism assumes that inbound flat files are encoded in
UTF-8 format.
The FLATFILE handler naming convention is:
򐂰File names have the following format:
externalsystemname_publishchannelname_uniqueidentifier.DAT
where:
–externalsystemname is the identifier of the system (the value of
MAXVARS.MXSYSID).
–publishchannelname is the name of the publish channel.
–uniqueidentifier is a number based on the current system time.
The FLATFILE handler (Table 2-5) has the following properties.
Table 2-5 FLATFILE handler properties
Note: You can only use the FLATFILE handler with Publish Channels, not
Invocation Channels.
Property Description
FLATFILEDIR This required property specifies the
location of the flat file. The location must
already exist on the local machine where
the application server is executing or on a
shared network drive.
FLATFILESEP This required property specifies the
character that separates the columns in
each row.
Chapter 2. Integration components 59
The HTTP handler is a Java component that delivers data (Table 2-6) as an XML
document to a URL using HTTP or HTTPS protocols and evaluates the response
code received from the external system.
The HTTP handler has the following properties.
Table 2-6 HTTP handler properties
Property Description
HTTPEXIT This optional property is used for
customization. It specifies the fully
qualified name of a Java class that
interprets the HTTP response. An external
system might require additional code to
interpret the HTTP response, and this exit
lets users implement the necessary code.
The Java class must be available in the
classpath specified for the application
server or the application enterprise
archive (EAR) file.
URL This optional property specifies a valid
URL to which XML data can be posted. It
is expected that a response is generated
whenever an HTTP POST is performed
upon this URL.
USERNAME and PASSWORD If the URL requests basic authorization,
these properties specify the required
values. The system encodes both values
and passes them to the URL. For more
information about basic authorization for
HTTP, refer to the documentation for your
HTTP server.
CONNECTTIMEOUT This optional property specifies the
connection timeout value in milliseconds.
READTIMEOUT This optional property specifies the read
timeout value in milliseconds.
HTTPMETHOD This optional property specifies the HTTP
method to use. The allowed values are
POST and GET, and the value defaults to
POST if no value is specified.
60 Integration Guide for IBM Tivoli Service Request Manager V7.1
The IFACETABLE handler writes data from an outbound queue to an interface
table in a local or remote database. There are no Java exits (Table 2-7) for this
handler. The IFACETABLE handler has the following properties.
Table 2-7 IFACETABLE handler properties
Property Description
ISREMOTE This required property specifies if
interface tables are available in the local
system database in the system schema or
in a different schema. Its value can be 0
(zero) or 1.
A value of 0 (false) indicates that the
interface tables are available in the local
system database in the system schema.
You do not have to enter any other
handler properties. For the predefined
MAXIFACETABLE handler, the value of
this property is 0.
A value of 1 (true) indicates that the
interface tables are in a remote database.
If so, you must specify the values for all of
the handler properties.
DRIVER This property specifies the JDBC driver to
be used to connect to a remote database
containing the interface tables. This
property applies only when the value of
ISREMOTE is 1.
URL This property specifies the JDBC URL that
indicates the location, port number, and
database name. This property applies
only when the value of ISREMOTE is 1.
For example:
jdbc:db2://mea6:5000/MERLIN
USERNAME and PASSWORD If access to the database instance
requires a user name and password,
these properties specify those values.
These properties apply only when the
value of ISREMOTE is 1.
Chapter 2. Integration components 61
The JMS handler is a Java component that delivers XML data into a messaging
system that has been enabled through JMS. Depending on the messaging model
that you implement, messages are placed in a virtual channel called a queue or
topic.
In the point-to-point messaging model, messages are generated by a sender and
placed in a queue. Only one receiver can obtain the message from the queue. In
the publish-subscribe messaging model, messages are generated by a publisher
and placed in a topic. Multiple subscribers can retrieve the message from the
topic. The messaging system that is discussed in this section represents a queue
or topic that is available in the local application server, a remote application
server, or a remote dedicated queuing system, such as IBM MQSeries®. To use
this handler, all of these messaging systems must be enabled through JMS
(Table 2-8 on page 62).
For more information, refer to the documentation for the application server.
The JMS handler has the following properties.
Note: The messaging system that is discussed in this section is distinct from
the standard internal queues used by the system. The standard internal
queues reside in the local application server where the system is executing.
62 Integration Guide for IBM Tivoli Service Request Manager V7.1
Table 2-8 JMS handler properties
Property Description
CONFACTORYJNDINAME This required property specifies a Java
object that is used to manufacture
connections to a Java Message Server
provider. Before directly connecting to a
queue or topic, the system must first
obtain a reference to a queue or topic
connection factory. Application servers
usually provide a default connection
factory. However, implementing your own
connection factory lets you tune the
resource attributes and properties to suit
your implementation. In this case, use the
following value for this property:
jms/mro/int/qcf/intqcf
DESTINATIONTYPE This required property specifies the JMS
entity (queue or topic) to which the
message is delivered.
DESTJNDINAME This required property specifies the name
by which the JMS queue or topic is
registered in the application server’s Java
Naming and Directory Interface (JNDI)
tree.
CONTEXTFACTORY This required property specifies a J2EE
context. Refer to the documentation for
your application server for the name of the
default context factory.
ISCOMPRESS This required property specifies whether
the message is compressed before being
placed into a queue or topic.
Compression is an optimization
technique that delivers smaller messages
to a queue or topic.
Note: Compressed messages must be
decompressed after receipt. Decompress
the messages by creating the appropriate
JMS receiver or subscriber component
and placing Java decompression logic
within the receiver or subscriber. Use the
standard Java Inflater() class that is part of
the java.util.zip package. The
system-provided compression uses the
standard Java Deflator() class.
Chapter 2. Integration components 63
JMSEXIT This optional property is used for
customization. It specifies the fully
qualified name of a Java class that
extends the JMSExit interface. The Java
class must implement the
getMessageProperties() method that is
defined in the JMSExit interface.
This option lets you change or add header
information in the JMS message. If this
property does not contain a value, the
header attributes for the message are not
changed when the message is delivered
to the external queue or topic.
PROVIDERURL This required property specifies a local or
remote URL where the JMS component
can be accessed. It can be local or
remote.
PROVIDERPASSWORD If the application server controls access to
the JMS resource, these properties
specify the user name and password that
are needed to connect to the resource.
USERNAME and PASSWORD If the application server controls access to
the JMS resource, these properties
specify the user name and password
needed to connect to the resource. The
user name must match the value
configured during the definition of Users
and Groups in the application server.
For more information, refer to the
documentation for your application server.
Property Description
64 Integration Guide for IBM Tivoli Service Request Manager V7.1
The WEBSERVICE handler is a Java component that invokes a specified Web
service with system data as a SOAP request parameter. This handler is a
Dynamic Invocation Interface (DII) using the JAX-RPC API. It supports a
document-literal type Web service.
The Webservice handler has the properties that are listed in Table 2-9.
Table 2-9 WEBSERVICE handler properties
Property Description
ENDPOINTURL This required property specifies a valid
Web service URL on which to invoke the
document-literal style Web service. You
can use the WSEXIT class to override the
endpoint URL just before the Web service
is invoked.
SERVICENAME This optional property specifies the name
of the Web service deployed in the URL. If
you do not provide a value, the system
uses the interface name in the XML. You
can use the WSEXIT class to override the
service name just before the Web service
is invoked.
SOAPACTION This optional property specifies the value
of the SOAPAction HTTP header to be
used while invoking the Web service. If
you do not provide a value, the system
uses the default value (an empty string).
You can use the WSEXIT class to override
the value that is specified in the user
interface just before the Web service is
invoked.
USERNAME and PASSWORD If the specified Web service is secured
(that is, if HTTP basic authentication is
enabled), specify a user name and
password. The system encodes the
password.
WSEXIT This optional property is used for
customization. It specifies the fully
qualified name of a custom Java class that
implements the psdi.iface.router.WSExit
interface.
Chapter 2. Integration components 65
HTTPCONNTIMEOUT This optional property specifies the
connection timeout value in milliseconds.
If nothing is set, the default value is 60000
milliseconds.
HTTPREADTIMEOUT This optional property specifies the read
timeout value in milliseconds. If nothing is
set, the default value is 60000
milliseconds.
CFGXMLPATH This property specifies the path to the
configuration XML file.
MEP This optional property specifies the
message exchange pattern for the Web
service. Valid values are fireandforget,
sendreceive, sendrobust, and null. If you
do not provide a value, the system uses
the default value sendreceive:
򐂰sendreceive - Request/Response
򐂰sendrobust - Request with void or
fault response
򐂰fireandforget - Request only. No
response or fault.
HTTPVERSION This optional property specifies the
version of the HTTP protocol to be used
for the Web service invocation. The valid
values are "HTTP/1.0" and "HTTP/1.1". If
no value is specified, it defaults to
"HTTP/1.1".
Property Description
66 Integration Guide for IBM Tivoli Service Request Manager V7.1
The XMLFILE handler is a Java component that converts data in the outbound
queue into an XML file format and then delivers it to the xmlfiles directory within
the global directory. You define the global directory (Table 2-10) through the
mxe.int.globaldir property in the System Configuration application.
Table 2-10 XMLFILE handler properties
File names have the following format:
externalsystemname_publishchannelname_uniqueidentifier.xml (for publish
channel)
invocationchannelname_uniqueidentifier.xml (for publish channel)
where:
–externalsystemname is the identifier of the system (the value of
MAXVARS.MXSYSID).
–publishchannelname is the name of the publish channel.
–invocationchannelname is the name of the invocation channel.
–uniqueidentifier is a number based on the current system time.
The CMDLINE handler is a handler that takes a command and an endpoint as
input. The CMDLINE uses the SSH protocol to securely invoke the command on
the target system and return the results.
The metaData parameter passed during the invocation of the handler is a map
that contains, among other things, the name of the endpoint that represents the
target system. Passing the endpoint to the Command Handler allows the caller to
Property Description
PRETTYPRINT This required property specifies whether
the handler “pretty prints” the XML file.
The valid values are 0 and 1. A value of 1
indicates for the handler to pretty print the
xml file.
FILEDIR This optional property specifies the folder
location where the handler creates XML
files. If no value is specified, the handler
defaults this property to the value of
<mxe.int.globaldir>/xmlfiles. You define
the global directory through the
mxe.int.globaldir property in the System
Configuration application.
Chapter 2. Integration components 67
target any system at run time, using whatever configuration exists for that
endpoint at the time of invocation.
Table 2-11 shows the CMDLINE handler properties.
Table 2-11 CMDLINE handler properties
The data parameter is a byte array representation of an XML document that
contains tags corresponding to the setup command, the working directory, the
command to invoke, and any substitution parameters.
Table 2-12 on page 68 shows the tags.
Property Description
CMDTIMEOUT Timeout value for command execution
CONNTIMEOUT Timeout value for connection
USERNAME User name for connection
PASSWORD Password for corresponding user name
HOST Host name of target where command is to
be executed
PORTNO Port number of target where command is
to be executed
IGNORESETUPERR Boolean to ignore an error executing the
Setup command
RETRYINTERVAL Time to wait before retrying a command
MAXRETRY Number of attempts to execute a
command before returning an exception
SSHEXIT A Java exit class that can be implemented
to customize processing of the handler
68 Integration Guide for IBM Tivoli Service Request Manager V7.1
Table 2-12 Tags
The return byte array representation of an XML document contains the results of
the command invocation. It contains tags corresponding to the return values:
STDOUT and STDERR.
Table 2-13 on page 69 shows the return value tags.
Tag Description
CLWORKINGDIR A directory to which to change (cd) on the
remote system before the command is
invoked. If this tag is nonexistent or
empty, no directory change is performed.
CLSSETUPCMD A setup command is to be invoked prior to
the main command. This tag is provided
to allow for any environmental setup that
must occur on the remote system before
the main command is issued. If this tag is
nonexistent or empty, no setup command
is issued.
CLCMDPATTERN A string that defines the pattern of the
command to be invoked. The format of
this pattern is similar to that used by the
java.text.MessageFormat class. An
example is “ls -l {0}”, where {0} represents
a parameter that is substituted.
CLSUB0 The value that is to be substituted into
positions marked by {0} in the
CLCMDPATTERN.
CLSUB1 The value that is to be substituted into
positions marked by {1} in the
CLCMDPATTERN.
CLSUBnThe value that is to be substituted into
positions marked by {n} in the
CLCMDPATTERN. In general, there must
be a CLSUBn corresponding to each
substitution position in the
CLCMDPATTERN.
Chapter 2. Integration components 69
Table 2-13 Return value tags
External systems
Any business application that sends data to the system or receives data from the
system is an external system. External systems let you synchronize external data
through an endpoint (location) and internal data through an external source.
You can use the External Systems application to perform the following functions:
򐂰Name the external applications or systems that exchange data with the
Integration Framework
򐂰Specify how the Integration Framework exchanges data with the defined
systems
򐂰Identify the specific Publish Channels and Enterprise Services process
between the Integration Framework and each system
򐂰Create interface tables
To create an external system, you specify an end point, queues, and integration
control values in the external system record. You also can define the properties
on the external system.
The endpoint identifies how and where the Integration Framework exchanges
data with the system:
򐂰The JMS queues that the system uses.
򐂰Whether the external system is ready to begin integration processing.
򐂰The Integration Framework can exchange data with one or more external
systems.
To access the External Systems application (Figure 2-26 on page 70), select
Go → Integration → External Systems.
Tag Description
CLRETURNCODE The return code from the remote
command
CLRESPONSEOUT The data returned by the remote
command in stdout
CLRESPONSEERR The data returned by the remote
command in stderr
70 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-26 External systems interface
Logical Management Operations
Logical Management Operations (LMOs) define an action, such as Get Status or
Deploy Software. LMOs identify actions that integration modules (IMs) support
and for PMPs to request. The LMO acts as an interface between the PMP and
IM; you can design and develop these entities to be independent of each other.
The LMO defines the action and the data, which is required to support that
action. You can install an LMO definition with the installation of an IM. You also
can define an LMO definition using the LMO application. The LMO definition
includes:
򐂰Name: Name of the action
򐂰Invocation Pattern
There are four types of invocation patterns:
– Synchronous: The PMP issues a request, and the IM returns the results of
the operation.
– Asynchronous one-way: The PMP issues a request, and there is no
response.
Chapter 2. Integration components 71
– Asynchronous deferred response: The PMP issues a request, and the IM
returns a token that the PMP can pass as input on another LMO. The PMP
passes the token at a later time to obtain the status of the original action.
– Asynchronous call back: The PMP issues a request, and the IM returns an
optional token that the target uses to report the results of the request. A
call back by the OMP to the PMP, possibly using the IM, can insert or
update a business object using the token.
򐂰Source Business Object: Input object for the LMO
򐂰Response Business Object: Output object for the LMO
򐂰Business Object Attributes: Specific attributes of the objects that are needed
either for input or output and their data types
To access the LMO application (Figure 2-27), select Go → Integration →
Logical Management Operations.
Figure 2-27 LMO interface
Integration modules
You can create integration modules (IMs) to assist PMP processes in
automating actions. You implement actions, such as Deploy Software, using the
Tivoli Provisioning Manager (TPM) OMP. An IM can support multiple LMOs for an
72 Integration Guide for IBM Tivoli Service Request Manager V7.1
OMP. You can configure and view your installed IM definitions in the Integration
Modules application.
IM processing is responsible for converting the LMO into the OMP-specific
interface. If the system returns a response to the IM, it converts the response to
an OMP response. The OMP response then returns data that is defined by the
LMO.
Typically, there is a one-to-one correspondence between an LMO and an OMP
function. However, your single LMO invocation can result in one or more IM
functions being invoked on an OMP.
You can implement an IM through a Java class or an invocation channel. The
underlying IM implementation (Java class or Invocation Channel) is transparent
to the PMP.
The IM definition includes:
򐂰The LMOs supported by the IM
򐂰The OMP products that the IM supports, including specific LMOs supported
for specific IMs
򐂰Optional properties that you can configure as part of an implementation to
control IM behavior
򐂰IM implementation as either a Java class or an invocation channel
To access the Integration Modules application (Figure 2-28 on page 73), select
Go → Integration → Integration Modules.
Chapter 2. Integration components 73
Figure 2-28 Integration modules interface
Launch in Context
In certain cases, your PMP integration to an OMP might not use an automated
solution through an IM. Instead, your integration can use an assisted approach
through a Launch in Context (LIC). Using an assisted approach lets you
navigate from a PMP application UI to an application UI of the OMP. The context
represents the data that you pass from the PMP, such as the software identifier
and the CI for which the software deployment applies.
A LIC requires:
򐂰Configuration of a PMP application to have a UI control that is tied to a
registered launch entry (push button or Select Action menu items)
򐂰A proper security assigned to it (limit users’ and user groups’ access to the
control)
򐂰Registered launch entries that are configured to the applicable OMP
applications
Note: Although this discussion is specific to OMP launches, LIC capabilities
can apply to any external application launch.
74 Integration Guide for IBM Tivoli Service Request Manager V7.1
Launch entry definitions include:
򐂰The OMP product that the launch can support
򐂰The URL of the OMP product application
򐂰Whether the launch opens a new browser session or uses the existing
window
򐂰The business objects to which the launch entry is specific (optional)
򐂰The classifications supported by the launch entry
The LIC provides additional capabilities:
򐂰The URL can contain substitution variables that use data from the business
object that you view in the application. For example, you can substitute a CI
number into the URL string. Your substitution can take place only if the OMP
application URL supports your substitution value. You can use this feature
when you launch into any application, not just OMPs.
򐂰Specific to OMP integration, you can substitute a host name instance from the
registered OMP data within the system.
򐂰Specific to OMP integration for a CI, you can retrieve the source token of the
CI for the specific OMP. The source token is the CI identifier that the OMP
product understands. If managed by multiple OMPs, a CI might have multiple
source tokens.
To access the Launch in Context application (Figure 2-29 on page 75), select
Go → Integration → Launch in Context.
Note: A launch entry might support a single or multiple business objects.
Note: For business objects that support classifications, this requirement
can limit your URL access to the data that contains the same classification
that you configured on the launch entry. For example, a launch entry that
has a classification value of “Server” is available to you in the CI
application if the CI that you view has a classification value of “Server.”
Chapter 2. Integration components 75
Figure 2-29 Launch in Context interface
Message tracking
In this section, we discuss how the Integration Framework tracks messages while
processing publish channels (outbound messages) and enterprise services
(inbound messages) and how system administrators work with the displayed
messages. It contains the following subsections:
򐂰Message details
򐂰Message tracking configuration
򐂰Message statuses
򐂰Message events
Message details
The Message Tracking application tracks and displays the processing history of
queue-based inbound (Enterprise Services) and queue-based outbound (Publish
Channels) messages.
The Message Tracking application works with the Message Reprocessing
application. Through the Message Tracking application, you can determine which
messages are flagged with an error. You then can select a specific failed
message and get redirected to the Message Reprocessing application to take
appropriate action to correct erroneous data.
76 Integration Guide for IBM Tivoli Service Request Manager V7.1
When you enable message tracking, the Integration Framework writes all
processed messages to the MAXINTMSGTRK table. The system assigns a
status to each message, which represents its current position in the Integration
Framework queue-based processing cycle. The system also displays individual
message events in the Message Details table window.
Table 2-14 shows the values that are assigned to the noted attributes based on
the originating enterprise service or publish channel.
Table 2-14 Predefined attributes
Table 2-15 shows the values that are assigned to the noted attributes at the time
that the transaction record is created.
Table 2-15 Assigned attributes
Attribute Description
Integration Mode Name of the integration mode that is used
in processing the message. For inbound
messages, the system assigns a MXJMS
default value. For outbound messages,
the system assigns the name of the
endpoint used in processing the message.
Operation Operation value that determines the
processing operation that the system
applies to the message (publish).
System External system value.
Integration Component Name of enterprise service or publish
channel.
Adapter Adapter name.
Queue Name Name of queue that is used by the
Integration Framework to process the
message.
Attribute Description
Received Datetime The date and time that the message is
received in the queue
External Message ID Unique message identifier that is assigned
by an external application
Search ID Unique message identifier that the
Integration Framework assigns
Chapter 2. Integration components 77
Table 2-16 shows the values that are assigned to the attributes that are dynamic
and the changes based on the transaction events.
Table 2-16 Dynamic attributes
Message tracking configuration
You can maintain a record of processing actions that are associated with publish
channels or enterprise services. The Message Tracking action in the Publish
Channels and Enterprise Services applications lets you track transactions and
perform the following functions:
򐂰Enable or disable transaction tracking
򐂰Store transaction messages on the application file server
򐂰Identify data that is used by the Message Tracking application search function
򐂰Identify transactions by a unique ID value through an XPATH expression
򐂰Identify XPATH expressions to let you search for a message
For the enable or disable transaction tracking function, you can maintain a record
of processing actions that are associated with an enterprise service or a publish
channel. To do so, select the Enable Message Tracking? check box in the
Message Tracking dialog box. You access the Message Tracking dialog box from
the Select Action menu in the Publish Channels and Enterprise Services
applications.
In the Message Tracking application, you can use the External Message ID
attribute to locate specific messages. In order to do so, an XPATH expression
must be entered in the External Message ID field in the Message Tracking dialog
box. You can set this value in the Publish Channels and Enterprise Services
applications. The syntax that you use to identify the node values must be a fully
qualified XPATH expression.
Attribute Description
Current status Most current processing status that is
associated with the tracked message
Status The status that is associated with the
individual message event in the
transaction history
Status date The status date that is associated with the
individual message event in the
transaction history
Error The error message that is associated with
the individual error message event in the
transaction history
78 Integration Guide for IBM Tivoli Service Request Manager V7.1
The Message Tracking action allows you to use an XPATH expression to specify
the location of your message identifier in the inbound XML. The Integration
Framework assigns an internal message identifier to guarantee uniqueness in
the messages that are being tracked. The system stores the external message
identifier as the EXTMSGIDFIELDDATA attribute in the MAXINTMSGTRK table.
In the event of receiving a multi-noun inbound message, the Integration
Framework uses the enterprise service External Message ID XPATH as the
identifier of the message. If the path expression points to an element included in
each one of the nouns in the inbound message, the Integration Framework
creates a multi-noun, comma-separated list of external identifiers.
Through the Advanced Search dialog box in the Message Tracking application,
you can use the Search ID attribute to locate specific messages. In order to do
so, an XPATH expression must be entered in the Search ID field in the Message
Tracking dialog box. You can set this value in the Publish Channels and
Enterprise Services applications. The syntax that you use to identify the node
values must be a fully qualified XPATH expression.
The Message Tracking action allows you to use an XPATH expression to specify
the location of an identifier in the inbound XML transaction. The XPATH
expression enables you to perform efficient record searches. The system stores
the search identifier in the SEARCHFIELDDATA field in the MAXINTMSGTRK
table.
In the event of receiving a multi-noun inbound message, the Integration
Framework uses the enterprise service Search ID XPATH as the search identifier
of the message. If the path expression points to an element included in each one
of the nouns in the inbound message, the Integration Framework creates a
multi-noun, comma-separated list of search identifiers.
You can store the original message that you receive from an enterprise service or
a publish channel definition. To store messages, select the Store Message?
check box in the Message Tracking dialog box. You access the Message Tracking
dialog box in the Select Action menu in the Publish Channels and Enterprise
Services applications.
The system stores files in the msgdata folder in the system global directory. You
define the global directory location in the mxe.int.globaldir system property, in the
System Properties application.
The naming convention of the stored messages is:
ExternalSystemName_IntegrationComponent_UniqueId.xml.
Chapter 2. Integration components 79
Message status
Every inbound and outbound queue-based message, which is registered in the
Message Tracking application, has a status value that indicates its position in the
transaction processing cycle (Table 2-17). The message tracking designated
status indicates whether the message has been successfully received or
processed. The message tracking designated status also indicates whether the
message has been deleted or flagged with errors.
Table 2-17 Inbound message status
Table 2-18 shows the outbound message status.
Table 2-18 Outbound message status
Message events
The Message Tracking application tracks and displays inbound and outbound
queue-based transaction processing events. Transaction processing events
trigger the system to update the MAXINTMSGTRK table. The system updates
the following message table attributes, according to event type:
򐂰STATUS
򐂰STATUDATETIME
򐂰ERRORMSGR
Status Description
Error Message processing failed due to
validation issues.
Deleted Message is deleted from the queue.
Processed Message is successfully processed.
Received Message is successfully written to the
inbound queue.
Status Description
Error Message processing failed due to
validation issues.
Deleted Message is deleted from the queue.
Processed Message is successfully processed.
Received Message is successfully written to the
inbound queue.
80 Integration Guide for IBM Tivoli Service Request Manager V7.1
Tracking inbound and outbound events
The following inbound and outbound events cause the system to update the
MAXINTMSGTRK table:
򐂰Message Written to Queue: The system creates a record in the message
tracking table when the Integration Framework first writes the message to the
queue. When the Integration Framework successfully writes the message to
the queue, the system sets the message record status to RECEIVED.
If the Integration Framework encounters an error when writing an inbound
message to the queue, it replies to the process caller with a message
detailing the cause of failure.
򐂰Error in Message Processing: The system updates the existing record in the
message tracking table in the event of a processing error. When the
Integration Framework encounters a processing error, the system updates the
message record status to ERROR. If you retry your message and a
processing error is again identified, the system maintains the ERROR
message status.
򐂰End of Queue Processing: The following transaction processing events cause
the system to update the existing record:
– The system successfully completes the message processing and updates
the message record status to PROCESSED. Because the processing
cycle is complete, the system no longer applies further updates to the
message tracking table.
– If you delete the message from the queue, the system sets the message
record status to DELETED. The system no longer applies further updates
to the message tracking table.
To access the Message Tracking application (Figure 2-30 on page 81), select
Go → Integration → Message Tracking.
Chapter 2. Integration components 81
Figure 2-30 Message Tracking interface
Message Reprocessing
The Message Reprocessing application allows you to manage and view
integration transaction messages that have been flagged with an error. Through
the Message Reprocessing application, you can view the error Extensible
Markup Language (XML) file without needing to gain access to the integration
server error files.
The Message Reprocessing application works with the Message Tracking
application and displays queue-based messages that failed any Integration
Framework process validation. When you enable message tracking in either the
Publish Channels or Enterprise Services applications, you can determine which
messages are flagged with an error in the Message Tracking application. You
then can take appropriate action to correct erroneous data in the Message
Reprocessing application.
If you have not enabled message tracking, you can go directly to the Message
Reprocessing application to check for transaction errors.
You can manage messages in the following ways:
򐂰Change the message statuses to stop message processing or to reprocess a
message
82 Integration Guide for IBM Tivoli Service Request Manager V7.1
򐂰Correct, process, save, or cancel the error XML file
򐂰Delete the message from the database
To change the message status, you use the Change Status action in the
Message Reprocessing application. The system designates a status to each
message to indicate whether they are ready for processing.
Messages can have the following statuses (Table 2-19).
Table 2-19 Message statuses
The RETRY status is the default status for messages that have been flagged with
an error. Until you correct the processing problem, the system continues to
reprocess and encounter errors with the applicable transaction.
You can halt message reprocessing by changing the message status to HOLD.
Assigning a hold status prevents the system from automatically reprocessing the
flagged message and from updating the system database tables.
For error correction, you use the Message Details dialog box in the Message
Reprocessing application to view the message details and to manually change
the contents of a message in error. You can choose to process or save your XML
changes. You also can choose to cancel the error XML file changes.
For error details, when you select the Message Details icon for each listed error,
the Message Details dialog box opens and displays the error XML file.
Example 2-3 on page 83 is an example of an error XML file that is displayed in
the Message Details dialog box. It contains the following information:
򐂰The error message in the ERRORMESSAGE element
򐂰The message from the queue in the ER element
򐂰The object structure XML in the IR element
Status Description
Retry Indicates that the message is ready to be
reprocessed by the system
Hold Indicates that the message is not ready to
be reprocessed by the system
Note: You only can edit a message if it is in a HOLD status. If the message
has a RETRY status, the error data content is read-only.
Chapter 2. Integration components 83
The IR element is present only for inbound transactions, and only if enterprise
service processing and user exit processing (Example 2-3) are successfully
applied to the message. It represents the object structure that was created during
enterprise service or user exit processing (or both).
Example 2-3 Example of an error xml file
<?xml version="1.0" encoding="UTF-8"?>
<ERROR>
<ERRORMESSAGE>Error occurred while processing PO (Object
Structure number 1). Error is:[system:unknownerror] An unknown
error has occurred. Contact your system administrator for
assistance. null</ERRORMESSAGE>
<ER> <SyncMXPO xmlns="http://www.ibm.com/maximo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
creationDateTime="2007-05-22T14:04:03-04:00"
transLanguage="EN" baseLanguage="EN"
messageID="11798570432187483" maximoVersion="7 1 Harrier 038a
HARRIER-042" event="1" messageid="11798570432652428">
<MXPOSet>
<PO action="Update">
.
.
.
</PO>
</MXPOSet>
</SyncMXPO>
</ER>
<IR>
<SyncMXPO xmlns="http://www.ibm.com/maximo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
creationDateTime="2007-05-22T14:04:03-04:00"
transLanguage="EN" baseLanguage="EN"
messageID="11798570432187483" maximoVersion="7 1 Harrier 038a
HARRIER-042" event="1" messageid="11798570432652428">
<MXPOSet>
<PO action="Update">
.
.
.
</PO>
</MXPOSet>
</SyncMXPO>
</IR>
</ERROR>
84 Integration Guide for IBM Tivoli Service Request Manager V7.1
To process a message, when you have completed your error XML changes in the
Error Data window, you can choose to resubmit the message by selecting the
Process option. The Message Details dialog box closes, and the application
starts reprocessing the message.
If the system successfully processes the message, it performs the following
actions:
򐂰Deletes the error file
򐂰Deletes the record in the MAXINTERRORMSG table
򐂰Updates the DELETEFLAG, CHANGEBY, and CHANGEDATE attributes in
the MAXINTERROR table
The application refreshes the result set and omits the successful message listing
on the main tab of the Message Reprocessing application.
If the system does not successfully process the message, it performs the
following actions:
򐂰The MAXINTERRORMSG table is updated with the new error.
򐂰Updates the CHANGEBY and CHANGEDATE attributes in the
MAXINTERROR table.
򐂰Opens an “Error encountered in processing transaction” error.
The application refreshes the result set and displays the new error for the
unsuccessful message listing on the main tab of the Message Reprocessing
application.
Save the message
When you have completed your error XML changes in the Error Data window,
you can choose to save the message by selecting the Save option. The Message
Details dialog box closes, and the application saves your XML changes.
The system saves the message and updates the CHANGEBY and
CHANGEDATE attributes in the MAXINTERROR table.
Note: The ER element in an error file that was created for inbound messages
from interface tables or flat files has a flat (non-hierarchical) structure.
Only the <ER> element can be edited; the <IR> element is provided for
information only, and any change to the <IR> is ignored when the message is
reprocessed.
Chapter 2. Integration components 85
Cancel the message
When you have edited your error XML file, you can choose not to proceed with
the message changes by selecting the Cancel option. The Message Details
dialog box closes, and the application cancels your XML changes.
When the system cancels the message, it does not perform any system
database updates. The error XML file remains in its original state.
Message deletion
You use the Delete Message action in the Message Reprocessing application to
delete a message from a queue, if necessary.
Critical errors
Critical errors are transaction processing exceptions that the Integration
Framework error correction process cannot retry. Transaction processing
exceptions can occur when invalid data, such as a special character, is in the
XML file. When the Integration Framework identifies a critical error, ER and IR
sections in the corresponding (Figure 2-31 on page 86) error file are not present.
To correct the critical error, remove the invalid data from the error XML. You can
see invalid data associated with a critical error in the main tab of the Message
Reprocessing application.
You can access the Message Reprocessing application by selecting Go →
Integration → Message Reprocessing.
Important: After you delete a message, the system cannot reprocess it. When
the system deletes the message, it deletes the record from the
MAXINTERRORMSG and MAXINTERROR tables.
The application refreshes the result set and omits the deleted message listing
on the main tab of the Message Reprocessing application.
86 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-31 Message Reprocessing interface
2.4.4 Integration enhancements and changes from V6.x to V7.1
In this section, we provide information about enhancements and changes from
MEA V6.x and Integration Framework MEA V7.1.
Changes to existing Version 6 MEA
The following changes have been made to the existing Version 6 MEA:
Integration Components Integration components application changed to
Object Structures
Integration Point Integration Point is removed. Now, it is collapsed into
the Object Structure.
Interfaces The interfaces are split into outbound and inbound:
The outbound interfaces are Publish Channels and
the Inbound interfaces are Enterprise Services.
Integration Framework V7.1 (MEA) new features
Next, we list the new features of Integration Framework 7.1.
Chapter 2. Integration components 87
Invocation Channels
Integration Framework has been improved to support the synchronous invocation
of an external service or application. The system also returns the response of the
service back to the caller for subsequent processing (Figure 2-32). It can be
initiated by the UI button, Escalation, or Work Flow.
Invocation channel provides the framework to:
򐂰Transform Object Structure to service input.
򐂰Associate an endpoint.
򐂰Transform service response to Object Structure.
Figure 2-32 Invocation Channel
For detailed information about invocation channels, refer to Invocation channels
on page 47.
Services
External applications can use Web services to query or to send transactions to
the Integration Framework. The Integration Framework provides three types of
services that you can choose to deploy as a Web service:
򐂰Object Structure Service:
– New feature in V7.1 (Figure 2-33 on page 88).
– These services rely entirely on Object Structure definitions and do not
utilize the exit processing available to Enterprise Services.
– Requires less configuration because there is no Enterprise Service or
External System required.
88 Integration Guide for IBM Tivoli Service Request Manager V7.1
– Each Object Structure supports five operations (create, update, delete,
sync, and query).
– The query operation provides object structure as the response content.
– The create operation provides the key of the top Maximo Business Object
(MBO) of the object structure as the response content.
Figure 2-33 Object Structure Service
򐂰Enterprise Service:
– Replaces the 6.x inbound interfaces (Figure 2-34 on page 89).
– Supports processing through the queue (async) or by bypassing the
queue (sync).
– The exit processing layer allows for mapping the external XML to the
object structure XML for both the invocation and the response.
– Enterprise Services are defined for a single operation.
– The query operation provides object structure as the response content.
– The create operation provides the key of the top MBO of the object
structure as the response content.
Chapter 2. Integration components 89
Figure 2-34 Enterprise Services
򐂰Standard Service:
– New in V7.1 (Figure 2-35 on page 90).
– Created from annotated methods (such as changeStatus) in an MBO
within an application service.
– The inputs and outputs (if any) for these services are tied to the input and
output parameters of the method.
90 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-35 Standard Services
All services are accessible via HTTP, HTTPS, EJB, and Web Service
(Figure 2-36).
Figure 2-36 Services
For detailed information about services, refer to the Web Services Library on
page 52.
Chapter 2. Integration components 91
Web Services Library
Web Services Library (Figure 2-37) is a new application in V7.1 to support the
management and deployment of Web services for all three service classes.
Figure 2-37 Web Services Library application
Figure 2-38 illustrates the Web Services Library architecture.
Figure 2-38 Web Services Library architecture
92 Integration Guide for IBM Tivoli Service Request Manager V7.1
PMP and OMP integration
OMPs are external products (to the system) that provide services for CIs, such
as a server that runs applications. PMPs are system applications and processes
that use OMPs to automate IT-related services. These services include software
deployment on CIs.
OMP integration supports:
򐂰Assisted and automated approaches for PMPs, such as Change and
Release, to integrate with OMPs, such as Tivoli Provisioning Manager (TPM).
򐂰Maximo is fed updates of CIs, OMPs, and their relationships through the IMIC
adapter from TADDM (discovery data).
򐂰Integration Framework supports the installation and configuration of
Integration Modules (IMs) and LMO.
򐂰The PMP processes (UI, workflow, and escalations) invoke IMs to perform
actions (LMOs) on CIs through OMPs. For example: Release PMPs invoke an
IM to distribute software (LMO) on a server (CI) using TPM (OMP).
򐂰The PMP application can also launch (UI) to an OMP application to support
integration in an “assisted” model.
For detailed information about OPM integration, refer to Integration Framework
for OMP integration on page 41.
Message tracking and reprocessing
Integration Framework provides two new applications to manage messages. The
Message Tracking application tracks messages while processing publish
channels (outbound messages) and enterprise services (inbound messages)
and how system administrators work with the displayed messages. Message
Reprocessing application allows you to manage and view integration transaction
messages that have been flagged with an error. Through the Message
Reprocessing application, you can view the error XML file without needing to
gain access to the integration server error files.
For detailed information about the Message Tracking application, refer to
Message tracking on page 75 and Message Reprocessing on page 81 for
detailed information about the Message Reprocessing application.
Additional content
Addition content available in Integration Framework V7.1:
򐂰The number of object structures that ship is increasing from approximately 40
(in Version 6.x) to over 55 (in Version 7.1).
򐂰There is a new Command Line (SSH) handler.
Chapter 2. Integration components 93
򐂰Predefined Launch Entries for TADDM from the CI applications ship.
򐂰The Object Group annotates the changeStatus method across multiple MBOs
and several additional methods.
2.4.5 Sample scenario
In this section, we introduce a sample scenario that shows how to expose a Web
service in Tivoli SRM V7.1 to have incidents created into SRM. We describe in
detail all of the necessary components.
Prerequisites
In order to create the Web service, you need the following prerequisites in your
environment:
1. Tivoli SRM V7.1 must be installed.
2. JMS queues must be created and configured. The installation of Tivoli
Process Automation Platform (TPAP) creates and configures all of the default
JMS queues automatically for you.
3. SOAP test client. This client is required to interact with the Web service
created in this section.
Configuring integration components
In order to set up your Web services, configure:
1. Enabling the cron task for the sequential queues
2. Object Structures
3. Enterprise Services
4. External system
5. Creating and exposing the Web Service
6. View WSDL
7. XML file
Enabling the cron task for the sequential queues
Activate the applicable instances of the cron task (SEQQIN and SEQQOUT) or
the inbound and outbound messages remain unprocessed in the queues. You
access the JMSQSEQCONSUMER cron task at the Cron Task Setup
application. Click Go To → System Configuration → Platform
Configuration → Cron Task Setup. Search for JMSQSEQCONSUMER and activate
both SEQQIN and SEQQOUT as shown in Figure 2-39 on page 94.
94 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-39 Enabling JMS queues
Object Structures
Create an object structure that consists of one business object that makes up the
content of the XML message.
You can access the Object Structure application by selecting Go →
Integration → Object Structures.
After launching the Object Structures application, follow these steps:
1. Click New. Figure 2-40 on page 95 appears.
Chapter 2. Integration components 95
Figure 2-40 Object Structure application
2. In the object structure field, type OBJSTR_SAMPLE.
3. Select INTEGRATION from the component field.
4. Click New Row in the Source Objects subtab. Select INCIDENT in the Object
field.
5. Accept all defaults and click Save.
Enterprise Services
After creating the object structure, create the enterprise service for querying
system data and importing data into the system from an external system.
Access the Enterprise Services application by selecting Go → Integration →
Enterprise Services.
After launching the Enterprise Services application, follow these steps:
1. Click New. Figure 2-41 on page 96 appears.
96 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-41 Creating a new Enterprise Services record
2. In the Enterprise Services field, type ENTSER_SAMPLE.
3. Select Create in the Operation field.
4. In the Object Structure field, select OBJSTR_SAMPLE. This is the object that
you created before.
5. Accept all defaults and click Save.
External system
Create an external system to receive data from an external business application.
Access the External Systems application by selecting Go → Integration →
External Systems.
After launching the External System application, follow these steps:
1. Click New.
2. Type EXTSYS_SAMPLE in the System field.
3. In the Enterprise Services tab, click Select Service and select the enterprise
services that we created in the step before. Search for ENTSER_SAMPLE
and select it.
4. Click OK.
Chapter 2. Integration components 97
5. Enable the enterprise services by clicking the Enabled? check box.
6. Enable the external system by clicking the Enabled? check box.
Creating and exposing a Web service
In this section, we create a Web service from an enterprise service and expose
it. As soon as we expose the Web service, a external application can call this
service, post an XML, and create a new incident.
You can access the Web Services Library application by selecting Go →
Integration → Web Services Library. Follow these steps:
1. Create a new Web service by clicking Select Action → Create Web
Service → Create WS from Enterprise Service as shown in Figure 2-42.
Figure 2-42 Creating a Web service
2. Select the enterprise service called EXTSYS_SAMPLE_ENTSER_SAMPLE
and click Create as shown in Figure 2-43 on page 98.
98 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-43 Selecting the enterprise service
3. The Web Service is now created. The next step is deploying the Web service
by selecting the EXTSYS_SAMPLE_ENTSER_SAMPLE record.
4. Click Select Action → Deploy Web Service. A system message appears as
shown in Figure 2-44 on page 99.
Chapter 2. Integration components 99
Figure 2-44 Web Service deployed
5. Click OK. The Web service EXTSYS_SAMPLE_ENTSER_SAMPLE is now
created and deployed.
View WSDL
In order to view the wsdl file, open a browser and type the following URL:
http://host/meaweb/wsdl/EXTSYS_SAMPLE_ENTSER_SAMPLE.wsdl
Figure 2-45 on page 100 shows the wsdl definition.
100 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 2-45 Wsdl definition
XML file
At this point, the Web service is created and deployed.
You can now test the Web service by using an external application to interact with
the Web service and post an XML file.
Example 2-4 shows two XML files for test purposes. One file is for request and
another file is for response.
Example 2-4 Request xml
<?xml version="1.0" encoding="UTF-8"?>
<CreateOBJSTR_SAMPLE xmlns="http://www.ibm.com/maximo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
creationDateTime="2008-03-04T14:00:57-08:00" transLanguage="EN"
baseLanguage="EN" messageID="12046680576872200" maximoVersion="7 1 112
V7110-450" event="1">
<OBJSTR_SAMPLE>
<INCIDENT action="Add">
<ACTLABCOST>0.0</ACTLABCOST>
<ACTLABHRS>0.0</ACTLABHRS>
<ACTUALCONTACTDATE xsi:nil="true" />
Chapter 2. Integration components 101
<ACTUALFINISH xsi:nil="true" />
<ACTUALSTART xsi:nil="true" />
<AFFECTEDDATE>2008-03-04T14:00:00-08:00</AFFECTEDDATE>
<AFFECTEDEMAIL />
<AFFECTEDPERSON>MAXADMIN</AFFECTEDPERSON>
<AFFECTEDPHONE />
<ASSETNUM />
<ASSETORGID />
<ASSETSITEID />
<CHANGEBY>MAXADMIN</CHANGEBY>
<CHANGEDATE>2008-03-04T14:00:37-08:00</CHANGEDATE>
<CINUM />
<CLASS maxvalue="INCIDENT">INCIDENT</CLASS>
<CLASSIFICATIONID />
<CLASSSTRUCTUREID />
<COMMODITY />
<COMMODITYGROUP />
<CREATEDBY>MAXADMIN</CREATEDBY>
<CREATEWOMULTI maxvalue="MULTI">MULTI</CREATEWOMULTI>
<CREATIONDATE>2008-03-04T14:00:38-08:00</CREATIONDATE>
<DESCRIPTION />
<DESCSRVID />
<EXTERNALRECID />
<EXTERNALSYSTEM />
<EXTERNALSYSTEM_TICKETID />
<FAILURECODE />
<FR1CODE />
<FR2CODE />
<GLACCOUNT />
<GLOBALTICKETCLASS />
<GLOBALTICKETID />
<HASACTIVITY>0</HASACTIVITY>
<HISTORYFLAG>0</HISTORYFLAG>
<IMPACT xsi:nil="true" />
<INDICATEDPRIORITY xsi:nil="true" />
<INHERITSTATUS>0</INHERITSTATUS>
<INTERNALPRIORITY xsi:nil="true" />
<ISGLOBAL>0</ISGLOBAL>
<ISKNOWNERROR>0</ISKNOWNERROR>
<ISKNOWNERRORDATE xsi:nil="true" />
<LOCATION />
<ORGID />
<ORIGRECORDCLASS />
<ORIGRECORDID />
<ORIGRECORGID />
102 Integration Guide for IBM Tivoli Service Request Manager V7.1
<ORIGRECSITEID />
<OWNER />
<OWNERGROUP />
<PMCOMRESOLUTION />
<PMCOMTYPE />
<PROBLEMCODE />
<RELATEDTOGLOBAL>0</RELATEDTOGLOBAL>
<REPORTDATE>2008-03-04T14:00:37-08:00</REPORTDATE>
<REPORTEDBY>MAXADMIN</REPORTEDBY>
<REPORTEDEMAIL />
<REPORTEDPHONE />
<REPORTEDPRIORITY xsi:nil="true" />
<SITEID />
<SITEVISIT>0</SITEVISIT>
<SOLUTION />
<SOURCE />
<STATUS maxvalue="NEW">NEW</STATUS>
<STATUSDATE>2008-03-04T14:00:37-08:00</STATUSDATE>
<SUPERVISOR />
<TARGETCONTACTDATE xsi:nil="true" />
<TARGETDESC />
<TARGETFINISH xsi:nil="true" />
<TARGETSTART xsi:nil="true" />
<TEMPLATE>0</TEMPLATE>
<TEMPLATEID />
<TICKETID>1008</TICKETID>
<TICKETUID>9</TICKETUID>
<URGENCY xsi:nil="true" />
<VENDOR />
</INCIDENT>
</OBJSTR_SAMPLE>
</CreateOBJSTR_SAMPLE>
Refer to Example 2-5 for the response XML file.
Example 2-5 Response xml
<?xml version="1.0" encoding="UTF-8"?>
<CreateOBJSTR_SAMPLEResponse xmlns="http://www.ibm.com/maximo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
creationDateTime="2008-03-05T17:50:49-08:00" transLanguage="EN"
baseLanguage="EN" messageID="12047682499375535">
<INCIDENTMboKeySet>
<INCIDENT>
<CLASS maxvalue="INCIDENT">INCIDENT</CLASS>
Chapter 2. Integration components 103
<TICKETID>1008</TICKETID>
</INCIDENT>
</INCIDENTMboKeySet>
</CreateOBJSTR_SAMPLEResponse>
104 Integration Guide for IBM Tivoli Service Request Manager V7.1
© Copyright IBM Corp. 2008. All rights reserved. 105
Chapter 3. Event management
integration
This chapter discusses event management integration products, such as Tivoli
Enterprise Console (TEC) and Tivoli Netcool/Omnibus, which are available
within the Tivoli portfolio.
This chapter discusses the following topics:
򐂰Event management on page 106
򐂰IBM TEC integration on page 106
򐂰IBM Tivoli Netcool/Omnibus integration (preview) on page 130
3
106 Integration Guide for IBM Tivoli Service Request Manager V7.1
3.1 Event management
The way that an organization handles an event is known as event management.
It can include the organization’s objectives for managing events, assigned roles
and responsibilities, ownership of tools and processes, critical success factors,
standards, and event-handling procedures. The link between the various
departments within the organization that are required to handle events and the
flow of this information among them is the focus of event management. Tools are
mentioned in reference to how they fit into the flow of event information through
the organization and to the standards that are applied to the flow.
Events are used to report problems, and event management is sometimes
considered a sub-discipline of problem management. However, it can really be
considered a discipline of its own, because it interfaces directly with several other
systems management disciplines. For example, system upgrades and new
installations can result in new event types that must be handled. Maintaining
systems both through regularly scheduled and emergency maintenance can
result in temporary outages that trigger events. There is clearly a relationship
between event management and change management.
In small organizations, it is possible to handle events through informal means.
However, as organizations’ IT support staffs and the number of resources that
they manage grow, it becomes crucial to have a formal documented event
management process. Formalizing the process ensures consistent responses to
events, eliminates duplication of effort, and simplifies the configuration and
maintenance of tools that are used for event management.
Based on the business process, most of the events generated in the environment
become an incident in the Information Technology Infrastructure Library (ITIL)
process, which is maintained and supported by the Tivoli Service Request
Manager (SRM) application.
3.2 IBM TEC integration
The Tivoli Enterprise Console (TEC) integration for Service Desk provides
bidirectional communication between TEC and the Service Desk component of
Tivoli SRM V7.1. TEC is an event management software system that collects,
consolidates, and correlates events from a variety of event sources across the
managed network. It initiates automated corrective action in order to reduce the
number of events that require human intervention to a manageable size.
Chapter 3. Event management integration 107
Events are consolidated or correlated by filtering redundant or low priority
events, discarding duplicate events, discarding secondary events (events
caused by other events) where appropriate, automatically closing a problem
event when the related recovery event occurs, and other techniques. Rules
define how events are processed.
TEC events are assigned a severity level that indicates the seriousness of the
underlying problem. The default classifications, in order of increasing severity,
are: UNKNOWN, HARMLESS, WARNING, MINOR, CRITICAL, and FATAL.
The Service Desk applications most directly related to TEC integration are the
following ticket applications:
򐂰Use the Service Requests application to create records of client calls or e-mail
messages that request service.
򐂰Use the Incidents application to create records of incidents that interrupt
service or reduce the quality of a service.
򐂰Use the Problems application to create records of the underlying problems
that cause incidents and service requests.
Service Request, Incident, and Problem records are referred to as ticket records
or ticket types. Ticket records can be created by a service desk agent and
automatically use data from e-mail messages, system monitoring tools, or
external software applications, such as IBM TEC. After a ticket record is created,
a person or group can take ownership of the ticket and see the issue through to
resolution.
After you install and configure TEC integration for Service Desk, TEC events that
meet defined criteria are used as triggers to automatically open ticket records in
the Service Desk ticket applications. For example, by default, FATAL events
trigger the opening of an Incident ticket, and CRITICAL events trigger a Service
Request ticket. You can change the event criteria for opening Service Desk
tickets and the types of tickets that are opened in response to events.
After a ticket is opened in Service Desk, subsequent updates to the ticket
automatically result in corresponding updates to the originating TEC event and
all correlated events, provided that the events still exist in the TEC event cache.
When the ticket is closed, all TEC events associated with the ticket are also
closed.
108 Integration Guide for IBM Tivoli Service Request Manager V7.1
The integration of TEC with Service Desk addresses an IT management need
that Service Desk alone is not designed to meet. While a service desk agent
might become aware of system outages and access failures reported by
employees or customers, the Service Desk software is not intended as a solution
for isolating and resolving performance and availability problems across
computer networks. TEC, however, is specifically designed to help ensure the
availability of IT resources. The integration of TEC with Service Desk enables
service desk agents to become aware of problems that need attention. The
automated opening of Service Desk tickets in response to events accelerates the
resolution process, reducing mean time to repair, and in certain cases, solving a
problem before it is reported by customers or becomes worse.
3.2.1 Prerequisites
The prerequisite software for TEC integration for Service Desk includes:
򐂰Service Desk component of Tivoli SRM V7.1 on Windows
򐂰TEC V3.9 or higher on Windows, Linux, or Unix
3.2.2 Architecture
When you install TEC integration for Service Desk software on a TEC server, the
installer creates a rule base that defines the default event criteria for opening
Service Desk tickets. You can change the default criteria by modifying the rule
base.
Figure 3-1 on page 109 shows the components that take part in the integration.
Note: IBM WebSphere V6.0.2.17 is required for IBM Tivoli SRM and can
be installed on Windows, Linux, or UNIX. However, Tivoli SRM must be
installed on the Windows platform for this integration.
Chapter 3. Event management integration 109
Figure 3-1 The components that take part in the integration
Moving from left to right in Figure 3-1:
1. After a TEC server receives an event from an event source, it evaluates the
event according to the rule base. If the event meets the established criteria,
the TEC server forwards the event information to the Tivoli Directory
Integrator (TDI) server.
2. TDI serves as the interface between TEC and Service Desk. When the TDI
server receives the event information, it evaluates the event to determine the
type of Service Desk ticket to open and evaluates other ticket attributes based
on default settings or based on mappings that you configure using the TDI
Configuration Editor. This information is passed on to the SRM server,
specifically to the MEA component.
3. The MEA provides the interface for communication between SRM and
external applications, in this case, the TDI server.
4. When the ticket description is updated or the ticket is closed, the TEC event
or events that are associated with the ticket are updated.
5. The updated ticket information is communicated through the MEA to the
non-TME logfile adapter on the TDI server.
The non-TME logfile adapter is a TEC product component that you install on
the TDI server. The logfile adapter is used to transmit information from Tivoli
SRM back to the TEC event server.
Note: TDI queries Maximo/MEA every minute (configurable timer) for
updates. Maximo/MEA does not need to be aware of any TDI servers.
110 Integration Guide for IBM Tivoli Service Request Manager V7.1
Your TEC integration for the Service Desk environment can include multiple TEC
servers, multiple TDI servers, and multiple Tivoli SRM servers. Although a single
TDI server can accommodate the data flow from multiple TEC and Tivoli SRM
servers, it is a best practice to install multiple TDI servers to maintain availability
in case of server failure.
Event automation means that actions can be performed when processing events.
For the purposes of this book, we refer to the process of taking action on system
resources without human intervention in response to an event. The actual
actions executed are referred to as automated actions. Automated actions in
Service Desk generates an Incident in Tivoli SRM based on certain predefined
rules.
Figure 3-2 on page 111 shows the communication between various components
involved in TEC integration for Service Desk software.
Note: For incoming events from TEC (port 6767), a logfile adapter is
unnecessary, because a TDI server connector listens for requests and
forwards them to the Maximo connector, which sends the ticket
Create/Update request to Tivoli SRM. Logfile adapter is only used to transmit
information from Tivoli SRM back to the TEC.
Chapter 3. Event management integration 111
Figure 3-2 Communication methods
The AssemblyLine with the Unified Connector is configured to listen on port
6767, which is the default communication port for event server. When an event
corresponds to the AssemblyLine condition, an Incident within Tivoli SRM is
created automatically.
Figure 3-3 on page 112 demonstrates how the event generates an Incident
record within Tivoli SRM and also how the event is generated within the TEC by
calling the postzmsg.
Tivoli
Enterprise
Agent
Server
Server A
Tivoli Directory Integrator
Unified CONNECTOR
Tivoli Enterprise Console
Assembly Line
Create/Update
Ticket
Update
Ticket
postzmsg
Port : 6767
Server B
Tivoli
Directory
Integrator
(UI)
Workstation
Non-Tivoli
Logfile
Adapter
112 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 3-3 TDI architecture
The user is able to open an incident record within the TEC Console by using the
Ticket Creation function.
3.2.3 Predefined scenarios
Table 3-1 lists the event status and corresponding actions for every event that is
created or generated in TEC.
Table 3-1 Action performed for a particular event status
Tivoli
Enterprise
Console
Tivoli
Service
Request
Manager
External
Service
Desk
NODE
Tivoli Directory Integrator
External External
Integration Object
(M E A)
Create/Update
TEC Event
Port : 6767
Update
TEC Event
postzmsg
Create/Update
Ticket
Update
Ticket
Unified Connector
TEC
Unified Connector
Service Request Manager
INTERPRETER
Assembly Line
Unified Connector
HP-Peregrine
ServiceCenter 6.1
Create/Update
Ticket
Update
Ticket
Web Services Integration
HTTP
Web Services Integration
HTTP
Event status Action in Tivoli SRM
Fatal An incident record is opened.
Critical or other status A service request record is opened.
Chapter 3. Event management integration 113
TDI has a rule inside the assembly lines to guide the creation of various ticket
types according to the event status sent by TEC (Example 3-1).
Example 3-1 TECInReadQueue assembly line
Open TECInReadQueue assembly line
Select ClassifyTECTicket script and take a look on the code.
if ("FATAL".equals(severity)) {
work.setAttribute("T_TICKET_TYPE", "INCIDENT");
task.logmsg("Ticket class is INCIDENT or PROBLEM.");
} else if (!"FATAL".equals(severity) && severity != null) {
work.setAttribute("T_TICKET_TYPE", "SR");
task.logmsg("Ticket class is SERVICE REQUEST.");
When the following actions (Table 3-2) are performed on the event, which opens
a record in Tivoli SRM, the corresponding actions are automatically reflected in
the service request or incident record.
Table 3-2 Action resolving the service request or the incident record
If the record created by an event is resolved or closed within the SRM
Application, the event record is automatically closed (Table 3-3 on page 114).
Note: You can change the event criteria for opening Service Desk tickets by
editing the mro_troubleticket ruleset.
The mro_troubleticket ruleset file (mro_troubleticket.rls) is located in the
following directory on the TEC server:
rbpath/TEC_Rules/mro_troubleticket.rls, where rbpath is the rulebase
directory.
You can obtain the exact location by running the following command from
within the Tivoli BASH Shell environment:
wrb –lsrb –path
Event status Action on the event Action performed in
Tivoli SRM
Fatal Closed Changes the incident
status to resolved
Critical or other status Closed Changes the service
request status to resolved
114 Integration Guide for IBM Tivoli Service Request Manager V7.1
Table 3-3 Action closing the event record
3.2.4 Steps for implementing TEC integration
You must follow the instructions in this section to implement TEC integration.
The steps are:
1. Install non-TME logfile adapter.
2. Install TDI.
3. Edit the mxe.properties file (optional).
4. Install the new SRM ruleset.
5. Start TDI.
6. Configure the TEC connector.
3.2.5 Installing the non-TME logfile adapter
The non-TME logfile adapter is the adapter that provides the communication
between the system where the logfile is installed and the TEC. The
communication between these components is not secure and uses port 5529.
The installation of this connector is required so that the system can post
messages (using the postzmsg application) and communicate with TEC.
Depending on the operating system of the TDI server, install either the UNIX or
Windows non-TME logfile adapter. The non-TME logfile adapter binary files are
located on the TEC CD. Be sure to install the non-TME version of the logfile
adapter. The TME® version is not supported.
SRM record SRM action Action performed in TEC
Service request Resolved Close the event
Incident Resolved Close the event
Note: Our scenario assumes that you are using one TDI server. If for
performance or high availability reasons you decide to use more than one TDI
server, additional steps are required. Refer to “TDI considerations” on
page 248 for more information.
Note: The Windows non-TME logfile adapter is also known as the Windows
event log adapter.
Chapter 3. Event management integration 115
Perform the following steps to install the Windows non-TME LogFile adapter:
1. The setup.exe file is located at Non-TME LogFile adapter
3.9\W32-IX86\InstallWIN.
2. Click setup.exe if you are using the file browser, or if you are using the
command line, execute the setup.exe.
3. Click Next at the Welcome box.
4. Click Next to accept the destination directory, C:\tec\win.
5. Click Next to accept the destination directory.
6. Click Next to accept the type of adapter.
The progress status bar shows the installation progress.
7. Click Next at the server configuration. The server configuration is done within
the AssemblyLine.
8. Click Next at the port number configuration.
9. The configuration is completed automatically, and the following command line
window appears (Figure 3-4 on page 116).
Important: For Windows, do not change the default value for the path where
you install the non-logfile adapter, because TDI uses this directory. For UNIX,
there is no default location, so you can install at any location on UNIX.
Note: You can use the default values. These values do not matter,
because TDI provides the required values in real time to communicate with
TEC.
116 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 3-4 Automated logfile adapter configuration window
10.Click any key on your keyboard to complete the installation.
11.Click OK to complete the installation after answering the readme file question.
12.A reboot is required to activate the non-Logfile adapter.
3.2.6 Installing TDI
You can use the TDI installation program that is provided with Tivoli SRM to
install a TDI environment that supports the integration of TEC (and other
products) with Tivoli SRM Service Desk.
To install one or more TDI servers, use the procedure described in “Installation
procedure” on page 31.
3.2.7 Editing the mxe.properties file (optional)
The TDI installation program prompts you for the location of the TEC non-TME
logfile adapter. The value that you specify is entered into a properties file named
mxe.properties. If you do not specify a location for the logfile adapter during
installation, you can manually update the mxe.properties file after installation.
Edit the mxe.properties file on each computer that hosts a TDI server to specify
the following values:
򐂰The full directory path where the TEC non-TME logfile adapter is installed.
If you specified the correct location of the logfile adapter when you installed
TDI, the mxe.properties file already contains this value.
Chapter 3. Event management integration 117
򐂰A SRM user ID and password that the TDI server can use to log on to SRM.
The SRM user that you specify must have the authority to create Service
Desk tickets. You can specify either a Lightweight Directory Access Protocol
(LDAP) or a non-LDAP user, depending on the type of authorization that is
required by SRM.
Complete the following steps to edit the mxe.properties file on each computer
where TDI is installed:
1. Change to the TDI work directory (solution directory). You specified a work
directory when you installed TDI.
2. Open the mxe.properties file.
3. Use the tecLogAdapterFilePath property to specify or verify the location of the
TEC non-TME logfile adapter:
– For Windows: tecLogAdapterFilePath=c:\tecwin
– For Linux or UNIX: tecLogAdapterFilePath=/opt/IBM/Tivoli/tec/nonTME
To enable the TDI server to access SRM, specify values for the following
properties:
–default.maximo.authentication.required=true
– default.maximo.user=user_ID
– default.maximo.url=http://172.27.34.45
–default.maximo.password={encr}
where user ID and password specify a user that is authorized to log on to
SRM and who has the authority to create Service Desk tickets
3.2.8 Installing the SRM rulebase
The prerequisites for installing the SRM rulebase are:
򐂰Access to root on a UNIX box and access to Administrator or any other user
on Windows with the Administrator privileges.
򐂰Locate the following zip files containing the new ruleset for Tivoli SRM:
– tec_integration_deployment.zip
– integrate\install\tec\winstall_mro_tec
– integrate\install\tec\mro_install\mro_troubleticket.baroc
Note: Typing {protect}- in front of a property name instructs TDI to encrypt
the property value the next time that it reads the file. In this case, the
encrypted password is shown if you open the mxe.properties file after the TDI
server is started.
118 Integration Guide for IBM Tivoli Service Request Manager V7.1
– integrate\install\tec\mro_install\mro_troubleticket.sh
– integrate\install\tec\mro_install\mro_post.pl
– integrate\install\tec\mro_install\mro_troubleticket.rls
Installation procedure
The installation procedure is:
1. Unzip or untar the tec_integration_deployment.zip file. Example 3-2 is based
on an Intel® architecture.
Example 3-2 Files required to add the ruleset
$bindir\tec\winstall_mro_tec
$bindir\tec\mro_install\mro_troubleticket.baroc
$bindir\tec\mro_install\mro_troubleticket.sh
$bindir\tec\mro_install\mro_post.pl
$bindir\tec\mro_install\mro_troubleticket.rls
2. Execute the Tivoli Environment variable, which is the setup_env.sh script file
located in the /winnt/system32/drivers/etc/tivoli directory.
3. Start the bash shell script:
a. Start a new Windows command line.
b. Type bash.
c. Press Enter.
Bash$
4. Set the Tivoli variable environment for your Bash Shell environment:
cd /winnt/system32/drivers/etc/tivoli
setup_env.cmd
bash
.. ./setup_env.sh
5. Follow these steps for the ruleset configuration:
a. Change the directory within the bash shell window to initiate the Perl script
for the configuration:
bash$ cd /appls/tivoli/bin/w32-ix86/tme/tec
bash$ perl winstall_mro_tec
b. Make your selection to the next question.
Important: If you do not run this script, you will not be able to run Tivoli
commands.
Chapter 3. Event management integration 119
c. In your implementation, add this rulebase to an existing and active
rulebase in your environment.
6. Choose a rulebase to modify:
–ITM61rulebase
–Omnibus
– ITM71toTEC
– Create new rulebase
7. Choose Create New Rulebase.
You get the message “You have chosen to create a new Rulebase.”
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
8. The following question prompts you to provide a name for the new rulebase.
We used the following name: TECtoSRVv10. The window shows:
Enter a valid Rulebase name.
Example: tsdrb or myrulebase: TECtoSRVv10
You entered: TECtoSRVv10.
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
9. The following question asks you to provide a path to store the new rulebase
and all the related files.
The window shows:
Enter a valid path for new Rulebase "TECtoSRVv10".
Example: "c:\TEC\tsdrb" or "/data/Tivoli/TEC/myrulebase":
c:\appls\tivoli\bin\w32-ix86\tme\tec\SRM_RBase
You entered "c:\appls\tivoli\bin\w32-ix86\tme\tec\SRM_RBase".
Note: The following predefined rulebase might not show in your
environment.
Important: In the Windows environment, it is important not to confuse the
backslash (\) with the forward slash (/). If the forward slash is appended,
you receive an error from the script.
For this example, we use the fully qualified path:
c:\appls\tivoli\bin\w32-ix86\tme\tec\SRM_RBase
120 Integration Guide for IBM Tivoli Service Request Manager V7.1
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
The following question asks on which rulebase the new rulebase is based.
10.Choose which Rulebase to inherit your functions:
a. Default
b. ITM61rulebase
c. Omnibus
d. ITM71toTEC
Choose ITM71toTEC.
You have chosen Rulebase Default.
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
11.For the next question, select the EventServer by entering 1. The window
shows:
Choose the Rulebase target(usually "EventServer"):
EventServer
Choice: 1
You have chosen Rulebase target "EventServer"
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
12.The next question is about the TDI Server, where you have to identify it by its
host name or by its IP address:
Enter the hostname or IP address of your TDI Server: 9.3.5.56
You have chosen TDI Server "9.3.5.56"
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
13.The next question is about the HTTP port and TDI communication:
Enter the HTTP Port for your TDI Server (usually "6767"): 6767
You have chosen TDI Server Port "6767"
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
Note: The following predefined rulebase might not show in your
environment. Substitute the name of a predefined rulebase from your
environment.
Chapter 3. Event management integration 121
14.For high availability reasons, you can specify another TDI server. Refer to
Chapter 9, “High availability best practices” on page 245 for more discussion
about this topic.
Do you want to specify an additional TDI Server? (Y/N): N
15.You can add the host name or the IP address related to the TEC server:
Enter the fully qualified hostname or IP address of your TEC Server.
Note: This is the fully qualified hostname of *THIS* machine:
9.3.4.139
You have chosen TEC Server "9.3.4.139"
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
16.The next question is about activating the rulebase after the script is run
successfully. Answer Y (Yes) to this question.
Do you wish to load and activate the new ruleset? [Y/N]:
This requires an EventServer restart: Y
You have chosen to load and activate the new ruleset.
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
17.This question is about UTF-8, which makes reference to the new standard for
the multi-language system. Confirm it by pressing the Enter key:
Enter the character set you wish to use. Enter "list" for choices.
Simply press Enter for the default choice of UTF-8.
You have chosen character set "UTF-8"
For “Press Y to confirm, Q to quit, or any other key to reselect:”
enter Y.
Example 3-3 lists a summary of the options that you chose.
Example 3-3 Summary
**********************************
Summary
**********************************
Rulebase Name: TECtoSRVv10*
Rulebase Directory:
c:\appls\tivoli\bin\w32-ix86\tme\tec\SRM_RBase*
Rulebase Target: EventServer
Tip: We highly recommend that you stop and start the TEC at the end of
this process to make sure that the rulebase is activated.
122 Integration Guide for IBM Tivoli Service Request Manager V7.1
Rulebase Parent: ITM61rulebase
TDI Server: 9.3.5.56
TDI Server HTTP Port: 6767
TEC Server Hostname: 9.3.4.139
TEC Server Port: 5529
Load and Active Rulebase Yes
Character Set: UTF-8
**********************************
*-is created
Press "Y" to continue, or "Q" to quit: y
Checking dependencies.
Creating new Rulebase "ITMtoTEC".
New Rulebase successfully created.
Inheriting functions from "Default"...this might take a
minute.
Successfully inherited functions.
Generating TDI properties file.
Successfully installed "tdi_server.props" file.
Successfully installed "mro_troubleticket.rls" file.
Successfully installed "mro_troubleticket.baroc" file.
Successfully installed "mro_Troubleticket.sh" file.
Successfully installed "mro_post.pl" file.
Importing mro_troubleticket.baroc into the "ITMtoTEC"
Rulebase.
Class import is successful.
Importing mro_troubleticket ruleset into the "ITMtoTEC"
Rulebase.
Ruleset import is successful.
Importing mro_troubleticket ruleset into the "EventServer"
Rulebase target.
Ruleset import to Rulebase target is successful.
Compiling the Rulebase "ITMtoTEC".
Ruleset compile operation is successful.
Loading and activating the modified Rulebase "ITMtoTEC".
Ruleset successfully loaded.
Restarting the EventServer.
EventServer restart operation is successful.
bash$
After the Assembly Line is configured, an incident record is generated within
Tivoli SRM for every event with status equal to “FATAL”.
Perform the following steps to make sure that the new rule base is properly
created and activated:
Chapter 3. Event management integration 123
1. Start the Tivoli Desktop.
2. Authenticate with the Administrator ID or root if you use UNIX.
3. Open the EventServer icon, as shown in Figure 3-5 on page 123. The new
rule base appears.
Figure 3-5 New rule set created and activate
3.2.9 Starting the TDI server
Complete the following steps to start the TDI server. Do not start the server if you
have not completed configuration of the SRM server:
1. Change to the TDI working directory.
2. Run the following command:
–On Windows:
mxetdi.cmd
– On Linux or UNIX:
mxetdi.sh
Note: You specified the TDI working directory when you installed TDI.
124 Integration Guide for IBM Tivoli Service Request Manager V7.1
3.2.10 Ticket synchronization
Based on the rules defined in “Predefined scenarios” on page 112, the following
AssemblyLine allows you to create an incident record within Tivoli SRM with
minimum configuration:
1. To establish communication between TDI and Tivoli SRM, the following
configuration in the TDI (described in Figure 3-6 on page 125 and Figure 3-7
on page 126) is required.
Chapter 3. Event management integration 125
Figure 3-6 Configuration required to establish the communication (1 of 2)
126 Integration Guide for IBM Tivoli Service Request Manager V7.1
Figure 3-7 Configuration required to establish the communication (2 of 2)
2. To test the scenario manually, generate an event with the severity “FATAL”,
using the following command:
wpostemsg -r FATAL -m "This Event is generated to create an Incident
within SRM v7.x" fqhostname="SRV_Server_404" TEC_Error Events
3. Log on to TEC, and validate the creation of the event specified in the previous
step, as shown in Figure 3-8 on page 127.
Chapter 3. Event management integration 127
Figure 3-8 Event with severity “Fatal”
4. Right-click and select RUN to run TEC in AssemblyLine, as shown in
Figure 3-9.
Figure 3-9 Run AssemblyLine
Output similar to Example 3-4 on page 128 appears.