04 MDM Stdadvinstall

IBM InfoSphere Master Data Management Standard and
Advanced Editions
Version 11 Release 0
Installation Guide
GI13-2658-00
IBM InfoSphere Master Data Management Standard and

Advanced Editions
Version 11 Release 0
Installation Guide
GI13-2658-00
Note
Before using this information and the product that it supports, read the information in Notices and trademarks on page
189.
Edition Notice
This edition applies to version 11.0 of IBM InfoSphere Master Data Management and to all subsequent releases and
modifications until otherwise indicated in new editions.
Copyright IBM Corporation 1996, 2013.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Tables . . . . . . . . . . . . . . . v
Figures . . . . . . . . . . . . . . vii
Chapter 1. Installing IBM InfoSphere
Master Data Management Server
Standard and Advanced Editions . . . . 1
Chapter 2. Installation overview . . . . 3
Typical versus custom installation deployment type . 4
Typical installation deployment type . . . . . 4
Custom installation deployment type . . . . . 7
Features installed by Installation Manager . . . . 8
Installation requirements . . . . . . . . . . 10
32-bit libraries needed on 64-bit operating
systems. . . . . . . . . . . . . . . 12
Multiple instance support . . . . . . . . . 13
Graphical or silent installation . . . . . . . . 14
Installation Startup Kit . . . . . . . . . . 14
User accounts and groups created by the installer 15
Default user accounts created during a typical
installation deployment . . . . . . . . . 17
Password storage and exposure . . . . . . . 18
Encrypting passwords with WebSphere
Application Server . . . . . . . . . . . 18
Directory structures. . . . . . . . . . . . 19
MAD_ROOTDIR and MAD_HOMEDIR use in
version 11.0 . . . . . . . . . . . . . 20
Chapter 3. Setting up the installation
media . . . . . . . . . . . . . . . 23
Chapter 4. Preparing for a typical
installation . . . . . . . . . . . . . 25
Chapter 5. Preparing for a custom
installation . . . . . . . . . . . . . 27
Installation and configuration worksheets . . . . 27
Installation directory worksheet . . . . . . 28
IBM DB2 or DB2 for z/OS data source worksheet 29
Microsoft SQL Server data source worksheet . . 31
Oracle data source worksheet . . . . . . . 33
WebSphere Application Server installation
worksheet . . . . . . . . . . . . . . 34
MDM application configuration worksheet . . . 37
User applications installation worksheet . . . . 38
History installation worksheet . . . . . . . 40
Prepare IBM Installation Manager . . . . . . . 42
Installing Installation Manager . . . . . . . 43
Adding offerings to IBM Installation Manager . . 43
Installing the Installation Startup Kit . . . . . . 44
Preparing for high availability . . . . . . . . 45
Account prerequisites for custom installations . . . 45
Preparing your database . . . . . . . . . . 46
Database user accounts and connections . . . . 47
Preparing a DB2 database . . . . . . . . 48
Preparing an Microsoft SQL Server database . . 50
Preparing an Oracle database . . . . . . . 51
ODBC drivers installed with standard edition . . 53
Prepare your application server. . . . . . . . 53
To set an IBM DB2 utility path . . . . . . . 54
To set an Oracle utility path . . . . . . . . 54
Preparing WebSphere Application Server
Network Deployment for a managed server
deployment . . . . . . . . . . . . . 55
Preparing WebSphere Application Server
Network Deployment for an unmanaged server . 56
Preparing WebSphere Application Server for base
deployment . . . . . . . . . . . . . 57
Creating a new user and adding the user to an
MDM group . . . . . . . . . . . . . 57
Preparing a Solaris system for MDM installation . . 58
WebSphere Application Server embedded messaging 59
Preparing an existing WebSphere Application
Server messaging bus for MDM installation on
z/OS . . . . . . . . . . . . . . . 59
Preparing an existing WebSphere Application
Server messaging bus for MDM installation . . 60
Set the locale and character encoding on target
computers . . . . . . . . . . . . . . . 60
Chapter 6. Installing InfoSphere MDM 63
Starting a typical installation process with
LaunchPad . . . . . . . . . . . . . . 64
Installing a typical server installation . . . . . . 65
Installing a typical workstation installation . . . . 67
Installing a custom installation . . . . . . . . 69
Installing in a clustered environment . . . . . . 72
Deploying the MDM Native Component feature on
remote Windows server . . . . . . . . . . 75
Installing on Oracle RAC . . . . . . . . . . 76
Enabling support for Oracle non-wired driver . . . 77
Installing on z/OS . . . . . . . . . . . . 77
Configuring your message bus on z/OS after
installation . . . . . . . . . . . . . . 79
Silent installation . . . . . . . . . . . . 80
Customizing the silent mode response file . . . 82
Disabling the installer splash screen during silent
installation . . . . . . . . . . . . . 87
Installing silently by using a response file . . . 88
Creating a response file while you are running a
graphical installation . . . . . . . . . . 89
Modifying an installation silently . . . . . . 89
Modifying your installation . . . . . . . . . 89
Installation scenarios . . . . . . . . . . . 90
Scenario 1: Installing MDM on a WebSphere
Application Server cluster, using an IBM DB2
database and IBM WebSphere MQ messaging . . 91
Copyright IBM Corp. 1996, 2013 iii
Application Server cluster, using an Oracle
database and WebSphere Default Messaging . . 94
Application Server Network Deployment on
Windows with an SQL Server database . . . . 97
madconfig utility . . . . . . . . . . . . 100
madconfig utility targets for MDM . . . . . 101
Manual installation of the physical MDM database 103
Setting the XA configuration in IBM WebSphere
Application Server to connect with DB2 for
z/OS . . . . . . . . . . . . . . . 104
z/OS database creation and installation . . . 104
Granting connection privileges on DB2 for z/OS 105
Oracle database setting . . . . . . . . . 105
Manual installation of the physical MDM
database on DB2 for Linux or UNIX. . . . . 106
database on DB2 for z/OS . . . . . . . . 109
Installing the core database manually on
Microsoft SQL Server . . . . . . . . . . 117
database on Oracle . . . . . . . . . . 118
Installing the InfoSphere MDM messaging server
component manually . . . . . . . . . . . 122
Updating the deployed properties files for physical
MDM . . . . . . . . . . . . . . . . 122
Chapter 7. Installing client
applications and individual
components . . . . . . . . . . . . 125
Business Administration UI installation. . . . . 125
Installing Business Administration UI . . . . 126
Data Stewardship UI installation . . . . . . . 127
Installing Data Stewardship UI . . . . . . 127
Product Maintenance UI installation. . . . . . 128
Installing Product Maintenance UI . . . . . 128
Inspector installation . . . . . . . . . . . 130
Installing Inspector . . . . . . . . . . 130
Configure Inspector . . . . . . . . . . 132
Enterprise Viewer installation . . . . . . . . 133
Installing Enterprise Viewer . . . . . . . 134
Configuration and Application Management . . 136
Globalization in Enterprise Viewer . . . . . 151
Web Reports installation. . . . . . . . . . 151
Installing Web Reports . . . . . . . . . 152
Editing the webreports.properties file . . . . 153
Adding security messages to Web Reports. . . 157
Viewing Report queries in InfoSphere MDM
Web Reports. . . . . . . . . . . . . 158
Configuring WebSphere Application Server
logging . . . . . . . . . . . . . . 158
Provider Direct installation . . . . . . . . . 158
Installing Provider Direct . . . . . . . . 159
Importing the Provider Direct project into
Workbench . . . . . . . . . . . . . 160
Loading the Provider Direct database tables . . 160
Deploying the modified Provider Direct EAR
file . . . . . . . . . . . . . . . . 160
Provider Direct configuration . . . . . . . 161
Message Broker installation. . . . . . . . . 164
Installing Message Broker Suite . . . . . . 164
Creating the broker services.ini file . . . . . 165
Directories and files installed with Message
Broker Suite . . . . . . . . . . . . . 166
Unicode and alternative language support. . . 167
InfoSphere MDM Healthcare Point of Service
Integrator installation. . . . . . . . . . . 168
Installing InfoSphere Healthcare Point of Service
Integrator . . . . . . . . . . . . . 168
Directory and files installed with Healthcare
Point of Service Integrator . . . . . . . . 169
Pair Manager installation . . . . . . . . . 169
Installing Pair Manager . . . . . . . . . 170
Samples . . . . . . . . . . . . . . . 170
Installing samples . . . . . . . . . . . 171
InfoSphere MDM Workbench installation . . . . 171
Installing InfoSphere InfoSphere MDM
Workbench . . . . . . . . . . . . . 172
Configuring application security for web
applications . . . . . . . . . . . . . . 173
Enabling SSL for virtual MDM web applications
deployed to a remote application server . . . . 173
Error codes seen in user applications . . . . . 174
Chapter 8. Verifying the installation 177
Verifying the installation with the Test Client on
WebSphere Application Server. . . . . . . . 178
Test Client properties . . . . . . . . . . . 180
Installation logs . . . . . . . . . . . . 180
Viewing Installation Manager log files . . . . 181
Viewing the MDM installation logs . . . . . 182
Chapter 9. Uninstalling InfoSphere
MDM . . . . . . . . . . . . . . . 183
Uninstalling your InfoSphere edition . . . . . 183
Uninstalling a typical server installation . . . . 183
Uninstalling a typical workstation installation . . 184
Uninstalling a single component . . . . . . . 185
Uninstalling in silent mode . . . . . . . . . 186
Removing CBA from internal bundle repository 187
Notices and trademarks . . . . . . . 189
Index . . . . . . . . . . . . . . . 193
Contacting IBM . . . . . . . . . . 197
iv Installation Guide
Tables
1. MDM installed features . . . . . . . . . 9
2. Installation requirements . . . . . . . . 10
3. MDM user accounts. . . . . . . . . . 15
4. MDM user groups . . . . . . . . . . 16
5. MDM_INSTALL_HOME directories . . . . . . . 19
6. InfoSphere MDM installation directory
worksheet . . . . . . . . . . . . . 29
7. IBM DB2 or DB2 for z/OS data source
worksheet . . . . . . . . . . . . . 31
8. Microsoft SQL Server data source worksheet 32
9. Oracle data source worksheet . . . . . . 33
10. IBM WebSphere Application Server installation
worksheet . . . . . . . . . . . . . 35
11. MDM application installation worksheet 37
12. User application installation worksheet 39
13. MDM user applications . . . . . . . . 40
14. History installation worksheet . . . . . . 41
15. Basic madconfig utility targets . . . . . . 100
16. madconfig utility targets for operational
server installation . . . . . . . . . . 101
17. madconfig utility targets for database
installation . . . . . . . . . . . . 102
18. madconfig utility targets for uninstall 102
19. Properties found in the inspector.properties
file . . . . . . . . . . . . . . . 131
20. Properties found in the inspector.properties
file . . . . . . . . . . . . . . . 135
21. Web pages and associated
mpi_appprop.propnames . . . . . . . 137
22. Prop files and SegCode Filter updates 140
23. Descriptions of the required properties in the
webreports.properties file . . . . . . . 153
24. Descriptions of the optional properties in the
25. Parameters for display attributes in the
26. Required operational server login properties 161
27. Required context factory properties . . . . 162
28. Required data source properties . . . . . 162
29. Extra required properties . . . . . . . 162
30. Required context factory properties . . . . 162
31. Required operational server-owned source
properties. . . . . . . . . . . . . 163
32. Extra required properties . . . . . . . 163
33. Enumerated data types . . . . . . . . 163
34. Custom attributes . . . . . . . . . . 164
35. Files used by the brokers . . . . . . . 166
36. Error code descriptions . . . . . . . . 174
37. Installation verification tests . . . . . . 179
38. Properties that can be set in the Test Client
properties file . . . . . . . . . . . 180
39. IBM resources . . . . . . . . . . . 197
40. Providing feedback to IBM . . . . . . . 197
Copyright IBM Corp. 1996, 2013 v
vi Installation Guide
Figures
1. Typical server installation . . . . . . . . 5
2. Typical workstation installation . . . . . . 6
3. Custom installation in a clustered environment 8
Copyright IBM Corp. 1996, 2013 vii
viii Installation Guide
Chapter 1. Installing IBM InfoSphere Master Data Management
Server Standard and Advanced Editions
The InfoSphere
MDM components are installed by using IBM
Installation Manager, which ensures a

simple and consistent installation experience.
IBM Installation Manager is also used to uninstall components and to modify an existing installation by
adding or removing components. You can run the installation in graphical or silent mode.
The installation topics describe how to prepare your application server and database for installation of
MDM and how to install MDM.
The installation topics assume that you are familiar with WebSphere
Application Server and with the

database that you plan to use.
Copyright IBM Corp. 1996, 2013 1
2 Installation Guide
Chapter 2. Installation overview
Most IBM InfoSphere Master Data Management Server components can be installed on a server or
workstation, a combination of the two, or across multiple servers to support clustered environments.
You must set up both a client system and one or more server systems. The application server, database
server, and HTTP server can all be on the same server, or they can each be on their own server. The
HTTP server is recommended, but is optional.
The time that is required to install InfoSphere MDM depends on a number of factors and, as such, time
estimates cannot be provided. Some factors that influence the amount of time to prepare and install can
include:
v The number of components that are being installed
v The number of servers or workstations in your environment
v Your network load capacity if you are installing in a clustered environment
v Whether IBM WebSphere Application Server is installed
v Whether your database software is installed
The first step in the installation process is to determine the best deployment type for your requirements:
Typical installation deployment type on page 4 or Custom installation deployment type on page 7. If
you choose a typical installation deployment, you always use LaunchPad to begin the process and
Launchpad, in turn, starts IBM Installation Manager. For custom installations, you must manually
configure IBM Installation Manager to point to the installation media. Most implementations require a
custom deployment.
After IBM Installation Manager is started, the basic order in which it works is described in these steps.
1. Select the features that you want to install. The MDM Database and MDM Operational Server are
the key components.
MDM Database includes the core database tables for the edition that you are installing. The MDM
Operational Server equates to the formerly named MDM Server and the MDS Master Data Engine.
2. After you select the features and installation directory location, the installer does some basic checks
on the operating system, disk space, and supporting software before continuing with the installation.
If the installation directory specified is an existing directory, IBM Installation Manager verifies
whether there is an existing installation and, if found, warns you about overwriting the installation.
3. You are then prompted to enter information in a series of configuration panels. This information is
used to automatically configure the MDM database and application server with specific connection
information and to identify the cell, node, and servers on which the InfoSphere MDM artifacts are
deployed.
If you are using a typical installation deployment, the configuration panels do not display. Default
values are used to automatically configure the database, application server, and operational server
settings.
4. Static data is extracted into the MDM_INSTALL_HOME directory that you selected at the beginning
of the process. Static data includes items like the Batch Processor, Management Agent, Management
Console, and the madconfig utility scripts among other items.
5. Database tables and indexes are created.
6. Next, the native components and web services are deployed to the application server. That means
that all artifacts are deployed in all specified nodes.
7. User interfaces and web applications that are selected for installation are also deployed to the
application server. The installer packages web-based application WAR files into an EAR file and
deploys the EAR file to the application server. During deployment, the application server unpacks
the content of the EAR files.
8. Native configuration files .cfg are created.
9. After deployment, the database is bootstrapped.
10. Before the installation is complete, the installer completes a verification process by running
transactions through the operational server.
In addition to the verification tests that the installer runs, you can use the Test Client to run test
transactions to ensure a successful installation.
Related concepts:
Chapter 8, Verifying the installation, on page 177
The IBM Installation Manager automatically runs a verification routine to test the installation by running
three physical transactions to add a person, an organization, and a contract, and one virtual transaction.
If these transactions are successful, then the installation completes successfully.
Typical versus custom installation deployment type
Installation of IBM InfoSphere Master Data Management can be accomplished by using either a typical
installation or a custom installation.
The InfoSphere MDM editions bundle the master data capabilities and are installed by using IBM
Installation Manager. Additional software, such as IBM WebSphere Application Server, IBM DB2
(if you
are using a DB2 database), and IBM Rational
Application Developer (RAD) (if you are using InfoSphere

MDM Workbench) are also installed by IBM Installation Manager.
The type of installation you choose depends on a number of considerations:
v Whether you are installing on a clean server or workstation
v Whether you have an existing database and application server installed
v The number of servers or workstations on which you want to deploy the components
v What messaging servers you install
v The degree of automation you want to employ in the installation process
Related tasks:
Chapter 6, Installing InfoSphere MDM, on page 63
The installation instructions are the same for all editions.
Typical installation deployment type
A typical installation deployment type must be done on a clean server or a clean workstation and installs
IBM InfoSphere Master Data Management, IBM WebSphere Application Server, and IBM DB2 in a single
run of IBM Installation Manager. Workstation installs include InfoSphere MDM Workbench and IBM
Rational Application Developer (RAD). This deployment type offers the quickest time between
completing the installation and running your first transaction.
Your server or workstation must not have any InfoSphere MDM components, IBM WebSphere
Application Server, or IBM DB2 already installed. A typical installation for server or workstation is
supported for InfoSphere MDM Standard, Advanced, and Enterprise Editions.
A typical installation for server or workstation is used when you:
v Plan to use a new DB2 database
v Are installing IBM WebSphere Application Server for the first time
v Are installing on Microsoft Windows, IBM AIX
, Linux, or Solaris operating systems

v Must be up and running in a short amount of time
A typical installation installs all MDM operational server and database capabilities on a single target
computer and can be run in graphical or silent mode.
A typical installation is started by using LaunchPad. When LaunchPad opens, you can select to use a
typical server installation or a typical workstation installation. That selection then does one of two
actions:
v Installs IBM Installation Manager if it is not already installed.
v Starts IBM Installation Manager if it is installed. If you do not have the current version of IBM
Installation Manager, an update automatically begins.
After the installation is complete, you can opt to return and install any additional component by using
the modify installation option.
Related reference:
Features installed by Installation Manager on page 8
The features that you can install are dependent upon the edition that you choose.
Typical server installation
A typical server installation implies that you are selecting to install anInfoSphere MDM edition, IBM
WebSphere Application Server, and IBM DB2 on a server.
This illustration shows a typical server installation.
For a typical server installation, IBM Installation Manager completes the following process.
1. Installs IBM WebSphere Application Server (network deployment) and IBM DB2.
2. Installs the InfoSphere MDM operational server, database component, and the two data stewardship
applications (InfoSphere MDM Data Steward UI and InfoSphere MDM Inspector). The MDM static
content is content that the installer extracts into the installation directory (MDM_INSTALL_HOME).
Static content can include client applications like Batch Processor, Management Agent, Management
Console, MDM Collector, MDM configuration scripts (madconfig utility scripts), and other applications
using default settings.
3. Automatically creates your IBM WebSphere Application Server profile and configures your database,
application server, and data stewardship applications.
4. The installation process finally deploys the MDM components to the application server.
Software repository/
Local media
MDM
static content
Installer
Download
IBM WebSphere Application Server,
IBM DB2, MDM offering
(includes operation server, database
component and data stewardship applications)
Box A
MDM data
Database Server
MDM operational server
Data Stewardship Applications
Data Stewardship UI
Inspector
Application Server
Figure 1. Typical server installation
Chapter 2. Installation overview 5
You can install more components by using the modify option after the typical installation for server is
complete.
Related tasks:
Installing a typical server installation on page 65
Use this procedure to run a typical server installation. A typical server installation implies that you are
selecting to install an IBM InfoSphere Master Data Management edition, IBM WebSphere Application
Server, and IBM DB2 on a clean server.
Related reference:
Typical workstation installation
A typical workstation installation implies that you are selecting to install an InfoSphere MDM edition,
IBM WebSphere Application Server, IBM DB2, IBM Rational Application Developer (RAD), and
InfoSphere MDM Workbench on a Microsoft Windows workstation.
Your workstation must be a Microsoft Windows operating system. Other operating systems are not
supported for typical workstation installations.
This illustration shows a typical workstation installation. Like the server scenario, you download IBM
WebSphere Application Server (base deployment), IBM DB2, your InfoSphere MDM edition, and
InfoSphere MDM Workbench.
For a typical workstation installation, IBM Installation Manager:
Local media
MDM
static content
Installer
Download
IBM WebSphere Application Server,
IBM DB2, MDM offering
(includes operation server, database component),
IBM Rational Application Deveoper,
MDM Workbench
Box A
MDM data
Database Server
MDM operational server
Application Server
MDM Workbench
IBM Rational
Application Developer
Figure 2. Typical workstation installation
1. Installs IBM WebSphere Application Server (base deployment), IBM DB2, and IBM Rational
Application Developer (RAD).
2. Installs InfoSphere MDM Workbench in IBM Rational Application Developer (RAD).
3. Installs the MDM operational server and database components. The MDM static content is content
that the installer extracts into the installation directory (MDM_INSTALL_HOME). Static content can
include client applications like Batch Processor, Management Agent, Management Console, MDM
Collector, MDM configuration scripts (madconfig utility scripts) and other applications.
4. Automatically creates your IBM WebSphere Application Server profile and configures your database,
application server, and data stewardship applications using default settings.
5. The installation process finally deploys the MDM components to the application server.
Related tasks:
Installing a typical workstation installation on page 67
Use this procedure to run a typical workstation installation. Typical workstation installations are
supported on a Microsoft Windows operating system only. A typical workstation installation implies that
you are selecting to install an IBM InfoSphere Master Data Management edition, IBM WebSphere
Application Server, IBM DB2, InfoSphere MDM Workbench, and IBM Rational Application Developer
(RAD) on a clean workstation.
Related reference:
Custom installation deployment type
A custom installation is used to do exactly that, customize the components that you install.
A custom installation is normally done under any of the following conditions.
v You are using an IBM DB2, Microsoft SQL Server, or Oracle database
v You are installing in a clustered environment
v You are installing on a server or workstation that has IBM WebSphere Application Server installed and
Deployment Manager (DMgr) is running
v You are installing on a configured IBM WebSphere Application Server cluster and all node agents are
running
v You have a database that is already installed and configured
v WebSphere MQ is installed and the listener is running
v You are installing only one InfoSphere MDM offering (for example Standard Edition, Advanced
Edition, or Enterprise Edition)
By using a custom installation, you can select multiple target servers for the InfoSphere MDM application
and the user interface applications, or you can install everything on a single target server. A custom
installation can be run in graphical or silent mode.
This illustration shows a custom deployment in a clustered environment.
After the InfoSphere MDM installation is complete, you can opt to return and install any additional
component by using the modify installation option.
Related concepts:
Preparing for high availability on page 45
To support installation of InfoSphere MDM in high-availability environments, you can configure multiple
instances on multiple host severs. By doing so, if one server or instance goes down, the others can
continue to process traffic.
Related tasks:
Installing a custom installation on page 69
Use this procedure to run a custom installation. A custom installation is the required method if you are
using an Oracle or Microsoft SQL Server database or if you are installing in a clustered environment. You
can also use a custom installation if you are using IBM DB2 database.
Chapter 5, Preparing for a custom installation, on page 27
Before you install InfoSphere MDM, make sure that you complete the planning steps and meet the
prerequisites. These steps are applicable to custom installations only.
Features installed by Installation Manager
This table shows the features that you can install with IBM Installation Manager. In this table, an asterisk
* indicates that the feature can be installed only on a workstation. Two asterisks ** indicate that the
product is not supported for use with a Microsoft SQL Server database.
Dmgr
Local media
Box C
WAS
Node C
MDM
operational
server
Box D
WAS
MDM
operational
server
Box B
Application
Server
Cluster
Application
Server
wsadmin.sh
Database
client
Install
Manager
Download
MDM offering
Node C
Database
Server
Figure 3. Custom installation in a clustered environment
Table 1. MDM installed features
If you install: These features are available:
MDM Standard Edition MDM Database
MDM Operational Server (includes Enterprise Service Oriented
Architecture (ESOA) Toolkit, Java, and Web Services SDKs)
User applications:
v Inspector
v Enterprise Viewer
v Web Reports
v Provider Direct
v Pair Manager*
Message Brokers
Healthcare Point of Service Integrator*
Samples
Patient Clinical Data Search (this item is automatically installed
with Standard Edition and is not listed as an option on IBM
Installation Manager)
MDM Advanced Edition Advanced Edition includes all features that are listed for Standard
Edition plus these applications:
v Business Administration UI**
v Data Stewardship UI**
v Product Maintenance UI**
MDM Enterprise Edition Includes all of the Advanced Edition features, plus Collaborative
Edition, and InfoSphere MDM Extension for Unstructured Text
Correlation
InfoSphere MDM Workbench MDM Workbench* (supports virtual, physical, and hybrid
implementations). IBM Rational Application Developer (RAD) is
also bundled with MDM and must be installed before you install
IBM DB2 If you are planning to use a typical installation deployment, you
can elect to install a DB2 database wrapper. The wrapper contains
the native DB2 database installer and runs in silent mode through
IBM Installation Manager.
If you plan to use a custom installation, then you must install DB2
on your own by using the native DB2 installer.
IBM WebSphere Application Server IBM WebSphere Application Server is required for the
implementation of MDM. If you do not have this application server
installed, you can elect to install it when you install MDM. This
feature is installed when you use the typical installation
deployment.
Other components are also installed by using IBM Installation Manager. Those components are listed here
and their installation instructions are provided in the Information Center.
v Master Data Policy Monitoring
v InfoSphere MDM Application Toolkit
v InfoSphere MDM Collaboration Server
v IBM InfoSphere Master Data Management Custom Domain Hub and InfoSphere MDM Reference Data
Management Hub
Related concepts:
Typical installation deployment type on page 4
A typical installation deployment type must be done on a clean server or a clean workstation and installs
IBM InfoSphere Master Data Management, IBM WebSphere Application Server, and IBM DB2 in a single
run of IBM Installation Manager. Workstation installs include InfoSphere MDM Workbench and IBM
Rational Application Developer (RAD). This deployment type offers the quickest time between
completing the installation and running your first transaction.
Typical server installation on page 5
Typical workstation installation on page 6
Related reference:
MDM user application and operational server association on page 40
Certain user applications are designed to support either a virtual or physical MDM configuration.
Installation requirements
Use this list as a reference before you start the installation. If you are also installing IBM DB2, IBM
WebSphere Application Server, or IBM Rational Application Developer (RAD), the list also offers a
guideline for choosing the correct features to install.
Attention: For an accurate listing of supported hardware and software and required versions, always
review the IBM InfoSphere Master Data Management Server System Requirements page. The link to this
page can be found in the version 11.0 release notes.
To install any of the features and applications, you must have IBM Installation Manager 1.6.0 installed on
the system from which you are running the installation. IBM Installation Manager is packaged with
MDM. IBM Installation Manager can be run only on a 64-bit machine.
The servers or workstations on which you install require a minimum of 30 GB available space.
Typical server installations require 40 - 50 GB available space. Typical workstation installations require 60
- 70 GB.
If the feature or application that you want to install is not listed in this table, see the documentation for
that feature to learn about specific requirements.
Table 2. Installation requirements
If you are planning to install this feature You need this prerequisite:
InfoSphere MDM Standard, Advanced, or
Enterprise Edition
All servers and workstations on which you install and use MDM
components have a supported operating system installed and
configured. Use the product-specific documentation for guidance.
Attention: The Advanced Edition supports installation on Microsoft
Windows operating system for a customization environment only. A
production environment on Windows is not supported for Advanced
Edition. Only Standard Edition is supported on Windows for both
customization and production environments.
Table 2. Installation requirements (continued)
Installation Startup Kit Make sure that you install the Installation Startup Kit if you plan to
use a custom installation.
You do not need to install the kit if you are using typical server or
typical workstation installations.
MDM Operational Server This feature installs the core IBM WebSphere Application Server
bundles, EBAs, and so on for your operational server.
If you are using a typical installation, IBM Installation Manager
installs the IBM WebSphere Application Server and configures it with
default settings.
If you are using a custom installation, you must have the supported
version of IBM WebSphere Application Server installed and an
administrative profile (user name and password) created. After you
install IBM WebSphere Application Server, use the preparing your
application server topics to configure the server.
MDM Database The database component creates the MDM tables and schema.
If you are using a typical installation, IBM DB2 is installed and
configured with default settings by IBM Installation Manager.
For custom installations, you must have a supported database
installed and configured with a user account name and password that
you intend to use to connect to your MDM operational server.
Use the product-specific documentation for guidance. After you install
the database software, use the preparing database topics to configure
the database to support MDM.
User applications A supported web browser must be installed on the workstations that
access the application.
InfoSphere MDM Workbench You must install IBM Rational Application Developer (RAD) for
WebSphere (64-bit) before you install the workbench on your
workstation.
IBM DB2 Install your DB2 database with the selected default features.
This software is required if you are using a typical installation
deployment type.
IBM WebSphere Application Server Select these features to install for your application server:
v IBM WebSphere Application Server
IBM WebSphere Application Server Full Profile
IBM WebSphere Application Server SDK for Java
Technology
Edition 6
Always check the system requirements page for the supported version
number.
Table 2. Installation requirements (continued)
IBM Rational Application Developer (RAD) When you install IBM Rational Application Developer (RAD) , you
must select, at a minimum, these additional required features in IBM
Installation Manager:
v Web Developer Tools
AJAX, Dojo, and HTML
JSF
JSP and servlet
v Enterprise Developer Tools
Data access
OSGi application
Development tools
Remote server stub
You must also make sure that the required 32-bit libraries are available
on your 64-bit operating system. See the related topic below.
Related tasks:
Installing InfoSphere InfoSphere MDM Workbench on page 172
Use this procedure to install InfoSphere MDM Workbench if you are using a custom installation
deployment type and are installing only the workbench.
Chapter 3, Setting up the installation media, on page 23
The installation media for installing InfoSphere MDM is available either as physical CDs or as
downloadable installation image files.
Related reference:
MDM user application and operational server association on page 40
Related information:
InfoSphere MDM Workbench installation on page 171
InfoSphere MDM Workbench is used by implementers and administrators to manage the InfoSphere
MDM environment. By using this application, you can manage algorithms, create composite views, edit
data dictionary tables, and develop member logical models, flows, and mappings to data sources.
32-bit libraries needed on 64-bit operating systems
When you install InfoSphere MDM Workbench and IBM Rational Application Developer (RAD) on a
64-bit workstation, you must have certain 32-bit libraries available on the workstation for a successful
installation.
You must either install the 32-bit libraries that are listed here or install IBM Rational Application
Developer (RAD) in 64-bit mode before you install MDM features.
The required 32-bit libraries are:
v libatk-1.0.so.0
v libfontconfig.so.1
v libfreetype.so.6
v libgdk_pixbuf-2.0.so.0
v libgdk-x11-2.0.so.0
v libglib-2.0.so.0
v libgmodule-2.0.so.0
v libgobject-2.0.so.0
v libgthread-2.0.so.0
v libgtk-x11-2.0.so.0
v libpango-1.0.so.0
v libpangoft2-1.0.so.0
v libpng12.so.0
v libselinux.so.1
v libX11.so.6
v libXcomposite.so.1
v libXcursor.so.1
v libXdamage.so.1
v libXext.so.6
v libXfixes.so.3
v libXft.so.2
v libXinerama.so.1
v libXi.so.6
v libXrandr.so.2
v libXrender.so.1
v libXtst.so.6
v libz.so.1
Related tasks:
Related information:
InfoSphere MDM Workbench installation on page 171
Multiple instance support
Multiple instances of MDM is supported by installing the application in a clustered environment.
All MDM application instances in the clustered nodes within a WebSphere Application Server cell must
be deployed with the same version of MDM product code and must have the same version of the MDM
customization code.
If you want to use the same physical machine (or LPAR) to deploy a second MDM application instance
that is running a different version of MDM product code, you must create a second WebSphere
Application Server cell, deployment manager, and node profile.
If you want to configure a simple functional test environment, you can use the same WebSphere
Application Server cell and node to deploy multiple instances of MDM with the same version of MDM
product code and different version of the MDM customization code. However, some limitations do apply.
Once you uninstall any one of MDM instances in the WebSphere Application Servercell, the other MDM
instances are no longer functional. Do not attempt this configuration in a production environment.
Related tasks:
Installing in a clustered environment on page 72
Use this procedure to run a custom installation in a clustered environment.
Graphical or silent installation
You can install InfoSphere MDM in graphical mode or silent mode. Consider which installation method
works best for your environment.
Graphical mode
If the computer on which you are running IBM Installation Manager can render a graphical user
interface, then graphical mode is the preferred option. IBM Installation Manager displays a series of
screens that walk you through the selection of features, basic parameter configuration, and provides a
summary of the options that you selected before the installation began.
Silent mode
If you are planning identical installations on multiple computers, you might consider the silent option. A
silent installation is started from the command line and uses a response file. This option does not require
you to specify the installation options. Instead, the installation options are read from a response file. You
can create a response file manually or by using the graphical installation wizard. A response file can be
created without installing any software or during an installation. The steps that are taken in the
installation process and errors that are encountered are logged to a file.
Installation Startup Kit
The startup kit extracts files and scripts to help you prepare your environment before you install the
MDM Operational Server. The files and scripts are in STARTUPKIT_INSTALL_HOME.
The Installation Startup Kit is used during custom installations.
Database scripts are run before you begin the MDM installation. The scripts automatically create the
appropriate tables, table spaces, buffer pools, encoding specifications, and triggers that are required for
your edition.
v Scripts to create IBM DB2 databases and table spaces are in STARTUPKIT_INSTALL_HOME/CoreData/Full/
DB2/Standard/ddl/
CreateDB.sql
CreateTS.sql
v Scripts to create DB2 z/OS database and install core and domain data:
STARTUPKIT_INSTALL_HOME/CoreData/Full/DB2/ZOS/pds/*
STARTUPKIT_INSTALL_HOME/Full/DB2/ZOS/pds/*
v Script to create Oracle database: STARTUPKIT_INSTALL_HOME/CoreData/Full/Oracle/Standard/ddl/
create_schema_ora.sql
v Script to create Microsoft SQL Server database: STARTUPKIT_INSTALL_HOME/CoreData/Full/SQLServer/
ddl/CreateDB.sql
v SQL Server files that are used for XA transactions are in STARTUPKIT_INSTALL_HOME/SQLServer JTA:
sqljdbc.dll files to support either 32-bit or 64-bit SQL Server are in win32 and win64_amd64
instjdbc.sql
Use the custSetupMQServer.mqsc and ChannelAuth.mqsc scripts to install the MDM messaging component
when WebSphere MQ is on a computer that is remote from where IBM Installation Manager is running.
The .res files are sample files that can be used for silent installations.
Related tasks:
Installing the Installation Startup Kit on page 44
Use this procedure to install the Installation Startup Kit before you begin preparing your environment for
installation.
Preparing your database on page 46
Use this procedure as a guide when you prepare your database to support a custom installation of MDM.
You must complete this procedure if you are using a custom installation.
Scenario 1, Procedure 3: Preparing IBM WebSphere MQ on page 93
Use this procedure to install and prepare IBM WebSphere MQ as a third step in completing scenario 1.
Related reference:
Silent installation on page 80
A properties file is generated when you are running the interactive installation program. To run silent
installations, you must edit this file or create your own file.
User accounts and groups created by the installer
When MDM is installed, a default administrative user name and user groups are created in the
application server.
The following table lists the user accounts and passwords that are created by the installer.
Table 3. MDM user accounts
User name Password Description
mdmadmin mdmadmin For both typical server and workstation installations, this
user name and password are created for WebSphere
Application Server to manage your operational server. For
custom installations, you can use the mdmadmin user name
and any password you choose.
The user name and password are associated with the
mdm_admin group.
Table 3. MDM user accounts (continued)
User name Password Description
mdmins11 mdmins11 If you use a typical installation on a Linux or UNIX
operating system, this user name and password
combination is created for your DB2 database.
db2admin db3Admin If you use a typical installation on a Microsoft Windows
operating system, this user name and password
combination is created for your IBM DB2 database.
Before you begin a custom installation of MDM, create a IBM WebSphere Application Server profile with
security enabled. The user name and password can be anything that you want.
Important: For security purposes, if you use the default mdmadmin password you are encouraged to
change the user password after installation.
Groups
The following table lists the groups and roles that are created by the installer. You can add users to these
groups through IBM WebSphere Application Server administrative console.
Table 4. MDM user groups
MDM group Description
mdm_admin Administrative role that is equivalent to a super user.
DataSteward This role is available only if user interface components are installed.
mdm_default This role allows user access to the application server container without granting the
user-specific permissions.
mdm_all_ops This role allows user access to all MDM operations.
mdm_all_cvws This role allows user access to all composite views.
mdm_all_ixns This role allows user access to all MDM interactions.
mdm_all_segs_rw This role allows read and write access to all segments.
mdm_all_segs_ro This role allows read only access to all segments.
ServiceConsumer This role maps to all authenticated users and is associated with all entry point
modules.
ServiceProvider This role maps to one default user: mdm. This role is associated with all modules that
are not considered entry points.
Related concepts:
Account prerequisites for custom installations on page 45
Before you begin a custom installation, you must have certain account prerequisites in place.
Related tasks:
Creating a new user and adding the user to an MDM group on page 57
Use this procedure to create a IBM WebSphere Application Server user and then add that user to an
InfoSphere MDM group.
Related reference:
Database user accounts and connections on page 47
All installations require at least one database user account.
Default user accounts created during a typical installation deployment
If you use a typical installation deployment type, the installer creates certain default user accounts.
If you are installing on Linux or UNIX, these defaults are created:
v DB2 database name: MDM11DB
v DB2 user name: mdmins11
v DB2 password: mdmins11
v DB2 home directory: /home/mdmins11
v WebSphere Application Server user name and password: mdmadmin
If you are installing on Microsoft Windows:
v DB2 database name: MDM11DB
v DB2 user name: db2admin
v DB2 password: db3Admin
v WebSphere Application Server user name and password: mdmadmin
Related concepts:
Related tasks:
Chapter 4, Preparing for a typical installation, on page 25
Before you begin a typical server or typical workstation installation, make sure that you complete the
planning steps and meet the prerequisites. These steps are applicable to typical installations only.
Password storage and exposure
During installation, passwords are encrypted by using WebSphere Application Server encryption.
All user interface applications and client applications have a user name and password to connect to the
MDM operational server. These passwords are also encrypted by using the WebSphere Application Server
encryption mechanism. If any of the passwords are changed on the application server, then you must also
apply the change in the respective component properties file as well.
Be aware that when the installer generates response files that can be used for silent installations, these
files contain user passwords in plain text. If plain text passwords stored in the files are against your
organizational policies, use the graphical installation mode.
Encrypting passwords with WebSphere Application Server
If you must change a user name and password in a properties file after installation, you can use this task
to encrypt the new password.
About this task
To prevent the password from being stored in clear text in your properties file, you can use WebSphere
Application Server to encrypt the password.
Procedure
1. Create a text file called mypassword.txt.
2. Add this line to the file: mypassword=user_password and save the file.
3. Run the following command to encode the password value:
v For Microsoft Windows: $NODE_HOME\bin\PropFilePasswordEncoder.bat path\mypassword.txt
mypassword
v For Linux and UNIX: $NODE_HOME/bin/PropFilePasswordEncoder.sh path/mypassword.txt
mypassword
Where $NODE_HOME represents the home directory of the WebSphere Application Server node and path
represents the directory location of the mypassword.txt file.
4. Open the mypassword.txt file and copy the encrypted password value to the password field in your
properties file.
Directory structures
There are three directories you want to understand when you install and use MDM: the installation
directory, the shared directory, and the application server directory.
When you run IBM Installation Manager, you choose an installation path. This path and root directory
are defined in the installation topics as MDM_INSTALL_HOME. MDM_INSTALL_HOME contains resources that are
unique to the installed package. Within this directory are subdirectories for each of the components that
you selected for installation. It also has directories that are specific to the operating system on which you
install.
The MDMShared directory contains resource files that are shared by multiple installed package groups. The
contents can include resources that are needed to run IBM Installation Manager scripts, Java custom code
libraries, and IBM Rational Application Developer for example. For more information about this directory,
see http://pic.dhe.ibm.com/infocenter/install/v1r6/index.jsp?topic=%2Fcom.ibm.cic.agent.ui.doc
%2Fhelpindex_imic.html
The application server path to which the installed components are deployed is defined in the installation
topics as WAS_PROFILE_HOME.
MDM_INSTALL_HOME
Contents of the installation directory includes, but is not limited to, the subdirectories that are listed in
the following table. The specific directories that you see depends on the features that you install.
Table 5. MDM_INSTALL_HOME directories
Directory Description
aix, linux, solaris, win32, win64, zlinux These directories contain operating system-specific files.
BatchProcessor Contains subdirectories and files that are required to run the Batch
Processor tool. The Batch Processor is designed primarily to work
with physical MDM data.
com.ibm.mdm.tools Contains OSGi bundles. An MDM Workbench workspace can be
configured to use these bundles so that reference models and Java
class references can be resolved.
database Contains static schema files.
documentation Contains a messages.properties file in the /nl/ subdirectory, which
is used by the installer during run time. For example, it contains
messages that are used by the installer progress monitor.
EnterpriseIntegrator Contains subdirectories and files that are required to configure and
use the InfoSphere MDM Healthcare Point of Service Integrator
search application.
eventManagmentClient Contains subdirectories and files to support the Event Manager
component. The Event Manager is a triggering component that can
detect events and activities in MDM.
InstallableApps Contains subdirectories and files for any installed user applications.
Applications include, but are not limited to, Data Stewardship UI,
Product Maintenance UI, Inspector, and Web Reports.
IVT Contains subdirectories and scripts that are used to run the
installation verification tests.
logs Contains the logs that are recorded during the installation process.
Table 5. MDM_INSTALL_HOME directories (continued)
Directory Description
ManagementAgent Contains subdirectories and files that are used to run the
configuration management agent, which is used to configure and
manage several MDM features.
ManagementConsole Contains subdirectories and files that are used by the Management
Console. The Management Console is the user interface that supports
the management agent.
MDMCollector Contains subdirectories and files that are used to run IBM Support
Assistant Data Collector.
mds This directory contains files for virtual MDM (formerly IBM Initiate
Master Data Service
). Java and Web Service SDK examples are

installed in the /lib/sdk/examples directory.
It also contains utilities in the /scripts directory, like the madconfig
utility.
MessageBrokerSuite Contains subdirectories and configuration files that are used to
implement and manage the Message Broker components. Message
Broker components are typically used in virtual implementations to
support messaging between source systems and the operational
server and MDM database.
PCDS Contains subdirectories and files that support the Patient Clinical
Data Search user interface.
properties Contents in this directory provide input parameters that are used
when you reset the MDM database and server from MDM
Workbench.
Samples Contains mappings and source code files that can be used in
development environments.
temp Contains all database logs. After installation, if you reset the
database, this directory is used to copy all temporary SQL files.
tmp Contains temporary files that are used during the installation process.
Uninstall This directory contains the scripts that are needed to uninstall the
MDM components.
utils Contains common entity name instance private key generator assets.
Related concepts:
Chapter 7, Installing client applications and individual components, on page 125
IBM Installation Manager gives you the option of selecting to install individual components. This option
is used when you want to install components on workstations or on a server that is different from the
server on which you install the operational server and MDM database.
MAD_ROOTDIR and MAD_HOMEDIR use in version 11.0
MAD_ROOTDIR and MAD_HOMEDIR are both terms and variables that are familiar to users of IBM Initiate
Master Data Service. The definitions of these terms with regards to MDM installation and the operational
server changes in version 11.0.
Previously, the MAD_ROOTDIR contained the installed files, including all binary files. MAD_HOMEDIR contained
all instance configuration information. In 11.0, the contents of the two directories are combined in a sense.
MAD_ROOTDIR contains both the installed binary files and the operational server configuration information.
The concept of a pure MAD_HOMEDIR is no longer valid.
In the documentation, the term MDM_INSTALL_HOME represents the root path where all MDM features are
installed.
During the installation process, a working MAD_ROOTDIR path is created in the MDM_INSTALL_HOME directory.
The path is noted in documentation as MDM_INSTALL_HOME/mds.This path contains the configuration for the
operational server installation and is the location from which all virtual MDM-related tools and utilities
are run.
During deployment to the WAS_PROFILE_HOME, relevant binary files and a copy of the configuration are
created in a runtime MAD_ROOTDIR. In a sense, this location becomes your instance directory. The path to
this runtime configuration is noted in the WebSphere Application Server JVM custom properties file as
the mad.root.dir property.
The configuration in MDM_INSTALL_HOME is primarily there to support the command-line tools. The
configuration in WAS_PROFILE_HOME is used by the operational server during run time. Editing the
deployed files in WAS_PROFILE_HOME affects changes on the running operational server.
Users of IBM Initiate Master Data Service must also understand that in 11.0 the concept of a single
installation directory supporting multiple instances is no longer valid. You must have a separate
installation for every instance of MDM that you require. For example, if you need instances for
production, testing, and training, then you must have three separate installation directories and three
separate deployments of the MDM operational server and database in your WAS_HOME_PROFILE.
In the Message Broker component topics, both MAD_ROOTDIR and MAD_HOMEDIR terms and variables are still
used.
Chapter 3. Setting up the installation media
Procedure
v If you obtained InfoSphere MDM in the form of physical CDs, check that you have all of the
installation disks.
v If you are obtaining installation image files from Passport Advantage
or other method, download and

extract the files into the following directories:
Extract IBM DB2 to a folder called DB2
Extract MDM content to a folder called MDM
Extract InfoSphere MDM Workbench content to a folder called MDMWB
Extract IBM Rational Application Developer (RAD) content to a folder called RAD (The IBM Rational
Application Developer (RAD) files might already extract to a folder called RAD so it might not be
necessary to create this folder.)
Extract WebSphere Application Server for base deployment content to a folder called WAS
Extract WebSphere Application Server for network deployment content to a folder called WASND
Extract WebSphere Application Server Fix Pack to a folder called WASFP
If you are planning to install MDM with a typical server or typical workstation installation and use
LaunchPad to start your installation, you must have your installation media in these directories. All
typical installation deployments are started with LaunchPad. LaunchPad is not used for custom
installations.
Related tasks:
Starting a typical installation process with LaunchPad on page 64
You can use LaunchPad to start the typical installation process. This method is the only way to begin a
typical server or typical workstation installation.
Related reference:
Installation requirements on page 10
Chapter 4. Preparing for a typical installation
About this task
A typical installation deployment type must be done on a clean server or a clean workstation. Your
workstation must be a Microsoft Windows operating system. Other operating systems are not supported
for typical workstation installations.
Procedure
v Review the readme file for system requirements and potential issues that might affect your installation.
v Read the release notes for information about supported product features or enhancements to the
release.
v Complete the Chapter 3, Setting up the installation media, on page 23 task.
v Review Installation requirements on page 10.
v Review Typical installation deployment type on page 4.
v If you are installing in a Dynamic Host Configuration Protocol (DHCP) environment, you must set the
host IP in the /etc/hosts file. This setting is not required if your host uses a static IP. This setting is
not required for custom installations either.
What to do next
Continue with starting your installation with LaunchPad and use the installation instructions for your
typical deployment type.
Related tasks:
Related reference:
Default user accounts created during a typical installation deployment on page 17
Chapter 5. Preparing for a custom installation
About this task
If you plan to do a typical server or typical workstation installation, you do not perform these steps.
v Review the readme file for system requirements and potential issues that might affect your installation
v Read the release notes for information about supported product features or enhancements to the
release
v Review the installation scenarios section, and determine the installation topology that you are going to
use
v Review and complete the installation worksheets
v Set up your installation media
v Use a different database user for each deployment of the offering
v Note these items if you plan on using an IBM DB2 database:
For installation purposes, set up one or more restricted users on a system for database schema users.
Because DB2 uses the operating system to authenticate a new user, use a user ID such as mdmdb1
with a restricted shell. This user is not required to be a member of any of the DB2 groups.
You can also do a simple installation by using a single ID for both the DB2 installation ID and the
schema ID. The default ID is db2inst1. For more information, see your DB2 documentation.
v In addition to these general prerequisites, there are other specific prerequisite tasks for installing
InfoSphere MDM. These tasks are outlined in the following topics.
Related concepts:
Custom installation deployment type on page 7
Multiple instance support on page 13
Related tasks:
Related reference:
Installation and configuration worksheets
The installation worksheets list all of the values that you must specify during an InfoSphere MDM
installation process. Completing the installation worksheets before you install the components can help
you plan your installation, save time, and enforce consistency during the installation and configuration
process.
If you are performing a typical installation, default values are used and you are not prompted for input.
Reuse the worksheets for each runtime environment that you plan to implement. For example, you might
have a production environment, a test environment, and a training environment.
The worksheets are used for applications and components with their base configuration settings that are
defined within IBM Installation Manager. Any operational server, user application, or component
configuration steps that are required outside of IBM Installation Manager are described in separate
individual application or component topics.
Related tasks:
Scenario 1, Procedure 4: Installing MDM on page 93
Use this procedure to install MDM and any selected user applications as the final step in completing
scenario 1.
scenario 2.
scenario 3.
Installation directory worksheet
Use this worksheet to record the root directory of the host on which you want to install InfoSphere
MDM.
If you install more runtime environments later, they might not point to the same database as the one
used for the initial environment. If you are installing multiple runtime environments, reuse the
installation worksheet to define the unique directory values for each environment.
v You must be running in Administrator mode for IBM Installation Manager to write to the Windows
registry. Administrator mode is not used for IBM AIX, Linux, or Solaris.
v Your installation directory path (for both MDM_INSTALL_HOME and IBMIMShared directories) must not
contain any spaces.
v Your installation directory must not contain a directory name that begins with a lowercase letter that
follows a slash (\ or /), (for example, C:/MDM/advanced or C:/advanced/MDM). Do not begin your
directory name with the following: \a, \cx, \e, \f, \n, \r, or \t.
v On a Microsoft Windows 7 operating system, you must install MDM into a directory that is not
virtualized.
The parameters that are listed in the following table equate to prompts or fields that you see in IBM
Installation Manager.
Table 6. InfoSphere MDM installation directory worksheet
Parameter Description Your value
Use the existing package group Choose this option if you want the
InfoSphere MDM components to be
installed into an existing Eclipse shell or
directory. You cannot modify the directory
name if you choose this option.
Do not choose this option if you
previously installed other products by
using IBM Installation Manager, such as
IBM Rational Application Developer
(RAD).
InfoSphere MDM Workbench must be
installed into the same package group as
IBM Rational Application Developer
(RAD).
Create a new package group This option is the default setting. IBM
Installation Manager creates a default
IBM/MDM directory under the root directory
that you choose. Or, you can name the
directory as you want.
For example MDM_INSTALL_HOME/IBM/
MDM_test or MDM_INSTALL_HOME/IBM/
MDM_prod
IBM DB2 or DB2 for z/OS data source worksheet
Use this data source worksheet to identify parameters for the IBM DB2 or DB2 for z/OS
data source to
which your MDM operational server is connecting.
For MDM Standard Edition, all IBM AIX
, Linux, or Solaris data source information is stored in an

odbc.ini file in the MDM_INSTALL_HOME/conf directory.
When you define the names for your databases and user accounts, consider giving the associated
database instance, user account, and data source configuration the same name. You might also want to
include the InfoSphere MDM version in your name. Using this naming convention can help other
members of your organization and IBM Software Support understand the mapping between instances,
accounts, and databases.
Table 7. IBM DB2 or DB2 for z/OS data source worksheet
Database type DB2 and DB2 for z/OS is supported
for all MDM editions.
Database host name Identify the fully qualified address of
the host on which the database is
installed. The default is localhost.
Chapter 5. Preparing for a custom installation 29
Table 7. IBM DB2 or DB2 for z/OS data source worksheet (continued)
Database port Identify the database port or use the
default port number provided. The
DB2 and DB2 for z/OS default is
50000.
Database user name The database user name must have
DBA privileges.
Restrictions on length and supported
characters for user names and
passwords are dependent upon any
restrictions that might be imposed by
your operating system.
If you install MDM using a typical
installation, the DB2 database user
name and password defaults to
mdminst11 on Linux and UNIX and to
db2admin on Microsoft Windows.
Database password Provide a password for the database
user name.
Local database name Provide a name that identifies the
MDM database. The default is MDMDB.
The name must consist of 12 or fewer
alphanumeric characters. Underscore
(_) characters can be used in the
name. Other characters are not
supported.
A physical MDM implementation
uses the DB2 local client to run
database scripts and requires a local
database name.
installation, the database name
defaults to MDM11DB.
Remote database name Provide a name that identifies the
remote MDM database. The default is
MDMDB.
Database home For custom installations, provide the
fully qualified directory where the
database is installed. Provide the
parent directory of SQLLIB. For
example:
Windows: C:\IBM\DB2
IBM AIX, Linux, or Solaris:
/home/db2inst1
installation, the DB2Home defaults to
/home/mdminst11
Table 7. IBM DB2 or DB2 for z/OS data source worksheet (continued)
Database schema Specify the database schema name.
By default the schema name is the
same as the database application
user.
Installing MDM Database manually If you are planning to install the
physical MDM database manually,
select this option to extract the scripts
that are used for manual installation.
Virtual MDM tables are installed
even if this option is selected.
Related tasks:
Preparing a DB2 database on page 48
Use this procedure to set up an IBM DB2 database for installation of InfoSphere MDM.
Scenario 1, Procedure 2: Preparing the IBM DB2 database on page 92
Use this procedure to install and prepare your DB2 database as a second step in completing scenario 1.
Microsoft SQL Server data source worksheet
Use the Microsoft SQL Server data source worksheet to identify parameters for the data source to which
your MDM operational server is connecting.
For MDM Standard Edition, all IBM AIX
, Linux, or Solaris data source information is stored in an

Attention: The Business Administration, Data Stewardship, and Product Management user applications
are not supported for use with a Microsoft SQL Server database.
Table 8. Microsoft SQL Server data source worksheet
Database type Microsoft SQL Server is supported
for MDM Standard Edition only. The
type must be MSSQLU.
Microsoft SQL Server default is 1433.
Table 8. Microsoft SQL Server data source worksheet (continued)
DBA privileges.
user name.
Database name Provide a name that identifies the
MDM database. The default is MDMDB.
Database schema Specify the database schema name.
By default the schema name is the
same as the database application
user.
Database server name Specify the name of the database
server to which the MDM database
instance connects.
Database file group Specify the name of a file group for
the database. A file group is a logical
structure to group objects (collections
of files) in a database. In Microsoft
SQL Server, file groups are used to
help with data placement and
administrative tasks such as backup
and restore operations.
Use Windows Native Authentication Choose whether you want the
operational server to authenticate to
the database by using Microsoft
Windows credentials. The default is
to use SQL Server credentials.
If you plan to use Windows
authentication, your DBA must set
the default schema of the login user
to the schema that will be used by
IBM Installation Manager.
Related tasks:
Preparing an Microsoft SQL Server database on page 50
Use this procedure to set up a Microsoft SQL Server database for installation of InfoSphere MDM.
Scenario 3, Procedure 2: Prepare Microsoft SQL Server database on page 98
Use this procedure to install and prepare your SQL Server database as a second step in completing
scenario 3.
Oracle data source worksheet
Use the Oracle data source worksheet to identify parameters for the data source to which your MDM
operational server is connecting.
For MDM Standard Edition, all IBM AIX, Linux, or Solaris data source information is stored in an
Table 9. Oracle data source worksheet
Database type Oracle is supported for all MDM
editions.
Oracle default is 1521.
DBA privileges.
user name.
Database name Provide the database system ID
(SID).
TNS Specify the name of the service that
is used to connect to the Oracle
database. This parameter is required
as this service can also be used to
connect to remote database.
Table 9. Oracle data source worksheet (continued)
Database home Provide the fully qualified directory
where the database is installed. For
example:
Windows: C:\App\oracle\product\
11.2.0\db_1
IBM AIX, Linux, or Solaris:
/home/mdm/oracle/product/11.2.0/
db_1
Related tasks:
Preparing an Oracle database on page 51
Use this procedure to set up an Oracle database for installation of InfoSphere MDM.
Scenario 2, Procedure 2: Preparing the Oracle database on page 95
Use this procedure to install and prepare your Oracle database as a second step in completing scenario 2.
WebSphere Application Server installation worksheet
Use the IBM WebSphere Application Server configuration worksheet to identify parameters for the
application server that is used to host your MDM operational server.
Table 10. IBM WebSphere Application Server installation worksheet
Deployment type Specify the deployment type and
note the IBM WebSphere Application
Server profile name. Your options are
Network Deployment or Base.
Network deployment is used for
server or cluster installations. A base
deployment is typically used in
workstation or demonstration
installations.
If you choose Network Deployment,
the installer runs a sequence of
commands against the IBM
WebSphere Application Server
deployment manager process to
configure application servers and
deploy applications. The deployment
manager and node agents must be
configured and running before the
deployment can proceed. For
example, use a profile name of
Dmgr01.
If you select Network Deployment,
the installer can also run against an
IBM WebSphere Application Server
cluster. The installation program
automatically detects the cluster. If
the cluster is configured, the default
is to deploy the applications on a
cluster. You can select to deploy the
applications on a single server
instead.
If you choose Base, then the
operational server is deployed on
server1 of the IBM WebSphere
Application Server Base. The installer
runs a sequence of commands against
server1 to configure the application
server and deploy applications. Make
sure that server1 is running before
you proceed with the deployment.
For example, use a profile name of
AppSrv1.
home
Specify the fully qualified directory
in which IBM WebSphere Application
Server is installed. The default is
/opt/IBM/WebSphere/AppServer.
profile home
If you are using a base deployment,
specify the fully qualified path of the
application server profile home
directory. The default is
/opt/IBM/WebSphere/AppServer/
profiles.
Table 10. IBM WebSphere Application Server installation worksheet (continued)
Host name Identify the fully qualified address of
the host on which IBM WebSphere
Application Server is installed. The
default is localhost.
SOAP port Identify the SOAP port of the
deployment manager on the remote
computer, if you are using remote
deployment. The default is 8879.
User name Identify the IBM WebSphere
Application Server user name. The
user must have administrative
privileges.
Password The IBM WebSphere Application
Server user password.
Cell Specify the IBM WebSphere
Application Server cell where you
want to deploy MDM.
If you have IBM WebSphere
Application Server already installed
and configured, you can click
Retrieve Host Details during the
installation process and have IBM
Installation Manager retrieve the
information for Cell, Node, and
Server.
Node Specify the IBM WebSphere
want to deploy MDM.
After you select the cell in IBM
Installation Manager, all of the nodes
within that cell are available in the
list.
Server Specify the server where you want to
deploy MDM.
After you select the node in IBM
Installation Manager, all of the
servers that are available for that
node show in the list.
If you want to create a new server
for deployment, you can specify the
new name on the configuration panel
and it is created in IBM WebSphere
Application Server during the
installation process.
Install MDM application on cluster If you have an existing WebSphere
Application Server cluster, this option
is available on the configuration
panel. Select this option if you want
to install the MDM application in a
clustered environment.
Table 10. IBM WebSphere Application Server installation worksheet (continued)
Cluster If you are installing in a clustered
environment, select the cluster where
you want to deploy your
applications.
Related concepts:
Prepare your application server on page 53
InfoSphere MDM components run inside WebSphere Application Server. The application server provides
infrastructure for component-to-component communication, authentication, and logging. If you are
planning to install InfoSphere MDM by using a custom installation, you must prepare an application
server before you begin the installation process.
Related tasks:
Scenario 1, Procedure 1: Preparing WebSphere Application Server Network Deployment on page 91
Use this procedure to install and prepare your application server as a first step in completing scenario 1.
Scenario 3, Procedure 1: Prepare WebSphere Application Server Network Deployment on page 97
MDM application configuration worksheet
Use the application configuration worksheet to identify parameters for the MDM operational server.
Installation Manager on the Application Configuration panel.
Table 11. MDM application installation worksheet
MDM application name Specify the name of the MDM
operational server. This name is used
in IBM WebSphere Application
Server. The default is E001.
User mdmadmin password Specify the password for the MDM
administrator user.
RMI port Specify the port on which the Remote
Method Invocation (RMI) registry
service listens for connections from
other services. In a clustered
environment, all nodes must use the
same RMI port to communicate. The
default is 9999.
Matching style Specify whether you want to use a
probabilistic or deterministic
matching style.
Enable multiple time zone
deployment
Select this option if your application
is running across different time
zones, or your data has time-sensitive
values under different time zones.
Default time zone Select the client default time zone
from the list. If a time zone is not
specified, the application server time
zone is used.
Table 11. MDM application installation worksheet (continued)
Messaging Specify the messaging type for your
implementation.
If you want to use the internal
WebSphere messaging, select IBM
WebSphere Default Messaging.
Most virtual MDM configurations
will select IBM WebSphere Default
Messaging and install the Message
Brokers feature.
IBM WebSphere MQ is a separate
enterprise product and must be
installed before you install MDM. If
you opt for IBM WebSphere MQ,
specify values for the following
parameters.
Message queue home Specify the fully qualified directory
of the messaging queue home. The
default is /usr/mqm.
Queue manager name Specify the name for the queue
manager. For example,
CUSTOMER.QUEUE.MANAGER.
MQ host name Specify the name of the server that is
hosting WebSphere MQ.
MQ port Specify the WebSphere MQ listening
port number.
Channel name Specify the channel name. Channels
are used to transmit messages
between queue managers.
User name Specify the WebSphere MQ user
name.
Password Specify the password.
Configure Messaging Server Select this option to deploy your
parameters and configure your
messaging server.
Related tasks:
User applications installation worksheet
Use this worksheet to record parameters for the user applications that you are planning to install.
Reuse this worksheet for each user application or note any differences between applications in the
worksheet.
Table 12. User application installation worksheet
Deployment type Specify whether your IBM
deployment is Base or Network.
Network deployment is used for
server or cluster installations. A base
deployment is typically used in
workstation or demonstration
installations.
profile home
If you are using a base deployment,
specify the fully qualified path of the
application server profile home
directory. The default is
/opt/IBM/WebSphere/AppServer/
profiles
Host name Specify the name of the IBM
WebSphere Application Server where
the MDM operational server server is
deployed.
SOAP port Specify the port number for the
MDM operational server or use the
default of 8879.
User name Specify the administrative user name
for this application.
Password Specify the administrative user
password.
Cell Specify the IBM WebSphere
want to deploy the application. If
you have IBM WebSphere
Application Server already installed
and configured, click Retrieve Host
Details during the installation
process to retrieve the information
for Cell, Node, and Server.
Node Specify the IBM WebSphere
Application Server node where you
want to deploy the application.
Server Specify the IBM WebSphere
Application Server server or servers
where you want to deploy the
application.
Install MDM application on cluster If you have an existing WebSphere
Application Server cluster, this option
is available on the configuration
panel. Select this option if you want
to install MDM application in a
Cluster If you are installing in a clustered
environment, select the cluster where
you want to deploy your
applications.
Related tasks:
Installing Business Administration UI on page 126
Use this procedure to install the Business Administration UI.
Installing Data Stewardship UI on page 127
Use this procedure to install the Data Stewardship UI. This data stewardship application supports data
governance for physical MDM data.
Installing Product Maintenance UI on page 128
Use this procedure to install the Product Maintenance UI.
MDM user application and operational server association
The following table associates user applications with the MDM configuration that they support.
Table 13. MDM user applications
Virtual MDM applications Physical MDM Applications
InfoSphere MDM Inspector
InfoSphere MDM Enterprise Viewer
InfoSphere MDM Web Reports
InfoSphere MDM Provider Direct
InfoSphere MDM Pair Manager
InfoSphere MDM Business Administration
InfoSphere MDM Data Stewardship
InfoSphere MDM Product Maintenance
Related reference:
History installation worksheet
Use this worksheet to record parameters for your history trigger configuration.
History triggers are used by physical MDM operational servers.
There are two sets of triggers that generate data for physical MDM database history tables. The first set is
for the core and domain tables. The second set is for the configuration management tables. Each set
consists of history triggers and delete triggers.
Table 14. History installation worksheet
Industry Specify the industry type that is
supported in this implementation.
You can specify only one type.
There are four supported industry
types. Each option installs the code
tables and data for that industry
type.
v Insurance - Choose this option for
lines of business such as Life,
Health, Annuities, Pensions,
Property and Casualty, and others.
v Banking - Choose this option for
lines of business such as Retail
Banking, Commercial Banking,
Credit Cards, Loans, and others.
v Telecommunication - Choose this
option for lines of business such as
Wireless, Cable Television, Satellite
Television, Internet, Telephone
Services, and others.
v Manufacturing - Choose this
option for lines of business such as
Precision Tools, Aerospace,
Electrical, Heating, Mechanical,
and others.
History triggers There are three history trigger
options. You can specify only one.
v None. Choose this option if you do
not want to install any triggers.
Choosing this option prevents
history from being stored in the
database.
v Simple. Choose this option to
install only the update triggers.
When a record is updated in the
database, a copy of that record
(before the update) is added to the
history table. Past versions of the
record are stored in the history
table.
v Compound. Choose this option if
you want to install both insert and
update triggers. When a record is
added to the database, or when a
record is updated in the database,
a copy of the record is added to
the history table. Copies of both
the current and past versions of
the record are stored in the history
table.
Table 14. History installation worksheet (continued)
Case sensitive searches By default, name searches for
contracts, products, and categories
are not case-sensitive. Check the
Enable case-sensitive searches check
box only if you want to place
case-sensitive restrictions on your
searches.
Once this feature is activated,
database objects are created and you
cannot deactivate the option.
Code table languages Translated code table values used for
predefined lists and error messages
are included with the physical MDM
operational server.
English is the default language.
Application resource language Specify the corresponding language
translations for the user interface to
install.
Prepare IBM Installation Manager
All components of the InfoSphere MDM editions are installed by using IBM Installation Manager.
IBM Installation Manager uses defined repositories to determine what packages are available for you to
install. These repositories point to your installation media.
Offerings must be manually added to the IBM Installation Manager repositories.
Launchpad is included in the MDM download and can be used to start IBM Installation Manager for
typical server and workstation installations. If you have IBM Installation Manager already installed,
LaunchPad checks the version number. If you do not have the current version, it is automatically
updated. If you do not have IBM Installation Manager installed, Launchpad initiates the installation.
If you are planning a custom installation, continue with the tasks for installing IBM Installation Manager
and adding your repositories. If you are planning a typical server or typical workstation installation,
these tasks are not required.
Related tasks:
scenario 1.
scenario 2.
scenario 3.
Installing Installation Manager
Use this procedure if IBM Installation Manager is not installed.
About this task
If you are using a typical server or typical workstation installation, LaunchPad installs IBM Installation
Manager automatically and completing this task is not necessary.
Do not install IBM Installation Manager in admin mode.
Procedure
1. From your installation media or from Passport Advantage, download IBM Installation Manager
version 1.6.
2. Extract the agent.installer.win32.win32.x86.zip file.
3. From a command prompt, start install.exe and complete the installation wizard.
What to do next
Continue with adding offerings to IBM Installation Manager.
Adding offerings to IBM Installation Manager
Use this procedure to add InfoSphere MDM to the list of offerings that are installed by IBM Installation
Manager.
Before you begin
Perform this task if you are using a custom installation. If you are using a typical server or typical
workstation installation, this task is not necessary.
Make sure that you installed IBM Installation Manager and that you did not install it in admin mode.
Procedure
1. Start IBM Installation Manager.
2. Click File > Preferences.
3. On the Preferences dialog, select Repositories > Add Repository.
4. On the Add Repository dialog, click Browse.
5. Locate and select the MDM packages that you want to install. For example, download_path/MDM/
disk1/diskTag.ini.
6. Add any additional offerings, such as IBM WebSphere Application Server, IBM DB2, or InfoSphere
MDM Workbench.
7. On the Add Repository dialog, click OK.
8. On the Preferences dialog, click OK.
What to do next
Continue with preparing for and installing the MDM operational server and applications.
Installing the Installation Startup Kit
installation.
Before you begin
Ensure that you add the startup kit offering to the IBM Installation Manager repositories.
About this task
The startup kit contains scripts that are used to create databases and profiles that are needed to prepare
your installation environment.
Procedure
2. On the IBM Installation Manager home screen, click Install.
3. On the Install Packages panel, select the Installation Startup Kit and click Next.
4. Continue through the panels, selecting the default package group and install packages.
5. Click Install.
6. Click Finish when the installation is complete and close IBM Installation Manager.
Results
The scripts and files are extracted to the STARTUPKIT_INSTALL_HOME directory.
What to do next
Continue with preparing your database and your application server.
Related tasks:
Installing silently by using a response file on page 88
You can install InfoSphere MDM silently, where the installation choices are provided in an options file
instead of in the interactive IBM Installation Manager panels. This type of installation is helpful when
you are doing multiple identical installations.
Installing the InfoSphere MDM messaging server component manually on page 122
You can use IBM Installation Manager to create the InfoSphere MDM messaging server component, or
you can install it manually.
scenario 3.
Related reference:
Installation Startup Kit on page 14
Preparing for high availability
To support installation of InfoSphere MDM in high-availability environments, you can configure multiple
instances on multiple host severs. By doing so, if one server or instance goes down, the others can
continue to process traffic.
The MDM operational serveruses an IBM WebSphere Application Server container and can be deployed
on single server or on a cluster as configured in the container. The cluster can be pre-configured on the
server. The installer can detect a clustered environment and deploy to that environment by using a
custom installation.
Review the installation scenarios before you begin the installation to better understand how to support
high availability and clustered environment requirements.
Related concepts:
Account prerequisites for custom installations
v You must be logged on with an account that owns the IBM WebSphere Application Server directories
and binary files. The database JDBC drivers must be accessible by this account. The instructions in the
preparation topics assume that you are doing the installation locally on the server.
v For best results, install InfoSphere MDM as a non-root user:
For IBM WebSphere Application Server, use the wasadmin ID. This ID must own a DB2 client or a
DB2 instance and be a member of the mqm management group.
For DB2:
- The suggested installation method is to set up one or more restricted users on a system for
database schema users. Because DB2 uses the operating system to authenticate to a new user, a
user ID such as mdmdb1 with a restricted shell is the best choice. This user is not required to be a
member of any of the DB2 groups.
- You can also do a simple installation by using a single ID for both the DB2 installation ID and the
schema ID. The default ID is db2inst1. For more information about IBM DB2, see the product
documentation.
A different database user and schema must exist for each deployment of InfoSphere MDM. Different
databases for each deployment are not required.
When you install on IBM WebSphere Application Server, ensure that no server named server or
cluster named cluster is being used on IBM WebSphere Application Server. The names server and
cluster are used by the MDM installation.
Related reference:
Database user accounts and connections on page 47
User accounts and groups created by the installer on page 15
application server.
Preparing your database
About this task
If you are planning to do a typical installation, this task is not required because the database is created
automatically.
When you define names for your databases and user accounts, consider giving the associated database
instance, user account, and data source configuration the same name. You might also want to include the
MDM version in the name. For example, you might name each of these elements mdmprod_110 for the
production database. Using this naming convention can help other members of your organization and
IBM Software Support understand the mapping between instances, accounts, and databases.
Procedure
1. Complete the applicable database worksheets that are listed as related reference.
2. Install the database software and create database user accounts with appropriate permissions. Use the
documentation provided by the database vendor to complete your installation. Review the database
user accounts topic before installing the database software. Typical server and workstation
installations install an IBM DB2 wrapper. For custom installations, use the standard DB2 installation
media.
3. Make sure that you installed the Installation Startup Kit. This toolkit provides scripts that are used to
create the MDM database.
4. Create the MDM database by using the script that is applicable to your database type. The scripts
automatically create the appropriate table spaces, buffer pools, and encoding specifications that are
required for your MDM edition. For details about some of these settings, see the related reference
topics.
Related tasks:
installation.
scenario 3.
Related reference:
Database user accounts and connections
To bootstrap the database (which is typically done during installation), process an upgrade, define new
entity types, or create implementation-defined segments, the database user account must have certain
permissions. This primary user account must have permission to:
v Create table and drop table
v Create index and drop index
v Select, insert, update, and delete
After the database is bootstrapped and entity types and implementation-defined segments are configured,
you can opt to restrict the user account if required. A restricted user account has only select, insert,
update, and delete permissions.
Consider configuring a one-to-one relationship between the database user and the database so that users
do not have access to multiple databases. This model provides a security layer that can prevent one
database user from dropping the tables of another.
Record the database user account credentials; you need this information to complete the installation.
The database connection count is the sum of connections that are used by the operational server and by
any entity managers that you plan to use. Some operational server or InfoSphere MDM Workbench
processes also require more database connections, which are closed when the process is completed. Allow
more connections for these processes in your configuration.
Related concepts:
Account prerequisites for custom installations on page 45
Related reference:
application server.
Preparing a DB2 database
About this task
To create the MDM database, you must be logged in to DB2 with the admin user account that you
created when you installed DB2.
You must also have the Installation Startup Kit installed.
Attention: If you are installing InfoSphere MDM on z/OS, skip the database preparation steps and go
to Installing on z/OS on page 77.
Procedure
1. Go to the STARTUPKIT_INSTALL_HOME/CoreData/Full/DB2/Standard/ddl/ directory (where
STARTUPKIT_INSTALL_HOME is the location of the installed kit).
2. Modify the CreateDB.sql script.
a. Open the CreateDB.sql file in a text editor.
b. Replace the variables in the script with values as described at the top of the script. Variables are
enclosed in <>, such as <DBNAME>.
3. Change to the DB2 admin user account.
For Microsoft Windows:
a. Open the Start menu and go to All Programs > IBM DB2 > DB2COPY1 (default).
b. Press Shift and right-click on Command Window and the select Run as different user....
c. Enter the DB2 admin user name and password.
For Linux and UNIX:
a. Open the Linux or UNIX terminal.
b. At the command-line prompt, type su - user where user is the DB2 admin user.
4. Run the CreateDB.sql script to create the database.
a. Go to the directory where your CreateDB.sql file is located.
b. Run the applicable command.
v For Microsoft Windows: db2 -td; -f CreateDB.sql
v For Linux and UNIX: db2 -tvf STARTUPKIT_INSTALL_HOME/database/CoreData/Full/DB2/
Standard/ddl/CreateDB.sql
5. Modify the CreateTS.sql script.
a. Open the CreateTS.sql file in a text editor.
b. Replace the variables in the script with values as described at the top of the script. Variables are
enclosed in <>, such as <DBNAME> or <TABLE_MDS4K>.
Attention: The values substituted for variables in this file must match how your database is set
up, or the installer will not be able to complete successfully.
6. Run the CreateTS.sql to create your table spaces.
a. Run the applicable command.
v For Microsoft Windows: db2 -td; -f CreateTS.sql
v For Linux and UNIX: db2 -tvf STARTUPKIT_INSTALL_HOME/database/CoreData/Full/DB2/
Standard/ddl/CreateTS.sql
7. After you run CreateTS.sql, verify that your table space settings are as you expect.
For Microsoft Windows:
v Open command prompt and type db2cmd
v Connect to database using this command: connect to MDMDB user DBUSER using DB2PWD
v When you are connected, type: db2 list tablespace
For Linux and UNIX:
v Open new terminal and type db2
v Connect to database using this command: connect to MDMDB user DBUSER using DB2PWD
v When you are connected, type: db2 list tablespace
Related tasks:
installation.
Related reference:
IBM DB2 or DB2 for z/OS data source worksheet on page 29
Use this data source worksheet to identify parameters for the IBM DB2 or DB2 for z/OS data source to
Preparing your DB2 database on a different server than InfoSphere MDM
Use this procedure when your DB2 database and MDM installations are on different servers.
Procedure
1. On the machine where you plan to install MDM, you must do the following:
v Install the DB2 client software
v Catalog the remote database to the local server
2. Use the WebSphere Application Server Integrated Solutions Console to create a DB2_JDBC_DRIVER_PATH
WebSphere Application Server environment variable, pointing to the DB2 instance home on the local
machine and targeting the node level.
Preparing your DB2 database to use InfoSphere MDMin a clustered environment
Use this procedure to prepare your DB2 database when you are installing MDM in a clustered
environment.
Procedure
1. Install the DB2 client software.
2. Catalog the database for every machine in the cluster.
3. Create a DB2_JDBC_DRIVER_PATH WebSphere Application Server environment variable that points to the
DB2 home that is present locally on that machine for every node in the cluster.
Related tasks:
Preparing an Microsoft SQL Server database
About this task
To create the MDM database, you must be logged in to Microsoft SQL Server either with Windows
Authentication or with the admin user account that you created when you installed Microsoft SQL Server.
If you plan to use Windows authentication, your DBA must set the default schema of the login user to
the schema that will be used by IBM Installation Manager.
You must also have the Installation Startup Kit installed before you begin database preparation.
Procedure
1. Modify the CreateDB.sql script that is provided in the Installation Startup Kit.
a. Go to the STARTUPKIT_INSTALL_HOME/CoreData/Full/SQLServer/ddl/directory (where
b. Open the CreateDB.sql file in a text editor.
c. Replace the variables in the script with values as described at the top of the script. Variables are
enclosed in <>, such as <DBNAME>.
2. Run the CreateDB.sql script by using sa user to create the database.
When you use Windows authentication rather than SQL authentication to access database, you must
do one of the following options:
v If the client and SQL Server are in same domain, the login user that the client uses must be added
into the SQL Server Security logins
v If the client and SQL Server are in different domains, then the two domains must be trusted
3. Copy the sqljdbc.dll file to the /Binn directory for the instance of SQL Server that is running.
v If you are using SQL Server 32-bit, the sqljdbc.dll file is in STARTUPKIT_INSTALL_HOME/SQLServer
JTA/win32
v If you are using SQL Server 64-bit, the file is in STARTUPKIT_INSTALL_HOME/SQLServer
JTA/win64_amd64
4. Install the XA stored procedures that are used by the JDBC driver. From the
STARTUPKIT_INSTALL_HOME/SQLServer JTA directory, run the instjdbc.sql script as the sa user.
5. Enable MS DTC for XA transactions.
For Windows 7 and Windows 2008
a. From the desktop, click the Start icon and open Component Services using one of these options.
v Type dcomcnfg in the Start Search box.
v Type %windir%/system32/comexp.msc in the Start Search box.
b. Go to Computers > My Computer > Distributed Transaction Cooridinator.
c. Right-click on Local DTC and select Properties.
d. On the Local DTC Properties dialog, open the Security tab.
e. Select Enable XA Transactions and click OK. This step restarts the MS DTC service.
f. Click OK on the Local DTC Properties dialog and close Component Services.
g. Restart Microsoft SQL Server to ensure that it syncs up with the MS DTC changes. Verify that
XATransactions=1 in Microsoft operating system registry.
Related tasks:
installation.
scenario 3.
Related reference:
Microsoft SQL Server data source worksheet on page 31
Preparing your Microsoft SQL Server database on a different server than
InfoSphere MDM
Use this procedure when your Microsoft SQL Server database and your MDM installations are on
different servers.
Procedure
Install a Microsoft SQL Server client on the machine where you plan to install MDM.
After you install the client, the client account is automatically added into the database user account. You
are not required to set the MSSQLSERVER_JDBC_DRIVER_PATH in your IBM WebSphere Application
Server environment.
Preparing your Microsoft SQL Server database to use InfoSphere MDM in a
clustered environment
Use this procedure to prepare your Microsoft SQL Server database when you are installing MDM in a
Procedure
Install a Microsoft SQL Server client on every machine on which you plan to install MDM components.
After you install the client, the client account is automatically added into the database user account. You
are not required to set the MSSQLSERVER_JDBC_DRIVER_PATH in your IBM WebSphere Application
Server environment.
Preparing an Oracle database
Before you begin
To create the MDM database, you must be logged in to Oracle with the admin user account that you
created when you installed Oracle.
You must also have the Installation Startup Kit installed.
Procedure
1. Modify the create_schema_ora.sql script that is provided in the Installation Startup Kit.
a. Go to STARTUPKIT_INSTALL_HOME/CoreData/Full/Oracle/Standard/ddl/ directory (where
b. Open the create_schema_ora.sql file in a text editor.
c. Replace the variables in the script with values as described at the top of the script. Variables are
enclosed in <>, such as <DBNAME>. Database table space variables must be entered as:
v <TABLE_SPACE> replace with DATSPACE
v <INDEX_SPACE> replace with IDXSPACE
v <TABLE_SPPMD> replace with EMESPACE1
v <TABLE_SPPMI> replace with EMESPACE2
v <LONG_SPACE> replace with LOBSPACE
2. Create the Oracle database.
a. Go to ORACLE_HOME/bin.
b. Open a command prompt and type sqlplus.
c. Run the create_schema_ora.sql script to create the database. Use this command:
@CreateDB_oracle.sql
Related tasks:
installation.
Related reference:
Oracle data source worksheet on page 33
Preparing your Oracle database on a different server than InfoSphere MDM
Use this procedure when your Oracle database and MDM installations are on different servers.
Procedure
1. Install an Oracle client on the machine where you plan to install InfoSphere MDM.
2. Point the TNS entry in the client machine to the database server.
3. Use the WebSphere Application Server Integrated Solutions Console to create an
ORACLE_JDBC_DRIVER_PATH environment variable that points to the Oracle database home on the local
machine and targets the node level.
Preparing your Oracle database to use InfoSphere MDM in a clustered
environment
Use this procedure to prepare your Oracle database when you are installing MDM in a clustered
environment.
Procedure
1. Install the Oracle client on every machine.
2. Point the TNS entry to the database server machine.
3. Create an ORACLE_JDBC_DRIVER_PATH WebSphere Application Server environment variable that points
to the Oracle database home that is present locally on that machine for every node in the cluster.
Related tasks:
ODBC drivers installed with standard edition
The ODBC drivers that are applied by the installer is determined by the database type you define.
The wire driver enables an operational server that supports a virtual MDM configuration to communicate
with the database and write data to the schema. However, the operational server host requires installation
of the applicable database client to enable bulk load operations.
The operational server includes the ODBC drivers that are listed here. Others are not supported.
v Oracle Wire
v Oracle Net
v IBM DB2 Wire (DB2 and DB2 for z/OS)
v Microsoft SQL Server Wire
For Oracle databases, the properties passed to the madconfig utility during the installation process
determines whether to install the wire or net driver. If empty values are passed for the database host, the
Oracle Net driver is installed; which requires installation of the Oracle client on the operational server
host.
Related tasks:
Enabling support for Oracle non-wired driver on page 77
If you are using a virtual MDM and plan to use a non-wired Oracle database driver, complete these steps
after you install the MDM database and features.
Prepare your application server
If you are planning to do a typical installation, your application server is automatically installed and
configured.
You can choose to prepare a new application server or reuse an existing application server.
Review these prerequisites before you prepare the application server for MDM installation.
v Ensure that you installed any prerequisite software and that the correct environment is set up.
v Set the database utility for DB2 or Oracle to your system path. Microsoft SQL Server does not require
this step.
v Review the application server configuration worksheet to understand the basic parameters that are
requested during the installation process. Completing the worksheet ensures that you have the basic
information necessary to complete the installation. For multiple instances, copy the worksheet and
prepare a separate worksheet for each deployment.
v Use the wasadmin ID when you prepare the application server. If you are using DB2, this ID must own
a DB2 client or a DB2 instance. The ID must be a member of the WebSphere MQ mqm group if you are
using WebSphere MQ for messaging. This group is used to administer WebSphere MQ.
v Ensure that you set up the WAS_HOME and the JAVA_HOME Java path for IBM WebSphere Application
Server.
v Ensure that there is no server named server or cluster named cluster.
Attention: For custom installations, you must have the WebSphere Application Server deployment
manager (Dmgr) JVM Heap size arguments set to 512MB and 1024MB. This is especially important if you
plan to install the Product Maintenance UI.
Related tasks:
Related reference:
WebSphere Application Server installation worksheet on page 34
To set an IBM DB2 utility path
If you are using an IBM DB2 database, you must set the database utility to your system path.
Procedure
At a command line, add the DB2 database utilities to the PATH variable on your system.
For example:
export PATH=DB2_HOME/sqllib/bin:$PATH
What to do next
You can also add the above lines to your user profile.
To set an Oracle utility path
If you are using an Oracle database, you must set the database utility to your system path.
Procedure
At the command line, add the Oracle database utilities to the PATH variable on your system.
For example:
export ORACLE_HOME=ORACLE_HOME
export PATH=$ORACLE_HOME/bin:$PATH
What to do next
You can also add the above lines to your user profile.
Preparing WebSphere Application Server Network Deployment for a
managed server deployment
Use this procedure to set up IBM WebSphere Application Server Network Deployment for a managed
server deployment.
About this task
Use this procedure for custom InfoSphere MDM installations only.
If you are planning a typical installation, this procedure is not required.
This procedure assumes that you have IBM WebSphere Application Server already installed.
Procedure
1. Create a deployment manager (dmgr).
a. Open a command prompt and browse to your IBM WebSphere Application Server installation
directory.
b. At the command-line prompt, run this command from the WAS_HOME\bin directory:
For Microsoft Windows: manageprofiles.bat -create -profileName dgmrName -profilePath
WAS_PROFILE_HOME\dmgrName -templatePath WAS_HOME\profileTemplates\management -serverType
DEPLOYMENT_MANAGER -enableAdminSecurity true -adminUserName userName -adminPassword
password
For Linux or UNIX: manageprofiles.sh -create -profileName dgmrName -profilePath
WAS_PROFILE_HOME/dmgrName -templatePath WAS_HOME/profileTemplates/management -serverType
DEPLOYMENT_MANAGER -enableAdminSecurity true -adminUserName userName -adminPassword
password
2. Start the deployment manager by running this command from the WAS_HOME\bin directory:
MicrosoftWindows: startManager.bat -profileName dmgrProfileName or Linux and UNIX:
startManager.sh -profileName dmgrProfileName
3. Find out which ports are assigned for the deployment manager.
a. Open the profiles/dmgrProfileName/logs/AboutThisProfile.txt file.
b. Find the entry for the Management SOAP connector port and make note of this number.
c. Find the entry for the administrative console port and make note of this number.
4. Create a node that is attached to the deployment manager by running this command from the
WAS_HOME\bin directory:
For Microsoft Windows: manageprofiles.bat -create -profileName profileName -profilePath
WAS_PROFILE_HOME\profileName -templatePath WAS_HOME\profileTemplates\managed -hostName
hostName -nodeName NodeName -cellName cellName -dmgrHost dmgrHost -dmgrPort dmgrPort
-dmgrAdminUserName userName -dmgrAdminPassword password
For Linux or UNIX: manageprofiles.sh -create -profileName profileName -profilePath
WAS_PROFILE_HOME/profileName -templatePath WAS_HOME/profileTemplates/managed -hostName
hostName -nodeName NodeName -cellName cellName -dmgrHost dmgrHost -dmgrPort dmgrPort
-dmgrAdminUserName userName -dmgrAdminPassword password
Where:
v nodeProfileName - is name of the node
v username - is the user you specified in step 1
v password - is the password you specified in step 1
v dmgrPort - is the management SOAP connector port number from step 3.b.
5. Start the node by running this command from the WAS_HOME\bin directory: Microsoft Windows:
startNode.bat -profileName nodeProfileName or Linux and UNIX: startNode.sh -profileName
nodeProfileName
6. Open IBM WebSphere Application Server administrative console and enable node synchronization.
a. Open a browser and go to https://localhostport/ibm/console. The port number is the
administrative console port number from step 3.c.
b. If you encounter a warning that states that the connection is not trusted, you can ignore the
message or add an exception as necessary for your browser.
c. Log in by using the credentials from step 1.
d. Browse to System administration > Console Preferences.
e. Select Synchronize changes with Nodes and click Apply.
7. Set the database driver path in IBM WebSphere Application Server administrative console.
a. Go to Environment > WebSphere variables.
b. For each of the driver path entries that are named for your database type, click the entry. For
example: DB2_JDBC_DRIVER_PATH, ORACLE_JDBC_DRIVER_PATH, or MICROSOFT_JDBC_DRIVER_PATH.
c. Enter the path to the parent directory of your database installation directory and click OK.
v For Oracle, use ORACLE_HOME/jdbc/lib/ojdbc6.jar.
v For Microsoft SQL Server, use SQL_PLUS_HOME\sqljdbc4.jar.
v Replace single backslashes with double backslashes. For example, if the path is C:/IBM/SQLLIB,
then enter C://IBM.
d. Select Save directly to the master configuration.
Related tasks:
Preparing WebSphere Application Server Network Deployment for an
unmanaged server
Use this procedure to set up IBM WebSphere Application Server Network Deployment for an unmanaged
server deployment.
About this task
This procedure assumes that you have IBM WebSphere Application Server already installed.
Procedure
1. Create an unmanaged node on the application server that creates a server named server1 on the
node. Use this command from the WAS_HOME\bin directory:
For Microsoft Windows: manageprofiles.bat -create -profileName nodeProfileName -templatePath
profileTemplates\default -federateLater false -dmgrAdminUserName username
-enableAdminSecurity true -adminUserName username -adminPassword password
For Linux or UNIX: manageprofiles.sh -create -profileName nodeProfileName -templatePath
profileTemplates/default -federateLater false -dmgrAdminUserName username
-enableAdminSecurity true -adminUserName username -adminPassword password
When you use an unmanaged server, the name of the node server is server1.
2. Start the node with this command from the WAS_HOME\bin directory: Microsoft Windows:
startServer.bat -server1 or Linux and UNIX: startServer.sh -server1
3. Set the database driver path in IBM WebSphere Application Server administrative console.
a. Go to Environment > WebSphere variables.
b. For each of the driver path entries that are named for your database type, click the entry. For
example: DB2_JDBC_DRIVER_PATH, ORACLE_JDBC_DRIVER_PATH, or MSSQLSERVER_JDBC_DRIVER_PATH.
c. Enter the path to the parent directory of your database installation directory and click OK. Replace
single backslashes with double backslashes. For example, if the path is C:\IBM\SQLLIB, then enter
C:\\IBM.
d. Select Save directly to the master configuration.
Preparing WebSphere Application Server for base deployment
Use this procedure to set up IBM WebSphere Application Server for base deployment.
About this task
If you are planning to use a base deployment, IBM Installation Manager creates a IBM WebSphere
Application Server profile named server1. If you choose to use this profile, you do not have to create one
before installation.
This procedure assumes that you have the application server already installed.
Procedure
1. Go to the WAS_HOME/ProfileManagement directory and run the profile management tool.
v For Microsoft Windows: pmt.bat
v For Linux and UNIX: pmt.sh
2. On the Environment Selection panel, click Application Server and click Next.
3. On the Profile Creation Options panel, select Typical profile creation and click Next.
4. On the Administrative Security panel, make sure the Enable administrative security option is
selected. Add a user name and password, and then click Next.
5. Review the summary and click Create.
6. After the profile is created, you can start the server and the node. You can use the First steps console
or a command line. For example, /opt/IBM/WebSphere/AppServerBASE/profiles/AppSrv01/bin/
startNode.sh
Creating a new user and adding the user to an MDM group
Use this procedure to create a IBM WebSphere Application Server user and then add that user to an
InfoSphere MDM group.
About this task
IBM Installation Manager creates all of the groups and an MDM admin user (mdmadmin) with the
required rights and privileges. Use this procedure to add new users.
Review the "user accounts and groups" topic for information about available groups.
Procedure
1. In IBM WebSphere Application Server administrative console, go to Users and Groups > Manage
Users and click Create.
2. On the Create a User page, type a user ID, name, and password.
3. Click Group Membership.
4. On the Group Membership page, search for groups with search key of * and click Search.
5. In the Available column, highlight the groups to which you want the user to belong and click Add to
move the group to the Mapped To column.
6. On the Group Membership page, click Close.
7. On the Create a User page, click Create.
Related reference:
application server.
Change the security roles for the channels in MDM
The security mechanism in MDM has some channel role configurations.
MDM accepts requests from these channels only if the role of the caller is configured in the respective
product configurations:
v /IBM/DWLCommonServices/Security/TrustedClientMode/Batch/roles
v /IBM/DWLCommonServices/Security/TrustedClientMode/EventManager/roles
v /IBM/DWLCommonServices/Security/TrustedClientMode/OtherChannels/roles
By default these configurations have the default value mdm_admin. If the new user is created and is not
assigned to the mdm_admin role, then a valid role of the created user must be configured by updating
these configurations.
For more information, see the Defining security services topic.
Preparing a Solaris system for MDM installation
If you are installing on a Solaris operating system, you must complete this procedure before you begin
the installation.
About this task
If you do not complete these steps, your MDM installation can potentially take more than 8 hours to
complete. The result is that the installation either times out or completes with a corrupted installation.
Procedure
Set the Java virtual machine argument for your deployment manager:
1. Create a WebSphere Application Server profile (Deployment Manager and node).
2. Open the WebSphere Application Server administrative console and go to System Administration >
Deployment Manager > Java and Process Management > Process Definition > Java Virtual
Machine.
3. In the Generic JVM Arguments field on the Configuration tab, enter the following argument:
-XX:MaxpermSize=384m. Click Apply and Save directly to the master configuration.
4. Restart the node and the deployment manager.
On a T-series, complete these steps:
5. Go to WAS_PROFILE_HOME/deployment manager properties directory and open the soap.client.props
file.
6. Change the value of com.ibm.SOAP.requestTimeout from 180 to 1800:
com.ibm.SOAP.requestTimeout=1800
7. Restart the node and deployment manager.
WebSphere Application Server embedded messaging
The MDM application uses Message Driven Beans (MDBs) that, on startup of the enterprise bundle
archive (EBA), look for their associated activation specifications and a JMS provider. If a JMS provider
does not exist, the MDBs timeout and fail to start. To simplify the installation and configuration process,
the MDM installation automatically configures a JMS provider and engine.
If you have an existing WebSphere Application Server embedded messaging (message bus) already
configured, or if you are installing MDM on z/OS, there are some steps that you must complete before
you begin the installation.
If you are installing on z/OS and you do not have an existing messaging bus, then there are steps that
you must complete after you install MDM. Post installation configuration is not required for non-z/OS
operating systems.
Related tasks:
Configuring your message bus on z/OS after installation on page 79
If you did not have an existing WebSphere embedded messaging (message bus) created before
installation, then you must complete this procedure after you install MDM on z/OS.
Preparing an existing WebSphere Application Server messaging bus
for MDM installation on z/OS
If you are installing MDM on z/OS, the database user for the MDM installation must have permission to
create tables and table spaces. If they do not, the WebSphere Application Server might not successfully
create the Service Integration Bus (SIB) tables. If you have an existing WebSphere Application Server
messaging bus and you are installing with a user that does not have table and table space creation
permissions, you must complete these steps before you begin MDM installation.
About this task
If you do not have an existing messaging bus, then proceed with first installing MDM and then complete
the steps in Configuring your message bus on z/OS after installation on page 79.
Procedure
1. Open WebSphere Application Server administrative console.
2. Go to Service Integration > Buses > your application bus > Bus Members.
3. On the bus members page, click your application bus member > your application SIB server >
Message Store.
4. Clear the Create tables option to prevent WebSphere Application Server from attempting to create the
SIB tables.
5. Verify that the Schema Name points to your MDM schema. If not, change the schema name.
6. Click Apply and then click Save directly to the master configuration.
7. Stop the application server.
8. Create the SIB tables for your instance by modifying the ZSIB.sql file for your schema, prefix, and
database owner. In the file, replace <SCHEMA> with your schema name, <PREFIX> with your three
character prefix, and <DBA ACCOUNT> with your database owner. Run the SQL as DB Owner.
9. Synchronize your nodes and start the application server.
Related tasks:
Installing on z/OS on page 77
Use this procedure if you are installing with IBM DB2 for z/OS.
Preparing an existing WebSphere Application Server messaging bus
for MDM installation
If you are installing on an operating system other than z/OS, the installer can successfully create the SIB
tables because special permission is not required. If you are pointing your existing messaging bus to an
instance of MDM, ensure that the messaging data source and the schema name in the message store are
pointing to the MDM schema.
About this task
Use this procedure to point the messaging schema to the MDM schema before you begin installation.
Procedure
Message Store.
4. Verify that the Schema Name points to your MDM schema. If not, change the schema name.
6. Synchronize your nodes and restart the application server.
Set the locale and character encoding on target computers
Globalization settings are automatically set for physical operational servers during installation. For
operational servers with virtual configurations, there are some settings that you must manually make
after installation.
Unicode settings are made when you run the create database script applicable for your database type.
Language settings are made during the installation. Use this procedure to set any additional settings for
operational servers if you plan to implement a language other than US English.
Log files that are created by the operational server are in ASCII encoding. Code points that are not
encompassed by ASCII are in the standard Unicode form of U+XXXX.
You want to make sure that the following Unicode items were set by the create database script before you
begin installing MDM.
v Microsoft SQL Server: new MAD_DBTYPE is mssqlu
v Oracle: CREATE DATABASE dname...CHARACTER SET AL32UTF8. You must also set the character
length semantics for Unicode. Set the variable NLS_LANG_SEMANTICS to CHAR (the default setting
is BYTE). Use the command:
ALTER SYSTEM SET NLS_LENGTH_SEMANTICS=CHAR SCOPE=BOTH
If you are using a non-wire connect driver with an Oracle client, you must also set this variable for the
user who is connecting to the operational server. (A non-wire connect driver uses Oracle client
libraries.)
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
v IBM DB2: CREATE DATABASE dname USING CODESET UTF-8 TERRITORY territory code. For
example: create database prod using codeset UTF-8 territory us, where prod is the database name
and us is the territory.
After you install the MDM operational server, you must manually set the MAD_ENCODING variable for
your virtual configuration. This variable is set in the com.ibm.mdm.mds.jni.cfg configuration file.
Translated strings are stored in the /smt directory. These files, such as fr_FR.smt or en_US.smt, contain the
interaction messages that are returned to clients. To set the language for the translated strings, you must
also set the MAD_SMTLIST environment variable in the com.initiate.server.system.cfg configuration file.
This variable points to the appropriate *.smt file. If you use multiple languages, you can separate the
languages with a comma in the variable property.
When the MAD_SMTLIST option is set to multiple languages (smtcode), the operational server can
potentially load multiple languages (strings) at one time. However, the MDMcomponents display the
strings for only one language at a time. For example, the same operational server is configured to send a
French client French messages and an English client English messages.
If client software is not configured to use an alternative language, only operational server level
information is returned in the chosen language. Translation or globalization of the data that is stored in
the MDM database, such as dates, are not converted when displayed in user applications. Rather, this
information displays in the locale in which it was received from the source.
Chapter 6. Installing InfoSphere MDM
Before you begin
Make sure that you meet these prerequisites:
v Your environment meets the hardware and software requirements for components you plan to install
v You completed the installation worksheets
v You have access to the InfoSphere MDM offering
v You completed the preparation steps
Procedure
If you plan to install a custom installation deployment type:
1. Add the necessary repositories to IBM Installation Manager.
2. Install your application and components.
If you plan to install a typical deployment type:
3. Determine your deployment type: typical server or typical workstation.
4. Use the procedure specific to your deployment type.
What to do next
A success message on the final installer panel indicates that the verification tests were automatically run
as part of the installation process. You can also view the log files to verify a successful installation. If the
installation is not successful, view the log files and use the information in the troubleshooting topics to
assist you.
After installation, if you want to add or remove a feature (for example, add an application or another
language translation), or modify any of your configuration settings, you can run IBM Installation
Manager again and select Modify.
Related concepts:
Typical versus custom installation deployment type on page 4
Installation of IBM InfoSphere Master Data Management can be accomplished by using either a typical
installation or a custom installation.
Related tasks:
Viewing the MDM installation logs on page 182
During the installation process, logs are created in the MDM_INSTALL_HOME/logs/database directory. Use
these logs to help you when troubleshooting or verifying your installation.
Starting a typical installation process with LaunchPad
Before you begin
LaunchPad is a browser-based application that is used as the starting point for a typical server or
workstation installation.
From LaunchPad you can:
v Start the installation process
v Exit the installation process
Attention: Your installation media must be in the correct locations for LaunchPad to start. See
Chapter 3, Setting up the installation media, on page 23.
Procedure
1. Go to the directory in which you downloaded the MDM media and open Disk1. For example.
download_path/MDM/disk1
2. Start LaunchPad using one of these scripts:
v Microsoft Windows: launchpad.exe - On Microsoft Windows, right-click on the script and choose
Run as Administrator.
v Linux and UNIX: launchpad.sh - Run as root user
Related tasks:
Chapter 3, Setting up the installation media, on page 23
Installing a typical server installation
Before you begin
v The server on which you are installing does not have any existing instances of MDM, IBM WebSphere
Application Server, or IBM DB2
v You have access to InfoSphere MDM, IBM WebSphere Application Server, and IBM DB2 offerings
v If you are installing on Linux or UNIX, log in as the root user.
contain any spaces.
virtualized.
Your installation media must be in the correct locations for LaunchPad to start. See Chapter 3, Setting up
the installation media, on page 23.
During a typical installation, default configuration values are provided for you. You can review the
configuration worksheets if you want to know what the defaults are before you begin the installation.
For server installations, you must use IBM WebSphere Application Server network deployment.
Attention: The typical installation is configured to use specific TCP or SOAP ports for the application
server. For a successful installation, first verify that the following TCP or SOAP ports are not in use:
50000 - 50002 and 60000 - 60004.
Procedure
2. On the Install Packages panel, verify that the following items are selected:
v IBM WebSphere Application Server network deployment
v IBM DB2
v InfoSphere MDM Standard or Advanced Edition
3. Click Next.
4. Select I accept the terms in the license agreementsand click Next.
5. Select your shared resource directory or accept the default. If you are also installing IBM Installation
Manager, you must also select an installation directory or accept the default. Click Next.
6. On the second Install Packages panel:
a. If you want to accept the default installation directories, click Next.
b. If you want to change the default directory for a package, select the package name and change
the Installation Directory field. Repeat for each package that you want to change. Click Next.
7. On the language panel, English is always selected.
a. If you want any languages beyond English, select the language.
b. If you want more languages for some packages, click the twistie for Translations Supported by
Only Some Packages and select each wanted language.
c. Click Next.
8. Select Data Stewardship UI or Inspector if you want to install one, or both, of the user applications.
9. Review the installation summary information and click Install.
10. When the installation is complete, click None in the Which program do you want to start pane.
11. On the final IBM Installation Manager panel, click View Log Files if you want to open the log file
viewer.
12. Click Finish and close IBM Installation Manager.
What to do next
assist you.
For a list of user names and passwords that are created by the installer, see the "default user accounts
created during a typical installation deployment" topic (see related reference topics).
Related concepts:
Typical server installation on page 5
Installation and configuration worksheets on page 27
process.
Related tasks:
Uninstalling a typical server installation on page 183
If you installed MDM by using a typical server installation, use this procedure to uninstall the features.
Related reference:
Installing a typical workstation installation
Before you begin
v The server on which you are installing does not have any existing instances of MDM, IBM WebSphere
Application Server, or IBM DB2
v You have access to InfoSphere MDM, IBM WebSphere Application Server, IBM DB2, IBM Rational
Application Developer (RAD), and MDM Workbench offerings
v If you are installing on Linux or UNIX, log in as the root user.
contain any spaces.
virtualized.
You must also make sure that the required 32-bit libraries are available on your 64-bit operating system.
See the related reference topics.
Your installation media must be in the correct locations for LaunchPad to start. See Chapter 3, Setting up
the installation media, on page 23.
During a typical installation, default configuration values are provided for you. You can review the
configuration worksheets if you want to know what the defaults are before you begin the installation.
For workstation installations, you must use IBM WebSphere Application Server base deployment.
Attention: The typical installation is configured to use specific TCP or SOAP ports for the application
server. For a successful installation, first verify that the following TCP or SOAP ports are not in use:
50000 - 50002 and 60000 - 60004.
Procedure
2. On the Install Packages panel, verify that the following items are selected:
v IBM DB2
v IBM Rational Application Developer (RAD)
v InfoSphere MDM Standard or Advanced Edition
v InfoSphere MDM Workbench
3. Click Next.
4. Select I accept the terms in the license agreementsand click Next.
5. Select your shared resource directory or accept the default. If you are also installing IBM Installation
Manager, you must also select an installation directory or accept the default. Click Next.
a. If you want to accept the default installation directories, click Next.
b. If you want to change the default directory for a package, select the package name and change
the Installation Directory field. Repeat for each package that you want to change. Click Next.
c. Click Next.
8. Review the installation summary information and click Next.
9. On the Help System Common Configurations panel, select one of the options for how you want to
access IBM Rational Application Developer (RAD) help and click Next.
10. Click Install.
11. When the installation is complete, click None in the Which program do you want to start pane.
viewer.
What to do next
assist you.
For a list of user names and passwords that are created by the installer, see the "default user accounts
created during a typical installation deployment" topic (see related reference topics).
Related concepts:
Typical workstation installation on page 6
process.
Related tasks:
Uninstalling a typical workstation installation on page 184
If you installed MDM by using a typical workstation installation, use this procedure to uninstall the
features.
Related reference:
32-bit libraries needed on 64-bit operating systems on page 12
installation.
Installing a custom installation
Before you begin
v You completed the installation preparation tasks (including preparing your IBM WebSphere
Application Server and database)
v Your IBM WebSphere Application Server (deployment manager and node) and database are started
v You installed IBM Rational Application Developer (RAD) if you are installing InfoSphere MDM
Workbench on a workstation
contain any spaces.
virtualized.
About this task
If you have IBM Rational Application Developer (RAD) installed, make sure that you do not install
InfoSphere MDM into the same package group.
If you are installing MDM on z/OS, see Installing on z/OS on page 77.
Procedure
3. On the Install Packages panel, select the edition and any additional packages that you require (such
as Workbench). Click Next.
a. Select the Installation Directory into which you want to install each component. If you choose to
install a component in a directory other than the default, select that component and click Browse
in the Installation Directory field.
Attention: If you have IBM Rational Application Developer (RAD) installed, make sure that you
do not install MDM into the same package group. On the Install Packages panel, select Create a
new package group.
b. Click Next.
c. Click Next.
6. Select the features to install and click Next.
7. Enter the configuration information. Use the installation worksheets for guidance.
a. On the Database Configuration panel, enter the database details and click Test Connection before
you exit the panel.
b. Complete the fields on the History Configuration panel, if applicable to your offering.
c. On the WebSphere Application Server Configuration panel:
v Enter the information that you used during application server preparation.
v Select Retrieve Host Details to obtain your Cell, Node, and Server information.
v If you are installing in a clustered environment, select Install MDM application on cluster and
choose the cluster name from the Cluster list.
v Click Verify MDM Instance on Server before you exit the panel.
d. On the Application Configuration panel:
v Provide your application name, user password, and RMI port.
v Select either Probabilistic matching or Deterministic matching for your matching style.
v If your application is running across different time zones or your data has time-sensitive
values under different time zones, select Enable multiple time zone deployment and select a
Default time zone.
v Select your messaging type. If you select IBM WebSphere MQ, you must provide more
information. If you installed WebSphere MQ on a different machine than the one where you
are running IBM Installation Manager, make sure that you clear the Configure messaging
server option to prevent the installer from creating a queue manager. Keep the option selected
if you do want to create a queue manager.
e. On each individual user application configuration panel, provide the parameters. If you are
installing in a clustered environment, select Install MDM application on cluster and choose the
cluster from the list.
viewer.
What to do next
assist you.
Related concepts:
process.
Prepare IBM Installation Manager on page 42
Related tasks:
Preparing your DB2 database to use InfoSphere MDMin a clustered environment on page 49
environment.
Preparing your Oracle database to use InfoSphere MDM in a clustered environment on page 52
environment.
scenario 1.
scenario 2.
scenario 3.
Related reference:
installation.
Installing in a clustered environment
Before you begin
v You completed the installation preparation tasks (including preparing your IBM WebSphere
Application Server and database)
v The IBM WebSphere Application Server (deployment manager and node) and database are started
v You installed IBM Rational Application Developer (RAD) if you are installing InfoSphere MDM
Workbench on a workstation
contain any spaces.
virtualized.
About this task
Review the installation scenarios before you begin a clustered installation. While the scenarios might not
exactly fit your environment, they can offer a guideline for installation.
Procedure
1. Verify that these items are completed for your application server:
a. WebSphere Application Server is installed on each required machine in your cluster.
b. The necessary clusters are created in WebSphere Application Server.
c. If you are using a DB2 or Oracle database, you must set the JDBC_DRIVER_PATH environment
variable.
d. Synchronize all managed nodes.
e. Note the WebSphere Application Server host name and port in your installation worksheet.
2. Verify that your database and database client software are installed on the necessary machines, and
that the database is started.
3. If you are using IBM WebSphere MQ messaging, complete these steps. If you are using IBM
WebSphere Default Messaging, continue to step 4.
a. Verify that it is installed.
b. Run the custSetupMQServer.mqsc and ChannelAuth.mqsc scripts to create the WebSphere MQ queue
manager, channel, and queues. These scripts are in the Installation Startup Kit.
4. Install MDM.
a. Start IBM Installation Manager and select your MDM offering and continue through the prompts.
b. On the Database Configuration panel, enter the database details and click Test Connection before
you exit the panel.
c. On the WebSphere Application Server Configuration panel:
v Enter the information that you used during application server preparation.
v Select Retrieve Host Details to obtain your Cell, Node, and Server information.
v Select Install MDM application on cluster and choose the cluster name from the Cluster list.
v Click Verify MDM Instance on Server before you exit the panel.
d. On the Application Configuration panel:
v Provide your application name, user password, and RMI port.
v Select either Probabilistic matching or Deterministic matching for your matching style.
v If your application is running across different time zones or your data has time-sensitive values
under different time zones, select Enable multiple time zone deployment and select a Default
time zone.
v Select your messaging type. If you select IBM WebSphere MQ, you must provide more
information. If you installed WebSphere MQ on a different machine than the one where you are
running IBM Installation Manager, make sure that you clear the Configure messaging server
option to prevent the installer from creating a queue manager.
e. On each individual user application configuration panel, provide the parameters. Select Install
MDM application on cluster and choose the cluster from the list.
viewer.
What to do next
assist you.
Related concepts:
process.
Multiple instance support on page 13
Related tasks:
Deploying the MDM Native Component feature on remote Windows
server
The Master Data Management Native Component feature is the ODBC data source that virtual MDM
configurations require to operate successfully. If you are planning to install the MDM Operational Server
and implement a virtual MDM configuration on a WebSphere Application Server cluster and a Microsoft
Windows operating system, there are steps that you must take after you install your operational server.
About this task
The installer automatically runs the madconfig create_datasource target to create an ODBC data source
on a remote server by using an Ant agent. However, the Ant agent does not have permission to modify
the Windows registry.
If you are running IBM Installation Manager and WebSphere Application Server deployment manager on
machine A and must deploy your operational server and virtual configuration to managed nodes on
other machines (for example B, C, and D), use this procedure. This procedure manually creates the ODBC
data source on each of the remote Windows servers after you first run IBM Installation Manager to install
your operational server.
Procedure
1. Run IBM Installation Manager on machine A and install the MDM Operational Server.
2. On machine B, go to your WAS_PROFILE_HOME\installedApps\YOUR_CELL_NAME\MDM-native-
IDENTIFIER.ear\native.war\scripts directory.
3. Open a command-line prompt.
4. Type this command: madconfig.bat register_odbc.
5. Type this command: madconfig.bat create_datasource -Dmad.db.type=DBTYPE -Dmad.db.name=DBNAME
-Dmad.db.port=DBPORT -Dmad.db.host=DBHOST -Dmad.db.dsn=DSN
Where:
v DBTYPE: is your database type; specify DB2, ORACLE, or MSSQLU on machine B
v DBHOST: is your database host name or IP address on machine B
v DBPORT: is your database port on machine B
v DBNAME: is your database name on machine B, for example mdmins11
v DSN: the data source name; DSN naming convention is
DB_NAME_MDM_INSTANCE_IDENTIFIER. MDM_INSTANCE_IDENTIFIER. must match the MDM
application name value that you entered on the Application Configuration panel during installation
on machine A.
6. Repeat steps 2 - 5 for each additional machine in your cluster (for example, C and D).
Installing on Oracle RAC
Use this procedure if you are using a virtual MDM and installing on Oracle Real Application Clusters
(RAC).
Before you begin
v You completed the IBM Installation Manager preparation steps
v You completed the preparation tasks for creating the database and application server
Procedure
a. On the Install Packages panel, select the edition and click Next.
b. Continue through the prompts to accept the license agreement, select an installation location, and
select languages.
c. Select the MDM Database and MDM Operational Server features and click Next.
d. Complete the configuration panels and click Next.
e. Click Install.
The installer creates the ODBC data source with the SID, and runs the madconfig
bootstrap_datasource target to create all virtual MDM tables.
2. Go to the WebSphere Application Server administrative console and select 'Resources > JDBC > Data
sources.
a. On the Data sources page, click the name of your MDM data source.
b. On the next Data sources page, click Custom properties.
c. Remove the SID by selecting it and clicking Delete.
d. Click New and add a new custom property Name for serviceName and the Value.
e. Click OK.
3. Run the following commands from the native.war/scripts directory. For a clustered environment,
you must run these commands on each cluster machine.
v madconfig remove_datasource -Dmad.db.dsn=DB_NAME_MDM_INSTANCE_ID
v madconfig create_datasource -Dmad.db.type=oracle -Dmad.db.host=DB_HOST
-Dmad.db.port=DB_PORT -Dmad.db.service=SERVICE_NAME -Dmad.db.dsn=DB_NAME_MDM_INSTANCE_ID
When running this command, you are prompted to enter the SID. Leave the prompt blank and
press Enter.
What to do next
Always review the installation logs to verify that the process completed successfully.
If you determine that the virtual data did not load successfully after you review the logs, you can use the
madconfig utility to either reload the data or run a bootstrap.
Enabling support for Oracle non-wired driver
If you are using a virtual MDM and plan to use a non-wired Oracle database driver, complete these steps
after you install the MDM database and features.
Before you begin
Complete the steps in Deploying the MDM Native Component feature on remote Windows server on
page 75.
Procedure
1. On the machine where you installed the native Oracle client and drivers and deployed the native
EAR file:
a. Configure the operating system environment variable as: ORACLE_HOME=PATH_TO_ORACLE_HOME.
b. Configure the operating system environment variable as:
v For Microsoft Windows: LIB=PATH_TO_ORACLE_HOME/lib
v For IBM AIX: LIBPATH=PATH_TO_ORACLE_HOME/lib
v For other operating systems: LD_LIBRARY_PATH=PATH_TO_ORACLE_HOME/lib
2. Go to the native.war/scripts directory and run these commands:
a. madconfig remove_datasource -Dmad.db.dsn=DB_NAME_MDM_INSTANCE_ID
b. madconfig create_datasource -Dmad.db.type=oracle -Dmad.db.dsn=DB_NAME_MDM_INSTANCE_ID-
Dmad.db.server=TNS_NAME
The create_datasource command prompts you to enter a database host. You can leave that
prompt blank and press Enter.
3. If you have a clustered environment, repeat the steps on each cluster member.
Related reference:
ODBC drivers installed with standard edition on page 53
The ODBC drivers that are applied by the installer is determined by the database type you define.
Installing on z/OS
Before you begin
v You added the MDM offering to IBM Installation Manager
v You completed the preparation tasks for creating the database and application server
v You completed the Preparing an existing WebSphere Application Server messaging bus for MDM
installation on z/OS on page 59
About this task
This process requires three distinct steps or sessions; two of those sessions you must run the installer
process. In the first session, the installer extracts the JCLs that are used to manually install the physical
MDM database.
After the physical database load is complete, the second installation session installs the virtual part of the
MDM database, the operational server, and any other features you select.
Procedure
First session, extract the physical MDM JCLs. Install the Installation Startup Kit to extract the physical
MDM DB2 z/OS assets to the STARTUPKIT_INSTALL_HOME directory.
1. Start IBM Installation Manager and click Install on the home panel.
2. On the Install Packages panel, select Installation Startup Kit and click Next.
3. Continue through the prompts to accept the license agreement, select an installation location, and
select languages.
5. Click Finish when the installation is complete.
Second session, transfer DB2 assets and load the physical MDM data manually.
6. Go to STARTUPKIT_INSTALL_HOME.
7. Copy the MDM Operational Server z/OS assets from the STARTUPKIT_INSTALL_HOMECoreData/Full/
DB2/ZOS/pds and STARTUPKIT_INSTALL_HOMEFull/DB2/ZOS/pds directories to the z/OS system.
8. Load the physical MDM manually by using these instructions: Manual installation of the physical
MDM database on DB2 for z/OS on page 109 (installing core database by using TSO and JCLs,
installing CLOB data, and installing the domain database).
Third session, install the MDM Operational Server and other features:
9. Start IBM Installation Manager and click Install on the home panel.
10. On the Install Packages panel, select the edition and click Next.
11. Continue through the prompts to accept the license agreement, select an installation location, and
select a language.
Attention: If you have IBM Rational Application Developer (RAD) installed, make sure that you do
not install InfoSphere MDM into the same package group. On the Install Packages panel, select
Create a new package group.
12. Select the MDM Operational Server, MDM Database, and any other features you want to install.
13. Enter the configuration information.
v On the database configuration panel, select DB2 Z/OS.
v For IBM WebSphere Application Server configuration, make sure that you enter the information
that you used during application server preparation. Use the mdmadmin user and password. Click
Verify MDM Instance on Server before you exist the panel.
v On the Messaging Server panel, select IBM WebSphere Default Messaging or MQ Messaging
Provider. (For information about manually installing SIB tables on WebSphere Application Server,
see the "Creating data store tables" topic at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/
index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/ae/tjm0080_.html
viewer.
What to do next
assist you.
Related tasks:
Preparing an existing WebSphere Application Server messaging bus for MDM installation on z/OS on
page 59
If you are installing MDM on z/OS, the database user for the MDM installation must have permission to
create tables and table spaces. If they do not, the WebSphere Application Server might not successfully
create the Service Integration Bus (SIB) tables. If you have an existing WebSphere Application Server
messaging bus and you are installing with a user that does not have table and table space creation
permissions, you must complete these steps before you begin MDM installation.
Configuring your message bus on z/OS after installation
If you did not have an existing WebSphere embedded messaging (message bus) created before
installation, then you must complete this procedure after you install MDM on z/OS.
About this task
After the installation completes, an error displays stating that the "Install Verification Test did not pass".
You can ignore this error if you complete these steps.
Procedure
Message Store.
4. Clear the Create tables option.
6. Synchronize your nodes and restart the application server. Stopping the server prevents WebSphere
Application Server from attempting to create and connect to the SIB tables.
7. Create the SIB tables for your instance by modifying the ZSIB.sql file for your schema, prefix, and
database owner. In the file, replace <SCHEMA> with your schema name, <PREFIX> with your three
character prefix, and <DBA ACCOUNT> with your database owner. Run the SQL as DB Owner.
8. Restart your application server.
9. From the MDM_INSTALL_HOME/IVT directory, run the Verify.sh script. For example, use the command:
verify.sh DB_Schema DB_Password WAS_user WAS_password
10. View the installation response files to ensure that the IVT was successful.
Response files are in the MDM_INSTALL_HOME/IVT/testCases/xml/response and MDM_INSTALL_HOME/IVT/
testCases/xml_virtual/response directories.
Related concepts:
WebSphere Application Server embedded messaging on page 59
The MDM application uses Message Driven Beans (MDBs) that, on startup of the enterprise bundle
archive (EBA), look for their associated activation specifications and a JMS provider. If a JMS provider
does not exist, the MDBs timeout and fail to start. To simplify the installation and configuration process,
the MDM installation automatically configures a JMS provider and engine.
Silent installation
Sample silent mode response files are provided in the STARTUP_INSTALL_HOME/StartupKit directory.
Operating system-specific files are available for supported systems.
The following sample silent mode response files for IBM WebSphere Application Server are available:
v typical_install_server.res use this response file to install the MDM operational server, MDM
database, IBM DB2 database server, and WebSphere Application Server Network Deployment
v typical_install_workstation.res use this response file to install the MDM operational server, MDM
database, IBM DB2 database server, WebSphere Application Server, IBM Rational Application
Developer (RAD), and InfoSphere MDM Workbench
v install_single_servers_aix.res use this response file to install the operational server with a
custom installation deployment type that uses the following parameters:
Platform: AIX
Messaging provider: WebSphere Application Server default messaging provider
MDM Operational Server deployment target (single server): mdm-s1-E001
Business Administration UI deployment target (single server): mdm-s2-E001
Data Stewardship UI deployment target (single server): mdm-s2-E001
Product Maintenance UI deployment target (single server): mdm-s2-E001
Inspector deployment target (single server): mdm-s3-E001
Enterprise Viewer deployment target (single server): mdm-s3-E001
Web Reports deployment target (single server): mdm-s3-E001
v install_cluster_aix_mq.res use this response file to install the Operational Server with a custom
installation deployment type that uses the following parameters:
Platform: AIX
Messaging provider: WebSphere MQ messaging provider
MDM Operational Server deployment target (cluster): mdm-CL01
Business Administration UI deployment target (cluster): mdm-CL02
Data Stewardship UI deployment target (cluster): mdm-CL02
Product Maintenance UI deployment target (cluster): mdm-CL02
Inspector deployment target (cluster): mdm-CL02
Enterprise Viewer deployment target (cluster): mdm-CL02
Web Reports deployment target (cluster): mdm-CL02
v install_single_servers_linux.res use this response file is to install the Operational Server with a
Platform: Linux
v install_cluster_linux_mq.res use this response file to install the MDM Operational Server with a
Platform: Linux
v install_single_servers_win.res use this response file to install the MDM Operational Server with a
custom installation deployment type that uses the following parameters. If there is a validation error in
the response file, silent installations on Windows might shut down without displaying any indication
of why. If your installation shuts down, review the log files to locate the reason.
Platform: Microsoft Windows 7
v install_cluster_win_mq.res use this response file to install the MDM Operational Server with a
Platform: Microsoft Windows 7
v install_single_servers_solaris.res use this response file to install the MDM Operational Server
with a custom installation deployment type that uses the following parameters:
Platform: Solaris
v install_cluster_solaris_mq.res use this response file to install the MDM Operational Server with a
Platform: Solaris
Related tasks:
Viewing the MDM installation logs on page 182
Uninstalling in silent mode on page 186
Use this procedure to uninstall InfoSphere MDM components in silent mode.
Related reference:
Customizing the silent mode response file
Use this procedure to customize your silent mode installation response file.
About this task
Attention: Although code examples might show with line breaks in the following content, the text
between <.../> must be entered in the response file as one line without breaks.
For more information about working in silent mode and using response files, see http://
pic.dhe.ibm.com/infocenter/install/v1r6/index.jsp?topic=%2Fcom.ibm.cic.agent.ui.doc
%2Fhelpindex_imic.html
Procedure
1. Open your response file.
2. Specify the home and shared resource directories.
a. To specify the MDM_INSTALL_HOME directory, add these lines to your response file:
<profile id=IBM InfoSphere Master Data Management installLocation=/usr/IBM/MDM/H087/mdm/>
<data key=eclipseLocation value=/usr/IBM/MDM/H087/mdm/>
Where usr/IBM/MDM/H087/mdm is the MDM installation home directory.
b. To specify the Installation Manager Shared Resource directory.
<preference name=com.ibm.cic.common.core.preferences.eclipseCache value=/usr/IBM/MDM/H087/
Shared/>
Where usr/IBM/MDM/H087/Shared is the Installation Manager Shared Resource directory.
3. Specify the MDM offering version and the features that you want to install by adding this line:
<offering id=com.ibm.mdm.advanced version=11.0.0.v20130415-1124 profile=IBM InfoSphere Master Data
Management features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.feature,
com.ibm.im.mdm.app.feature installFixes=none/>
Where 11.0.0.v20130415-1124 is the version number of MDM.
You can find the version number by looking in your installation media folder (download_path/MDM/
disk1/md/Offerings) and locating the offering JAR file. For example, disk1/md/Offerings/
com.ibm.mdm.advanced_11.0.0.v20130415-1124.jar, where 11.0.0.v20130415-1124 is the version
number.
4. Specify the feature to install during the single IBM Installation Manager session by adding this line:
Management features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.
feature, com.ibm.im.mdm.app.feature installFixes=none>
Where
features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.feature,com.ibm.im.mdm.app.
feature
is the specific feature to install. For guidance, see Examples for specifying features for a silent
installation.
com.ibm.mdm.install.iu.localization.feature must always be included in a feature list. This feature
is an internal feature that provides multi-language support for the installer logging system.
Healthcare Point of Service Integrator (com.ibm.im.mdm.ei.feature) can be installed only on Microsoft
Windows. If you include this feature on a non-Windows environment, the installer ignores the feature
and does not install it.
5. Specify your database parameters. For guidance, use the applicable database parameters topic for
your database. The topics are listed in the related reference links.
The following parameters must not be modified in your response file:
<data key=user.L2.db.vertype,com.ibm.mdm.advanced value=DB2UDBNT_V82_1/>
<data key=user.L2.mdm.mad.type.db2,com.ibm.mdm.advanced value=DB2/>
<data key=user.L2.mdm.mad.type.db2z,com.ibm.mdm.advanced value=DB2Z/
>
<data key=user.L2.mdm.mad.type.oracle,com.ibm.mdm.advanced value=ORACLE/>
6. Specify your WebSphere Application Server parameters. For guidance, use the application server
parameters topic that is listed at the end of this procedure.
What to do next
Continue with disabling the installer splash screen and running the silent installation.
Related tasks:
Examples for specifying features for a silent installation
You must edit your response file and specify the exact features that you want to install during a silent
installation.
Specify the features in the following line in the <offering id.../> section of your response file:
features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.feature,com.ibm.im.mdm.
app. feature
For example:
Management features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.
feature,com.ibm.im.mdm.app.feature installFixes=none>
Example 1: Installing MDM Database and MDM Operational Server
To install only the database and operational server, add this line:
feature
Example 2: Installing MDM Database, MDM Operational Server, and user applications
To install the database, operational server, and all of the user applications and features, include this line:
feature,com.ibm.mdm.ba.webapp.feature,com.ibm.mdm.ds.webapp.feature,com.ibm.mdm.pui.webapp.feature,
com.ibm.mdm.inspector.webapp.feature,com.ibm.mdm.ev.webapp.feature,com.ibm.mdm.wb.webapp.feature,com.
ibm.mdm.pd.webapp.feature,com.ibm.im.mdm.message.broker.feature, com.ibm.im.mdm.ei.feature,com.ibm.im.
mdm.eutc,com.ibm.mdm.ba.webapp.sample.feature
Silent installation database parameters for DB2
You must specify parameters for your IBM DB2 database in your silent installation response file.
Enter the following lines in your response file if you are using a DB2 database. Change value= to the
specific value used by your database.
v Database type
<data key=user.db.type,com.ibm.mdm.advanced value=DB2/>
<data key=user.db.type.cm,com.ibm.mdm.advanced value=DB2/>
v Database alias in a database catalog for the DB2 Client
<data key=user.db.name,com.ibm.mdm.advanced value=MDM11E/>
<data key=user.db.name.cm,com.ibm.mdm.advanced value=MDM11E/>
v Database name
<data key=user.db.name.remote,com.ibm.mdm.advanced value=YOURDBASENAME/>
<data key=user.db.name.remote.cm,com.ibm.mdm.advanced value=YOURDBASENAME/>
v Database schema name
<data key=user.db.schema,com.ibm.mdm.advanced value=SCHEMANAME/>
<data key=user.db.schema.cm,com.ibm.mdm.advanced value=SCHEMANAME/>
v Database server host name
<data key=user.db.host,com.ibm.mdm.advanced value=your.host.com/>
<data key=user.db.host,com.ibm.mdm.advanced value=your.host.com/>
v Database server port number
<data key=user.db.port,com.ibm.mdm.advanced value=50000/>
<data key=user.db.port.cm,com.ibm.mdm.advanced value=50000/>
v Database user name (should be the same as the schema name)
<data key=user.db.user,com.ibm.mdm.advanced value=USERNAME/>
<data key=user.db.user.cm,com.ibm.mdm.advanced value=USERNAME/>
v Database password
<data key=user.db.password,com.ibm.mdm.advanced value=/>
<data key=user.db.password.cm,com.ibm.mdm.advanced value=/>
v DB2 Client home directory
<data key=user.db2.home,com.ibm.mdm.advanced value=/home/ws8admin/>
<data key=user.db2.home.cm,com.ibm.mdm.advanced value=/home/ws8admin/>
v Database JDBC URL
<data key=user.user.db.url,com.ibm.mdm.advanced value=jdbc:db2://HOSTNAME:PORT/
DBASENAME/>
<data key=user.user.db.url.cm,com.ibm.mdm.advanced value=jdbc:db2://HOSTNAME:PORT/
DBASENAME/>
The following parameters must not be modified in your response file:
<data key=user.L2.db.vertype,com.ibm.mdm.advanced value=DB2UDBNT_V82_1/>
<data key=user.L2.mdm.mad.type.db2,com.ibm.mdm.advanced value=DB2/>
<data key=user.L2.mdm.mad.type.db2z,com.ibm.mdm.advanced value=DB2Z/
>
Silent installation database parameters for Microsoft SQL Server
You must specify parameters for your SQL Server database in your silent installation response file.
Enter the following lines in your response file if you are using an SQL Server database. Change value= to
the specific value used by your database.
v Database type
<data key=user.db.type,com.ibm.mdm.advanced value=MSSQLU/>
<data key=user.db.type.cm,com.ibm.mdm.advanced value=MSSQLU/>
v Database name
<data key=user.db.name,com.ibm.mdm.advanced value=YOURDBASENAME/>
<data key=user.db.name.cm,com.ibm.mdm.advanced value=YOURDBASENAME/>
<data key=user.db.name.remote,com.ibm.mdm.advanced value=YOURDBASENAME/>
<data key=user.db.name.remote.cm,com.ibm.mdm.advanced value=YOURDBASENAME/>
v Database password
<data key=user.db.password,com.ibm.mdm.advanced value=/>
<data key=user.db.password.cm,com.ibm.mdm.advanced value=/>
v Database JDBC URL
<data key=user.user.db.url,com.ibm.mdm.advanced value=jdbc:ibm:sqlserver://HOSTNAME:PORT/
DBASENAME/>
<data key=user.user.db.url.cm,com.ibm.mdm.advanced value=jdbc:ibm:sqlserver://HOSTNAME:PORT/
DBASENAME/>
v Database host name
<data key=user.db.host,com.ibm.mdm.advanced value=DBHOSTNAME/>
<data key=user.db.host.cm,com.ibm.mdm.advanced value=DBHOSTNAME/>
v Database port
v Database home directory
<data key=user.L2.db.home,com.ibm.mdm.advanced value=DBHOMEDIR/>
v Additional parameters
<data key=user.db.servername,com.ibm.mdm.advanced value=SERVERNAME/>
<data key=user.db.filegroup,com.ibm.mdm.advanced value=FILEGROUPNAME_FG/>
<data key=user.db.auth.native,com.ibm.mdm.advanced value=false/>
Set user.db.auth.native to true if you use Windows Native Authentication.
Silent installation database parameters for Oracle
You must specify parameters for your Oracle database in your silent installation response file.
Enter the following lines in your response file if you are using an Oracle database. Change value= to the
specific value used by your database.
v Database type
<data key=user.db.type.cm,com.ibm.mdm.advanced value=ORACLE/>
<data key="user.db.type,com.ibm.mdm.advanced value=ORACLE/>
v Oracle client TNS name
<data key=user.db.name.cm,com.ibm.mdm.advanced value=TNSNAME/>
<data key=user.db.name,com.ibm.mdm.advanced value=TNSNAME/>
v Oracle server database name
<data key=user.db.name.remote,com.ibm.mdm.advanced value=DBASENAME/>
<data key=user.db.name.remote.cm,com.ibm.mdm.advanced value=DBASENAME/>
v Database user password
<data key=user.db.password.cm,com.ibm.mdm.advanced value=DBPASSWORD/>
<data key=user.db.password,com.ibm.mdm.advanced value=DBPASSWORD/>
v Database JDBC URL
<data key=user.user.db.url,com.ibm.mdm.advanced value=jdbc:oracle:thin:@HOSTNAME:PORT/DBASENAME/>
<data key=user.user.db.url.cm,com.ibm.mdm.advanced value=jdbc:oracle:thin:@HOSTNAME:PORT/DBASENAME/>
v Database server host name
<data key=user.db.host,com.ibm.mdm.advanced value=DBHOSTNAME/>
<data key=user.db.host.cm,com.ibm.mdm.advanced value=DBHOSTNAME/>
v Database server port
v Oracle client home directory
<data key=user.L2.db.home,com.ibm.mdm.advanced value=ORACLEHOMEPATH/>
The following parameter must not be modified in your response file:
<data key=user.L2.mdm.mad.type.oracle,com.ibm.mdm.advanced value=ORACLE/>
Silent installation WebSphere Application Server parameters
You must specify parameters for WebSphere Application Server in your silent installation response file.
Enter the following lines in your response file. Change value= to the specific value used by your
application server.
v WebSphere Application Server installation home directory
<data key=user.L1.was.home,com.ibm.mdm.advanced value=/WAS_INSTALL_HOME/>
v WebSphere Application Server type, either ND (network deployment) or BASE
<data key=user.was.type,com.ibm.mdm.advanced value=ND/>
v Profile Home (required if installing MDM database only using INSTALL mode)
<data key=user.was.profile.home,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
v WebSphere Application Server Network Deployment Manager or WebSphere Application Server Base
server1 SOAP port
<data key=user.deploy.port,com.ibm.mdm.advanced value=8880/>
v WebSphere Application Server Deployment Manager or WebSphere Application Server Base server1
host name
<data key=user.deploy.host,com.ibm.mdm.advanced value=HOSTNAME/>
v WebSphere Application Server deployment target (single server)
<data key=user.was.cell,com.ibm.mdm.advanced value=CELLNAME/>
<data key=user.was.node,com.ibm.mdm.advanced value=NODENAME/>
<data key=user.was.server,com.ibm.mdm.advanced value=SERVERNAME/>
<data key=user.was.cluster,com.ibm.mdm.advanced value=None/>
<data key=user.was.cluster.flag,com.ibm.mdm.advanced value=false/>
v WebSphere Application Server deployment target (cluster)
<data key=user.was.cell,com.ibm.mdm.advanced value=CELLNAME/>
<data key=user.was.node,com.ibm.mdm.advanced value=None/>
<data key=user.was.server,com.ibm.mdm.advanced value=None/>
<data key=user.was.cluster,com.ibm.mdm.advanced value=CLUSTERNAME/>
<data key=user.was.cluster.flag,com.ibm.mdm.advanced value=true/>
v WebSphere Application Server security parameters
<data key=user.was.security,com.ibm.mdm.advanced value=1/>
<data key=user.was.security.on.off,com.ibm.mdm.advanced value=on/>
<data key=user.was.user,com.ibm.mdm.advanced value=USERNAME/>
<data key=user.was.password,com.ibm.mdm.advanced value=/>
<data key=user.security.user.name,com.ibm.mdm.advanced value=USERNAME/>
<data key=user.security.user.password,com.ibm.mdm.advanced value=/>
Disabling the installer splash screen during silent installation
Use this procedure to disable the IBM Installation Manager splash screen for silent installations. This task
must be completed for the silent installation to run successfully.
About this task
Follow these steps to add the -nosplash parameter in the IBMIM.ini file.
Procedure
1. Go to the INSTALLATIONMANAGER_INSTALL_HOME/eclipse directory.
2. Open the IBMIM.ini file.
3. Add the -nosplash parameter. For example:
v Microsoft Windows:
-toolId ibmim
-accessRights nonAdmin
-vm
/home/ws7admin/IBM/InstallationManager/eclipse/jre_5.0.1.sr8a_20080811c/jre/bin/java
-nosplash
-vmargs
-Xms40m
-Xmx512m
-Xquickstart
-Xgcpolicy:gencon
v Linux and UNIX:
vi IBMIN.ini
/opt/IBM/InstallationManager/eclipse/jre_6.0.0.sr9_20110208_03/jre/bin/java
-nosplash
-vmargs
-Xquickstart
-Xgcpolicy:gencon
4. Save and close the file.
Installing silently by using a response file
Before you begin
Verify that the installation startup kit is installed. The response files in the kit can be used for a silent
installation.
Make sure that you complete the steps in Disabling the installer splash screen during silent installation
on page 87.
About this task
A properties file is generated when you run the interactive installation program. To use a silent
installation, you must edit the properties file or create your own file by editing one of the sample
response files.
Procedure
1. To use a sample response file, go to STARTUPKIT_INSTALL_HOME. Response files have a .res extension.
Use the file that is applicable to your operating system.
2. Edit the response file and make any necessary changes before you start the installation.
3. Start the installation with the applicable command:
v Use this command to run IBM Installation Manager and then generate the corresponding response
file:
IBMIM -record recordedFile
v Use this command to run IBM Installation Manager in silent mode:
IBMIM -acceptLicense -silent -input inputFile
4. If an unrecoverable problem occurs during the silent installation, look for the cause of the problem in
the log files in the MDM_INSTALL_HOME/logs/logs directory. After you correct the issue, run the silent
installation again.
Related tasks:
installation.
Customizing the silent mode response file on page 82
Creating a response file while you are running a graphical installation
Use this procedure to capture responses and create a response file when you are running IBM Installation
Manager in graphical mode.
Before you begin
The password values in the file are encrypted. If the password value is changed in the system, you must
input the correct password value to the response file before you use it for a silent installation. You can
enter a new unencrypted value for the password, and the system encrypts it when the file is used during
installation.
Procedure
Create the response file by starting the installation with the following command:
../IBMIM -record $YOUR_PATH/mysilent.res
Modifying an installation silently
Use this procedure to modify an existing silent installation.
About this task
To use a silent installation to modify an existing installation, you must edit your installation response file.
Procedure
To modify your installation, set the modify parameter to true and list the features that you want to add.
For example:
<install modify=true>
Management
features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.feature,com.ibm.im.mdm.
app.feature,com.ibm.mdm.ba.webapp.feature,com.ibm.mdm.ds.webapp.feature,com.ibm.mdm.pui.webapp.feature,
com.ibm.mdm.pd.webapp.feature,com.ibm.mdm.wb.webapp.feature,com.ibm.mdm.ev.webapp.feature,com.ibm.mdm.
inspector.webapp.feature,com.ibm.mdm.ba.webapp.sample.feature installFixes=none/>
</install>
Modifying your installation
Use this procedure to install other InfoSphere MDM components on a workstation or server that already
has components of the same version installed.
Procedure
1. Start IBM Installation Manager and click Modify.
2. Select the InfoSphere MDM package and click Next.
3. Select the language and click Next.
4. On the Modify Packages panel, select the component that you want to install. Previously installed
components are automatically selected. Make sure that they remain selected, otherwise IBM
Installation Manager removes them. Click Next.
5. Review the summary information and verify that the component that you want to install is listed in
the Adding Features box and that no components are listed in the Removing Features box. Click
Modify.
viewer.
What to do next
assist you.
Related concepts:
Installation scenarios
There are some common installation scenarios, which you can use as guidelines when installing MDM in
similar environments. The scenarios are not meant to address every possible configuration or
environment, but show the basic steps involved in a custom installation involving multiple products and
machines.
Before you install, ensure that the system or systems that you choose meet the necessary operating
system, hardware, software, communications, disk, and memory requirements.
These scenarios assume that you have completed the following tasks:
v Chapter 3, Setting up the installation media, on page 23
v Prepare IBM Installation Manager on page 42
v Installing the Installation Startup Kit on page 44
Before you begin any installation, ensure that these conditions are met:
v Ensure any Dmgr node agents are deployed and running.
v Ensure any AppSrv node agents are deployed and running. For some installation scenarios, the
WebSphere Application Server AppSrv profile is called server1.
v Ensure the JAVA_HOME and PATH environment variables are set correctly on each machine.
v For WebSphere Application ServerNetwork Deployment, ensure the DB2_JDBC_DRIVER_PATH
application server variables are targeted to the respective nodes containing the DB2 JDBC drivers for
the machines. This is not applicable if you are using WebSphere Application Server base.
v Know your machine host names and SOAP port numbers for Dmgr processing.
v Know your host name and bootstrap port number of the application server, where the InfoSphere
MDM application was previously installed as a result of running the IBM Installation Manager.
Scenario 1: Installing MDM on a WebSphere Application Server cluster,
using an IBM DB2 database and IBM WebSphere MQ messaging
Use this scenario as a reference when planning and installing MDM on a WebSphere Application Server
cluster with a DB2 database and IBM WebSphere MQ messaging. This scenario is applicable for DB2 on
Microsoft Windows, Linux, or UNIX operating systems.
This scenario is accomplished through four procedures.
1. Prepare your application server.
2. Prepare your DB2 database.
3. Prepare IBM WebSphere MQ messaging.
4. Install MDM.
In this scenario, the topology is:
v Machine A:
WebSphere Application Server Deployment Manager
DB2 client software
IBM Installation Manager and MDM
v Machines B, C, and D:
WebSphere Application Server managed nodes
DB2 client software
v Machine E:
DB2 database
v Machine F:
IBM WebSphere MQ
Scenario 1, Procedure 1: Preparing WebSphere Application Server Network
Deployment
About this task
The resulting topology from this procedure is that machine A has WebSphere Application Server
Deployment Manager and machines B, C, and D have WebSphere Application Server managed nodes.
Procedure
1. Install and configure WebSphere Application Server on machines A, B, C, and D. Use the WebSphere
Application Server Network Deployment documentation as a guide.
2. Create two WebSphere Application Server clusters. CLUSTER1 for the MDM Operational Server and
CLUSTER2 for the user applications.
3. Create a DB2_JDBC_DRIVER_PATH WebSphere Application Server environment variable for each
node in the cluster. The path must point to the JDBC drivers for each machine. For example, if the
DB2 client and JDBC drivers are installed at $USER_HOME/sqllib/java, specify the
DB2_JDBC_DRIVER_PATH equal to $USER_HOME.
4. Make sure that all managed nodes are properly synchronized before you begin installing MDM.
5. Make sure that you know the WebSphere Application Server Deployment Manager host name and
SOAP port before you start the MDM installation. Use the WebSphere Application Server
configuration worksheet to record your values.
6. Make sure your cluster is started before you begin the MDM installation.
Related concepts:
Related tasks:
Preparing WebSphere Application Server Network Deployment for a managed server deployment on
page 55
server deployment.
Preparing your DB2 database to use InfoSphere MDMin a clustered environment on page 49
environment.
Related reference:
Scenario 1, Procedure 2: Preparing the IBM DB2 database
About this task
The resulting topology from this procedure is that machine E hosts the DB2 software and database, and
machines A,B,C, and D have the DB2 client software.
Procedure
1. Install DB2 database. Use the IBM DB2 installation documentation as a guide.
a. Install DB2 on machine E.
b. Install DB2 client software on machines A, B, C, and D.
c. Catalog DB2 client on machine A to connect to the DB2 database server on machine E. Repeat this
step for machines B, C, and D.
2. Create the database and table spaces by using the scripts that are provided in the Installation Startup
Kit.
3. Make sure that DB2 Client $HOME/sqllib/bin is included in the PATH on machine A. This step is
required for IBM Installation Manager to implement the $HOME/sqllib/bin/db2 utility when running
the SQL scripts.
Related tasks:
installation.
Related reference:
IBM DB2 or DB2 for z/OS data source worksheet on page 29
Use this data source worksheet to identify parameters for the IBM DB2 or DB2 for z/OS data source to
Scenario 1, Procedure 3: Preparing IBM WebSphere MQ
Procedure
1. Install IBM WebSphere MQ on machine F. Use the IBM WebSphere MQ installation documentation as
a guide.
2. Create the WebSphere MQ queue manager, channel, and queues by using the
custSetupMQServer.mqsc and ChannelAuth.mqsc scripts. These scripts are included in the Installation
Startup Kit.
Related tasks:
installation.
Related reference:
MDM application configuration worksheet on page 37
Use the application configuration worksheet to identify parameters for the MDM operational server.
Scenario 1, Procedure 4: Installing MDM
scenario 1.
About this task
Make sure that your application server and database are started before you begin the MDM installation.
Procedure
1. Start IBM Installation Manager on machine A and choose your InfoSphere MDM offering. Continue
through the prompts.
2. Specify the MDM installation home and shared directories. For example, MDM home -
/usr/IBM/MDM/E001/mdm and Shared - /usr/IBM/MDM/E001/Shared
3. Choose the MDM Database, MDM Operational Server, and any user applications or other features
you want to install. For example: select the Applications feature to install all user applications, or
select specific applications.
4. On the Database Configuration panel, specify the database type and database parameters. You can
choose whether you want to test the database connection by selecting Test Connection or select No
connection test required.
5. On the WebSphere Application Server Configuration panel, specify the application server parameters.
Select Retrieve Host Details to obtain your Cell, Node, and Server information. Select Install MDM
application on cluster. Choose CLUSTER1 from the Cluster list.
6. On the Application Configuration panel, select IBM WebSphere MQ messaging and enter the
parameters. Clear the Configure messaging server option to prevent IBM Installation Manager from
creating a queue manager on machine A (because the queue manager is enabled on machine F).
7. On each individual user application configuration panel, provide the parameters. Select Install MDM
8. Click Install.
9. When the installation is complete, view the logs and use the installation verification tools.
Related concepts:
process.
Related tasks:
Scenario 2: Installing MDM on a WebSphere Application Server cluster,
using an Oracle database and WebSphere Default Messaging
Use this scenario as a reference when planning and processing an MDM installation on a WebSphere
Application Server cluster. This scenario uses an Oracle database and WebSphere Default Messaging.
This scenario is accomplished through three procedures.
2. Prepare your Oracle database.
3. Install MDM.
v Machine A:
WebSphere Application Server Deployment Manager
Oracle client software
v Machines B, C, and D:
WebSphere Application Server managed nodes
Oracle client software
v Machine E:
Oracle database
Scenario 2, Procedure 1: Preparing WebSphere Application Server Network
Deployment
About this task
Deployment Manager, and machines B, C, and D have WebSphere Application Server managed nodes.
Procedure
1. Install and configure WebSphere Application Server on machines A, B, C, and D. Use the WebSphere
Application Server Network Deployment documentation as a guide.
2. Create a WebSphere Application Server cluster named CLUSTER1 for the MDM Operational Server.
3. Create an ORACLE_JDBC_DRIVER_PATH WebSphere Application Server environment variable for
each node in the cluster. The path must point to the JDBC drivers for each machine. For example, if
the Oracle client and JDBC drivers are installed at $USER_HOME/jdbc/lib/ojdbc6.jar, specify the
ORACLE_JDBC_DRIVER_PATH equal to $USER_HOME.
4. Make sure that all managed nodes are properly synchronized before you begin installing MDM.
6. Make sure your cluster is started before you begin the MDM installation.
Related concepts:
Related tasks:
page 55
server deployment.
Preparing your Oracle database to use InfoSphere MDM in a clustered environment on page 52
environment.
Related reference:
Scenario 2, Procedure 2: Preparing the Oracle database
About this task
The resulting topology from this procedure is that machine E hosts the Oracle software and database, and
machines A,B,C, and D have the Oracle client software.
Procedure
1. Install Oracle database. Use the Oracle installation documentation as a guide.
a. Install Oracle on machine E.
b. Install the Oracle client software on machines A, B, C, and D.
c. Point the TNS name on machine A to connect to the remote Oracle database server on machine E.
Kit.
3. Make sure Oracle Client sqlplus is included in the PATH on machine A. This step is required for IBM
Installation Manager to implement the sqlplus utility when running the SQL scripts.
Related tasks:
installation.
Related reference:
Oracle data source worksheet on page 33
scenario 2.
About this task
Procedure
6. On the Application Configuration panel, select IBM WebSphere Default Messaging.
8. Click Install.
Related concepts:
process.
Related tasks:
Scenario 3: Installing MDM on a WebSphere Application Server
Network Deployment on Windows with an SQL Server database
Use this scenario as a reference when planning and processing an MDM installation on a WebSphere
Application Server Network Deployment. This scenario uses a Microsoft SQL Server database and IBM
WebSphere MQ messaging. This scenario is applicable for a Microsoft Windows operating system.
This scenario is accomplished through four procedures.
2. Prepare your SQL Server database.
3. Prepare IBM WebSphere MQ messaging.
4. Install MDM.
v Machine A:
WebSphere Application Server Deployment Manager and WebSphere Application Server managed
node
IBM WebSphere MQ
v Machine B:
SQL Server database
Scenario 3, Procedure 1: Prepare WebSphere Application Server Network
Deployment
About this task
Deployment Manager and a managed node.
Procedure
1. Install and configure WebSphere Application Server on machine A. Use the WebSphere Application
Server Network Deployment documentation as a guide.
2. Make sure that your managed node is properly synchronized before you begin installing MDM.
4. Make sure your application server is started before you begin the MDM installation.
Related concepts:
Related tasks:
page 55
server deployment.
Related reference:
Scenario 3, Procedure 2: Prepare Microsoft SQL Server database
scenario 3.
Procedure
1. Install SQL Server database on machine B. Use the Microsoft SQL Server installation documentation
as a guide.
Kit.
Related tasks:
installation.
Related reference:
Microsoft SQL Server data source worksheet on page 31
Scenario 3, Procedure 3: Preparing IBM WebSphere MQ
Procedure
1. Install IBM WebSphere MQ on machine A. Use the IBM WebSphere MQ installation documentation
as a guide.
2. Create the WebSphere MQ queue manager, channel, and queues by using the
custSetupMQServer.mqsc and ChannelAuth.mqsc scripts. These scripts are included in the Installation
Startup Kit.
scenario 3.
About this task
Procedure
6. On the Application Configuration panel, select IBM WebSphere MQ messaging and enter the
parameters. Keep the Configure messaging server option selected to instruct IBM Installation
Manager to create a queue manager on machine A.
8. Click Install.
Related concepts:
process.
Related tasks:
madconfig utility
The madconfig utility can be used to manually install MDM operational server and database components.
IBM Installation Manager uses the utility targets during installation.
To run any madconfig target, you must open a command-line prompt from the MDM_INSTALL_HOME/mds/
scripts directory.
The targets listed in the following table are the basic utility targets. There are more madconfig utility
targets that are specific to InfoSphere MDM and are described in a separate topic.
Table 15. Basic madconfig utility targets
Command Description
-projecthelp Lists all valid options and usage information for this utility
-propertyfile Loads properties from a recorded file
-recordfile Record response properties to file
When commands are run, you are prompted to provide more information. For example, to configure the
server on which your MDM operational server is installed, you are prompted to provide certain
configuration parameters. This example shows a partial output of a madconfig install_server_config
target (where user input is a blank line where you enter your response).
C:/MDM/mds/scripts:madconfig install_server_config
Buildfile: build.xml
install_server_config:
#
# Enter WAS home:
#
WAS_INSTALL_HOME/IBM/WebSphere/AppServer
#
# Enter WAS host:
#
localhost
#
# Enter WAS port:
#
8879
The utility further prompts for more WebSphere Application Server parameters, database parameters
(JDBC providers and data source in the application server), application name, messaging types to use
(connection factories, queues, and topics), and JVM heap size.
An alternative way to run a target is by using the propertyfile option. The following example shows
how to use propertyfile to run the install_mdm_eba target. This target installs the MDM Enterprise
Bundle Archive (.eba) file onto an application server. The properties that are required for deployment
include details of the server, the ebaID, the ebaName, the blaName (business level application name), and
blaDes (business level application description).
C:/MDM/mds/scripts:madconfig propertyfile install_mdm_eba.properties install_mdm_eba
The properties that are required by the target are read from the property file. When this option is being
used, the values are provided with the exact property names as expected by the target because it can be
run only when the property names are known.
madconfig utility targets for MDM
Use the madconfig utility to manually install the MDM operational server and database components for
physical and virtual implementations. IBM Installation Manager uses the utility targets during MDM
installation.
This utility is run from the operational server installation MDM_INSTALL_HOME/mds/scripts directory.
This following tables list the madconfig targets for MDM and their usage.
Operational server installation
The following table lists the targets that are related to installing the operational server. Each target
requests values for parameters that pertain to the server and database. The server targets are used to
configure the server on which MDM is installed.
Table 16. madconfig utility targets for operational server installation
Command Description
-install_native_engine_ear Installs the native operational server (engine) for a virtual MDM
implementation
-install_server_config Configures the application server for physical and virtual components;
including JDBC, class path, and environment variables
-stop_server Stops an operational server in WebSphere Application Server Network
Deployment. Stopping and starting the server is required after you install
an operational server configuration. The option -stop_base_server must be
used when the server is unmanaged (Base server).
-start_server Starts an operational server in a managed application server deployment.
Use the option -start_base_server when the application server is
unmanaged.
-install_mdm_old_ws_ear Installs the physical MDM web services JAR in the application server
-install_mdm_eba Installs the MDM OSGi
-install_prop_file_jar Installs the property file JAR required by MDM applications
-install_mdm_ws_ear Installs the MDM web services enterprise archive
-install_mds_ws_api Installs the API for virtual MDM
Table 16. madconfig utility targets for operational server installation (continued)
Command Description
-enable_app_security Creates users, creates groups, adds users to groups, creates policy set, and
creates policy set binding for web services EAR file
-map_roles_to_users Creates the Security role mapping and RunAs role mapping for the EBA
and web services EAR file
-full_sync Synchronizes nodes in a managed server deployment to reflect the user
security for MDM. This target must be run after you run the
map_roles_to_users target.
-enable_deployment_target Checks the status of the operational server; if the server is stopped you can
use this target to restart the server.
MDM database installation
The following table lists the targets that are used to install and configure physical and virtual schemas for
the MDM database.
Table 17. madconfig utility targets for database installation
Command Description
-install_core_db_db2 Creates tables, triggers, constraints, and functions for the MDM core
database that is installed on IBM DB2
-install_domain_db_db2 Creates tables, triggers, constraints, and functions for MDM domains on a
DB2 database
-install_core_db_ora Creates tables, triggers, constraints, and functions for an MDM core
database on Oracle
-install_domain_db_ora Creates tables, triggers, constraints, and functions for MDM domains on an
Oracle database
-install_core_db_sql Creates tables, triggers, constraints, and functions for the MDM core
database on Microsoft SQL Server
-Update_configelement_matching Updates the Configelement table for the selected matching type
-Update_appsoftware_eba Updates the appsoftware table by providing the appropriate name of the
EBA in the software name column
-create_datasource Creates the data source that is used by a virtual MDM
-create_odbc Creates an ODBC for use by virtual MDM
-register_odbc Registers ODBC for virtual MDM
-bootstrap_odbc Creates the tables for virtual MDM
MDM uninstall
The madconfig utility also supports uninstalling the MDM application server and database.
Attention: Reset of the MDM operational server and database components is supported by the Test
Environment tool in InfoSphere MDM Workbench. Even though madconfig targets are available for reset,
the best practice is to always use the workbench tool.
Table 18. madconfig utility targets for uninstall
Command Description
-uninstall_mds_ws_api Uninstalls the API for virtual MDM
-uninstall_mdm_ws_ear Uninstalls the MDM web services enterprise archive
Table 18. madconfig utility targets for uninstall (continued)
Command Description
-uninstall_prop_file_jar Uninstalls the property file JAR required by an MDM application
-uninstall_mdm_eba Uninstalls the MDM OSGi
-uninstall_mdm_old_ws_ear Uninstalls the physical MDM web services JAR in the application server
-uninstall_server_config Removes the MDM-related configuration changes made to the application
server
-uninstall_native_engine_ear Uninstalls the native operational server (engine) for the virtual MDM
-remove_datasource Removes the data source that is used by a virtual MDM
-unregister_odbc Unregisters ODBC used by virtual MDM
Manual installation of the physical MDM database
You can manually install the physical MDM database on DB2 for UNIX or Linux, DB2 for z/OS, and
Oracle.
You can always use IBM Installation Manager to create the physical MDM database. However, if you
choose, you can install it manually.
The virtual MDM database is always installed by using IBM Installation Manager.
Before you begin the manual installation, read the following and made any necessary decisions about
creating table spaces and installing triggers.
Table spaces
For DB2 databases on UNIX or Linux and Oracle databases, you can create table spaces for user
data, user indexes, and user large objects to improve database performance. Placeholder values
are provided in relevant scripts as TABLE_SPACE, INDEX_SPACE, and LONG_SPACE. You can
adjust the table space sizes in the provided scripts to the appropriate size for your production
environment.
There are two separate table spaces for the InfoSphere MDM Probabilistic Matching Engine,
requiring that the InfoSphere MDM Probabilistic Matching Engine table spaces have the same
names as TABLE_SPACE and INDEX_SPACE, but with an additional letter E at the end of the
table space name.
Triggers
Two types of triggers are provided with the InfoSphere MDM installation: simple triggers and
compound triggers. You must select one of these types of triggers to install:
v Simple triggers: Create a copy of the "before" image of the current data to the HISTORY table
when a base table is created, updated, or deleted. The HISTORY table contains only old
records; it does not contain the current record in base table. If you choose to install simple
triggers, you must install the simple update triggers. You can also install the simple delete
triggers, which are optional.
v Compound triggers: Create a copy of the "before" and "after" images of the current data from
the base table to the HISTORY table when a base table is inserted, updated, or deleted. The
HISTORY table contains all old records and the current record in base table. If you choose to
install compound triggers, you must install the insert and update triggers. You can also install
the compound delete triggers, which are optional.
Multi-time Zone (UTC)
If your application is running across different time zones, or your data has time values under
different time zones, you must enable the multi-time zone feature.
Once this feature is activated, you cannot deactivate it.
If you do not require the multi-time zone feature, you must disable it when you install the
database.
Case sensitive or non-case sensitive search capability
You can add the capability to search for contracts, products, and categories by name, but without
case sensitivity restrictions. Once the non-case sensitive feature is activated, you cannot deactivate
it. It is available on DB2 UDB, DB2 for z/OS v9 and later, and Oracle.
Setting the XA configuration in IBM WebSphere Application Server to
connect with DB2 for z/OS
When manually installing the MDM database on DB2 for z/OS, use this procedure to set the XA
configuration in IBM WebSphere Application Server.
About this task
You must change the sample values in the procedure to match your server environment.
Procedure
1. Log in to the UNIX system as the root user and go to the DB2 instance directory. For example: cd
/usr/opt/db2_10_01/instance
2. Run the following command from the instance directory to create a full ESE instance: db2icrt -a
SERVER -p 60000 -s ese -u db2fenc1 db2inst1
3. Log in as the instance user (db2inst1 in this example) after the instance is created and catalog the
z/OS database.
4. Start the DB2 instance by using the db2start command.
5. Configure a type 4, CLI-based JDBC provider for XA support.
6. Configure IBM WebSphere Application Server to use XA driver for DB2 for z/OS.
7. Add the following line to your CLASSPATH:
<DB2HOME>sqllib/java/db2jcc.jar
Related tasks:
Installing the core database manually on DB2 for z/OS by using TSO and JCLs on page 109
You can use Job Control Language (JCL) to manually install the InfoSphere MDM core database on DB2
for z/OS.
z/OS database creation and installation
When you are creating the subsystem and associating databases to it, keep in mind that InfoSphere MDM
is developed on DB2 for z/OS with Unicode data and more than one language. You also need to set XA
configuration.
To address Unicode, there are two setup options for you to choose from:
v
1. Set up one DB2 for z/OS subsystem with UNICODE parameter in the DSNZPARM, for example:
Unicode CCSID = 1208 CCSID of Unicode UTF-8 data.
DEF ENCODING SCHEME = UNICODE
LOCALE LC_CTYPE = UNI
APPLICATION ENCODING = UNICODE
2. Work with the default DB2 for z/OS subsystem and rebind all MDM packages with Unicode by
using LOCALE LC_CTYPE = UNI., which is required for aggregate functions like UPPER and LOWER.
v If you are using a new DB2 subsystem, set all DSNZPARM to Unicode, including the DSNHDECP macro
parameter LC_TYPE. Unicode databases and access plans are required for full functionality.
v Space allocation: before physical objects are created, it is necessary to provide space on DASD. To
simplify storage allocation, the recommendation is to use storage groups under SMS. Create HLQ
MDMIBM for all z data files.
v Table spaces and index spaces: for easier maintenance and to avoid performance issues, separate tables
and their related indexes into different table spaces and index spaces. For small tables, use segmented
table spaces; for large tables, use simple table spaces. You can also use partitioned table spaces.
v Authorization and qualifier: Create and access all objects by using one authorization ID.
v Buffer pools: if buffer pools do not exist, you must create them. A minimum size of 1000 if good. A
sample SQL statement to create buffer pools is: ALTER BUFFERPOOL (bp3) VPSIZE (1000);
XA configuration for DB2 for z/OS
Make sure that you complete the procedure for the WebSphere Application Server JDBC provider and
data source. This procedure is necessary for WebSphere Application Server to work properly against DB2
for z/OS.
Granting connection privileges on DB2 for z/OS
If you are manually installing a physical MDM database on DB2 for z/OS, use this procedure to grant
the necessary connection privileges.
Procedure
1. Ensure SYSADM is granted to the installation user for table spaces and initial database creation.
2. Ensure that the following list of privileges is granted to the installation user:
Attention: You must change the sample values in the procedure to match your server environment.
v GRANT CREATETAB, CREATETS ON DATABASE DSNDB04 TO <USER_ID>;
v GRANT USE OF BUFFERPOOL BP0 TO <USER_ID>;
v GRANT USE OF STOGROUP SYSDEFLT TO <USER_ID>;
v GRANT USE OF TABLESPACE DSNDB04.SYSDEFLT TO <USER_ID>;
v GRANT EXECUTE ON PLAN DSNESPCS TO <USER_ID>;
v GRANT EXECUTE ON PLAN DSNESPRR TO <USER_ID>;
v GRANT EXECUTE ON PLAN DSNEDCL TO <USER_ID>;
v GRANT EXECUTE ON PLAN DSNHYCRD TO <USER_ID>;
v GRANT SELECT ON SYSIBM.SYSDUMMY1 TO <USER_ID>;
v GRANT EXECUTE ON PLAN DSNTIA<DB2 VERSION> TO <USER_ID>;
v GRANT EXECUTE ON PROCEDURE SYSPROC.DSNWZP TO <USER_ID>;
v GRANT EXECUTE ON PROCEDURE SYSPROC.DSNWSPM TO <USER_ID>;
v GRANT EXECUTE ON PACKAGE DSNUTILS.DSNUTILS TO <USER_ID>;
v GRANT EXECUTE ON PROCEDURE SYSPROC.DSNUTILS TO <USER_ID>;
v GRANT EXECUTE ON PACKAGE DSNUTILU.DSNUTILU TO <USER_ID>;
v GRANT EXECUTE ON PROCEDURE SYSPROC.DSNUTILU TO <USER_ID>;
Related tasks:
Installing the core database manually on DB2 for z/OS by using TSO and JCLs on page 109
for z/OS.
Oracle database setting
When manually installing the physical MDM database on Oracle, if you omit the execution of the
create_schema_ora.sql script then you must alter the Oracle database system.
Inside the create_schema_ora.sql script, make sure that the ALTER SYSTEM SET open_cursors statement is
set as:
ALTER SYSTEM SET open_cursors = 1500 SCOPE=BOTH;
Also verify that the grants are done specially as GRANT CREATE SEQUENCE TO <SCHEMA>;
Manual installation of the physical MDM database on DB2 for Linux or
UNIX
You can manually install the physical MDM database on DB2 for Linux or UNIX.
There are separate instructions for installing the configuration and management database, and the core
domain database.
Before you start the installation, read about manual installation of the database.
Installing the core database manually on DB2 for UNIX or Linux
Use this procedure to install the core physical MDM database on DB2 for UNIX or Linux.
Procedure
1. Go to the MDM/database/CoreData/DB2/Standard/ddl directory.
2. Edit the scripts in this directory by replacing the placeholder values with the values to use in your
database.
Remember: To run most scripts, use the command syntax
db2 -tvf SCRIPT_NAME -l LOG_FILE_NAME
where SCRIPT_NAME is the name of the script you are running, and LOG_FILE_NAME is the name
of the history file where the commands are logged. If you must use a different command syntax, the
syntax is shown in the procedure.
Change the placeholder value:
a. Replace DBNAME with the database name you want to use.
b. Replace TERRITORY with the territory.
c. Replace TABLE_SPACE with the table space name where base and history table data are to be
stored.
d. Replace INDEX_SPACE with the table space name where indexed data is stored.
e. Replace LONG_SPACE with the table space name where long user column data like CLOB and
XML is stored.
f. Replace SCHEMA with the schema name assigned to hold the database assets.
g. Replace DBUSER with the database user ID that owns the schema.
h. Change the DTYPE placeholder value to one of the following values in lowercase:
v banking
v insurance
v telco
v manufacturing
i. CONFIG_LANG to the configuration language to be used.
For example, for English, use en; for French, use fr.
j. CODE_LANG to the language of any additional code table data to be loaded.
For example, for Japanese, use ja; for French, use fr.
3. Ensure that you have DBA privileges to run the CreateDB.sql script.
4. Create the database and table spaces, and grant required privileges to authorized users and schemas
by running the CreateDB.sql file.
5. Create the table spaces, and grant required privileges to authorized users and schemas by running
the CreateTS.sql file. In this script, four extra table spaces for InfoSphere MDM Probabilistic
Matching Engine database objects are created. The names of the two table spaces are created based
on TABLE MDS4K, TABLE_SPACE, TABLE SPMDS, TABLE SPPMI, LONG SPACE and
INDEX_SPACE. You can change them if you want.
6. Connect to the database you just created.
7. From the command line in MDM/database/CoreData/DB2/Standard/ddl, run the scripts in the order
listed:
a. CreateTables.sql: Creates all base tables and primary key definitions.
b. CreateTables_H.sql: Creates all history tables and primary key definitions.
c. CreateIndexes.sql: Creates all indexes, including unique index constraints.
d. CreateFK.sql: Creates all foreign keys.
e. CreateCHK.sql: Creates all check constraints.
8. Determine whether you must enable the multi-time zone feature:
If your application is running across different time zones, or your data has time values under
different time zones, you must enable the multi-time zone feature.
If you do not require the multi-time zone feature, you must disable it when you install the database.
v To enable the multi-time zone feature:
a. Go to the .ddl subdirectory.
b. From the command line, run the script:
Create_function_utc_enabled.sql
v To disable the multi-time-zone feature:
Create_function_utc_disabled.sql
9. Run the scripts for either compound triggers or simple triggers.
Remember: To run scripts to create triggers, use the command syntax
db2 -v -td@ -f SCRIPT_NAME -l LOG_FILE_NAME
v To install simple triggers, run the script:
a. CreateTriggers_simple.sql: Installs simple triggers.
b. Optional: CreateTriggers_delete_simple.sql: Installs simple triggers for deletes.
v To install compound triggers, run the script:
a. CreateTriggers_compound.sql: Installs compound triggers for inserts and updates.
b. Optional: CreateTriggers_delete_compound.sql: Installs compound triggers for deletes.
10. To populate the code tables with English language data for the industry that is entered in the DTYPE
placeholder and the configuration data in the language that is entered in the CONFIG_LANG
placeholder, run the script:
ImpReqData.sql
11. Choose whether to install more than one language:
v If you are installing the product in English only, skip this step.
v Proceed with this step to install supplemental sets of code table data for languages other than
English. For the industry entered in the DTYPE placeholder and for language code that is entered
in the CODE_LANG placeholder, run the script:
ImpCodeTableData.sql
Repeat this step for every language you are installing.
12. Optional: To enable non-case sensitive searching, run the following script:
Insensitive_search_enabled.sql
Manual installation of the domain database on DB2 for UNIX or Linux
You can manually install the domain database on DB2 for UNIX or Linux.
Before you start the installation:
v Make sure that you created the core database, and that you have the correct level of access to it. The
domain database assets are added to the same database.
v Read the manual installation of the physical MDM database topic, and make the same decisions on the
optional steps as you made when you install the core database.
Installing the domain database manually on DB2 for Linux or UNIX:
Use this procedure to manually install the domain database.
Procedure
1. Go to the MDM/database/WCC/DB2/Standard/ddldirectory.
2. Edit all of the scripts in this directory by replacing the placeholder values with the values you want to
use in your database as follows:
a. Replace DBNAME with the database name you want to use.
b. Replace SCHEMA with the schema name assigned to hold the database assets.
c. Replace TABLE_SPACE with the table space name where base and history table data are to be
stored.
d. Replace INDEX_SPACE with the table space name where indexed data is stored.
e. Replace LONG_SPACE with the table space name where long user column data like CLOB and
XML is stored.
f. Replace DBUSER with the database user ID that owns the schema.
g. Change the DTYPE placeholder value to one of the following values in lowercase:
v banking
v insurance
v telco
v manufacturing
h. CONFIG_LANG to the configuration language to be used. For example, for English, use en; for
French, use fr.
i. CODE_LANG to the language of any additional code table data to be loaded. For example, for
Japanese, use ja; for French, use fr.
Attention: The CreateDB.sql statement creates two separate table spaces for the InfoSphere MDM
Probabilistic Matching Engine, as follows: TABLE_SPACE and INDEX_SPACE.
3. Connect to the core database that you created.
Remember: To run most scripts, use the command syntax
db2 -tvf SCRIPT_NAME -l LOG_FILE_NAME
4. Run the following scripts in the order that they are listed from the command line in
MDM/database/WCC/DB2/Standard/ddl
v CreateTables.sql: Creates all base tables and primary key definitions.
v CreateTables_H.sql: Creates all history tables and primary key definitions.
v CreateIndexes.sql: Creates all indexes, including unique index constraints.
v CreateFK.sql: Creates all foreign keys.
v CreateCHK.sql: Creates all check constraints.
v Create_eME.sql: Creates all InfoSphere MDM Probabilistic Matching Engine objects. In this script,
you must replace the two place holder for real table spaces and the index space name.
5. Run the scripts for either compound triggers or simple triggers:
Remember: To run scripts to create triggers, use the command syntax
db2 -v -td@ -f SCRIPT_NAME -l LOG_FILE_NAME
v To install simple triggers:
CreateTriggers_simple.sql installs simple triggers
Optional: CreateTriggers_delete_simple.sql installs simple triggers for deletes.
v To install compound triggers, run the scripts:
CreateTriggers_compound.sql installs compound triggers for inserts and updates.
Optional: CreateTriggers_delete_compound.sql installs compound triggers for deletes.
6. To populate the code tables with English language data for the industry that is entered in the DTYPE
placeholder and the configuration data in the language that is entered in the CONFIG_LANG
placeholder, run the script: ImpReqData.sql
7. Choose whether to install more than one language:
v Proceed with this step to install supplemental sets of code table data for languages other than
English. For the industry entered in the DTYPE placeholder and for language code that is entered
in the CODE_LANG placeholder, run the script: ImpCodeTableData.sql. Repeat this step for every
language that you are installing.
8. If non-case sensitive searching is enabled in the core database, you must run the following script:
Insensitive_search_enabled.sql.
9. Check the installation log files to verify that the installation is complete.
Manual installation of the physical MDM database on DB2 for z/OS
You can manually install the physical MDM database on DB2 for z/OS.
Before you start the installation, read the manual installation of the database topic, including the notes
and the information about z/OS database creation and installation, and make you consider all the issues
presented.
Installing the core database manually on DB2 for z/OS by using TSO and JCLs
for z/OS.
Before you begin
This task contains a number of placeholder values. Make sure that you have the necessary system
information before you begin. Contact your systems programmer for this information as necessary.
Make sure that you created HLQ MDMIBM. This is needed only for installation and can be dropped after
you complete the install.
Procedure
1. Go to the MDM/database/CoreData/DB2/ZOS/pds/ddllib directory and take the following steps:
a. Modify the script .netrc to create and transfer the ddls to the mainframe.
b. Replace USER with an authorized name to FTP to the mainframe.
c. Replace PASSWORD with the password for the authorized user.
d. Replace HOSTNAME with the host name of the mainframe.
e. Make sure that the permission of the file is 600. If it is not, run the command chmod 600 .netrc.
This .netrc file must be inside the $HOME directory.
f. Run the following command:
echo "\$ transferddl" | ftp hostname
The MDMIBM.MIHDDL.LIB library is added to your system on the mainframe.
2. Go to the MDM/database/CoreData/DB2/ZOS/pds/jcllib directory and take the following steps:
e. Ensure that the permission of the file is 600. If it is not, run the command chmod 600 .netrc. This
.netrc file must be inside the $HOME directory.
echo "\$ transferjcl" | ftp hostname
The MDMIBM.MIHJCL.LIB library is added to your system on the mainframe.
3. Go to the MDM/database/CoreData/DB2/ZOS/pds directory and take the following steps:
e. Make sure that the permission of the file is 600. If it is not, run the command chmod 600 .netrc.
echo "\$ transferbins" | ftp hostname
The MDMIBM.MIH*.BIN data set is added to your system on the mainframe.
4. Log in to TSO on the database server.
5. Using TSO/ISPF, go to MDMIBM.MIH.DDLLIB and edit each of the scripts in the data sets one at a time
as follows:
a. Replace DBA ACCOUNT with a DB account with DBADM authority.
b. Replace USER ACCOUNT with a user account with the appropriate authority level.
c. Replace STOGROUP_NAME with the storage group name.
d. Replace db_prefix with the three-character database prefix assigned by the database administrative
authority.
e. Replace VCATNAME with the actual VCAT name.
For more information, see the CREATE STOGROUP statement in the MDMIBM.MIHDDL.LIB library data set
member .
6. Using TSO/ISPF, browse to MDMIBM.MIHJCL.LIB and modify the data set member MDMICOR to replace
the following placeholder values with appropriate values for use in your database:
a. Replace JOB NAME with the name of the job.
b. Replace db-hlq with a valid DSN High Level Qualifier value.
c. Replace SYSTEM with a valid DB2 Subsystem ID.
d. Replace USRQ with the High Level Qualifier of the user account.
e. Replace PLANNAME with DB2 plan for the utility DSNTEP2.
f. Multiple time zone (MTZ) is disabled by default. If you want to ENABLE MTZ, then comment
out the line //SYSIN DD DSN=MDMIBM.MIHDDL.LIB(Z08CRUTE),DISP=SHR inside the JCL MDMICOR (see
step 8). For MDMICOR job, return codes of 0 or 4 indicate that the JCL ran successfully.
g. Submit the MDMICOR JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
7. Extract the common data to receive the data files by browsing to MDMIBM.MIHJCL.LIB and modify the
data set member RECBINDT to replace the following placeholder values with appropriate values for
use in your database:
e. Submit the RECBINDT JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
8. Expand the data sets to restore the data sets by browsing to MDMIBM.MIHJCL.LIB and modify the data
set member RESDATDT to replace the following placeholder values with appropriate values for use in
your database:
d. Submit the RESDATDT JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
9. Extract the EN data files by browsing to MDMIBM.MIHJCL.LIB and modifying the data set member
RECBINEN to replace the following placeholder values with appropriate values for use in your
database:
d. Submit the RECBINEN JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
10. Expand the data sets to restore the EN data sets by browsing to MDMIBM.MIHJCL.LIB and modify the
data set member RESDATEN to replacing the following placeholder values with appropriate values for
e. Submit the RESDATEN JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
11. Extract the CODE_LANGUAGE data files by browsing to MDMIBM.MIHJCL.LIB and modifying the data
set member RECBINOP to replace the following placeholder values with appropriate values for use in
your database:
d. Replace CODE_LANG with the code language (not EN) that you want to receive.
e. Submit the RECBINOP JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
12. Expand the data sets to restore the CODE_LANGUAGE data sets by browsing to MDMIBM.MIHJCL.LIB
and modifying the data set member RESDATOP to replace the following placeholder values with
appropriate values for use in your database:
d. Replace CODE_LANG with the code language (not EN) that you want to receive.
e. Submit the RESDATOP JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
13. Using TSO/ISPF, browse to MDMIBM.MIHJCL.LIB and modify the data set member IMPRQCO to replace
the following placeholder values with the appropriate values for use in your database:
c. Replace SYSTEM to a valid DB2 Subsystem ID.
d. Replace CONFIG_LANG to the code language that you want to install (for example, DE for
German, EL for Greek, and so on).
e. Replace DTYPE with one of the following values:
v BAN for banking
v INS for insurance
v TEL for telco
v MAN for manufacturing
f. Replace USER_ACCOUNT with a user account with the appropriate authority level.
g. Submit the IMPRQCO JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
14. Import the data for config manager tables on the database by browsing MDMIBM.MDMJCL.LIB and
modify the dataset member IMPRQCM to replace the following placeholder values with the appropriate
values for use in your database.
d. Replace USER ACCOUNT with a user account with the appropriate authority level.
e. Submit the IMPRQCM JCL using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
15. Choose whether to populate the code tables with data for languages other than English:
v If you are installing for the English language only, skip this step. English was loaded in step 13.
v If you are installing for more languages, browse to MDMIBM.MIHJCL.LIB and modify the data set
member IMPOPCO to replace the following placeholder values with the appropriate values for your
database:
Replace JOB NAME with the name of the job.
Replace db-hlq with a valid DSN High Level Qualifier value.
Replace SYSTEM with a valid DB2 Subsystem ID.
Replace CONFIG_LANG with the code language (not EN) that you want to install (for example,
DE for German, EL for Greek, and so on).
Replace DTYPE with one of the following values:
- BAN for banking
- INS for insurance
- TEL for telco
- MAN for manufacturing
Replace USER_ACCOUNT with a user account with the appropriate authority level.
Submit the IMPOPCO JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
Repeat this procedure for each language (not EN) that you want to install (for example, ES for
Spanish, IT for Italian, and JA for Japanese, and so on).
Related tasks:
Setting the XA configuration in IBM WebSphere Application Server to connect with DB2 for z/OS on
page 104
When manually installing the MDM database on DB2 for z/OS, use this procedure to set the XA
configuration in IBM WebSphere Application Server.
Granting connection privileges on DB2 for z/OS on page 105
If you are manually installing a physical MDM database on DB2 for z/OS, use this procedure to grant
the necessary connection privileges.
Installing the CLOB data manually on DB2 for z/OS for the core database
Use this procedure to manually install the CLOB data on DB2 for z/OS
Procedure
1. Go to the data set library MDMIBM.MIHJCL.LIB and edit the data set member IPDCLSPF to replace the
following placeholder values with appropriate values for your database.
a. Change JOB NAME to the name for the job.
b. Change db-hlq to a valid DSN High Level Qualifier value.
c. Change SYSTEM> to a valid DB2 Subsystem ID.
2. Submit the IPDCLSPF JCL by using the sub command.
Manual installation of the domain database on DB2 for z/OS
You can manually install the physical MDM domain database on DB2 for z/OS.
Installing the domain database manually on DB2 for z/OS:
Use this procedure to manually install the domain database on DB2 for z/OS.
Before you begin
This task contains a number of placeholder values. Make sure that you have the necessary system
information before you begin. Contact your systems programmer for this information as necessary.
In the mainframe, the High Level Qualifier (HLQ), called MDMIBM, has 3-GB space that is allocated to store
all files and libraries for InfoSphere MDM.
Procedure
1. Go to the MDM/database/WCC/DB2/ZOS/pds/ddllib directory where the WAS.jar was expanded.
2. Modify the script .netrc to create and transfer the ddls to the mainframe by taking the following
steps.
a. Change USER with an authorized user name to FTP to the mainframe.
b. Change PASSWORD with the password for that user. Before you run the command, make sure
that the permission of the file is 600. If it is not, run the command chmod 600 .netrc. This .netrc
file must be inside the $HOME directory.
c. Run the following command:
echo "\$ transferddl" | ftp host-name
The library MDMIBM.MDMJCL.LIB is added to your system on the mainframe.
3. Go to the MDM/database/WCC/DB2/ZOS/pds/jcllib directory and modify the script .netrc to create
and transfer the ddls to the mainframe by taking the following steps.
a. Replace USER with an authorized user name to FTP to the mainframe
b. Replace PASSWORD with the password for that user.
c. Change HOSTNAME with the host name of the mainframe.
d. Make sure that the permission of the file is 600. If it is not, run the command chmod 600 .netrc.
e. Run the following command:
echo "\$ transferjcl" | ftp host-name
The library MDMIBM.MDMJCL.LIB is added to your system on the mainframe.
4. Go to the MDM/database/WCC/DB2/ZOS/pds directory and modify the script .netrc to create and
transfer the ddls to the mainframe by taking the following steps.
a. Replace USER with an authorized user name to FTP to the mainframe.
b. Replace PASSWORD with the password for that user.
c. Replace HOSTNAME with the host name of the mainframe.
d. Make sure that the permission of the file is 600. If it is not, run the command chmod 600 .netrc.
e. Run the following command:
echo "\$ transferbins | ftp hostname
The data set MDMIBM. MDM*.BIN is added to your system on the mainframe.
5. Log on to TSO on the database server.
6. Using TSO/ISPF, browse to MDMIBM.MDMDDL.LIB and edit each of the scripts in the data sets one at a
time to replace the following placeholder values with appropriate values for use in your database:
a. Replace DBA ACCOUNT with a DB account with DBADM authority. For example, run the CHG
command: CHG 'DBA ACCOUNT' 'DB2OPER' all
b. Replace USER ACCOUNT with a user account with the appropriate authority level.
c. Replace STOGROUP_NAME with the storage group name.
d. Replace db_prefix with the three-character database prefix assigned by the database administrative
authority.
e. Replace VCATNAME with the actual VCAT name.
For more information, see the CREATE STOGROUP statement in the data set member @01crdb of the
MDMIBM.MDMDDL.LIB library.
7. Using TSO/ISPF, go to MDMIBM.MDMJCL.LIB and edit the data set member MDMIDOM to replace the
following placeholder values with values appropriate to your database:
e. Replace PLANNAME with DB2 plan for the utility DSNTEP2.
f. Submit the MDMIDOM JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
8. Extract the code table data to receive the data files by going to MDMIBM.MDMJCL.LIB and modify the
data set member RECBINDT to replace the following placeholder values with appropriate values for
e. Submit the RECBINDT JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully.
9. Expand the data sets to restore the data, and browse to MDMIBM.MDMJCL.LIB and modify the data set
member RESDATDT to replace the following placeholder values with appropriate values for use in
your database:
d. Submit the RESDATDT JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
10. Extract the EN data files, browse to MDMIBM.MDMJCL.LIB and modify the data set member RECBINEN to
replace the following placeholder values with appropriate values for use in your database:
d. Submit the RECBINEN JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
11. Expand the data sets to restore EN data, go to MDMIBM.MDMJCL.LIB and modify the data set member
RESDATEN to replace the following placeholder values with appropriate values for use in your
database:
d. Submit the RESDATEN JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
12. Extract the data files to receive CODE_LANG data files, and go to MDMIBM.MDMJCL.LIB and modify the
data set member RECBINOP to replace the following placeholder values with appropriate values for
d. Change CODE_LANG to code language (not EN) you want to receive.
e. Submit the RECBINOP JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
13. Expand the data sets to restore CODE_LANG data sets, and go to MDMIBM.MDMJCL.LIB and modify the
data set member RESDATOP to replace the following placeholder values with appropriate values for
d. Change CODE_LANG to code language (not EN) you want to receive.
e. Submit the RESDATOP JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
14. Using TSO/ISPF, browse to MDMIBM.MDMJCL.LIB and modify the data set member IMPRQDM to replace
the following placeholder values with the appropriate values for use in your database:
d. Replace CONFIG_LANG with the configuration language you want. For example, DE for German
or EL for Greek.
e. Replace DTYPE with one of the following values:
v BAN for banking
v INS for insurance
v TEL for telco
v MAN for manufacturing
f. Replace USER ACCOUNT with a user account with the appropriate authority level.
g. Submit the IMPRQDM JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
15. Update the data from the core database by going to MDMIBM.MDMJCL.LIB and modifying the data set
member IMPUPDM to replace the following placeholder values with the appropriate values for use in
your database:
e. Submit the IMPUPDM JCL by using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
16. Import the domain data for config manager tables on the database by browsing MDMIBM.MDMJCL.LIB
and modifying the dataset member IMPRQCM to replace the following placeholder values with the
appropriate values for use in your database.
a. Replace JOBNAME with the name of the job.
e. Submit the IMPRQCM JCL using the sub command. Return codes of 0 indicate that the JCL ran
successfully.
17. Choose whether to populate the code tables with data for languages other than English:
v If you are installing the English language only, skip this step.
v If you are installing more languages, browse to MDMIBM.MIHJCL.LIB and modify the data set
member IMPOPDM (this name is not consistent with IMPOPDM mentioned in the Submit instructions)
to replace the following placeholder values with the appropriate values for your database:
Replace JOB NAME with the name of the job.
Replace db-hlq with a valid DSN High Level Qualifier value.
Replace SYSTEM with a valid DB2 Subsystem ID.
Replace CONFIG_LANG with the code language that you want to install (for example, DE for
German, EL for Greek, and so on).
Replace DTYPE with one of the following values:
- BAN for banking
- INS for insurance
- TEL for telco
- MAN for manufacturing
Replace USER_ACCOUNT with a user account with the appropriate authority level.
Submit the IMPOPDM JCL by using the sub command. Return codes of 0 or 4 indicate that the JCL
ran successfully. Repeat this procedure for each language (not EN) that you want to install.
Installing the CLOB data manually on DB2 for z/OS for the domain database:
Use this procedure to install the CLOB data manually for the domain database on DB2 for z/OS.
Procedure
1. Go to the data set library MDMIBM.MIHJCL.LIB and edit the data set member IPDCLIQL to replace the
following placeholder values with appropriate values for your database:
a. Change JOB NAME to the name for the job.
b. Change db-hlq to a valid DSN High Level Qualifier value.
c. Change SYSTEM to a valid DB2 Subsystem ID.
2. Submit the IPDCLIQL JCL by using the sub command.
Installing the core database manually on Microsoft SQL Server
Use this procedure to install the full core database manually on Microsoft SQL Server.
About this task
Before you start the installation, read about manual installation of the physical MDM database.
Procedure
1. Go to the MDM/database/CoreData/SQL Server/ddl directory.
use in your database. Change the following placeholders:
v db_name to the name of the database
v MDMSEFG to the name of the filegroup
v Logical_FG_Namex to the name of the new file to be added to the filegroup and where x is a
number starting from 1 if more than one filegroup must be created or added
v location to the location of the filegroup file; for example:
Microsoft SQL Server 2008R2: C:/Program Files/Microsoft SQL Server/
MSSQL10_50.MSSQLSERVER/MSSQL/DATA
Microsoft SQL Server 2012: C:/Program Files/Microsoft SQL Server/MSSQL11.DBSQL2/MSSQL/
DATA
v db_user to a database object owner
v password to the db_user password
v schema to the object owner
v CODE_LANG to the language of any additional code table data to be loaded, for example: for
Japanese, use ja or for French, use fr
v CONFIG_LANG to the configuration language to be used; for example, for English, use en or for
French, use fr
v DTYPE to the type of data to be loaded; specify one of the following values in lowercase: banking;
insurance, manufacturing, telco
v mds_home to the location of your virtual MDM operational server
v datasource_name to the name of your database
v dbadmin user to the name of the database user
v dbadmin password to the password for your database user
3. From the command line in the MDM/database/CoreData/SQL Server/ddl directory, run the commands
in the order that they are listed.
a. Sqlcmd S Server Name-U dbadmin user-P dbadmin password-i Create_DB.sql > logfile name
b. Sqlcmd S Server Name -U dbuser -P dbuser password -d db_name -i CreateTables.sql >
logfile name
c. Sqlcmd S Server Name -U dbuser -P dbuser password -d db_name -i CreateFK.sql > logfile
name
d. Sqlcmd S Server Name -U dbuser -P dbuser password-d db_name -i CreateIndexes.sql >
logfile name
e. Sqlcmd S Server Name -U dbuser -P dbuser password -d db_name -i CreateCHK.sql > logfile
name
4. Use IBM Installation Manager to load the data. On the features to install panel, select MDM database.
Manual installation of the physical MDM database on Oracle
You can manually install the physical MDM database on Oracle.
Before you start the installation, read manual installation of the physical MDM database topic.
Installing the core database manually on Oracle
Use this procedure to manually install the core database on Oracle.
Procedure
1. Go to the MDM/database/CoreData/Oracle/Standard/ddl directory.
use in your database. Change the following placeholders:
a. DBNAME to the name of the database.
b. SCHEMA to a database user with the required privileges
c. NEWPASSWORD to the password of the schema user
d. TABLE_SPACE to the table space name where base and history table data is stored
e. INDEX_SPACE to a table space name where indexed data is stored
f. LONG_SPACE to a table space where long user column data like CLOB and XML is stored
g. TABLESPACE_LOCATION to the location where the table space is created. This is usually in the
database directory that is in ORACLE_HOME. For example, D:/Oracle/product/10.2.0/oradata/
MDMDB where MDMDB is the name of the database and 10.2.0 is the version of Oracle that is being
used.
h. DTYPE to the type of data to be loaded. Specify one of the following values in lowercase:
v banking
v insurance
v telco
v manufacturing
i. CONFIG_LANG to the configuration language to be used. For example, for English use en; for
French use fr
j. CODE_LANG to the language of any additional code table data to be loaded. For example, for
Japanese use ja; for French use fr
k. DBUSER to a database user with DBA Authority
l. DBPASSWORD to the password of the dbuser
3. From the command line in MDM/database/CoreData/Oracle/Standard/ddl, run the commands in the
order that they are listed:
a. sqlplus DBUSER/DBPASSWORD@DBNAME @create_schema_ora.sql>> LOG_FILE_NAME creates the database
schema.
b. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_tables_ora.sql>> LOG_FILE_NAME creates the base
tables and primary key definitions.
c. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_hist_tables_ora.sql>> LOG_FILE_NAME creates the
history tables and primary key definitions.
d. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_ix_ora.sql>> LOG_FILE_NAME creates all indexes,
including unique index constraints.
e. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_fk_ora.sql>> LOG_FILE_NAME creates the foreign
keys.
f. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_chk_ora.sql>> LOG_FILE_NAME creates the check
constraints.
g. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_eME_ora.sql>> LOG_FILE_NAME creates the InfoSphere
MDM Probabilistic Matching Engine objects
4. If your application is running across different time zones, or your data has time values under different
time zones, you must enable the multi-time zone feature. If the multi-time zone feature is not
required, you must disable it when you install the database
v To enable the multi-time zone feature:
sqlplus SCHEMA/NEWPASSWORD@DBNAME
@Create_function_utc_enabled.sql >> LOG_FILE_NAME
v To disable the multi-time-zone feature:
sqlplus SCHEMA/NEWPASSWORD@DBNAME
@Create_function_utc_disabled.sql >> LOG_FILE_NAME
5. Run the commands for either compound triggers or simple triggers.
v To install simple triggers, run the scripts:
sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_triggers_simple_ora.sql>> LOG_FILE_NAME installs
simple triggers
Optional: sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_delete_triggers_simple_ora.sql>>
LOG_FILE_NAME installs simple triggers for deletes.
sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_triggers_compound_ora.sql>> LOG_FILE_NAME
installs compound triggers for inserts and updates.
Optional: sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_delete_triggers_compound_ora.sql>>
LOG_FILE_NAME installs compound triggers for deletes.
6. Convert the ImpReqData.script file to a shell script, and run the shell script from the command line.
This script populates the required code tables and required system configuration tables with English
code table data for the industry that is entered in the DTYPE placeholder, and the configuration data
in the language that is entered in the CONFIG_LANG placeholder.
7. Choose whether to install code table date for languages other than English.
v To install code table data for languages other than English for the industry that is entered in the
DTYPE placeholder and the language code that is entered in the CODE_LANG placeholder, convert
the Imp_CodeTables_Data.script file to a shell script, and run the shell script from the command
line. Repeat this step for each language you want to install.
8. Optional: To enable non-case sensitive searching, run the script:
sqlplus SCHEMA/NEWPASSWORD@DBNAME @Insensitive_search_enabled.sql >> LOG_FILE_NAME
Attention: The create_schema_ora.sql statement creates two separate table spaces for the
InfoSphere MDM Probabilistic Matching Engine, as follows: TABLE_SPACE>E and INDEX_SPACE>E
Manual installation of the domain database on Oracle
You can manually install the domain database on Oracle.
Installing the domain database manually on Oracle:
Use this procedure to manually install the domain database on Oracle.
Procedure
1. Go to the MDM/database/WCC/Oracle/Standard/ddl directory:
use in your database as follows:
a. Replace DBNAME with the name of the database.
b. Replace SCHEMA with the schema name assigned to hold the database assets.
c. NEWPASSWORD to the password of the schema user.
d. TABLE_SPACE to the table space name where base and history table data will be stored.
e. INDEX_SPACE to a table space name where indexed data will be stored.
f. LONG_SPACE to a table space where long user column data like CLOB and XML will be stored
g. TABLESPACE_LOCATION to the location where the table space will be created. This is usually in
the database directory that is in ORACLE_HOME. For example, D:/Oracle/product/10.2.0/
oradata/MDMDB where MDMDB is the name of the database and 10.2.0 is the version of Oracle being
used.
h. DTYPE to the type of data to be loaded. Specify one of the following values in lowercase:
v banking
v insurance
v telco
v manufacturing
i. CONFIG_LANG to the language to be used. For example, for English use en; for French use fr.
j. CODE_LANG to the language of any additional code table data to be loaded. For example, for
Japanese use ja; for French use fr.
3. From the command line in MDM/database/WCC/Oracle/Standard/ddl, run these commands in the order
that they are listed:
a. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_tables_ora.sql>> LOG_FILE_NAME creates the base
tables and primary key definitions
b. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_hist_tables_ora.sql>> LOG_FILE_NAME creates the
history tables and primary key definitions
c. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_ix_ora.sql>> LOG_FILE_NAME creates all indexes,
including unique index constraints
d. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_fk_ora.sql>> LOG_FILE_NAME creates the foreign
keys
e. sqlplus SCHEMA/NEWPASSWORD@DBNAME> @create_chk_ora.sql>> LOG_FILE_NAME creates the check
constraints
f. sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_eME_ora.sql>> LOG_FILE_NAME creates the InfoSphere
MDM Probabilistic Matching Engine objects.
Important: Before you run the create_eME_ora.sql script in the next step, edit the script and
replace the place holders TABLE_SPACE and INDEX_SPACE with the table space and index space
names created for the InfoSphere MDM Probabilistic Matching Engine database objects.
4. Run the scripts for either compound triggers or simple triggers:
v To install simple triggers:
sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_triggers_simple_ora.sql>> LOG_FILE_NAME installs
simple triggers
Optional: sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_delete_triggers_simple_ora.sql>>
LOG_FILE_NAME installs simple triggers for deletes
sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_triggers_compound_ora.sql>> LOG_FILE_NAME
installs compound triggers for inserts and updates.
Optional: sqlplus SCHEMA/NEWPASSWORD@DBNAME @create_delete_triggers_compound_ora.sql>>
LOG_FILE_NAME installs compound triggers for deletes.
5. Convert the ImpReqData.script file to a shell script, and run the shell script from the command line.
This script populates the required code tables and required system configuration tables with English
code table data for the industry that is entered in the DTYPE placeholder, and the configuration data
in the language that is entered in the CONFIG_LANG placeholder.
6. Choose whether to install code table date for languages other than English.
v To install code table data for languages other than English for the industry that is entered in the
DTYPE placeholder and the language code that is entered in the CODE_LANG placeholder, convert
the Imp_CodeTables_Data.script file to a shell script, and run the shell script from the command
line. Repeat this step for each language you want to install.
7. If you enabled non-case sensitive searching in the core database, you must run the following script:
Sqlplus SCHEMA/NEWPASSWORD@DBNAME @Insensitive_search_enabled.sql >> LOG_FILE_NAME
Installing the InfoSphere MDM messaging server component manually
You can use IBM Installation Manager to create the InfoSphere MDM messaging server component, or
you can install it manually.
About this task
Use IBM Installation Manager to install the InfoSphere MDM messaging component if IBM WebSphere
MQ is on the same machine as the one on which you plan to run the installer to install the MDM
operational server component. InfoSphere MDM messaging server component is installed by IBM
Installation Manager by default when you choose WebSphere MQ messaging provider rather than
WebSphere Application Server default messaging provider on the MDM application configuration panel.
Procedure
1. Ensure that you have the custSetupMQServer.mqsc script before you start manually installing
InfoSphere MDM messaging server component.
2. Obtain the custSetupMQServer.mqsc script from the STARTUPKIT_INSTALL_HOME directory.
3. Create and start the queue manager to be used by the InfoSphere MDM messaging server component
(replace MDM1011.QMANAGER with whatever name you choose) by running the script:
/usr/mqm/crtmqm MDM1011.QMANAGER
Skip this step if you intend to use an existing queue manager.
4. Start the queue manager by running the script:
/usr/mqm/strmqm MDM1011.QMANAGER
5. Prepare custSetupMQServer.mqsc by replacing the CHANNEL_NAME placeholder in the
custSetupMQServer.mqsc script with the actual value of the WebSphere MQ channel to be used.
6. Create the InfoSphere MDM messaging server component configuration objects by running the script:
/usr/mqm/runmqsc < $HOME/custSetupMQServer.mqsc MDM1011.QMANAGER
Replace the CHANNEL_NAME placeholder in the custSetupMQServer.mqsc script with the actual
value of the WebSphere MQ channel to be used.
7. Enable support for the event broker by running the script:
/usr/mqm/runmqsc < /usr/mqm/java/bin/MQJMS PSQ.mqsc MDM1011.QMANAGER
8. Start the event broker by running the script:
/usr/mqm/strmqbrk m MDM1011.QMANAGER
9. Start the queue listener by running the script:
/usr/mqm/runmlsr m MDM1011.QMANAGER t TCP p 1414&
You can use any valid port number for the WebSphere MQ listener port.
Related tasks:
installation.
Updating the deployed properties files for physical MDM
After you install or upgrade InfoSphere MDM, you might need to update the deployed properties files if
they require changes that cannot be made by using the Configuration Manager. Use this procedure to
update deployed properties files.
About this task
Attention: Updating properties dynamically is not ideal. Whenever possible, port your custom
properties to the Configuration Manager.
Because the properties files are packaged in a .jar and deployed as a business level application (BLA)
shared library asset, they cannot be changed by only altering a property value. When installed, a
duplicated properties.jar file is extracted to a deployment subdirectory of the BLA composition unit.
This extraction allows updates to be done in near real time without having to reinstall the enterprise
bundle application (EBA). For example, if the name of the application deployment is E001 and the
WebSphere Application Server installation home directory is opt/IBM/WebSphere/AppServer/, then the
location of deployed property files is in the installed asset directory of the application profile. In this case,
opt/IBM/WebSphere/AppServer/profiles/Node01/installedAssets/
com.ibm.mdm.server.resources.properties-E001.jar/BASE
You can modify the content of the JAR file directly on the node. In a multinode or cluster topology, the
changes must be manually replicated to all nodes and servers. The best way to update the properties is
by using the WebSphere Application Server administrative console, which handles the propagation for
you.
Procedure
1. Start WebSphere Application Server administrative console and go to Applications > Application
Types > Assets.
a. Select the com.ibm.mdm.server.resources.properties-deployment_name_used_for_install.jar file.
b. Click Export to export the currently deployed properties. From here, you can download the library
to your local system for updating.
2. Edit the values and files by using the expanded properties files of the
com.ibm.mdm.server.resources.properties-deployment_name_used_for_install.jar package that you
downloaded in step 1.
3. Repackage the changed properties into a new com.ibm.mdm.server.resources.properties-
deployment_name_used_for_install.jar file. Ensure that you keep the same name as the original
library.
4. In WebSphere Application Server administrative console, select the
com.ibm.mdm.server.resources.properties-deployment_name_used_for_install.jar file again.
a. Click Update.
b. On the next screen, choose the type of update you want and select the new properties JAR. For
example: select the Replace entire asset option along with the new or updated properties JAR.
Updating the properties asset by using this option automatically propagates the changes to all
nodes and servers.
5. After the update is complete, you must restart the BLA application.
Chapter 7. Installing client applications and individual
components
If you are electing to install an individual component on a machine with other InfoSphere MDM
components that are already installed, use the Modify option rather than the Install option.
Use IBM Installation Manager to uninstall client applications.
contain any spaces.
virtualized.
After installing your feature, verify a successful installation by viewing the log files.
Related tasks:
Modifying your installation on page 89
Use this procedure to install other InfoSphere MDM components on a workstation or server that already
has components of the same version installed.
Uninstalling a single component on page 185
Use this procedure to uninstall an InfoSphere MDM application or component.
Configuring application security for web applications on page 173
All web applications that are installed on IBM WebSphere Application Server are set to secure for cookies
and single sign-on. You must use the https protocol and the secure port number to access the web
application as the http protocol is no longer valid.
Related reference:
Directory structures on page 19
There are three directories you want to understand when you install and use MDM: the installation
directory, the shared directory, and the application server directory.
Business Administration UI installation
Administrators are responsible for installing, deploying, and supporting users of the Business
Administration application.
Individuals who are responsible for the maintenance and management of InfoSphere MDM can use the
Business Administration UI to manage certain elements of the MDM operational server without having to
manually modify properties files or database tables.
This application can be installed on either a server or workstation. It can also be installed on a remote
machine by choosing a remote WebSphere Application profile.
This application is not supported for use with a Microsoft SQL Server database.
Installing Business Administration UI
Before you begin
v Your environment meets the hardware and software requirements for this component
v You reviewed and completed the user applications installation worksheet
v You have IBM WebSphere Application Server installed and running
v If you are upgrading from an earlier version of the application and have custom settings in your
property files, make a copy of the files.
About this task
You have two options available for installation: Install or Modify. The Install option assumes that you are
installing the application on a clean server or workstation. That means that the server or workstation
does not have any InfoSphere MDM components that are already installed (for example the MDM
operational server, database component, or another user application). If any MDM components are
present on the machine on which you are installing the application, you must use the Modify option.
Procedure
2. On the IBM Installation Manager home panel, select Install or Modify.
3. If you selected Install, complete these steps.
a. On the Install Packages panel, select the InfoSphere MDM offering and click Next.
b. Continue through the panels to accept the license agreement, select the installation directory, and
the language.
c. On the Install Packages panel, select Business Administration UI. Click Next.
d. Enter the configuration information for the application.
e. Review the installation summary information and click Install.
4. If you selected Modify, complete these steps.
a. On the Modify Packages panel, select the InfoSphere MDM package and click Next.
b. Select the language and click Next.
c. On the Modify Packages panel, select Business Administration UI. Previously installed
d. Enter the configuration information for the application. Use the MDM user applications worksheet
as a guideline. Click Next.
e. Review the summary information and verify that the component that you want to install is listed
in the Adding Features box and that no components are listed in the Removing Features box. Click
Modify.
6. Go to IBM WebSphere Application Server administrative console and verify that the application is
deployed to the server specified during installation.
What to do next
Learn more about using Business Administration UI by reviewing the related concept that is listed below.
Related tasks:
Related reference:
User applications installation worksheet on page 38
Data Stewardship UI installation
Administrators are responsible for installing, deploying, and supporting users of the Data Stewardship
application.
Data Stewardship UI is used for maintaining data quality within the core physical MDM application.
machine by choosing a remote WebSphere Application Profile.
Installing Data Stewardship UI
Before you begin
v You reviewed and completed the MDM user applications installation worksheet
About this task
Procedure
Chapter 7. Installing client applications and individual components 127
the language.
c. On the Install Packages panel, select Data Stewardship UI. Click Next.
as a guideline.
c. On the Modify Packages panel, select Data Stewardship UI. Previously installed components are
automatically selected. Make sure that they remain selected, otherwise IBM Installation Manager
removes them. Click Next.
Modify.
What to do next
Learn more about using Data Stewardship UI by reviewing the related concept that is listed below.
Related tasks:
Related reference:
Product Maintenance UI installation
Administrators are responsible for installing, deploying, and supporting users of the Product
Maintenance UI application.
The Product Maintenance UI is used to maintain product data quality.
machine by choosing a remote WebSphere Application Profile.
Installing Product Maintenance UI
Before you begin
Before installing this application, ensure that you have the WebSphere Application Server deployment
manager (Dmgr) JVM Heap size arguments set to 512MB and 1024MB.
About this task
Procedure
the language.
c. On the Install Packages panel, select Product Maintenance UI. Click Next.
as a guideline.
c. On the Modify Packages panel, select Product Maintenance UI. Previously installed components
are automatically selected. Make sure that they remain selected, otherwise IBM Installation
Manager removes them. Click Next.
Modify.
What to do next
Learn more about using Product Maintenance UI by reviewing the related concept that is listed below.
Related tasks:
Related reference:
Inspector installation
Administrators are responsible for installing, deploying, and supporting users of this data stewardship
application.
The InfoSphere MDM Inspector data stewardship application supports the maintenance of virtual MDM
data. Use the Inspector application to resolve data quality issues, review member records, create, edit,
update, or delete relationships between entities, and make appropriate adjustments to correct data errors.
When you install the application, IBM Installation Manager automatically deploys the application to the
target web application server. The installation process creates property files that control the behavior of
application. These property files can be manually edited if necessary. The installer also sets security for
web applications (for example, setting https protocol and secure server port).
If any components of InfoSphere MDM are already installed on the machine on which you are installing
the Inspector application, use the Modify MDM installation procedure instead.
If you are upgrading from a previous version of InfoSphere MDM Inspector, make sure that you save a
copy of your property files for reference.
Installing Inspector
Use this procedure to install the InfoSphere MDM Inspector data stewardship application. This web
application supports data governance for virtual MDM data.
Before you begin
v IBM WebSphere Application Server is installed and running
About this task
Procedure
the language.
c. On the Install Packages panel, select Inspector. Click Next.
as a guideline.
c. On the Modify Packages panel, select Inspector. Previously installed components are automatically
selected. Make sure that they remain selected, otherwise IBM Installation Manager removes them.
Click Next.
Modify.
Results
The installer updates the inspector.properties file with the host name, port, and valid user name and
password that you provided on the configuration panel and deploys the Inspector EAR to the target
application server. During deployment, the application server unpacks the EAR content into an installed
apps directory. For example, WAS_PROFILE_HOME/installedApps/$cell_name/inspector.ear.
Connect to Inspector by opening a browser and using this URL: https://host:port/inspector
Inspector properties file
The inspector.properties file contains the parameters that are used to connect to the operational server.
Some of the properties that are listed in the following table are set by IBM Installation Manager when
you complete the Inspector configuration panel. Other properties, if you want to change their defaults,
must be manually changed by editing the file.
Table 19. Properties found in the inspector.properties file
Property Description
HostName Name or IP address of the server where the MDM
operational server is running. This is the host name that
is specified on the IBM Installation Manager Inspector
configuration panel.
HostPort The HTTP or HTTPS port number from your application
server. Default HTTP value is 9080. Default HTTPS value
is 9443.
Table 19. Properties found in the inspector.properties file (continued)
InitContext The initial number of contexts (threads) to create for
communication between Inspector and the operational
server. The default is 5. This property must be manually
changed.
MaxContext Maximum number of contexts to create. The default is
10. A setting of 0 means there is no limit to the number
of contexts that can be created. This property must be
manually changed.
TimeOut Seconds to wait for a free context to come into the
context pool. The default is 30 seconds. If a context does
not open within the specified number of seconds,
communication attempts between Inspector and the
operational server stops. This property must be manually
changed.
UseSSL A true or false value that indicates whether SSL is used
to communicate with the operational server. The default
is false. This property must be manually changed.
KeepAlive A true or false value that indicates whether the
KEEPALIVE option for all socket connections to the
operational server is enabled. If enabled, then every two
hours a KEEPALIVE packet is sent to the operational
server to verify that the connection exists and to keep the
connection alive. The default is false. This property must
be manually changed.
UserName The administrative user name for this application. This is
the name that is specified on the IBM Installation
Manager Inspector configuration panel and is a required
property. The default is mdmadmin.
Password The administrative user password for this application.
This is the password that is specified on the IBM
Installation Manager Inspector configuration panel and is
a required property. The default is mdmadmin.
*To use an encrypted password, you must re-encrypt the plain-text password by using the madpwd2 or
madpwd3 utility and then update the property file. The MDM Operational Server component must be
installed to use these utilities.
Configure Inspector
After you install Inspector, there are a additional configuration tasks that you can complete if necessary.
You can modify certain settings in the property file or configure IBM WebSphere Application Server
logging. Customizing your search templates and results pages is done by using InfoSphere MDM
Workbench.
Editing the inspector.properties file
Use this procedure to manually change settings in the inspector.properties file after installation.
About this task
IBM Installation Manager updates the inspector.properties file with the host name, port, and valid user
name and password that you provided on the configuration panel and deploys the Inspector EAR to the
target application server. During deployment, the application server unpacks the EAR content into an
installed apps directory. For example, WAS_PROFILE_HOME/installedApps/$cell_name/inspector.ear. The
inspector.properties file is under inspector.war/WEB-INF/classes.
Procedure
1. Go to the inspector.war/WEB-INF/classes directory and open the inspector.properties file in a text
editor.
2. Change the necessary parameters and make sure that required parameters are not commented out.
3. Save the inspector.properties file to the inspector.war/WEB-INF/classes directory.
Configuring IBM WebSphere Application Server logging
Use this procedure to enable logging for the application server.
Procedure
1. Log on to the IBM WebSphere Application Server administrative console.
2. From Troubleshooting, click Logs and Trace.
3. Click server1, and then Change log detail levels.
4. Click Runtime. Expand Components and Groups and then expand the All Components option.
5. Change only the specific trace level for your web application by appending it to the existing default
value. The default value is "*=info:" Here is an example of common trace levels at a broader scope.
In the following example, webapp component name values can be "inspector", or "reports".
com.initiatesystems.audit.*=all:
com.initiatesystems.webapp component name>.*=finest:
com.initiatesystems.web.webapp component name.*=finer:
To set the levels at a fully qualified package trace level, the ".*" before the equal sign is not required,
as shown in this Inspector example. For other web applications such as InfoSphere MDM Web
Reports, the trace package names might be different.
com.initiatesystems.inspector.svc.impl.MemberSvc=finest
com.initiatesystems.inspector.svc.member.MemberService=finest
Changes take effect immediately, so restarting the application is not required. The changes do not
persist after you restart the application.
To permanently save the changes, you must save the run time to the Configuration tab. Continue
with the next step.
6. Select the Save runtime changes to configurationoption.
7. Click Apply and then save the configuration.
8. Go back to Troubleshooting and select Logs and Trace.
9. Click server1, and then select Change Log Detail Levels.
10. Go to the Configuration tab and verify that the runtime changes are being added.
Enterprise Viewer installation
Administrators are responsible for installing the application and supporting users of the InfoSphere MDM
Enterprise Viewer.
Enterprise Viewer is a web application that supports searching for and viewing member data. The search
results return an enterprise view of members that are known in the MDM database. Enterprise Viewer is
used to view virtual MDM data.
When you install Enterprise Viewer, IBM Installation Manager automatically deploys the application to
the target web application server. The installation process creates property files that control the behavior
of application. These property files can be manually edited if necessary.
Enterprise Viewer uses the mpi_memtype and mpi_enttype tables to determine what member and entity
types are supported in the configuration. Member and entity type configuration is done through
Installing Enterprise Viewer
Use this procedure to install InfoSphere MDM Enterprise Viewer. This web application is used to search
for and view member records in a virtual MDM configuration.
Before you begin
About this task
Procedure
the language.
c. On the Install Packages panel, select Enterprise Viewer. Click Next.
as a guideline.
c. On the Modify Packages panel, select Enterprise Viewer. Previously installed components are
Modify.
Results
When you install Enterprise Viewer, IBM Installation Manager updates the ContextManager.prop file with
the host name, port, and valid user name and password that you provided on the installation
configuration panel and deploys the Enterprise Viewer EAR to the target application server. During
deployment, the application server unpacks the EAR content into an installed apps directory.
Connect to Enterprise Viewer by opening a browser and using this URL: https://host:port/accessweb
ContextManager.prop file
When you install Enterprise Viewer, IBM Installation Manager updates the ContextManager.prop file with
the host name, port, and valid user name and password that you provided on the installation
configuration panel and deploys the Enterprise Viewer EAR to the target application server.
During deployment, the application server unpacks the EAR content into an installed apps directory. For
example, WAS_PROFILE_HOME/installedApps/$cell_name/viewer.ear. The ContextManager.prop file is in
viewer.war/WEB-INF/classes.
Some of the properties that are listed in the following table are set by IBM Installation Manager when
you complete the Enterprise Viewer configuration panel. Other properties, if you want to change their
defaults, must be manually changed by editing the file.
Table 20. Properties found in the inspector.properties file
HostGroupName This property is typically always server1.
server1.HostName Name or IP address of the server where the MDM
operational server is running. This property is the host
name that is specified on the IBM Installation Manager
Enterprise Viewer configuration panel.
HostPort The HTTP or HTTPS port number from your application
server. Default HTTP value is 9080. Default HTTPS value
is 9443.
server1.UseSSL A true or false value that indicates whether SSL is used
to communicate with the operational server. The default
is false. This property must be manually changed.
UsrName The administrative user name for this application. The
default is mdmadmin. This property is the name that is
specified on the IBM Installation Manager Enterprise
Viewer configuration panel and is a required property.
This value is the user name that facilitates connection
between the application and the operational server. This
name is used only to get the initial connection; all
interactions run as the user name specified on the
Enterprise Viewer log in page.
server1.UsrPass *The administrative user password for this application.
The default is mdmadmin. This property is the name that is
specified on the IBM Installation Manager Enterprise
Viewer configuration panel and is required.
server1.InitContext The initial number of contexts (threads) to create for
communication between Enterprise Viewer and the
operational server. The default is 5. This property must
be manually changed.
Table 20. Properties found in the inspector.properties file (continued)
server1.MaxContext Maximum number of contexts to create. The default is
10. A setting of 0 means that there is no limit to the
number of contexts that can be created. This property
must be manually changed.
server1.TimeOut Seconds to wait for a free context to come into the
context pool. The default is 30 seconds. If a context does
not open within the specified number of seconds,
communication attempts between Enterprise Viewer and
the operational server stops. This property must be
manually changed.
doDebug Indicates whether debug logging is enabled. The default
is false.
*To use an encrypted password, you must re-encrypt the plain-text password by using the madpwd2 utility.
The MDM Operational Server component must be installed to use this utility.
v To store a plain-text password, use the server1.UsrPass=password property.
v To store an encrypted password, use the server1.UsrPass2=password property.
Configuration and Application Management
Implementation and configuration options for InfoSphere MDM Enterprise Viewer are set by the
implementation team.
The appropriate configuration options for your organization are set before your implementation is
released for production use. If you must adjust the configuration settings after implementation and you
have questions, contact IBM Software Support for assistance.
Configuring the ContextManager.prop file for Enterprise Viewer
InfoSphere MDM Enterprise Viewer is configured to find the MDM operational server that is defined in
the ContextManager.prop file. This configuration file is contained in the viewer.war file.
About this task
Use this procedure to edit the ContextManager.prop after installation if necessary. The
ContextManager.prop file is in the WAS_PROFILE_HOME/installedApps/$cell_name/viewer.ear/WEB-INF/
classes directory.
The HostName and HostPort properties are set by IBM Installation Manager during installation.
Procedure
1. Go to viewer.war/WEB-INF/classes directory and open the ContextManager.prop file in a text editor.
2. Change the necessary parameters and make sure that required parameters are not commented out.
3. If you are configuring the server to communicate through SSL, set server1.UseSSL to true.
4. Save the ContextManager.prop file to the viewer.war/WEB-INF/classes directory.
5. Verify that there is only one ContextManager.prop file in the viewer.war/WEB-INF/classes directory.
Testing, style, and font issues
Enterprise Viewer uses style sheets. Regardless of which browser from the supported options is used, the
pages all look similar in browsers that support style sheets.
The pages are designed for an 800x600 screen setting, although a 640x480 setting also works.
The pages use the default font size for the body of the pages, and use relative sizes (+1 or 2) for headers
and footers. Using these settings allows the pages to look acceptable on most computers regardless of
resolution; however, you can adjust font sizes as with any web page.
You can change the standard color scheme by editing the viewer.war\styles\alignStyles.css file.
mpi_appprop table configuration
The contents of the mpi_appprop table is used as the base configuration for Enterprise Viewer behavior.
The configuration controls these items:
v What attributes display on what pages
v The formatting of search pages
v Support for Enterprise Viewer to use implementation-defined segments
If the mpi_appprop configuration is not completed, attributes do not display on the applications pages.
Configuring mpi_appprop to order the display of attributes:
There are settings in the mpi_appprop table that control the order in which attributes are displayed in
InfoSphere MDM Enterprise Viewer.
You can modify these settings as necessary for your implementation.
Column #1 and #2 - mpi_appprop.caudrecno/maudrecno must be a valid number from mpi_audhead; this
setting is not used by Enterprise Viewer.
Column #3 - mpi_appprop.recstat must be set to A for active. InfoSphere MDM Enterprise Viewer looks
only at AppProp rows that are active.
Column #4 - mpi_appprop.apprecno = mpi_apphead.apprecno - The apprecno for this appprop entry; this
setting is typically 1 for InfoSphere MDM Enterprise Viewer.
Column #5 - mpi_appprop.segrecno must be 0. This setting is not used by the InfoSphere MDM
Enterprise Viewer.
Column #6 - mpi_appprop.therecno is used to order the attributes within a propname or page name (see
description for Column #7). This number typically begins at 1, which means that attribute is the first one
displayed on the page and count up until the last attribute.
Column #7 - mpi_appprop.propname is a key value that contains a prefix of 'WebAcc' and the page name
that is separated by a ~. The page names are predefined key values that do not change.
This table lists title of the web page and the valid mpi_appprop.propname for that page:
Table 21. Web pages and associated mpi_appprop.propnames
Web Page Title Valid mpi_appProp.propname
Search Results WebAcc~MemSrchRslt#
Detail View WebAcc~MemGetDetailCol#
Detail History View WebAcc~MemGetDetailRow#
Report View WebAcc~MemReport#
Task View WebAcc~MemTskGetRslt#
Column #8 - mpi_appprop.propval must contain the mpi_segattr.attrcode value of the attribute you
want to display for this row, such as LGLNAME or HOMEADDR.
For each page name (propname values) configured, you see 'therecno' (Column #6) in the order in which
they display on the page. There must be no duplicates or gaps in 'therecno' values.
The following is an SQL example for the search results page:
INSERT INTO mpi_AppProp VALUES
(101,101,A,01,00,01,WebAcc~MemSrchRslt1,LGLNAME);
(101,101,A,01,00,02,WebAcc~MemSrchRslt1,SSN);
(101,101,A,01,00,03,WebAcc~MemSrchRslt1,HOMEADDR);
(101,101,A,01,00,04,WebAcc~MemSrchRslt1,HOMEPHON);
(101,101,A,01,00,05,WebAcc~MemSrchRslt1,BIRTHDT);
(101,101,A,01,00,06,WebAcc~MemSrchRslt1,SEX);
To look at the mpi_appprop table in a meaningful manner, use this sample SQL:
SELECT * FROM mpi_AppProp WHERE (propname LIKE Web%) ORDER BY propname,
therecno;
Related concepts:
Composite view column location on page 149
The Detail View page 'WebAcc~MemGetDetailCol#' can display composite view (CVW) columns.
Implementation-defined segments attribute display order and formatting:
InfoSphere MDM Enterprise Viewer can be configured to display implementation-defined segments.
The configuration for implementation-defined segment support is much the same as described for
non-implementation-defined segments. The exception is the configuration for Column #8 in the
mpi_appprop table.
Column #8: mpi_AppProp.propval = mpi_SegAttr.attrcode. For implementation-defined segment
configuration, 'propval' must have the attrcode of the attribute you want to display for this row. It also
requires extra formatting information. The segment name that is defined in mpi_segxfld.fldname must be
listed, along with any formatting you optionally define, after the equal sign.
The following is an example of 'propval' values for formatting implementation-defined segments.
NEWSEG=~segdate:dt~ ~segval~ ~segscore:^^.^~ 
NEWPHONE=(~areacode~)} ~phonenumber~ {x~phoneext~})
NEWPHON2=~phonenumber:^^^-^^^^~
Formatting can be optionally applied to non-implementation-defined segments. The following are
formatting examples for MEMPHONE and MEMIDENT segments:
HOMEPHON={~phicc~-}{(~pharea~)-}~phnumber~{ X~phextn~}
SSN={~idissuer~:}~idnumber:^^^-^^-^^^^~{ Exp:~idexpdate:d~}
The format definition consists of the following items:
v Tilde (~) and curly braces {} are reserved and cannot be used as fixed display characters.
v Field names must be surrounded by tilde (~) and must match the field name in mpi_segxfld.fldname.
Lowercase characters must be used for all field names.
v Any field, and the formatting characters that are enclosed in curly braces {}, are "optional" for display.
This means if the area code in the example is blank (there is no data for the attribute token), then the
parenthesis around it do not display. The fixed display characters are only shown if the data exists.
The optional groups of fields cannot be nested or contain more than one field. These examples are
invalid:
{(~pharea~) ~phnumber~}
{(~pharea~) {~phnumber~}}
In the NEWPHONE example:
If all three fields are present, the display is (123) 555-1212 x1234
If only number and extension are present, the display is 555-1212 x1234
If only the number are present, the display is 555-1212
v Within a field, it is possible to implement some basic formatting. For example, if the phone number
field is stored in the database as 5551212, then defining the pattern as ^^^-^^^^ displays the number as
555-1212.
v The formatting must be within the beginning and ending tilde (~) for the field name.
v The formatting must immediately follow a colon (:), which must follow the field name. For example:
fldname:^^
v The formatting routine works by replacing the characters in the field for each caret (^) symbol that is
defined in your format string.
v Because characters such as ^ ~ {} : are used as special formatting characters, they cannot be used to
appear as themselves in the format string. They will always be interpreted as special characters.
v Valid, non-special characters that are contained within the format string display in the defined position
as themselves.
v If the format string does not match the length of the data, no formatting is applied and only the raw
data is shown. For example, the format of ~segval:^^^-^~
v If the data is this: ValA,ValCZ,VAL,VALB, then the formatted result is this: Val-A, VALCZ, VAL, VAL-B.
Only ValA and VALB are of correct length and are formatted.
v If there is no custom formatting that is specified for non-implementation-defined segments (such as
MEMNAME, MEMPHONE, and MEMIDENT), the default formatting is used. This means that the
same default formatting is applied as in earlier versions of the application.
v If there is no definition of formatting for implementation-defined segments, then nothing displays.
Minimum definition for an implementation-defined segment is the AttrCode and one fldname:
NEWSEG=~segval~
v This formatting feature is unavailable for the non-implementation-defined MemAttr or MemDate
segments; it is irrelevant because there is only one field. Any formatting, if defined, is ignored for these
segments.
v Date fields must have an optional ":d", ":t", ":dt" on the end to specify display date only, display time
only, or both. I18N is supported for this formatting that is based on the locale that is defined in the
browser. For example: ~dateField:t~ ~dateField:d~ ~dateField:dt~
v Any HTML formatting tags are allowed if they do not interfere with the surrounding HTML tags
generated for the page. For example, use of HTML table tags might cause errors on the page and are
discouraged. Basic bold or line breaks tags are safe to use if HTML standards are
followed.
v An invalid implementation-defined segment configuration, such as a bad fldname, causes the fldname
to display with a NULL next to it on the configured application web page.
v Having invalid begin and ending tildes (~) cause "Bad or NULL Format String" to display on the
configured web page.
v It is possible to incorrectly configure to the point that an attribute might not show up at all. Another
possibility is that the errors show, but they might be a different problem than what is described.
Because of how these configuration parameters are processed, it is not always possible to provide
detailed help for an incorrect configuration. Trial and error is the best way to create a complex
requirement. Add one field at a time to get it working correctly and then add more fields as you have
success. After adding the field, then you can add the formatting. InfoSphere MDM Enterprise Viewer
requires a restart for each change that is made.
The following SQL script is an example of implementation-defined segments in the Detail View page:
(101,101,A,01,00,01,WebAcc~MemGetDetailCol1,NAME={~degree~ }{~prefix~
}{~last~ }{~middle~ }{~first~ }{~suffix~ }~title~);
(101,101,A,01,00,02,WebAcc~MemGetDetailCol1,ID={~idissuer~:}~idnumber:
^^^-^^-^^^^~{ Exp:~iddate:d~});
(101,101,A,01,00,03,WebAcc~MemGetDetailCol1,ADDR={~line1~}{,
~line2~}{, ~line3~}{, ~line4~} {~city~, }{~state~ }~zipcode~{,
~country~});
(101,101,A,01,00,04,WebAcc~MemGetDetailCol1,PHONE={~icc~-}{(~area~)-}~
number~{ X~extn~});
Contained in the .prop files are SegCodeFilters that can be defined.
The following is an example of the SegCodeFilter:
form.SegCodeFilter=MEMHEAD,MEMNOTE,MEMXTSK,ENTXTSK,MEMATTRALL
MEMATTRALL by default includes any active implementation-defined segments and modification of this
parameter is not necessary. However, if performance is a concern and large result sets are returned,
performance can be increased by modifying this parameter to specifically define only the required
segments that are needed by a specified page.
The following list of prop files are found in the WEB-INF\classes\ sub-directory in the viewer.war file.
For each page that you want to define specific segments for, you must modify its corresponding .prop
file and update the form.SegCodeFilter. Report and Detail History share the .prop file.
Table 22. Prop files and SegCode Filter updates
.prop file Page Title form.SegCodeFilter
doMemGet.prop Detail View Page WebAcc~MemGetDetailCol#
doMemGetAll.prop Report View Page WebAcc~MemReport#
doMemGetAll.prop Detail History Page WebAcc~MemGetDetailRow#
doMemSrch.prop Search Results Page WebAcc~MemSrchRslt#
doTskGet.prop Task View Page WebAcc~MemTskGetRslt#
Search forms (pages):
The search pages that are used in InfoSphere MDM Enterprise Viewer are configurable.
The search form configurations are stored in the mpi_appprop table. All search form property settings in
the table begin with WebAccMemSrchForm##-## in the propname column. The format of the full name is
WebAcc~MemSrchForm##-##.prop, where the first ## is replaced with the Member Type number from
mpi_memType.memtypeno table and the second ## is replaced with the Entity Type number from
mpi_entType.enttypeno.
There are two main configuration sections to focus on when you create a search form: form. and section.
form. configuration:
The top portion of the file contains the form. configuration that defines the number of sections in this
form and what groups of search attributes are contained in each section.
For example, the standard Provider search form has three sections that are defined as:
form.sections=3
form.section1.width=50,10,170,10,500,100
form.section1.group=ProvName,BusName,Addr
form.section2.group=Phone,Sex,DOB,SSN,Spec
form.section3.group=UPIN,NPI,FED,MCRE,LICID,NRC,DEA,MCAID
form.sections - set to the number of the form.section# you will define.
form.section#.width sets the table column widths on the form. Typically these definitions do not change,
and if they do only the fifth width (defined as 500 in the previous example) usually changes. The fifth
width represents the column that contains the form input fields. One reason to increase the value of the
fifth width would be to handle unusually long input fields. The third width (defined as 170 in previous
example) is the width that is used for the label column. Again, you might want to increase the width if
you have a large label. The other widths are used for spacing in between these columns and are not
changed.
form.section#.group sets the group names that are contained in each section. The section group names
must be unique within all of the defined sections in this search form appProp configuration. The names
can be any name that is appropriate for your configuration. The names are case-sensitive and are used as
a key into the section. area of the search form appProp configuration rows. This setting determines the
order of the groups on the page. In the previous sample, the group of 'ProvName' input fields displays
first, with 'BusName' under 'ProvName' and so on.
section. configuration:
The bottom portion of the search form configuration file contains the section. configuration.
This parameter defines the specific fields to use for searching, field display, label, and other information
that is required to show an input field on the page.
This example shows a section. configuration that is based on the form. configuration.
#Start of Section 1
section.ProvName.attrcode=PROVNAME
section.ProvName.1.method=setOnmLast
section.ProvName.1.label=Last Name
section.ProvName.1.class=
section.ProvName.1.value=Sanghera
section.ProvName.1.size=25
section.ProvName.2.method=setOnmFirst
section.ProvName.2.label=First Name
section.ProvName.2.value=Hitpreet
section.ProvName.3.method=setOnmMiddle
section.ProvName.3.label=Middle Name
section.ProvName.3.value=K
#
section.BusName.attrcode=PROVNAME
section.BusName.1.method=setOnmLast
section.BusName.1.label=Business Name
section.BusName.1.class=
section.BusName.1.value=jones research labs
section.BusName.1.size=35
section.BusName.1.maxsize=50
The area after section. is the group name that is configured in the form. configuration area. The # after
the group name is the ordering of the field on the page within the group.
section.GroupName.attrcode is the first line of all group names. It is configured to equate to the
mpi_segattr.attrcode field that this group represents. The .attrcode is non-case sensitive and represents
the attribute code that is created and sent as the search criteria to the operational server. .attrcode has a
keyword of 'APPPROP' that is also valid and is used with the .dropdown parameter.
section.GroupName.Order#.method is set to the Java API method name that is used to set the value of this
field. Earlier examples showed searches based on a PROVNAME value, which as defined in the
mpi_segAttr.segCode field as a MEMNAME. Looking up MemName in the Java API documents and
HTML files provides a list of valid 'set' methods. Method names are typically the table field name that is
prefixed with the word 'set'. To support implementation-defined segments, the prefix of 'set' is optional
and only the mpi_segxfld.fldname is required. The Java API documentation can be used to determine the
valid field names for non-implementation-defined segments. The table mpi_segxfld can be used to look
up fldnames for both implementation-defined and non-implementation-defined segments.
section.GroupName.Order#.label value defines what displays on the search form as the label for the
field.
section.GroupName.Order#.class is typically blank, and must be set only if the value entered is not a
string and must be converted from a string to another data type before using the 'setMethod' name. For
example, if you wanted to use the setIdExpDate method on MemIdent class. You see in the Java API
documents that the method needs a 'java.util.Date' passed in. Therefore, setting this parameter to 'Date'
causes the 'String' to be converted into a Java 'Date' before it calls the 'setIdExpDate' method. Valid class
types for MemAttrRows are Date, Time, DateTime.
section.GroupName.Order#.value is typically blank. If it is not blank, the data entered displays as the
default value on the input form. In the previous example, 'Public' is pre-filled in the input box for 'Last
Name' on the search form.
section.GroupName.Order#.size is size of the input label on the form. You can also use the special
keyword 'hidden' to not display an input field for this entry. Typically this parameter is used with the
.value parameter to allow a default value to be set, but not shown. A typical use for this configuration is
Social Security Number. It always has the MemIdent.setIdIssuer value as SSA,' and you can configure
field as hidden so the user does not need to type in or see the Issuer input box on the form.
section.GroupName.Order#.maxsize is the maximum size of the input label on the form. This sets the
HTML form maxlength parameter. Defining maxsize is optional, and if not defined then it defaults to 50.
'section.GroupName.Order#.celldelim' parameter:
The .celldelim is used to combine what would normally be two input fields in two different table rows
into one table row cell.
In the following example, Address Lines 1, 2, and 3 are combined in the same table cell and an HTML
 tag is used between them. The result is that these address lines are grouped; address line 1 on top
of address line 2 and 3, all in one cell. They all use the same label that is provided in the first address
lines 'label' which is 'Address Lines.' If the .celldelim parameter is not configured, then each address
line has its own table row that uses individual labels.
# Example of celldelim parameter
section.Addr.attrcode=SRVAD
section.Addr.1.method=setStLine1
section.Addr.1.label=Address Lines
section.Addr.1.class=
section.Addr.1.value=
section.Addr.1.size=25
section.Addr.1.celldelim= 
section.Addr.2.label=Address Line 2
section.Addr.5.method=setZipCode
section.Addr.5.label=ZIP
.celldelim can contain any valid HTML tag. For example, can be used to have a phone area on
the same line as the phone number as shown here:
#Start of Section 2
section.Phone.attrcode=SPHNA
section.Phone.1.method=setPhArea
section.Phone.1.label=Telephone
section.Phone.1.class=
section.Phone.1.value=
section.Phone.1.size=5
section.Phone.1.celldelim=
section.Phone.2.method=setPhNumber
section.Phone.2.label=
section.Phone.2.class=
section.Phone.2.value=
section.Phone.2.size=9
section.Phone.2.hint=(111) 555-1212
'section.GroupName.Order#.hint' parameter:
The hint parameter is used to provide information about how to input the data.
As configured, the hint displays immediately to the right of the phone number and shows the format that
is used for the phone number.
Configure the 'section.GroupName.Order#.dropdown' parameter:
Use this information to configure the section.GroupName.Order#.dropdown parameter to create a unique
list.
The following example shows the use of a parameter to create a unique drop-down list:
#
section.Sex.attrcode=PROVSEX
section.Sex.1.method=setAttrVal
section.Sex.1.label=Gender
section.Sex.1.class=
section.Sex.1.value=
section.Sex.1.dropdown=PROVSEX
section.Sex.1.size=9
Any valid mpi_edtElem.edtCode can be entered (case sensitive) in the dropdown parameter and a
drop-down list is generated on the page for that edtCode.
Do not use the value parameter when you have a drop-down entry. The default drop-down selection is
always --select--to maintain consistency.
dropdown also has a special keyword that can be used SRCHEAD. SRCHEAD creates a drop-down menu that is
based on the mpi_srchead table with a default srcType=I and the MemTypeno defined for the
mpi_appprop.propName used by the form.
When a SRCHEAD is being defined, you can specify the source type (srctype) to use in the SRCHEAD list.
Defining a .srctype is optional. If the .srctype entry is not found, then the default is 'I'. For even further
filtering of the .srctype list, you can specify the .memtypeno to use. Defining a .memtypeno is also optional
and, if not defined, defaults to the current MemTypeno used for this form.
The following example shows a valid .memtypeno configuration:
section.SSN.2.memtypeno=1
section.SSN.2.memtypeno=0,1,5
Any .memtypeno can be defined in the comma-separated list. A .memtypeno=0 is allowed as a special
memtypeno that can be shared across all member types.
The following example shows a valid srctype configuration:
section.SSN.2.srctype=I,D
section.SSN.2.srctype=D
Valid values for srctype are 'I', 'D', or 'I,D' and these values are non-case sensitive.
You can also set up a special attribute code (attrCode) with the keyword of APPPROP and the drop-down
as SRCHEAD. When APPPROP is used, SRCHEAD must be configured as the drop-down. This combination
causes the source code that is selected in the drop-down to be looked up in the mpi_appprop table. The
mpi_appProp.propName of SrxAttrand mpi_appProp.propVal is used to convert a source code to the needed
attribute code to use for this search.
This example illustrates valid use of APPPROP and SRCHEAD.
#Start of Section 2
section.AppProp1.attrcode=APPPROP
section.AppProp1.1.method=setIdIssuer
section.AppProp1.1.label=Identifier Type
section.AppProp1.1.class=
section.AppProp1.1.value=
section.AppProp1.1.size=20
section.AppProp1.1.dropdown=SRCHEAD
section.AppProp1.1.srctype=I
section.AppProp1.1.memtypeno=0,1
section.AppProp1.2.method=setIdNumber
section.AppProp1.2.label=Identifier Number
section.AppProp1.2.class=
section.AppProp1.2.value=
section.AppProp1.2.size=20
The previous example instructs the search, that based on the source code that is selected in the .dropdown,
to find the AttrCode that is related to that SrcCode, and use the selected SrcCode as the setIdIssuer value
for that MemIdent. In the second section, setIdNumberalso uses the same AttrCode as the first section.
Use of edtElem to present a list for a MEMIDENT source:
You can use mpi_edtElem.edtCode to populate a list of member identification number issuers.
The following example shows the use of mpi_edtElem.edtCode to populate a drop-down list for a
MemIdent IdIssuer.
section.LICID.attrcode=LICID
section.LICID.1.method=setIdNumber
section.LICID.1.label=State Lic
section.LICID.1.class=
section.LICID.1.value=
section.LICID.1.size=20
section.LICID.1.celldelim=
section.LICID.1.hint= Issuer:
section.LICID.2.method=setIdIssuer
section.LICID.2.label= Issuer:
section.LICID.2.class=
section.LICID.2.value=
section.LICID.2.size=10
section.LICID.2.dropdown=STATE
Typically the iIdIssuer is completed from a .dropdown from the mpi_srchead table, but presenting
everything in mpi_srchead for the member type number (memTypeno) might list irrelevant entries. To
present a refined list, you can use the mpi_edtelem table. For this configuration to work correctly, the
mpi_edtElem.elemval must match the mpi_srcHead.srcCode you want to use for this MemIdent.
Configuring the mpi_segattr.edtcode field is not required.
Parameters combinations to create a unique search form:
There is a combination of parameters that can be used to create a unique search form that is used by
The following example shows a combination of these parameters. This example illustrates the flexibility
of parameter configuration by using the parameters in a way that was not the initial intent.
#
section.MCAID.attrcode=MEDICAID
section.MCAID.1.method=setIdNumber
section.MCAID.1.label=Medicaid
section.MCAID.1.class=
section.MCAID.1.value=
section.MCAID.1.size=20
section.MCAID.1.celldelim=
section.MCAID.1.hint= Issuer:
section.MCAID.2.method=setIdIssuer
section.MCAID.2.label=
section.MCAID.2.class=
section.MCAID.2.value=
section.MCAID.2.size=10
section.MCAID.2.dropdown=STATE
Typically for a MemIdent segment, you have a Source (SrcCode) that is set with a .dropdown and below
that an input box for the ID Number. The .celldelim uses an HTML hard space to indicate that the lines
must be in the same cell with a space between them. The .hint is used as a Label for the Source
drop-down list. This configuration is necessary because using .celldelim means the .label is ignored on
the next input field. The drop-down list is then moves to the right of the .hint and makes the .hint look
like a label for the drop-down list.
Member date search and input formatting:
It can be helpful to understand the search and input formatting for member dates.
This information is for education only. There are no configuration changes required. InfoSphere MDM
Enterprise Viewer expects form input for searches that use member date (MemDate) attributes in
YYYYMMDD, YYYYMM, or YYYY format when a delimiter is not used. When a delimiter is part of the
input, InfoSphere MDM Enterprise Viewer uses the Java API FixDateFormat class to properly format any
date that uses a four-digit year and a . (period) (dash), or / (slash) as a delimiter into the ISO 8601
format of YYYY-MM-DD. That format is used by the operational server for searching.
Transaction Viewer:
The Detail View WebAcc~MemGetDetailCol# can display one or more segments as a Transaction Viewer
segment.
When configured, the Detail View page displays a label and an icon for the segment. When a user clicks
the icon, a pop-up window opens and shows the data that is configured for Transaction Viewer.
Transaction Viewer supports implementation-defined segments, but does not support any custom
formatting options used by the predefined segments.
Transaction Viewer is segment-based rather than attribute-based. Therefore, if you define multiple
attributes for a segment and then set up that segment in Transaction Viewer, all the attributes show up in
Transaction Viewer. For example, if you are using the segment MemAddr, you typically have a
HOMEADDR and WORKADDR attributes for the MemAddr segment. If you define a Transaction Viewer
window for MemAddr, you cannot limit it by a specific attribute so both HOMEADDR and WORKADDR
rows display in the viewer.
To configure the Transaction Viewer, you must add the following entry to mpi_appprop:
For Person member type:
INSERT INTO mpi_appprop VALUES
(101,101,A,01,00,01,WebAcc~MemGetDetailCol1~PopUp,MemExtc,Event
Summary,event.gif);
For Provider member type:
(101,101,A,01,00,02,WebAcc~MemGetDetailCol1~PopUp,MemCont,Contracts,co
ntract.gif);
For Guest member type:
(101,101,A,01,00,03,WebAcc~MemGetDetailCol1~PopUp,MemExtc,Event
Summary,stay.gif);
Column #1 to Column #5 have the same definition as described in other topics.
Column #6 represents the ordering of the icons.
Column #7 - WebAcc~MemGetDetailCol#~PopUp is the key value that is used to indicate to InfoSphere MDM
Enterprise Viewer that you want to configure a Transaction Viewer segment. The # must be replaced with
the member type.
Column #8 contains three tilde (~) delimited configuration parameters:
1. Lists the segment class name to display. This is the not case-sensitive segcode name that is defined in
mpi_seghead.segcode, for example: MemExta, MemExtb, MemExtc, MemExtd, MemCont. Reference
the Java API documentation for more information. The mpi_seghead table can be used to determine
both implementation-defined segment names and predefined segment names.
2. The label to display on the page that describes the icon.
3. The icon graphic name. The icon.gif file must be in the viewer.war file in the \images directory.
Default icons that exist are event.gif (Person member type), contract.gif (Provider member type),
and stay.gif (Guest member type).
After the Column #7 key is defined, the Column #8 key signals Enterprise Viewer to look for more
configuration information with the key of 'WebAcc~MemExtc1.'
(101,101,A,01,00,01,WebAcc~MemExtc1,AcctNumber~String~Acct Num);
(101,101,A,01,00,02,WebAcc~MemExtc1,EncDate~Date~Encounter Date~-);
(101,101,A,01,00,03,WebAcc~MemExtc1,DisDate~Date~Discharge Date);
(101,101,A,01,00,04,WebAcc~MemExtc1,PatType~String~Patient Type);
(101,101,A,01,00,05,WebAcc~MemExtc1,SvcType~String~Service Type);
(101,101,A,01,00,06,WebAcc~MemExtc1,SvcLoc~String~Service Location);
(101,101,A,01,00,07,WebAcc~MemExtc1,Phys1~String~Physician 1);
(101,101,A,01,00,08,WebAcc~MemExtc1,Phys2~String~Physician 2);
(101,101,A,01,00,09,WebAcc~MemExtc1,Plan1~String~Plan 1);
(101,101,A,01,00,10,WebAcc~MemExtc1,Plan2~String~Plan 2);
(101,101,A,01,00,11,WebAcc~MemExtc1,User1~String~User 1);
(101,101,A,01,00,12,WebAcc~MemExtc1,User2~String~User 2);
Column #6 represents the ordering of the fields on the window from left to right.
Column #7 is the key that consists of the application code 'WebAcc' and the segment key, as previously
defined, MemExtc with the memtypeno of 1appended to it. The full value of this key is
WebAcc~MemExtc1'.
Column #8 contains four ~ delimited parameters that relate to the display of segment data.
1. The first parameter is the Java method name that is used to retrieve the data from the segment.
Typically this is the database column name.
2. The data type of the field name. 'String', 'Date', 'Time', and 'DateTime' are the supported data types.
Other numeric data types should be configured as a 'String'.
3. The label to display on the table header for the data.
4. The sorting option. '-' means descending and '+' means ascending, while no value means that this
field name is not used in sorting. You can define more than one column in the sort. The order is
determined by the printing order: the first - or + found based on the Column 6 order is the major
sort, and the next one found would be the minor sort, and so on.
Attention: You must remove the get' keyword before the field name because it causes an error when
those columns are sorted. This parameter is not case-sensitive. The Java SDK documentation can be
helpful in determining the correct field names for non-implementation-defined segments. The table
mpi_segxfld can be used to look up field names for both implementation-defined and
non-implementation-defined segments.
Display AsaIdxno attributes:
If an attribute uses AsaIdxno (has values greater then 0) and you want it to print on a page, then the
AttrCode in the mpi_appprop table must be configured in two ways.
AsaIdxno stands for Attribute Sparse Array Index. This database field is used to subdivide a given
attribute and permit the association of multiple occurrences of the same attribute type. The primary
function of AsaIdxno is to direct the placement of attribute values from source systems into slots in the
MDM database.
Attention: This information is applicable to all pages except for the MemSrchRslt (Composite View
Results) page. The MemSrchRslt page has no knowledge or special mpi_appprop requirements for
displaying attributes with AsaIdxno values.
An AsaIdxno attribute must have key definitions as:
v WebAcc~MemTskGetRslt# which acts like a trigger for the grouping (or single) value to print and sets a
position for the location of the grouping to print.
v WebAcc~MemTskGetRslt#~AsaIdxno this key value tells Enterprise Viewer to print and group the
AsaIdxno value with other alike AsaIdxno values if more than one AsaIdxno is listed in the PropVal
for this row.
Even though an attribute might be represented in the WebAcc~MemTskGetRslt#~AsaIdxno grouping row, it
still needs a regular key WebAcc~MemTskGetRslt# entry to ensure all the values print:
Row #1 WebAcc~MemTskGetRslt# SRVAD
Row #2 WebAcc~MemTskGetRslt# SPHNA
Row #3 WebAcc~MemTskGetRslt# SPHNB
Row #4 WebAcc~MemTskGetRslt~AsaIdxno SRVAD,SPHNA,SPHNB
This ensures that all alike AsaIdxno values print for the attributes that are grouped in row #4, and that
any unlike AsaIdxno values print directly after the SRVAD.
If the value is a simple attribute that only has AsaIdxno = 0, then the AsaIdxno key row is not needed
and only the standard key must be defined in the mpi_appprop table WebAcc~MemTskGetRslt#.
If an attribute has both AsaIdxno=0 and > 0, it depends on what is configured in mpi_appprop as to
what prints. This configuraton really is not a valid combination; but if it is configured, then the option is
to show one or the other on a page but not both.
If there is only an AppProp row with a propname (such as Row #1) and it does not include AsaIdxno
rows (such as Row #4), then only the attributes that have an AsaIdxno = 0 print on that page.
If there are two AppProp rows, the regular key (such as Row #1) and the AsaIdxno key row (such as
Row #4), then only the attributes that had an AsaIdxno > 0 would print on that page.
The rows with AsaIdxno in the propname do not use 'segrecno' and can be left as 0.
The 'therecno' column is used to order the AsaIdxnos and typically starts at 1 and ascends to the final
AsaIdxno for that 'propname.' As mentioned, the display of the AsaIdxno group is triggered by the
'~AsaIdxno' key values, which is why AsaIdxno values are configured twice.
This is an example of the regular mpi_appprop rows (you must always have these rows):
INSERT INTO mpi_appprop VALUES (1,1,A,20,1,WebAcc~MemReport#,HOMEADDR);
INSERT INTO mpi_appprop VALUES (1,1,A,21,2,WebAcc~MemReport#,HOMEPHON);
You can select only one method to print them.
This additional row is needed to group the alike AsaIdxno values on a page (this causes HomeAddr and
HomePhon to be grouped on the page that is based on equal AsaIdxno values):
(1,1,A,0,1,WebAcc~MemReport#~AsaIdxno,HOMEADDR,HOMEPHON);
If you just wanted the AsaIdxno number to print but not group them, add the
following rows:
(1,1,A,0,1,WebAcc~MemReport#~AsaIdxno,HOMEADDR);
(1,1,A,0,2,WebAcc~MemReport#~AsaIdxno,HOMEPHON);
SrcXAttr drop-down MemIdent searches:
The ScrXAttr setting in mpi_appprop is used to map a SrcCode to an AttrCode for MemIdent Searches.
This property is shared by InfoSphere MDM Inspector and InfoSphere MDM Enterprise Viewer.
This setting allows a search page with a drop-down menu of SrcCode and SrcName combinations from
the mpi_srchead table and creates the appropriate MEMIDENT AttrCode segment that is defined in the
mpi_segattr table, which is built and sent to the operational server for searching.
For example, the following (in combination with the InfoSphere MDM Enterprise Viewer
MemSrchForm#-# MPI_appprop configuration entries) allows for a drop-down list of 'Social Security
Administration SSA.' Because of the MPI_appprop setting, the search knows to create a MEMIDENT
with an AttrCode=SSN, and set the source on the MemIDent to 'SSA.'
INSERT INTO mpi_appprop VALUES (1,1,A,0,0,SrcXAttr,SAA=SSN);
The SrcCode is used as a KEY in InfoSphere MDM Enterprise Viewer and cannot have duplicates.
Therefore, if two SSAs are defined, then the last one overwrites the first and be used. You can have an
AttrCode that maps to more than one SrcCode.
Composite view column location:
The Detail View page 'WebAcc~MemGetDetailCol#' can display composite view (CVW) columns.
In previous versions of Enterprise Viewer, composite views were also known as enterprise views. The
location of the composite view column was always to the right of members that are in the same entity.
Another way to think of it is that the composite view is to the right of all the member data columns that
are used to make the composite view. To maintain this behavior, insert the following configuration:
(101,101,A,01,00,01,WebAcc~MemGetDetailCol1~CVWLocation,right);
To have the composite view column come before or to the left of all the member data columns, the
following configuration must be inserted:
(101,101,A,01,00,01,WebAcc~MemGetDetailCol1~CVWLocation,left);
Column #1 to Column #5 have the same definition as described in other topics for the order of attributes.
Column #6 will always be '01' as you cannot have more than one CVWLocation defined for a member
type.
Column #7 is the key that is the application code 'WebAcc', the page appProp is 'MemGetDetailCol#', and
the case-sensitive keyword "CVWLocation". The # must be replaced with the member type (memTypeno)
used in this configuration.
Column #8 describes where the composite view column must be located; valid values are 'right' or 'left'.
Related concepts:
Configuring mpi_appprop to order the display of attributes on page 137
There are settings in the mpi_appprop table that control the order in which attributes are displayed in
Restricted composite view configuration:
To configure InfoSphere MDM Enterprise Viewer to display only the Composite View column on a page,
you can create a special Restricted Composite View.
Attention: To configure a Restricted Composite View Before version 7.0, the View name
(mpi_cvwhead.cvwname) had to end with the case-sensitive keyword Restricted. For later versions, this
requirement is no longer necessary or valid. All upgrades using Restricted views must be changed to
the new configuration.
To configure a Restricted Composite View, the mpi_appprop table needs an mpi_appprop.propname=
WebAcc~RestrictedCvw' and the mpi_appprop.propval=mpi_cvwhead.cvwname.
If the RMCA view is configured in mpi_cvwhead.cvwname, the appprop SQL statement looks like the
following example:
(101,101,A,01,00,01,WebAcc~RestrictedCvw,RMCA)
InfoSphere MDM Workbench (Applications editor) can also be used to configure the AppProp entries that
are needed to define restricted composite views.
A user or group that is configured to have only Restricted Composite Views available to them can see
only the Composite View column in InfoSphere MDM Enterprise Viewer. Source-specific data columns
are not displayed when Restricted Views are used. Restricted Views are only implemented in InfoSphere
MDM Enterprise Viewer.
If a user or group is given access to both normal Composite Views, and Restricted Composite Views, they
are able to see source-specific data for the non-restricted views.
The Transaction Viewer is not a Composite View-based display and cannot support Restricted Composite
View settings. If transaction-based data is not allowed to be shown in a restricted composite view, then
Transaction Viewer cannot be configured for use with InfoSphere MDM Enterprise Viewer. This means
that InfoSphere MDM Enterprise Viewer users do not have access to Transaction Viewer data if restricted
composite views are used, and transaction data are not shown to restricted users.
You must restart InfoSphere MDM Enterprise Viewer for any new Composite View that is created. Also,
if you change the Restricted or Kind settings for the composite view, you must restart the application.
Setting an automatic timeout for Enterprise Viewer
Use this procedure to set automatic timeout after a specified period of inactivity for the application.
Procedure
1. Go to viewer.war/WEB-INF/classes directory and open the web.xml file in a text editor.
2. In the web.xml file, locate the following lines:
<session-config>
<session-timeout>20</session-timeout>
</session-config>
3. Edit the number between the <session-timeout> tags with the number of minutes in which you want
an inactive session of InfoSphere MDM Enterprise Viewer to log off the user.
4. Save the web.xml file to the viewer.war/WEB-INF/classes directory.
Globalization in Enterprise Viewer
If your organization has multi-language requirements, InfoSphere MDM Enterprise Viewer can be
displayed in only one language at a time. The language in which the application displays is dependent
on the browser settings; the default setting is US English.
A few notes about implementing InfoSphere MDM Enterprise Viewer in an alternative language:
v The prop files, such as i18N resource bundles (prop files), are in the \WEB-INF\classes directory.
v Dates on the Search page are in ISO 8601 format (YYYY-MM-DD). Incomplete or invalid dates are still
allowed for input such as YYYY-MM, YYYY. Year is always assumed as the first digits. The browser
locale (display language) is used to determine the type of date formatting for true date values.
v MemDate values are not true dates (for example, not required to be valid or complete). Because they
are not true dates, an assumption on formatting cannot be made for a locale. These dates are retrieved
from the database and are displayed as they exist in the database.
The following provides a little more background on how i18n requirements are accomplished in
All InfoSphere MDM Enterprise Viewer labels, such as buttons for [Reset] and [Search] are retrieved from
resource bundles and display in the language setting of the browser that is being used. Labels such as
Last Name are retrieved from the MDM database and are in the database-specified language. Entity and
member types (for example, Identity and Person) are labels that are defined in the MDM database and
cannot be displayed in the local language.
Some labels are combinations and can be formatted appositionally. For example, the combination of
InfoSphere MDM Enterprise Viewer client labels and database labels such as [Get Event Summary]. Get
is a client label retrieved from a resource bundle, but Event Summary is a database label. The resource
bundle allows for the word Get to be moved as needed by the language around the Event Summary
label. The same is true for the entity bar and title of the page.
Error messages sent to the browser (for example, No record found based on the input criteria) and seen
by users display in the localized language. However, error messages sent to log files, which are typically
seen by IBM Software Support, are in English.
For more information about resource bundles and globalization and localization, see
http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/
Web Reports installation
Administrators are responsible for installing, deploying, and supporting users of the reporting
application.
The application collects, consolidates, and presents information to your web browser about member data
activities in your MDM database. The InfoSphere MDM Web Reports are designed to work with virtual
MDM data. The reports use a special viewer application to collect the parameters and display the results
within a browser window.
When you install the application, IBM Installation Manager updates the webreports.properties file with
the host name, port, and valid user name and password that you provide on the installation
configuration panel and deploys the application EAR to the target application server. During deployment,
the application server unpacks the EAR content into an installed apps directory. For example,
WAS_PROFILE_HOME/installedApps/$cell_name/webreports.ear.
The extracts of the web-based reports are processed when the reports are run. When possible, run these
reports during non-peak hours to avoid affecting the performance of the operational server.
Installing Web Reports
Use this procedure to install InfoSphere MDM Web Reports.
Before you begin
About this task
Procedure
the language.
c. On the Install Packages panel, select Web Reports. Click Next.
as a guideline.
c. On the Modify Packages panel, select Web Reports. Previously installed components are
Modify.
6. Go to IBM WebSphere Application Server administrative console and verity that the application is
Results
When you install the application, IBM Installation Manager updates the webreports.properties file with
the host name, port, and valid user name and password that you provide on the installation
configuration panel and deploys the application EAR to the target application server. During deployment,
the application server unpacks the EAR content into an installed apps directory. For example,
WAS_PROFILE_HOME/installedApps/$cell_name/webreports.ear.
Connect to InfoSphere MDM Web Reports by opening a browser and using this URL:
https://host:port/webreports
Editing the webreports.properties file
Create your environment-specific webreports.properties.example file by modifying the
webreports.properties.example file to fit your environment.
The webreports.properties.example file is in the WAS_PROFILE_HOME/installedApps/$cell_name/
webreports.ear/webreports.war/tehnotes directory. See the comments in the
webreports.properties.example file for more details.
Attention: When you create your environment-specific webreports.properties.example file, you must
place it in an area that is accessible to your web server application class loader.
Authentication options for InfoSphere MDM Web Reports
There are several authentication options available during installation.
User authentication to the MDM database happens by using one of these options:
v Set thejdbc.user and jdbc.password parameters in the webreports.properties file. For encrypted
passwords, set the jdbc.password2 or jdbc.password3 parameters as appropriate.
For databases other than Microsoft SQL Server, or to use Microsoft SQL Server without Windows
authentication, set the user and password parameters in the webreports.properties file.
Required properties in the webreports.properties file
There are required properties that must be configured to deploy and use web reports.
Many of these properties are set in the webreports.properties file during installation. Other properties,
specified in the following table, must be set after installation.
Table 23. Descriptions of the required properties in the webreports.properties file
HostName Name or IP address of the server where the MDM operational server is running. This
value is the host name that is specified on the IBM Installation Manager Web Reports
configuration panel.
HostPort The port that is used for the operational server. The default is 9080.
Table 23. Descriptions of the required properties in the webreports.properties file (continued)
jdbc.className The jdbc data source class name to use to connect to the MDM database.
Copy one of the commented examples to ensure that the valid format is used.
jdbc.serverName The name or IP address of the server where the MDM database is located.
jdbc.portNumber The port number for the MDM database.
jdbc.databaseName The name of the MDM database.
jdbc.serviceName or
jdbc.SID
The Oracle service name or the Oracle system ID.
jdbc.user A user name that is configured for the MDM database.
If you are using Microsoft SQL Server with Windows authentication, you must
comment out the line with this property. Use the # character to comment out this line.
This property is a required.
jdbc.password The password for the selected database user. Omit this property if you are using an
encrypted password. Encrypted passwords are entered against the jdbc.password2
property.
This property is a required.
jdbc.password2 *The encrypted database password (as encrypted with the madpwd2 utility).
jdbc.password3 *The encrypted database password (as encrypted with the madpwd3 utility).
jdbc.aeskeyfile The path to the file that contains an AES 128, 192, or 256-bit key. The key can be hex
encoded and should not contain carriage returns or new line characters. The key can
be of one of the following sizes and depends on the strength of the key:
v 128-bit => 32 characters
For keys greater than 128-bit you must install the unlimited strength jurisdiction
policy files for your JVM vendor.
jdbc.aesivfile The path to the file that contains an AES initialization vector (IV). The IV can be hex
encoded and should not contain carriage returns or new line characters. The IV must
be 32 characters in length.
Table 23. Descriptions of the required properties in the webreports.properties file (continued)
jdbc.aesprovider The Java Cryptography Extension (JCE) provider. This property can contain a specific
provider, for example SunJCE or IBMJCE, or none. If no provider is specified, then
providers are selected based on preference order in the java.security file that is in
the $JAVA_HOME/lib/security directory or the $JAVA_HOME/jre/lib/security directory.
*To use an encrypted password, you must re-encrypt the plain-text password by using the madpwd2 or
madpwd3utility. The MDM Operational Server component must be installed to use these utilities.
Optional properties in the webreports.properties file
There are optional properties that you can configure in the webreports.properties file after installation.
Table 24. Descriptions of the optional properties in the webreports.properties file
DateStyle Controls the display of dates in the reports. Valid values are: FULL, LONG,
MEDIUM, or SHORT. The default value is MEDIUM.
MaxContext Maximum number of contexts to create. The default is 10.
TimeOut The number of seconds to wait for a free context to come into the pool. The default is
30.
TimeStyle Controls the display of times in the reports. Valid values are: FULL, LONG,
MEDIUM, or SHORT. The default value is MEDIUM.
UseSSL A true or false value that indicates if SSL is used to communicate with the operational
server. The default value is false.
UseHTTP Indicates whether MPINET communication is conducted over HTTP or by using
standard TCP/IP protocols. Valid values include:
v False. Set to false when you want the reporting application to communicate by
using standard MPINET TCP/IP communication.
v True. Set to true when you want MPINET to communicate over HTTP. In some
government environments, this method is required.
Customize the report display attributes
Some of the fields in the reports are customizable. By adding a few configuration parameters to the
webreports.properties file, you can customize the content of those fields.
The default fields for the Task Creation Detail report are Member Name, Address, Sex, and Birth Date,
which apply to some entity types, but not to others.
To change these fields globally for all reports that use them, add the parameters to the
webreports.properties file. See the following example:
webreports.SegCodeFilter.id=MEMNAME,MEMADDR,MEMATTR,MEMDATE
webreports.AttrCodes.id=LGLNAME,HOMEADDR,SEX,BIRTHDT
webreports.AttrLabels.id=Member Name,Address,Sex,Birth Date
webreports.AttrTypes.id=,,,Date
webreports.Templates.id=,${stLine1}&ltbr>${city}${,} ${state}
${zipCode}
Because attributes are comma-separated, use ${comma;} if you want a comma to display on the report
along with the field values.
Table 25. Parameters for display attributes in the webreports.properties file
webreports.SegCodeFilter.id Determines which of the segment codes is used for the customizable fields.
They are comma-delimited.
webreports.AttrCodes.id Determines the attribute codes to use for the customizable fields. These codes
must correspond exactly to the segment codes indicated in the
webreports.SegCodeFilter.id parameter.
webreports.AttrLabels.id Determines the text labels for the customizable fields to display on the
reports. You must specify a label for each of the attribute codes that are
indicated in the webreports.AttrCodes.id parameter.
webreports.AttrTypes.id Determines the data types for formatting. Only date and numeric types must
be explicitly specified, for special formatting purposes. Text types can be
omitted, however the separating commas must remain in place.
webreports.Templates.id Determines the individual fields within the attribute segments to display. For
instance, the MEMADDR segment consists of data fields stLine1, stLine2,
stLine3, stLine4, city, state, zipCode, country, and so forth. You can display
the wanted fields by including them as shown in the previous example.
Templates are optional, but any supplied values for each attribute segment
must be listed in the same order as the segment codes in the SegCodeFilter
parameter, separated by commas.
Customize the report appearance with style sheets
You can change the look of the web reports viewer by adding a few configuration parameters to the
webreports.properties file and specifying your own custom style sheets.
Use the webreports.properties.example file to see how the default style sheets are indicated in the
section labeled WebApp Customization Properties.
webreports.cssPath=../styles
webreports.imagePath=../images
The .css assets (for example, files and images) are included in the webreports.war file, which is deployed
on the web application server. Using custom style sheets requires that you add the custom files to similar
directories in your own WAR file and modify these webreports.properties values appropriately.
Customize maximum results and items per page
You can change the look of the web reports viewer by editing some configuration parameters in the
webreports.properties file.
These parameters are in the section labeled WebApp Customization Properties.
webreports.pageSize=50
webreports.subPageSize=50
webreports.maxResults=100
Edit the webreports.pageSize parameter to change the number of items that are displayed per page in
the web view.
Edit the webreports.subPageSize parameter to change the number of items that are displayed when a
search result is expanded.
Edit the webreports.maxResults parameter to change the maximum number of items that are retrieved by
a report query.
In the webreports.properties.example file, each of these parameters is commented out so that the default
values apply. If you edit these parameters, make sure that you remove the comment symbol (#) from the
beginning of the line.
Configuring globalization for web reports
If you are using a language other than US English, you must edit the webreports.properties file to
translate certain column headings that display in the reports.
With the webreports.properties file, you can customize the content of some of the columns in your
reports. Because these columns are customizable for each installation, the column labels are not translated
by default, and must be translated by the administrator as needed.
There are three parameters that are related to customizing these columns that must be synchronized:
webreports.AttrCodes.id, webreports.SegCodeFilter.id and webreportsAttrLabels.id.
The webreports.AttrCodes.id parameter determines which the attribute codes to use for the customizable
columns. These parameters must correspond exactly to the segment codes specified in the
webreports.SegCodeFilter.id parameter.
The webreportsAttrLabels.id parameter provides the column headings, or labels, of the fields that are
specified in the webreports.AttrCodes.id parameter, when the column heading displays on reports. Use
the webreportsAttrLabels.id parameter to define the column headings in your preferred language.
The following example shows the webreports.SegCodeFilter.id and webreports.AttrCodes.id
parameters that are set to include four custom attributes in a report: member name, home address, sex,
and date of birth. The webreports.AttrLabels.id parameter provides the labels that display on the
report.
webreports.SegCodeFilter.id=MEMNAME,MEMADDR,MEMATTR,MEMDATE
webreports.AttrCodes.id=LGLNAME,HOMEADDR,SEX,BIRTHDT
webreports.AttrLabels.id=Nom de membre,Adresse,Genre,Anniversaire
Only one language for each installation is supported. Thus a single installation of web reports can use
only a single language at a time.
Adding security messages to Web Reports
If you are installing web reports in an environment that requires usage agreements and custom security
headers and footers (for example, in government environments), you must provide the custom text for
the Configuration page.
Procedure
1. When you have installed web reports, open a browser and type http://server:port/webreports/
diacap/config.html.
2. The Configuration Security Messages page opens. Complete the following information:
a. Usage Agreement: If this implementation requires users to accept a usage agreement before
logging in to the application, type the message in this box. For example: You are accessing a U.S.
Government (USG) Information System (IS) that is provided for USG authorized use only. By using this IS
(which includes any device attached to this IS), you consent to the following conditions.... If the
agreement box is left blank, users are taken directly to the login page when accessing the
application.
b. Security Header: Type the text that you want to display as the header for all pages in the
application. Leave this field blank if you do not want a header to display.
c. Security Footer: Type the text that you want to display as the footer for all pages in the
application. Leave this field blank if you do not want a footer to display.
3. Click the Configure button.
The Download webreports.diacap.properties file page opens.
4. Complete the steps listed in the WebSphere Installation Instructions box.
5. After restarting the application server, go back to http://WAS_HOST:WAS_PORT/webreports.
The web reports login page opens. If you supply a usage agreement, users see the agreement when
they access the report viewer. Users must then accept the agreement before the login page is
displayed. If the usage agreement box is left blank, users are taken directly to the report viewer login
page.
Viewing Report queries in InfoSphere MDM Web Reports
To view report queries, you can enable a logging implementation through the applications server, or
some other logging function of your choosing.
About this task
Enabling log creation can help when you want to know the exact SQL that the application is using to
generate a report. The SQL queries are recorded in the log file.
Configuring WebSphere Application Server logging
Use this procedure to enable logging for the application server.
Procedure
1. Log on to the IBM WebSphere Application Server administrative console.
2. From Troubleshooting, click Logs and Trace.
3. Click server1, and then Change log detail levels.
4. Click Runtime. Expand Components and Groups and then expand the All Components option.
5. Change only the specific trace level for your web application by appending it to the existing default
value. The default value is "*=info:" Here is an example of common trace levels at a broader scope.
In the following example, webapp component name values can be "inspector", or "reports".
com.initiatesystems.audit.*=all:
com.initiatesystems.webapp component name>.*=finest:
com.initiatesystems.web.webapp component name.*=finer:
To set the levels at a fully qualified package trace level, the ".*" before the equal sign is not required,
as shown in this Inspector example. For other web applications, such as InfoSphere MDM Web
Reports, the trace package names might be different.
com.initiatesystems.inspector.svc.impl.MemberSvc=finest
com.initiatesystems.inspector.svc.member.MemberService=finest
Changes take effect immediately, so restarting the application is not required. The changes do not
persist after you restart the application.
To permanently save the changes, you must save the run time to the Configuration tab. Continue
with the next step.
6. Select the Save runtime changes to configuration option.
7. Click Apply and then save the configuration.
8. Go back to Troubleshooting and select Logs and Trace.
9. Click server1, and then select Change Log Detail Levels.
10. Go to the Configuration tab and verify that the runtime changes are being added.
Provider Direct installation
Administrators are responsible for installing, deploying, and supporting users of the InfoSphere MDM
Provider Direct application.
Use Provider Direct to manage provider data with direct access to crucial information such as provider
contact information, credentials, and information changes.
The installation process takes four steps:
1. Install Provider Direct using IBM Installation Manager
2. Import the Provider Direct project in InfoSphere MDM Workbench
3. Manually load Provider Direct tables to the MDM database
4. Deploying the Provider Direct EAR file into IBM WebSphere Application Server
Installing Provider Direct
Use this procedure to install the Provider Direct application. This web application is used to manage
provider data for a virtual MDM configuration.
Before you begin
v You have an MDM operational server with a virtual configuration and IBM WebSphere Application
Server installed and running
v You have InfoSphere MDM Workbench installed to configure and deploy your MDM configuration
About this task
Procedure
the language.
c. On the Install Packages panel, select Provider Direct. Click Next.
as a guideline.
c. On the Modify Packages panel, select Provider Direct. Previously installed components are
Modify.
Results
Unlike other web applications, Provider Direct is not deployed to an application server. The installer
extracts the files to the installation directory MDM_INSTALL_HOME/installableApps/ear.
What to do next
Continue with importing your Provider Direct project into InfoSphere MDM Workbench and deploying
your provider.ear file to IBM WebSphere Application Server.
Importing the Provider Direct project into Workbench
After you install Provider Direct and load the database tables, you must import your Provider Direct
project in InfoSphere MDM Workbench.
Procedure
1. Open the workbench and use the Configuration Project wizard to import the project files from
MDM_INSTALL_HOME/InstallableApps/ear/provider. Make sure that you include the .project and
.setting files in the project folder. These files are typically hidden.
2. Modify the project as your implementation requires.
3. Save your project.
4. In the workbench, define a new IBM WebSphere Application Server.
5. Star the application server.
6. Connect to the operational server in the Jobs tab.
7. Deploy your Provider Direct project to your operational server.
What to do next
Continue with manually loading the Provider Direct database tables.
Loading the Provider Direct database tables
After running the installer, you must load the Provider Direct database tables by using the madconfig
utility.
Procedure
1. From a command-line prompt, go to the MDM_INSTALL_HOME/mds/scripts directory.
2. Type this command:
./madconfig.sh install -Dprovider.config.dir=../sql
3. Verify that you did not encounter any errors during the madconfig processing. If you did, rerun the
utility after addressing the errors.
What to do next
Continue with deploying Provider Direct to your application server.
Deploying the modified Provider Direct EAR file
Unlike other user applications, the installer does not automatically deploy the Provider Direct EAR file to
IBM WebSphere Application Server; you must deploy the EAR manually.
Procedure
1. Locate the provider.ear file in the MDM_INSTALL_HOME/installableApps/ear directory. The
provider.properties and mdm.properties files are in the EAR file.
2. Deploy the provider.ear to IBM WebSphere Application Server.
a. In IBM WebSphere Application Server Administrative console, select Applications > Application
Types > WebSphere enterprise applications.
b. Click Install.
c. Click Browse and locate the provider.ear in your MDM_INSTALL_HOME/installableApps/ear
directory. Click Next.
d. Click Next again after you accept the default settings.
e. Click Finish.
3. Set a custom property in your application server.
a. In Administrative console, click Servers > Server Types > WebSphere application servers.
b. Click the server to which the custom property is to be applied.
c. On the Configuration page, select Container settings > Web Container Settings > Web container.
d. On the web containerConfiguration page, select Additional Properties > Custom Properties.
e. On the Custom Properties page, click New.
f. On the settings page, enter the Name as
com.ibm.ws.webcontainer.suppressLoggingFileNotFoundExceptions and a Value of true.
g. Click OK.
h. Click Save.
4. Start the operational server and then start Provider Direct in IBM WebSphere Application Server. The
operational server must be started before you start Provider Direct.
What to do next
Connect to Provider Direct by opening a browser and using this URL: https://host:port/provider
Provider Direct configuration
There are some parameters that must be set in the property files before you use the application.
IBM Installation Manager updates the provider.properties file with the hostname, port, and valid user
name and password that you provided on the configuration panel. You can edit the provider.properties
and mdm.properties files. These files are in MDM_INSTALL_HOME/installableApps/ear.
After you complete any custom configuration, you must deploy the Provider Direct EAR to your
application server. For example, WAS_PROFILE_HOME/installedApps/$cell_name/provider.ear.
Required properties in the provider.properties file
During configuration, edit the operational server login credentials, context factory, data source, and
operational server interactions properties in the provider.properties file.
The following properties must be set to deploy Provider Direct.
Table 26. Required operational server login properties
adminLoginProvider.username Must be an administrative user who has at least read-only access to
all dictionary segments. This user name is used to connect to the
operational server and initialize system metadata.
(Default=mdmadmin)
Table 26. Required operational server login properties (continued)
adminLoginProvider.password Identifies the password for the adminLoginProvider.username.
(Default=mdmadmin)
Table 27. Required context factory properties
contextFactory.hostName Change the value to indicate the machine where the MDM operational
server is running. The default is localhost.
contextFactory.hostPort The HTTP or HTTPS port number from your application server.
Default HTTP value is 9080. Default HTTPS value is 9443.
contextFactory.useSSL Can be set to true or false. The default is false.
Table 28. Required data source properties
datasource.databaseName The name of the MDM database
datasource.serverName The name or IP address of the server where the MDM database is
located
datasource.portNumber The port that is used for the MDM database.
datasource.user A user name that is configured for the MDM database.
You must comment out this line (with a # character) if you are using
Microsoft SQL Server with Windows authentication.
datasource.password The password for the selected database user.
You must comment out this line (with a # character) if you are using
Microsoft SQL Server with Windows authentication.
datasource.className The data source class name to use to connect to the MDM database.
Valid values are: com.ibm.mdm.jdbc.DB2DataSource,
com.ibm.mdm.jdbc.OracleDataSource, or
com.ibm.mdm.jdbc.SQLServerDataSource.
Copy one of the commented examples to ensure that the correct format
is used.
Table 29. Extra required properties
applicationContext Set the value to beans-mds.xml.
DisableNotifications Set the value to false.
Required properties in the mdm.properties file
During configuration, edit the context factory, operational server-owned source, and cvw.id properties in
the mdm.properties file.
The following properties must be set before you deploy Provider Direct.
Table 30. Required context factory properties
contextFactory.useSSL Can be set to true or false. The default is false.
Table 30. Required context factory properties (continued)
contextFactory.hostName Change the value to indicate the machine where the MDM operational
server is running. The default is localhost.
contextFactory.hostPort The HTTP or HTTPS port number from your application server. Default
HTTP value is 9080. Default HTTPS value is 9443.
Table 31. Required operational server-owned source properties
hub.owned.source.PROVIDER INITHUB
hub.owned.source.ORGANIZATION INITHUBORG
Table 32. Extra required properties
cvw.provider PEMCA
cvw.org PEMCAORG
Configuration conventions
Provider Direct includes its own virtual MDM configuration that defines the data model and other
elements that are required by the application.
This default virtual MDM configuration contains several elements that can be extended or customized by
following predetermined naming conventions. All of these changes can be made in InfoSphere MDM
Workbench.
Enumerated data types
Default values can be customized unless otherwise noted.
Table 33. Enumerated data types
Value Description
Provider Specialty Specialization field for individual providers. Values and descriptions
can be customized according to your organization needs.
Provider Gender Available genders for individual providers.
Language Languages that are spoken by the provider. The default includes 5 most
common languages. More languages can be set as needed.
Provider Delivery Preferences -
Information Types
Information types for delivery preferences.
Provider Delivery Preferences - Delivery
Mode
Available delivery modes for specified delivery preferences.
Provider Title Title for the individual provider.
Provider Role Valid roles for the individual provider (can include Administrative,
Imaging, Labs, Physician).
License Status Valid status for the provider state ID credentials (can include Active,
Inactive).
Provider Status Valid status for the provider (can include Active, Inactive).
Organization Type The type of organization for organizational provider records.
Organization Status The status of organizational provider records.
Extensible attributes
Use the following information when you are working with custom attributes and custom identifiers or
credentials.
Custom attributes
All custom attributes must be defined with MEMATTR attribute type and have single values that are
allowed by setting the property nsactive=1.
Table 34. Custom attributes
Value Description
Provider Entity Custom attributes for individual providers must use the three-letter
prefix of PCA in the attribute code. For example, the default
configuration includes a sample custom attribute for "Board
Certification", with an attribute code of PCABRDCERT.
Organization Entity Custom attributes for organizational providers must use the three-letter
code of OCA in the attribute code.
Custom identifiers and credentials
v Custom identifiers must be defined as attribute MEMIDENT.
v The attribute code must be unique but does not follow a naming convention.
Message Broker installation
Message Brokers. Message Broker components are installed on a server.
The brokers are generic interfaces that are used to manage communication to and from sources systems
and the MDM operational server. The broker components support client-specific Extensible Markup
Language (XML), Health Level 7 (HL7v2 and v3), fixed, or delimited messages.
After installation, you can configure the following components:
v Inbound Broker
v Outbound Broker
v HL7 Query Broker
v Mapping Message Manager (Mapping Broker)
v Routing Message Manager (Routing Broker)
The Message Broker feature is not supported on z/OS.
Installing Message Broker Suite
Use this procedure to install the InfoSphere MDM Message Brokers.
Before you begin
v If you have an existing services.ini file, it is a good idea to make a copy and save it to another
location
About this task
Procedure
the language.
c. On the Install Packages panel, select Message Brokers. Click Next.
d. Review the installation summary information and click Install.
c. On the Modify Packages panel, select Message Brokers. Previously installed components are
d. Review the summary information and verify that the component that you want to install is listed
Modify.
6. Verify that the files are installed in the MDM_INSTALL_HOME/MDM/MessageBroker directory.
What to do next
v Create an empty services.ini file if you do not have one from a previous installation
v Create instances for each broker component you plan to implement (for example, inbound, outbound,
and so on) and customize your component configuration files
For information about creating instances, configuring broker components, and general usage of the
brokers, see the related topics that are listed at the end of this topic.
Creating the broker services.ini file
The Message Broker stores environment variable configuration settings in a .ini file called services.ini.
This file is required to run brokers.
About this task
Upgrading customers typically already have a services.ini file. If you have one, this procedure is not
required; the broker configuration process finds and updates the existing file.
Use this procedure to create an empty services.ini. After you create the file, it is automatically updated
by the madconfig utility when you create your broker component instances.
Procedure
1. Open a text editor.
2. Save the empty file with the name services.ini to a directory of your choosing.
Directories and files installed with Message Broker Suite
The installer lays down the broker root directory structure under the MDM_INSTALL_HOME/MDM/
MessageBroker directory.
The directories are as follows:
\ant (contains ant scripts used by the madconfig utility)
\bin (contains all executable and .dll files)
\conf (certificate)
\config (sample configuration .ini files)
\dtd (IBM DTD files for XML messages)
\lib (contains broker libraries)
\proxy (contains files needed to run brokers over a web service)
\readme
\scripts (contains various scripts, such as madconfig)
\smt (language translation files)
\sql (maddbx.dbp file to maintain database specific syntax and data types)
\utf (Unicode)
There are three categories of files that are used by the brokers that you must be familiar with:
services.ini file, broker component configuration files, and broker service .exe files. These files are
described in the following table:
Table 35. Files used by the brokers
File Directory Description
Component .ini configuration files \config Each broker component (Inbound,
Outbound, Query, Routing, and
Mapping) depends upon a set of
component-specific configuration files
to manage how messages are
processed. Sample configuration files
are provided in the \config directory.
For example, the Inbound Broker
configuration file is named
InboundProcessormessage_type.ini
(for example,
InboundProcessorDelimited.ini).
This file is used to instruct the
Inbound Message Manager in how to
format, modify, and evaluate the
incoming data. Information about the
configuration files is contained in the
individual component configuration
chapters.
Table 35. Files used by the brokers (continued)
File Directory Description
Broker service .exe files \bin When the Message Broker is
installed, master broker services
executable (.exe) files are installed in
the \bin directory. When a broker
instance is created, the madconfig
utility automatically creates
instance-specific broker service .exe
files, by using the master broker
service files and adding the instance
name. More information can be
found in the "Message Broker Suite
files" topic that is listed in the related
topics.
services.ini file This file must be manually created
after installation and before instance
creation.
The Message Broker stores
environment variable configuration
settings in a .ini file called
services.ini. This file is not created
by the installer.
Upgrading customers typically
already have a services.ini file.
After the installation or upgrade, you
use the madconfig utility to create
broker component instances. The
madconfig utility appends the .ini file
as you configure new instances.
The madconfig utility, which islocated in the /scripts directory, is used to create broker instances. For
details on creating broker instances and configuring the broker behavior, see the related topics.
Unicode and alternative language support
Variables can be set in your services.ini file that instructs the brokers to pick up the necessary UTF files
that are used for Unicode and alternative language support.
Under the interfaces section of the services.ini file, make sure that the MAD_ROOTDIR variable for each
component points to the MDM operational server root directory.
For Inbound Brokers:
In your configuration file (that is, services.ini), under the interfaces section, make sure that you point to
the directory for the utf and smt files. MAD_BROKDIR identifies the Message Broker installation directory
and the location of the utf and smt files. If you do not set MAD_BROKDIR, the broker uses the MAD_ROOTDIR
setting (which points to the MDM operational server root directory) to pick up the utf and smt files.
For Outbound Brokers:
In your configuration file (services.ini), under the interfaces section, make sure that the following
settings are included:
v MAD_BROKDIR variable must point to the broker installation directory to pick up the utf and smt files. If
not set, the Broker defaults to the MAD_ROOTDIR location.
v MIEncoding must be set to the appropriate type; the default encoding is LATIN1 if none is specified.
InfoSphere MDM Healthcare Point of Service Integrator installation
Healthcare Point of Service Integrator application.
The InfoSphere MDM Healthcare Point of Service Integrator provides a simple solution for integrating
your heritage healthcare applications with a virtual MDM configuration. Using the application
capabilities, you can create a search GUI that enables users to search for members in the MDM database
from a heritage system.
InfoSphere MDM Healthcare Point of Service Integrator must be configured and used on a Microsoft
Windows 32-bit workstation. Because IBM Installation Manager can be run only on a 64-bit machine, you
must first install InfoSphere MDM Healthcare Point of Service Integrator on a 64-bit machine and then
deploy it to a 32-bit machine.
The information in installation topics cover prerequisites and running IBM Installation Manager. For
information about configuration and usage of InfoSphere MDM Healthcare Point of Service Integrator, see
the related topic that is listed at the end of this overview.
Installing InfoSphere Healthcare Point of Service Integrator
Use this procedure to install InfoSphere MDM Healthcare Point of Service Integrator.
About this task
Attention: InfoSphere MDM Healthcare Point of Service Integrator is supported to run on a 32-bit
Microsoft Windows workstation, however IBM Installation Manager can be run only on a 64-bit machine.
After you install InfoSphere MDM Healthcare Point of Service Integrator on a 64-bit machine, you must
deploy it to a 32-bit machine.
Procedure
the language.
c. On the Install Packages panel, select Healthcare Point of Service Integrator. Click Next.
c. On the Modify Packages panel, select Healthcare Point of Service Integrator. Previously installed
Modify.
6. Verify that the files are installed in the MDM_INSTALL_HOME/EnterpriseIntegrator directory.
7. Deploy the application to your 32-bit machine.
a. Copy the files from the MDM_INSTALL_HOME/EnterpriseIntegrator directory on the 64-bit machine
to your 32-bit machine.
b. On the 32-bit machine, go to the MDM_INSTALL_HOME/EnterpriseIntegrator/vcredist/ directory
and run vcredist_x.86.exe.
What to do next
Continue with customizing your search program on the 32-bit machine. For information about
configuration and usage of InfoSphere MDM Healthcare Point of Service Integrator, see the related topic
that is listed below.
Directory and files installed with Healthcare Point of Service Integrator
When you finish installing InfoSphere MDM Healthcare Point of Service Integrator, a set of directories
and files are added to the installation path.
The following directories are added to the location where the application is installed:
MDM_INSTALL_HOME/EnterpriseIntegrator
/axis2c
/lib
/modules
/bin
/include
/lib
/license
/samples
/Library
/modelsearch
/vcredist
/ModelWeb
/webapp
See the InfoSphere MDM Healthcare Point of Service Integrator user topics for details on using the
installed files.
Pair Manager installation
This application is used to evaluate the sample pair files that are generated by the InfoSphere MDM
Workbench Generate Threshold Analysis Pairs job.
As part of the weight generation process, you must run the Generate Threshold Analysis Pairs job to
create one or more sample pair .xls files that contain pairs of members. To establish threshold values that
are used by the MDM operational server to match members accurately, you must evaluate these sample
pairs and indicate whether the members are the same or not the same.
InfoSphere MDM Pair Manager supports only sample pair files that are created with InfoSphere MDM
Workbench.
InfoSphere MDM Pair Manager is supported for installation only on a Microsoft Windows operating
system.
Installing Pair Manager
Use this procedure to install InfoSphere MDM Pair Manager on a MicrosoftWindows workstation.
Before you begin
v Your environment meets the hardware and software requirements
About this task
Procedure
the language.
c. On the Install Packages panel, select Pair Manager. Click Next.
c. On the Modify Packages panel, select Pair Manager. Previously installed components are
Modify.
6. Verify that the files are installed in the MDM_INSTALL_HOME/MDM/tmp/PairManager directory.
What to do next
Use InfoSphere MDM Workbench to run the Generate Threshold Analysis Pairs job and then use
InfoSphere MDM Pair Manager to review the sample pair files.
You can access InfoSphere MDM Pair Manager from Start > All Programs > InfoSphere Master Data
Management > Pair Manager.
Samples
The samples include mappings and source code files that demonstrate the consumption of MDM. Install
these samples on development environments only.
Installing samples
Use this procedure to install the Samples feature.
About this task
Operational Server, database component, or another user application). If any MDM components are
Procedure
the language.
c. On the Install Packages panel, select Samples. Click Next.
c. On the Modify Packages panel, select Samples. Previously installed components are automatically
selected. Make sure that they remain selected, otherwise IBM Installation Manager removes them.
Click Next.
Modify.
6. Verify that the sample files have been created in the MDM_INSTALL_HOME directory.
InfoSphere MDM Workbench installation
InfoSphere MDM Workbench is an Eclipse-based technology and runs on computers that use Microsoft
Windows.
You must have IBM Rational Application Developer (RAD) installed to use the workbench.
Related reference:
installation.
Installing InfoSphere InfoSphere MDM Workbench
Before you begin
v Your environment meets the hardware and software requirements
v You completed the IBM Installation Manager preparation steps if this is a custom installation
v You installed IBM Rational Application Developer (RAD)
v You installed InfoSphere MDM
v The login that you use on the computer must have permission to write to the registry.
If you plan to install Workbench as part of a typical workstation installation deployment, see the
instructions listed at the bottom of this topic.
Procedure
1. Shut down IBM Rational Application Developer (RAD) if it is running.
4. On the Install Packages panel, select IBM InfoSphere Master Data Management Workbench and
click Next.
5. Accept the license agreement.
6. Select the package group where IBM Rational Application Developer (RAD) is installed and click
Next.
7. Click Install.
8. Click Finish when complete.
What to do next
You can now use InfoSphere MDM Workbench to configure your operational server.
Related tasks:
Related reference:
installation.
Configuring application security for web applications
Procedure
1. To locate the secure port number, open the WebSphere Application Server administrative console and
go to the Server Types > WebSphere application servers > %WEB_SERVER_NAME% > Portsand
find WC_defaulthost_secure.
2. To set the secure attribute to force https protocol:
a. Go to the Server Types > WebSphere application servers > %SERVER_NAME% > Session
management.
b. Under the Enable cookies menu, select the Restrict cookies to HTTPS sessions option.
c. Go to Security > Global security > Authentication > Web and SIP security > Single sign-on
(SSO) and select the Requires SSL option.
Related concepts:
Related tasks:
Installing Business Administration UI on page 126
Installing Data Stewardship UI on page 127
Installing Product Maintenance UI on page 128
Enabling SSL for virtual MDM web applications deployed to a remote
application server
When you deploy virtual MDM web applications to a remote application server (not the one hosting the
MDM operational server) and want to enable SSL mode, you must complete these steps in WebSphere
Application Server administrative console. Virtual web applications include Inspector, Enterprise Viewer,
Web Reports, and Provider Direct.
Procedure
1. Import the SSL certificate from the application server that is hosting the MDM operational server to
the application server that hosts the web applications. From the application server that is hosting your
web applications:
a. Open WebSphere Application Server administrative console and go to Security > SSL certificate
and key management > Key stores and certificates.
b. On the Key stores and certificates page, select your CellDefaultTrustStore.
c. On the CellDefaultTrustStore page, select Signer certificates.
d. Click Retrieve from port and enter the necessary information:
v Host: specify the host name or IP address of the server that hosts the MDM operational server
v Port: specify the WC_defaulthost_secure port of the deployed WebSphere Application Server
v Alias: specify the alias name
e. Click Retrieve signer information.
f. Click Save.
2. Open each virtual web application property file and set the property UseSSL=true.
3. Restart your web applications.
What to do next
For additional information, see http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/
com.ibm.websphere.nd.doc/ae/tsec_securecomm.html
Error codes seen in user applications
The error codes that are listed indicate issues that can occur between user applications that support
virtual MDM configurations and the operational server.
This list might not be a comprehensive list, but shows the most common errors.
Table 36. Error code descriptions
Code Description Resolution
OK (0) No error No action is required
EPERM (1)
Permission error
Invalid permissions. Your user account has
insufficient permissions to use this function.
If you have authorization to access this
application, retype your user name and
password. Take care to type the correct
spelling and case. If the error continues,
contact your application administrator.
ECOMM (2)
Communication error
Communications error - lost server
connection
You must re-establish connection to the
application server. If unable to connect,
contact your application administrator.
EODBC (3)
ODBC error
ODBC error reported from the ODBC driver
or database directly
Database error contact your application
administrator or your database
administrator.
ENOTCONN (5)
Unable to establish
connection with the
operational server
Connection to the requested server is
denied
Verify that the server is running. If so,
attempt to reconnect to the application.
EINVAL (6)
Invalid argument error
Invalid values are contained in the
incoming parameters or data type. Invalid
characters were entered in an input field.
Retype your input criteria. Take care to
enter letters and numbers as required by
the fields. For example, the Social Security
number field accepts numbers only.
Table 36. Error code descriptions (continued)
ENOMEM (7)
Unable to allocate
memory
Out of memory error - no working memory
can be allocated
Contact your application or system
administrator.
ENOREC (8)
Record not found
No record found based on the input criteria Adjust the search criteria and reattempt the
action.
ENOLIB (9)
Library not found
Runtime loadable libraries were not found This error most likely indicates a
configuration issue. Contact your
application administrator or IBM Software
Support.
ENOFUNC (10)
Function not found
Pointed-to-function was unavailable This error most likely indicates a
configuration issue. Contact your
application administrator or IBM Software
Support.
ELOCKED (11)
Record or object is
locked
A record cannot be updated because it is
locked
The record was recently retrieved and has
not been released by the system memory.
Reattempt to retrieve the record.
EEXISTS (12)
Record or object exists
A record insert is requested, but the record
exists
The system believes that the record you are
trying to insert (add) exists in the database.
Try to retrieve the record that you want to
add.
EFILEIO (13)
File I/O error
Cannot read or write from a file Contact your system administrator.
EVERSION (14)
Version error
Version mismatch, caused by opportunistic
locking
Retrieve the member or task again and
reapply the changes.
ESTATUS (15)
Status error
The requested attribute status does not exist Use another attribute status type.
EACTIVE (16)
Record or object is active
Not in use Not applicable
EINACTIVE (17)
Record or object is
inactive
EDELETED (18)
Record or object is
deleted
Results if an attempt is made to add or
update a logically deleted member
You cannot update a logically deleted
member. If the member was marked
logically deleted in error, contact your
application administrator.
ESHADOW (19)
Record or object is
shadow
EOBSOLETE (20)
Record or object is
obsolete
Results if an attempt is made to apply a
change or update to an obsolete record
You cannot update an obsolete record.
EINTEGRITY (21)
Referential integrity
error
A data integrity issue, for example, a
violation of a unique constraint
This error might indicate a database issue.
Contact your system or database
administrator.
EDISABLED (22)
Record or object is
disabled
A user ID is inactive (or disabled) If the user requires authorization to the
application, reactivate their ID through
Administrator.
Table 36. Error code descriptions (continued)
EINSANE (23)
Unexpected internal
error
The system detected a condition or state in
which it believes is not possible. It does not
have the information to explain how it
reached this state.
Contact your system administrator.
EEXTAUTH (24)
External authorization
error
External authorization failed Update user login in external authentication
system.
ENUNKNOWN (25)
Unknown error
An unknown error Contact IBM Software Support.
EINTERNAL (26)
Critical internal error
Recovery often cannot be achieved Typically requires restart of the operational
server and all connected clients.
Chapter 8. Verifying the installation
Additionally, you can use the Test Client to run test transactions to ensure that InfoSphere MDM is
installed correctly.
Related tasks:
scenario 1.
scenario 2.
scenario 3.
Related reference:
Chapter 2, Installation overview, on page 3
Most IBM InfoSphere Master Data Management Server components can be installed on a server or
workstation, a combination of the two, or across multiple servers to support clustered environments.
application server.
Verifying the installation with the Test Client on WebSphere
Application Server
Use this procedure to verify your installation with the application server Test Client.
About this task
The Test Client only supports DB2 and Oracle databases.
Procedure
1. In the TestClient.properties file in the MDM_INSTALL_HOME/IVT/properties folder, enter the user
name at user= and the password at password= if application security is enabled.
2. Edit any other required properties to create the parameters for the test you want to run. For
information about the properties you can edit, see the "Test client properties" topic.
3. Go to the MDM_INSTALL_HOME/IVT directory:
4. Clear the data by following the steps for your installation type:
v Run the following script at the command line to clear the data if you installed InfoSphere MDM on
Oracle:
sqlplus <DB_USER>/<DB_PASSWORD>@TNS@./sql/clearOperationData.sql
v Take these steps to clear the data if you installed InfoSphere MDM on DB2:
a. Connect to the DB2 database.
b. Clear the DB2 data by running the following script at the command line:
db2 -tvf ./sql/deleteIVTdata
5. From the command line, to run the test cases, run the script:
TestClient.sh TEST_CHANNEL XML_FOLDER [USER_NAME PASSWORD] where:
v TEST_CHANNEL is the method to send the test cases to the server, either:
For RMI, enter rmi
For HTTP, enter soap
For JMS, enter jms
v XML_FOLDER is the folder that contains the XML test cases that you want to run, either:
For TCRM test cases, enter ./testCases/xml
For admin test cases, enter ./testCases/xml_admin
For TCRM composite test cases, enter ./testCases/xml_composite
For a messaging test case, enter ./testCases/xml_msg
For web services test cases, enter ./testCases/xml_ws
v If security is enabled, enter the user name to log on to the system at USER_NAME
v If security is enabled, enter the password for the user name at PASSWORD
For example, to run web services test cases on WebSphere Application Server through HTTP with
security not enabled, enter:
TestClient.sh soap testCases/xml_ws
6. When the test is complete, you can see the results in the following directories:
v To see the responses that were created by the tests, check testCases/xml_ws/response
v To see the logs, the list of test cases run, and their statuses, check the log files in
MDM_INSTALL_HOME/IVT/logs
Example
The following table shows the tests, with corresponding command lines, that you can run:
Table 37. Installation verification tests
To run the test: Use the command:
To provide a request file to run single TCRM test
case
TestClient.sh rmi ./testCases/xml/TCRMaddPerson.xml
To run JMS test cases Provide the queue connection factory, request queue name, and
response queue name in the TestClientJMS.properties file, then
run TestClient.sh jms ./testCases/xml
Table 37. Installation verification tests (continued)
To run the test: Use the command:
To run messaging test cases
v For Oracle:
1. Run @./sql/Oracle/update_event_active.sql to activate
an event
2. Restart WebSphere Application Server
3. Run TestClientWL.sh rmi ./testCases/xml_msg
v For DB2:
1. Run IVT/sql/db2/update_event_active.sql to activate an
event
2. Restart the WebSphere Application Server
3. Run TestClientWL.sh rmi ./testCases/xml_msg
To run the admin test cases TestClient.sh rmi ./testCases/xml_admin
To run Web Services test cases TestClient.sh soap ./testCases/xml_ws
Test Client properties
You can edit the entries in the TestClient.properties file in the MDM_INSTALL_HOME/IVT/properties folder
to set the parameters for the test.
Table 38. Properties that can be set in the Test Client properties file
To set the parameter for: Set the following parameter to:
To run test cases without sorting sort=
To sort the test cases by directory. See regex=for sort criteria sort=d
To sort the test cases. See regex=for sort criteria sort=f
To sort directories and test cases. See regex=for sort criteria sort=d|f
To extract the first match as sorting comparison key. The
sort order is based on the key.
The default is to extract the last digital number from
request file.
regex= [0-9]*[0-9]$
To sort by string order regex=
To add a user name user=
To add a password password=
To test the extracted value by using a regular expression java -cp ./lib/TestClient.jar -regex tcrmtest_001
For information about using Java to run test cases java -cp ./lib/TestClient.jar ?
To use the MDM JMS adapter, enter the queue connection
factory name
QueueConnectionFactory=
Enter the request queue destination name RequestQueue=
Enter the response queue destination name ResponseQueue=
Installation logs
There are two types of logs that are created during the installation process. One set logs IBM Installation
Manager related information and the other logs MDM related information.
The location of IBM Installation Manager logs depends on how the application was installed. If IBM
Installation Manager was installed in admin mode (root user on UNIX), the logs are in
/var/ibm/InstallationManager/logs. If the application was not installed in admin mode, the logs are in
$HOME/var/ibm/InstallationManager/logs.
You can also specify a location for the IBM Installation Manager logs by updating the Agent Location
variable (cic.appDataLocation) in the config.ini file. The config.ini is in the
InstallationManager_INSTALL_HOME/eclipse/configuration directory.
MDM logs are in the MDM_INSTALL_HOME/logs/database directory.
The following directories contain logs that are created when the physical MDM database SQL scripts are
run (by manual installation and by the installer):
v MDM_INSTALL_HOME/logs/database/DomainData
v MDM_INSTALL_HOME/logs/database/CoreData
v MDM_INSTALL_HOME/logs/database/CMData
Log files that are created by bootstrapping a virtual MDM database that uses ODBC are in
MDM_INSTALL_HOME/logs/database/Virtual
Viewing Installation Manager log files
The IBM Installation Manager application creates log files during the installation process. These logs can
be viewed through a browser.
Before you begin
You must have a browser available in which to view the log files. If you are on a server that does not
have a browser, copy the logs to a workstation.
About this task
The logs contain messages with INFO, DEBUG, WARNING, or ERROR labels. If the installation is
successful, all messages have an INFO or DEBUG label. Messages that are identified as WARNING or
ERROR must be reviewed.
Procedure
1. Go to the ./InstallationManager/logs directory.
2. Open the index.xml file.
3. From the All Log Files table, click a link that corresponds to the IBM Installation Manager session
that installed MDM.
4. Locate the following link: Custom operation MDM Operational Server, verifying install location in
unit mdmv.app.set.install.location.
That link, and subsequent links, show installation process messages.
5. Look for messages that are identified as WARNING or ERROR. The messages must be reviewed to
identify potential problems with your installation.
6. Click a link to view native log file representations of an installation process segment.
Such processes can include running custom Java code to manage MDMfiles, to run the madconfig
utility Ant-based tool that in turn runs SQL scripts, and to implement the WebSphere Application
Server MBean API that deploys MDM deployment archives like EBA and EAR files, and other actions.
Results
If you have messages that are identified as WARNING or ERROR, try to determine the cause of the issue
by searching for Java or Ant exception errors. If you locate a workaround for the WARNING or ERROR,
attempt to fix the installation or contact IBM Software Support.
Viewing the MDM installation logs
About this task
Logs are stored in .xml files with the date and time of the installation as the file name. For example, a file
with the name 20130312_1101.xml, indicates the installation occurred on March 12, 2013 at 11:01. You can
access the logs in two different ways.
Procedure
v On the final IBM Installation Manager panel after the installation is complete, click View Log File.
v Go to the MDM_INSTALL_HOME/logs/database directory and open the .xml file.
Related tasks:
Related reference:
Chapter 9. Uninstalling InfoSphere MDM
Use IBM Installation Manager to uninstall your edition or remove individual components.
If you want to remove the entire edition (operational server, database, and components), use the IBM
Installation Manager uninstall option.
If you want to remove only selected components, use the modify option.
Uninstalling your InfoSphere edition
Use this procedure to uninstall the full InfoSphere MDM edition.
Before you begin
If you are planning to reinstall this runtime environment and use the same database instance that it uses,
make sure that you create a backup image of the database as a precaution.
In the environment that you want to uninstall, stop each runtime InfoSphere MDM instance (operational
server, entity manager instance, client application, and so on).
About this task
Using the IBM Installation Manager uninstall option removes the entire offering. If you want to remove
only selected components (for example, Inspector or Data Steward UI), use the modify option.
Procedure
1. Start IBM Installation Manager and click Uninstall.
3. Review the summary information and click Uninstall.
4. Click Finish.
What to do next
The uninstall process does not remove the composite bundle archive (CBA) from the internal bundle
repository. You must manually remove the CBA in IBM WebSphere Application Server administrative
console.
Related tasks:
Removing CBA from internal bundle repository on page 187
Uninstalling MDM does not remove the composite bundle archive (CBA) from the internal bundle
repository. You must manually remove it after you finish running the uninstall process.
Uninstalling a typical server installation
If you installed MDM by using a typical server installation, use this procedure to uninstall the features.
About this task
A typical installation creates a database called MDM11DB. On Microsoft Windows, uninstalling MDM
removes your MDM11DB database entirely. On Linux or UNIX, the database is not deleted (you must
manually deleted the MDM11DB database).
If you want to uninstall only the MDM features, use this procedure: Uninstalling your InfoSphere
edition on page 183.
IBM Installation Manager does support the selection of multiple offerings for uninstall at one time.
However, you might choose to uninstall the offerings separately as described in this procedure.
Procedure
2. Uninstall MDM.
a. Select the InfoSphere MDM package and click Next.
b. Continue through the prompts and click Uninstall.
c. Click Finish and return to the IBM Installation Manager home panel.
3. Uninstall IBM DB2.
a. Select the IBM DB2 package and click Next.
4. Uninstall WebSphere Application Server.
a. Ensure that both your WebSphere Application Server and Deployment Manager are stopped.
WebSphere Application Server cannot be uninstalled if these processes are running.
b. On the IBM Installation Manager home panel, select Uninstall.
c. Select the WebSphere Application Server package and click Next.
d. Continue through the prompts and click Uninstall.
e. Click Finish and close IBM Installation Manager.
Related tasks:
Uninstalling a typical workstation installation
If you installed MDM by using a typical workstation installation, use this procedure to uninstall the
features.
About this task
A typical installation creates a database called MDM11DB. On Microsoft Windows, uninstalling MDM
removes your MDM11DB database entirely. On Linux or UNIX, the database is not deleted (you must
manually deleted the MDM11DB database).
If you want to uninstall only the MDM features, use this procedure: Uninstalling your InfoSphere
edition on page 183.
IBM Installation Manager does support the selection of multiple offerings for uninstall at one time.
However, you might choose to uninstall the offerings separately as described in this procedure.
Procedure
2. Uninstall MDM.
a. Select the InfoSphere MDM package and click Next.
3. Uninstall IBM DB2.
a. Select the IBM DB2 package and click Next.
4. Uninstall InfoSphere MDM Workbench and IBM Rational Application Developer (RAD) at the same
time.
a. Select the MDM Workbench and IBM Rational Application Developer packages and click Next.
c. Click Finish and close IBM Installation Manager.
5. Uninstall WebSphere Application Server.
a. Ensure that both your WebSphere Application Server and Deployment Manager are stopped.
WebSphere Application Server cannot be uninstalled if these processes are running.
b. On the IBM Installation Manager home panel, select Uninstall.
c. Select the WebSphere Application Server package and click Next.
d. Continue through the prompts and click Uninstall.
e. Click Finish and return to the IBM Installation Manager home panel.
Related tasks:
Uninstalling a single component
About this task
This procedure removes only the selected application or component. If you want to remove the entire
InfoSphere MDM edition, use the IBM Installation Manager uninstall option.
Procedure
1. Start IBM Installation Manager and click Modify.
3. Select the language and click Next.
4. On the Modify Packages panel, all previously installed components are automatically selected. Make
sure that only the component that you want to remove is cleared. Click Next.
5. Review the summary information and verify that only the component you want to remove is listed in
the Removing Features box. Click Modify.
6. Click Finish.
Chapter 9. Uninstalling InfoSphere MDM 185
What to do next
console.
Related concepts:
Related tasks:
Removing CBA from internal bundle repository on page 187
Uninstalling in silent mode
About this task
A properties file is generated when you are running an interactive uninstall. To use a silent uninstall, you
must edit this file or create your own file.
Procedure
1. To uninstall, replace the <install modify=false> and </install> tags in your response file with
uninstall. For example:
<uninstall modify=false>
<offering id=com.ibm.mdm.advanced version=versionNumber profile=IBM InfoSphere Master Data
Management features=com.ibm.mdm.install.iu.localization.feature,com.ibm.im.mdm.db.feature,com.ibm.
im.mdm.app.feature,com.ibm.im.mdm.native.feature,com.ibm.mdm.ba.webapp.feature,com.ibm.mdm.ds.webapp.
feature,com.ibm.mdm.pui.webapp.feature,com.ibm.mdm.inspector.webapp.feature,com.ibm.mdm.ev.webapp.
feature,com.ibm.mdm.wb.webapp.feature,com.ibm.mdm.pd.webapp.feature,com.ibm.im.mdm.pair.manager.
feature,com.ibm.im.mdm.message.broker.feature,com.ibm.im.mdm.ei.feature,com.ibm.mdm.ba.webapp.sample.
feature,com.ibm.im.mdm.eutc/>
</uninstall>
2. Replace the default profile value with real profile values. For example:
Before the change:
<data key=user.was.profile.home,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
<data key=user.was.profile.home.ba,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
<data key=user.was.profile.home.ds,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
<data key=user.was.profile.home.pui,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles
/AppSrv01/>
<data key=user.was.profile.home.inspector,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/
profiles/AppSrv01/>
<data key=user.was.profile.home.wb,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
<data key=user.was.profile.home.ev,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
<data key=user.was.profile.home.pd,com.ibm.mdm.advanced value=/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/>
After the change:
<data key=user.was.profile.home,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDClusterProfiles/
DmgrCL1/>
<data key=user.was.profile.home.ba,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDClusterProfiles
/DmgrCL1/>
<data key=user.was.profile.home.ds,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDClusterProfiles
/DmgrCL1/>
<data key=user.was.profile.home.pui,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDClusterProfile
s/DmgrCL1/>
<data key=user.was.profile.home.inspector,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDCluster
Profiles/DmgrCL1/>
<data key=user.was.profile.home.wb,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDCluster
Profiles/DmgrCL1/>
<data key=user.was.profile.home.ev,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDCluster
Profiles/DmgrCL1/>
<data key=user.was.profile.home.pd,com.ibm.mdm.advanced value=/home/wsadmin/WAS8502NDClusterProfiles
/DmgrCL1/>
3. Make sure that the following three features are always included in the response when you run a silent
uninstall:
com.ibm.mdm.install.iu.localization.feature,com.ibm.mdm.server.swtag.feature,com.ibm.mdm.server.
bundles.feature
4. If you use a sample response file from the Installation Startup Kit and want to modify it for a silent
uninstall, add: com.ibm.mdm.server.swtag.feature,com.ibm.mdm.server.bundles.feature featues For
example:
<uninstall modify=false>
<offering id=com.ibm.mdm.advanced version=versionNumberprofile=IBM InfoSphere Master Data
Management features=com.ibm.mdm.install.iu.localization.feature,com.ibm.mdm.server.swtag.feature,com.
ibm.mdm.server.bundles.feature,com.ibm.im.mdm.db.feature,com.ibm.im.mdm.app.feature,com.ibm.mdm.ba.
webapp.feature installFixes=none/>
</uninstall>
What to do next
console.
Related tasks:
Customizing the silent mode response file on page 82
Related reference:
Removing CBA from internal bundle repository
Procedure
1. Log in to IBM WebSphere Application Server Administrative Console.
2. Go to Environment > OSGI bundle repositories > Internal bundle repository.
Chapter 9. Uninstalling InfoSphere MDM 187
3. Select the MDM.ear CBAs and click Delete.
Related tasks:
Uninstalling your InfoSphere edition on page 183
Use this procedure to uninstall the full InfoSphere MDM edition.
Uninstalling a single component on page 185
Notices and trademarks
This information was developed for products and services offered in the U.S.A.
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 grant 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.
For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
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.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
J46A/G4
555 Bailey Avenue
San Jose, CA 95141-1003 U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases,
payment of a fee.
The licensed program described in this document and all licensed material available for it are provided
by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or
any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the
results obtained in other operating environments may vary significantly. Some measurements may have
been made on development-level systems and there is no guarantee that these measurements will be the
same on generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
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.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without
notice, and represent goals and objectives only.
This information is for planning purposes only. The information herein is subject to change before the
products described become available.
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. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must include a copyright
notice as follows:
(your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs.
Copyright IBM Corp. _enter the year or years_. All rights reserved.
If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Privacy Policy Considerations
IBM Software products, including software as a service solutions, ("Software Offerings") may use cookies
or other technologies to collect product usage information, to help improve the end user experience, to
tailor interactions with the end user or for other purposes. In many cases no personally identifiable
information is collected by the Software Offerings. Some of our Software Offerings can help enable you to
collect personally identifiable information. If this Software Offering uses cookies to collect personally
identifiable information, specific information about this offerings use of cookies is set forth below.
Depending upon the configurations deployed, this Software Offering may use session and persistent
cookies that collect each users name, user name, password, profile name, or other personally identifiable
information for purposes of session management, authentication, enhanced user usability, single sign-on
configuration, or web page identification that the user tried to load prior to login. These cookies can be
disabled, but disabling them will also likely eliminate the functionality they enable.
If the configurations deployed for this Software Offering provide you as customer the ability to collect
personally identifiable information from end users via cookies and other technologies, you should seek
your own legal advice about any laws applicable to such data collection, including any requirements for
notice and consent.
For more information about the use of various technologies, including cookies, for these purposes, see
IBMs Privacy Policy at www.ibm.com/privacy and IBMs Online Privacy Statement at
www.ibm.com/privacy/details the section entitled "Cookies, Web Beacons and Other Technologies" and
the "IBM Software Products and Software-as-a-Service Privacy Statement" at www.ibm.com/software/
info/product-privacy.
Trademarks
IBM, the IBM logo, and ibm.com
are trademarks or registered trademarks of International Business

Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at
"Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.
The following terms are trademarks or registered trademarks of other companies:
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks
of Adobe Systems Incorporated in the United States, and/or other countries.
IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications
Agency which is now part of the Office of Government Commerce.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon,
Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Notices and trademarks 191
ITIL is a registered trademark, and a registered community trademark of The Minister for the Cabinet
Office, and is registered in the U.S. Patent and Trademark Office.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or
its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other
countries, or both and is used under license therefrom.
Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are trademarks of HP, IBM Corp.
and Quantum in the U.S. and other countries.
Index
A
accessing web application
https protocol 173
secure server port 173
account prerequisites 46
adding
security messages 157
adding a user 57
alternate language 167
application
installation 125
application name 37
application resource language 40
application server
logging 133, 158
preparing 53
preparing dmgr 55
preparing for base deployment 57
preparing unmanaged server 56
AsaIdxno attributes 148
attributes
AsaIdxno 148
Authentication 153
B
Business Administration UI
installation overview 125
installing 126
C
case sensitive searches 40
cell
WebSphere Application Server 34, 38
celldelim parameter 142
character encoding
setting on target computers 60
cluster 34, 37, 38
installation 73
installation scenarios 91, 94
code table language 40
configuration
composite views in Enterprise
Viewer 149
conventions 163
custom attributes 163
custom identifiers/credentials 163
enumerated data types 163
extensible attributes 163
inspector.properties file 131
mpi_appprop table 137
provider direct 161
restricted composite views in
Enterprise Viewer 150
Transaction Viewer 146
worksheets 27
DB2/DB2 for z/OS data
source 29
history triggers 40
configuration (continued)
worksheets (continued)
installation directory 28
MDM application 37
Microsoft SQL Server data
source 31
Oracle data source 33
user applications 38
WebSphere Application Server 34
configuring Enterprise Viewer 136
configuring Transaction Viewer 146
connections
database 47
ContextManager.prop file 136
configuring 136
editing 136
locating 136
core
manually installing CLOB data 113
create
database scripts 14
custom
installation 69
custom attributes
configuration 163
custom identifiers/credentials
configuration 163
custom installation
deployment type 7
customer support
contacting 195
customizing display attributes 155
D
Data Stewardship UI
installing 127
database
connections 47
create using the quick start scripts 44
home 29, 31, 33
host name 29, 31, 33
manual install 29, 31, 33
port 29, 31, 33
preparing DB2 48
preparing Oracle 51
preparing SQL Server 50
schema 29, 31, 33
type 29, 31, 33
user accounts 47
user name and password 29, 31, 33
DB2 database
installation scenarios 91
preparing for installation 48
DB2 for z/OS core
DB2 for z/OS domain
DDJDBCAuth.04dll 153
DDJDBCx64Auth04.dll 153
defaults
typical installation settings 17
user account settings 15
deployment
multiple time zone 37
deployment type
custom 7
typical 4, 5, 6
directory structure 19
disable splash screen
silent installation 87
display attributes, customizing 155
displaying AsaIdxno attributes 148
domain
dropdown parameter 143
E
editing the ContextManager.prop
file 136
editing the webreports.properties
file 153
edtElem parameter 145
encoding 167
Enterprise Viewer
application management 136
celldelim parameter 142
combining parameters 145
configuration 136
configuring composite view
displays 149
configuring restricted composite
views 150
configuring search sections 141
dropdown parameter 143
edtElem parameter 145
hint parameter 143
input formatting 146
installing 134
mapping SrcCode to AttrCode 149
MemDate searching 146
enumerated data types
configuration 163
error codes
EACTIVE 174
ECOMM 174
EDELETED 174
EDISABLED 174
EEXISTS 174
EEXTAUTH 174
EFILEIO 174
EINACTIVE 174
EINSANE 174
EINTEGRITY 174
EINTERNAL 174
EINVAL 174
ELOCKED 174
ENOFUNC 174
error codes (continued)
ENOLIB 174
ENOMEM 174
ENOREC 174
ENOTCONN 174
ENUNKNOWN 174
EOBSOLETE 174
EODBC 174
EPERM 174
ESHADOW 174
ESTATUS 174
EVERSION 174
extensible attributes
configuration 163
F
files
inspector.properties 131
G
globalization 60, 151
web reports 157
graphical
installation 14
groups 15
H
high availability 45
hint parameter 143
host name 34, 38
https
configure web application 173
I
industry 40
Inspector
installing 130, 170
install
directory structure and names 19
installation
Business Administration UI
Data Stewardship UI installation
overview 127
Enterprise Viewer installation
overview 133
graphical 14
Inspector installation overview 130
modify 90
overview 3
Product Maintenance UI installation
overview 128
silent 14
viewing logs 182
Installation Manager 181
web reports installation
overview 152
worksheets 27
Installation Manager
adding MDM offerings 43
Installation Manager (continued)
installing 43
installing
applications 125
Business Administration UI 126
custom 69
custom deployment type 7
Data Stewardship UI 127
deployment types
typical versus custom 4
in a cluster 73
Inspector 130
manually installing
Oracle database setting 106
manually installing the
application 103
manually installing the application on
DB2 for Linux or Unix 108
DB2 for Linux or UNIX 106, 108
DB2 for z/OS 104, 105, 109, 110,
113, 114
Oracle 118, 120
MDM features 8
on z/OS 77
Product Maintenance UI 129
samples 171
silent
application server parameters 87
creating response file 89
customize response file 82
DB2 parameters 84, 85
disable splash screen 87
Oracle parameters 86
specify features 84
using response file 88
silent installations 80
silent modify 89
typical deployment type 4, 5, 6
typical server 65
typical workstation 67
uninstall silent 186
using LaunchPad 64
verifying 177, 178, 180
your MDM edition 63
items per page, customizing 156
L
language
application resource 40
code table 40
LaunchPad
starting the typical installation 64
legal notices 189
locale
setting on target computers 60
logging
application server 133, 158
logs
viewing 182
M
MAD_HOMEDIR 20
MAD_ROOTDIR 20
manually installing
domain database on Oracle 120
manually installing physical MDM
database 106
manually installing the application 103
DB2 for Linux or Unix 108
DB2 for Linux or UNIX 106, 108
DB2 for z/OS 104, 105, 109, 110, 113,
114
Oracle 118, 120
matching style 37
maximum results per page,
customizing 156
MDM groups
adding a user 57
MDM_INSTALL_HOME 20
MemIdent searches 149
messaging
Message Brokers 37
WebSphere Default Messaging 37
WebSphere MQ 37
messaging component
installing manually 122
Microsoft SQL Windows Authentication
Tomcat 153
modify
installation 90
silent modify 89
mpi_appprop table
configurable search forms 140
display implementation-defined
segments 138
display ordering of attributes 137
mpi_appprop table configuration 137
multi-language requirements 151
multiple instances
installing and configuring 14
multiple time zone deployment 37
N
node
O
ODBC drivers 53
operational server
user application association 40
Oracle
manually installing the domain
database 120
Oracle database
P
package group
existing 28
new 28
parameters
AttrCodes 155
AttrLabels 155
AttrTypes 155
celldelim 142
combining in Enterprise Viewer
configuration 145
dropdown 143
edtElem 145
hint 143
SegCodeFilter 155
Templates 155
password 34, 37, 38
pop-up segments in Enterprise
Viewer 146
prepare
DB2 database for installation 48
Oracle database for installation 51
SQL Server database for
installation 50
preparing
high availability 45
preparing to install 27
account prerequisites 46
adding MDM offerings to
installer 43
application server dmgr 55
application server for base
deployment 57
application server unmanaged
server 56
database 46
DB2 database in a clustered
environment 49
DB2 database on a different
server 49
Oracle database in a clustered
environment 52
Oracle database on a different
server 52
set DB2 utility path 54
set Oracle utility path 54
setting up installation media 23
SQL Server database in a clustered
environment 51
SQL Server database on a different
server 51
startup kit 14
typical installation 25
using the quick start toolkit 44
Product Maintenance UI
installing 129
profile
properties
optional 155
required 153
provider direct
configuration 161
Provider Direct
installing 159
provider.properties file
required properties 161
R
reports
customizing 156
required properties
provider.properties file 161
response file
customize 82
graphical creation 89
silent installation 89
specify features 84
using 88
results 156
RMI port 37
S
samples
install overview 171
installing 171
secure server port
accessing web application 173
security
channel roles 58
security messages
adding 157
server
set DB2 utility path 54
set Oracle utility path 54
silent
installation 14
silent installation
creating response file 89
customizing response file 82
disable splash screen 87
modify 89
specify features 84
uninstall 186
using response file 88
SOAP port 34, 38
software services
contacting 195
SQL Server database
startup kit 14
support
customer 195
T
trademarks
list of 189
typical
installation 67
server installation 65
typical installation
defaults 17
deployment type 4
for server 5
for workstation 6
U
Unicode 167
uninstall 183
full edition 183
individual applications/
components 185
silent 186
updating deployed properties files 123
user accounts 15
database 47
user application
operational server association 40
user name 34, 38
users
adding user to a group 57
V
verifying the installation 177, 178, 180
W
WAS
web application configuration
https protocol 173
web reports
globalization 157
Web Reports
installing 152
webreports.properties file 153
optional properties 155
required properties 153
cell 34
deployment type 34
home 34
node 34
profile 34
server 34
WebSphere default
messaging 37
WebSphere MQ
messaging 37
Windows native authentication 31
worksheets 27
DB2/DB2 for z/OS data source 29
history triggers 40
installation directory 28
MDM application 37
Microsoft SQL Server data source 31
Oracle data source 33
user applications 38
Index 195
X
XA configuration for DB2 for z/OS 103
Z
z/OS
installing on 77
z/OS database creation and
installation 103
Contacting IBM
You can contact IBM for customer support, software services, product information, and general
information. You also can provide feedback to IBM about products and documentation.
The following table lists resources for customer support, software services, training, and product and
solutions information.
Table 39. IBM resources
Resource Description and location
Product documentation for InfoSphere MDM You can search and browse across all the InfoSphere
MDM documents at http://pic.dhe.ibm.com/infocenter/
mdm/v11r0/index.jsp.
Product documentation for InfoSphere MDM Custom
Domain Hub, including InfoSphere MDM Reference Data
Management
You can search and browse across all the InfoSphere
MDM Custom Domain Hub documents at
http://pic.dhe.ibm.com/infocenter/mih/v11r0/index.jsp.
IBM Support Portal You can customize support information by choosing the
products and the topics that interest you at
www.ibm.com/support/.
Software services You can find information about software, IT, and
business consulting services, on the solutions site at
www.ibm.com/businesssolutions/.
My IBM You can manage links to IBM web sites and information
that meet your specific technical support needs by
creating an account on the My IBM site at
www.ibm.com/account/.
Training and certification You can learn about technical training and education
services designed for individuals, companies, and public
organizations to acquire, maintain, and optimize their IT
skills at www.ibm.com/software/sw-training/.
IBM representatives You can contact an IBM representative to learn about
solutions at www.ibm.com/connect/ibm/us/en/.
Providing feedback
The following table describes how to provide feedback to IBM about products and product
documentation.
Table 40. Providing feedback to IBM
Type of feedback Action
Product feedback You can provide general product feedback through the
Consumability Survey at www.ibm.com/software/ucd/
consumability/.
Table 40. Providing feedback to IBM (continued)
Type of feedback Action
Documentation feedback To comment on the information center, click the
Feedback link on the top right side of any topic in the
information center. You can also send comments about
PDF file books, the information center, or any other
documentation in the following ways:
v Online reader comment form: www.ibm.com/
software/data/rcf/
v E-mail: comments@us.ibm.com
Printed in USA
GI13-2658-00

04 MDM Stdadvinstall

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

04 MDM Stdadvinstall

Caricato da

Copyright:

Formati disponibili

IBM InfoSphere Master Data Management Standard and

IBM InfoSphere Master Data Management Standard and

MDM components are installed by using IBM

Installation Manager, which ensures a

Application Server and with the

Application Developer (RAD) (if you are using InfoSphere

, Linux, or Solaris operating systems

). Java and Web Service SDK examples are

or other method, download and

, Linux, or Solaris data source information is stored in an

, Linux, or Solaris data source information is stored in an

are trademarks or registered trademarks of International Business

Potrebbero piacerti anche