There is a typical workstation install that automatically sets up a full development and test environment, described in the 'Full development environment install' section of the Inst
The alternative is to manually install the MDM Workbench for MDM configuration and development, and an Operational Server for test purposes. In this example I will install a full development and test environment on Windows, using a DB2 database. The instructions below assume that you do not have any of the prerequisite software installed but, if you do, just skip the relevant steps.
To avoid problems with path lengths, special characters, or Windows virtualised directories, I installed all the software under a C:\IBM directory.
This blog post is accompanied by a seri
Downloading and extracting install images
These are all the install images I downloaded. See the Down
Important: If you are about to install MDM but downloaded the install images before 17th October 2013, you must download the product refresh first.
Important: The workbench install will fail if the .tar.gz install images are extracted using WinZip. So far it looks like the Download Director unpack option, WinRAR, and 7-Zip all work but please leave a comment if you have problems with any unzip tools and I'll update the list.
IBM Installation Manager V1.6.0
This is required to install everything except DB2.
Part number: CIM7CML
DB2 Enterprise Server Edition V10.1
I used fix pack 2 to install DB2, available via the DB2
Part number: CI6WEML
Installation Startup Toolkit
This provides the scripts required to create an MDM database.
Part number: CIR9WML
Master Data Management Standard & Advanced Edition
This is the actual MDM Operational Server install.
Part numbers: CIR9NML, CIR9PML, CIR9QML, CIR9RML, CIR9SML
Master Data Management Workbench Standard & Advanced Edition
This is the Rational based workbench used to configure and develop MDM solutions.
Part numbers: CIR9TML, CIR9UML, CIR9VML
Rational Application Developer for WebSphere Software V8.5.1
I installed the workbench into Rational Application Developer but you could use Rational Software Architect for WebSphere Software instead. In either case you need at least version 8.5.1, however there is a know
Part numbers: CIE5FML, CIE5GML, CIE5HML, CIE5IML
WebSphere Application Server V18.104.22.168
The minimum version required is 8.5.0 fix pack 2, otherwise the install verification tests will fail. I down
Part numbers: CI6XNML, CI6XPML, CI6XQML
Installing Installation Manager
I ran install.exe to install Installation Manager in GUI mode. After installing Installation Manager you can add the required repositories individually before you run each install, as I did in the video series, or you can add all the repositories in one go as follows.
Create a repository.config file in the directory where you extracted the install images. Copy and paste in this content:
Edit any paths based on the directories you used before saving the file. Now you can add this single repository using the Installation Manager repository preferences and all the packages will show up on the install page.
For more information about Installation Manager, see the Inst
Note: you may have seen a suggestion to alter Installation Manager's agent data location using the cic.appDataLocation configuration setting, however it is not typically necessary, or a good idea, to change this setting.
Installing the workbench
Installing the workbench is straightforward once you've added the Rational Application Developer and workbench repositories to Installation Manager. Pick a suitable install location, for example C:\IBM\SDP, and you can accept the defaults for everything else.
In the MDM
Installing Operational Server prereqs
Before installing the MDM operational server, you need to install DB2 Enterprise Server Edition version 10.1 and WebSphere Application Server 22.214.171.124. In addition, the Installation Startup Toolkit provides the database scripts you'll need to create an MDM database.
You can watch how to run these installs in the MDM
Important: you must install DB2 in a directory called SQLLIB, otherwise the operational server install will not work. For example, I installed DB2 to C:\IBM\SQLLIB
I accepted most of the defaults in the DB2 install wizard, except that I chose not to enable email notifications or operating system security since this is for a development environment.
WebSphere Application Server and Installation Startup Toolkit
Both of these are installed using Installation Manager so I installed them at the same time. (You could even install them at the same time as the workbench to save time.)
Important: you must install fix pack 2 for WebSphere Application Server 8.5 otherwise the MDM install verification tests will fail.
I changed the install locations, to C:\IBM\AppServer and C:\I
Preparing to install the Operational Server
There are several advantages to manually installing a development and test environment, however the biggest disadvantage compared to a typical install is that the installer does not create an MDM database or WebSphere profile for you. Instead, you have to prep
These are the steps I followed, which are covered in the MDM
Edit SQL files
There are a couple of SQL files provided in the startup toolkit for creating an MDM database on DB2:
Both these files contain placeholders which need to be replaced with suitable values before use. These are the values I used:
Notes: Authority will be granted to the user specified by the <DBUSER> value, so this should be different to the user running the scripts. The database name is easy to specify in the installer but here I used the default. The tablespace names need to match the settings used by the installer, and the easiest way to do that for a development environment is to use the values shown above.
The following PowerShell command will fill in the placeholders and I ran it for CreateDB.sql and CreateTS.sql rather than editing the files by hand:
powershell -command "(Get-Content C:\I
After editing the SQL files, I ran them using this command in a DB2 Command Window:
db2 -v -td; -f C:\t
And the same for CreateTS.sql.
Create application server profile
I used the advanced option when creating an application server profile using the Profile Management Tool. I chose not to install the default application, gave the profile a meaningful name and picked the Development tuning setting. Administrative security must be enabled for MDM, and the advantage of creating the profile yourself is that you get to choose the username and password. If you run the Profile Management Tool as administrator, you will also be given the option to run the server process as a Windows process, which isn't necessary for a development environment.
Important: When creating a profile for use with the MDM Workbench, make sure you create it in the default location with a directory name that matches the profile name.
If you've used previous versions of the workbench, one of the first changes you'll hit is that you no longer need to run the developer environment setup tool when you create a new workspace. In version 11, no projects need to be imported into the workspace, and you use the same installer to setup a local test server on your development machine as you would to install a production system.
Full development environment install
If you have a completely clean machine, the simplest way to get started is to use the workbench typical install. This will install DB2, Rational Application Developer, and WebSphere Application Server, along with MDM Server and the workbench, i.e. everything you need for a full development and test environment in one go. Here's how to get everything ready to run a typical install...
Firstly, you'll need to download all the typical install images. The following part numbers are required for a full MDM Workbench v11 typical install:
CIM6NEN, CIM6PEN, CIR9NML, CIR9PML, CIR9QML, CIR9RML, CIR9SML, CIR9TML, CIR9UML, CIR9VML, CIE5FML, CIE5GML, CIE5HML, CIE5IML, CI6XNML, CI6XPML, CI6XQML
Important: If you are about to install MDM but downloaded the install images before 17th October 2013, you must download the product refresh first.
Once you have all the install images downloaded, the contents must be extracted into a specific dire
After extracting all the install images, open the install launchpad, which you can find in the MDM\disk1 directory (there are 32 and 64 bit versions). The typical workbench install link is right at the bottom of the launchpad:
When the install starts, you should be able to click through all the panels without changing anything:
Make sure you confirm that the IVT tests pass at the end of the install and, if they did, you're ready to start developing for MDM v11!
Note: you should change the defa
Workbench only install
If you don't want a local server to test changes on, installing the workbench is much quicker, since DB2, WebSphere Application Server and the server install are not required. In this case, you'll only need the following part numbers:
CIM7CML, CIR9TML, CIR9UML, CIR9VML, CIE5FML, CIE5GML, CIE5HML, CIE5IML
The launchpad doesn't support this scenario, so you have to install Installation Manager manually, add
Alternatively, you can use the Installation Manager command line to install Rational Application Developer and the workbench in one step. For example, assuming you extract the install images in the same structure as for a typical install:
imcl install com.
A typical install is ideal for demos or evaluating MDM but to set up developer environments I would recommend installing manually. You'll also need to do this if the typical install does not support your environment. The following blog post describes the manual install process:
There is also a wiki page with an up-to-date* list of install related information.
(* Please update it if it's not up-to-date!)
From an early MDM Workbench news site, the MDM Developers community has evolved and grown to a group of over 200 members, and it would be great to take a break from the usual posts and forum discussions to find out more about some of you with a quick blog interview. Whether you're a new member or a long term contributor, please say hi and tell us a little about yourself.
Feel free to leave a comment and answer any of the following questions that resonate with you, or add your own questions instead. This is just a casual blog interview and meant to be more like a real world conversation, rather than a formal resume or biography!
For fun, and a bit of encouragement, I have a few limited edition MDM Developer community stickers to give away!
Here are a few questions to get you started:
Update: Unfortunately no one replied in time to claim the ticket that prompted this blog post. Luckily if you're one of the first to reply, you could still get one of these, much more exclusive, MDM Developers stickers!
You may have seen the recent tech talks that the team here have been producing for our clients. In these tech talks an IBM expert will talk through a specific MDM topic in great detail sharing the deep expertise of the architects and developers that are living and breathing the technology. These tech talks are provided for free and just require a simple registration process to allow you to attend. All sessions are recorded and replays will be available shortly afterwards.
One area of keen interest to our clients has been concerning the Stewardship and Governance capabilities provided by MDM, specifically the IBM Stewardship Center, that was released in MDM 11.3. So it falls to me to host the next MDM tech talk on June 23rd. In this session I will be discussing the new capabilities offered by the IBM Stewardship Center, how we are changing the game for stewardship teams looking to evolve their organization to be more reactive to data quality events, engaging line of business users to provide input to data quality issues and adding advanced business rules and intelligence to automate events from across the entire data quality landscape.
A one hour tech talk is no where near enough time to do such a broad and important area justice however, we will spend some time up front explaining IBM's perspective on Information Governance and how IBM's InfoSphere portfolio provides the market leading integrated suite of comprehensive governance capabilities that can flex to suit your specific industry requirements. We will dive into the IBM Stewardship Center and its comprehensive workflow engine, providing collaboration and orchestration across the enterprise and touch on the MDM Application Toolkit, a suite of accelerators designed and built by some of our development ninja's to make creating custom governance workflows and quick and easy experience....and if we have time we may even have a live demo of the latest version of the Stewardship Center. During the session the live chat will be open allowing you to ask questions and I will have a team of experts ready to respond in real time.
If your organization is trying to address the growing focus on Information Governance, if you are trying to figure out how to make your Stewardship organization more efficient, or you just wanted to take a look at one of the coolest new features from the MDM team then don't miss the Mast
This document outlines how Physical MDM customisations can be built from source artefacts in an automated build and test system. This document does not aim to be a complete guide on this topic, but rather to point the way to how some detailed steps can be implemented using examples.
The MDM Advanced or Standard editions both include the MDM Workbench. In version 11.0 and beyond the MDM Workbench is used by solution developers to create artefacts which customise the MDM solution for the physical, virtual and hybrid implementation styles. These source code artefacts are typically built into a Composite Bundle Archive (CBA) and deployed to WebSphere where they augment the functionality already available in the MDM Server Enterprise Business Application (EBA).
A good practice amongst MDM solution developers is to create an automated build process such that customisation source code is checked-in to a code control repository, and an automated build process takes those source files and builds the CBA ready for deploying onto post-build test systems, placing built artefacts into a second repository or shared file system.
Some automated systems take this “build” concept further, by automating the deployment of such built artefacts to test systems, which in turn report back on the “health” of the build, how many tests passed and failed, and generally quickly provide valuable feedback to developers whether recent changes broke the solution or not. Project managers overseeing such projects are able to reduce project risk by adopting this continuous delivery processes, and changes to MDM solutions become more reliable and safer as a result.
To add MDM solutions to such a continuous build environment it is necessary to:
This article is mostly concerned with step #7 – building source artefacts.
2. Materials and prerequisites
This article is accompanied by a collection of example scripts. We do not intend that these are used directly, but as an example of how you may wish to implement your own automated build process.
The current solution consists of four main files:
In order for the scripts to work, the machine running the scripts needs to have the following products installed:
To run the Ant scripts the user needs to run mdm_wb_build.xml as a build file.
The script contains only the “runBuild” target.
The target checks that necessary properties, such as Eclipse Home, date and time stamps and output folder prefix are set. Provided these properties do exist, it creates a folder based on OutputFolderPrefix and date and time, within which “logs”, “CBAExport” and “workspace” folders are created.
The logs folder contains “MDM
generateDevProject: BUILD SUCCESSFUL
workspaceBuild: BUILD SUCCESSFUL
exportCBA: BUILD SUCCESSFUL
End of report.
The CBAExport folder contains all of the exported CBAs.
The workspace folder contains a local copy of build artefacts.
After the directories have been created, the script checks which operating system it is running on and sets the isLinux or isWindows property to “true” as appropriate and calls either runAnt.sh or runAnt.bat to run a headless Eclipse process. The relevant file (either the batch or the shell script) should be available by default in the bin directory in the Eclipse installation directory.
The runAnt script then sets up the log files, environment variables and runs a second script “mdm
3. Step breakdown of the automated build and test system
Given that automated building and testing of MDM solutions is a worthwhile goal, the following sections provide some guidance in some of these areas where actions specific to the MDM tools and development/build environment are necessary, and some points of discussion are presented where choices exist.
3.1 Identify the pieces of the solution which represent the “source code” for the solution.
The source code for an MDM solution will be made up of a collection of Eclipse projects and their contents. MDM development, MDM configuration, MDM hybrid mapping, MDM service tailoring, MDM custom interface, MDM metadata and other MDM-specific projects types. CBA projects will add to the list.
MDM Development projects contain a “module.mdmxmi” file, which contains a model of the customizations which the project aims to create. This file should always be considered to be source code.
At some point the mdmxmi file will be used to generate Java, XML, SQL and other file artefacts, and there are a few different approaches you can take for these files:
The current solution is to only consider files which have been manually changed as “source code”, and “generate artefacts” from the mdmxmi model as part of the automated build process itself. This approach demands that the MDM workbench tools are installed as part of the build environment, because the “generate artefacts” process that turns .mdmxmi files into other artefacts will be a necessary part of the build process.
A project “MDM
3.2 Create a source code repository.
There are many choices regarding which product to use as a source code repository and covering them is not the aim of this document.
3.3 Recognize when a consistent set of code has been checked-in, at which point a “build” is started.
This event may be triggered manually, automated overnight, or whenever a change-set is delivered to the code stream. The capturing of this event is often specific to the code control system being used, though some solution teams augment this by adding a web page that enables build requests to be manually requested.
3.4 Create a build environment.
A build environment should include RAD (or RSA) which can be called in a “headless” manner such that functionality within RAD can be used without a user-interface being present.
MDM Workbench will be required in addition to RAD to perform a complete build of “module.mdmxmi” files.
For the list of platforms that MDM Workbench v11.0 and onwards support – refer to the product release documentation.
3.5. The build environment “boot-straps” itself.
A small script is responsible for “boot-strapping” the process by it checking-out the other build scripts which in turn build the artefacts from solution developers.
3.6 The build scripts check out the artefacts from code control to the local file system.
These actions are specific to the code control system so will not be discussed further here.
3.7. The source artefacts are processed, transforming them into built artefacts.
This phase of the automated system typically consists of a hierarchy of Ant files which decomposes the overall build process into many smaller steps and “Ant targets”. The Maven framework is a common choice of technology to oversee this phase.
These Ant files can be categorized into two types:
For a detailed walkthrough of specific implementations of the build process refer to the Ant scripts provided with this blog entry.
3.8. The build process often executes “unit tests” to further validate that the solution artefacts are healthy and do what they are expected to do.
The tools and approaches used to execute unit tests vary widely dependent on technology choice. Simple Java JUnit tests offer one simple solution, which can be invoked with scripts once the tests and tested code are built.
3.9 Built artefacts are published to a repository.
Every build against which build metadata can be gathered and reported is versioned by the publish process. Build logs, unit test results and results of other tests indicating the “health” of the build are gathered and published to the repository as well.
Products such as Rational Asset Manager can be used here, or for a really basic solution a simple shared folder on a network drive may suffice.
3.10 Automated deploy and test health of overall build.
If the build is considered “good” then further automation can be added to deploy the built solution to a test environment, with higher-level tests (functional and end-to-end system tests) exercising the solution further. Such tests can also report back to the build repository on the health of each build.
The automated deployment of entire systems for testing is often one of the most complex areas of the whole continuous development process. Products such as Rational Urban Code Deploy (UCD) can be used for this stage of the process, though for some environments a set of (reasonably complex) scripts might be sufficient.
For the MDM pieces, we are mostly concerned with deploying and un-deploying SQL scripts, depl
Prior to deploying extensions to the server, it is often necessary to modify the database. This is possible using the SQL scripts found in the MDMSharedResources project in the built workspace. Rollback scripts in the same location should be applied once testing is complete to reset the database back to a known good state.
For CBA deployment, Jython scripts can be used to manipulate the WebSphere server. Detailed documentation of these steps can be found in the WebSphere documentation.
As of version 10.1, MDM is secured by default. This means that using the Web Service Explorer to test your web service will not be possible. Whilst there are many web service testing tools out there like SOAPUI, there is one that is included within the MDM Workbench that you can use, the Generic Service Client. The following steps detail how to invoke the required MDM web service :
This will then open the following editor :
The responses are saved and can be rerun, but if you want more functionality you'll probably need to look at Rational Performance Tester
MDM Application Toolkit for Product Domain
I recently had to build a product bundling process for a demo using BPM and the MDM Application Toolkit(MDMAT). Having built many business processes over the past 2 years using data from InfoSphere MDM I realized this was going to be the first one I that I was to build against the product domain of the physical engine. Using the MDMAT against the Party domain is pretty darn easy and very quickly a rich process can be built that interacts with MDM's library of web services for many different types of processes. How useful would it be for me when operating against the Product Domain, especially when a good chunk of my data was stored in Product domain XML soft specs? Well I'm pleased to say it was also very straight forward. I've written some notes below that will hopefully allow others to also find it just as easy to use the MDMAT against the product domain.
The process was to execute a search against the MDM product domain using some pre defined criteria that would allow me to pull back all products that met a certain criteria. in this case it was to retrieve a list of products that were within the 'Mobile Phone' category of the 'Channels' hierarchy, were aimed at a 'Market Segment' that was 'Affluent' had an 'Effective Date' before today's date and an 'Expiry Date' that was after todays date. This would allow me to show currently active offers on the mobile channel for Affluent customers. The 'Market Segment', 'Effective Date' and 'Expiry Date' attributes were all stored as attributes within an XML spec called 'Offer Attributes'. In the search results that come back from MDM I also needed to pull out some additional attributes that were stored within another XML spec called 'Channel Mobile Phone', these attributes were named 'Mob
Whenever I build a business process I first start by defining the variables that I will need. Since BPM applications are data driven, I find it helpful to define the data upfront and then worry about wiring them into a process at a later stage. Using the MDM Workbench I exported my MDM WSDL and imported it into Process Designer. This gives me access to my MDM Product business objects within BPM, allowing me to easily construct a ProductSearchBobj object with the criteria I need to execute my search and also create a Prod
With the objects defined I could move on to define my process flow. I created a very simple flow to suit the requirements as seen below:
I would first use the 'Configure Spec Search Criteria' node to execute a script to populate the ProductSearch object with the crieteria I needed. I would then configure the 'Retrieve all Offers' node to use the MDM Application Toolkits' Physical MDM Txn service to execute a search an return a list of Prod
With my objects defined and my process defined all I had to do was a little bit of scripting to firstly populate my search and then extract my search results to populate my displayObject. (I had already populated my MDMConnection object with my MDM server's credentials and configured the 'Retrieve all Offers' node to use the MDM Application Toolkit's Physical MDM TXn service to call an MDM 'sea
Populating the Search
I wrote a simple script in my 'Configure Spec Search Criteria' object to pass in the search criteria. I wont include the full script here, but all I had to do was create an instance of a ProductSearch object and set the following attributes:
When passed into the 'Retrieve all Offers' node my search criteria successfully results in a list of products that I am interested in being returned as a list of Prod
Extracting the spec values and populating the display object
Up until now everything I had done was pretty similar to other processes I had built, this final piece was the most challenging, in that I had never extracted values from an XML spec before within a business process. Looking at my Prod
With my spec values now populated inside my Prod
This ended up being a bit of a longer blog post then I intended (sorry JT), but hopefully it will provide you a good starter in using the MDMAT for the product domain. I really enjoyed building this process (and writing this article) as it showed me how cool the MDMAT is for helping me to build MDM centric business processes. The ability to build processes against MDM and not worry about the connection and any complexity in calling MDM Web Services saves a huge amount of time and with a little bit of script I was able to leverage the value of MDM's XML specs. if you want more information drop me an email. I'd love to hear what you are doing.
Author: Geetha S Pullipaty
Product: Infosphere Master Data Management.
Other prerequisite software: IBM Business Process Manager 8.5.6 , IBM Process Designer 8.5.6, IBM Stewardship Center 11.5.0 installed and all process applications imported on BPM and EPVs for MDM Connection details set for all of them.
This blog provides detailed steps of connecting two MDM instances to a single Process center environment for IBM Stewardship Center(ISC) component. It provides the manual steps and doesn't do run any scripts. It also doesn’t explain all the steps required for installing and configuring ISC but only those additional steps when two MDM instances are involved.
This document assumes that you haven’t done any configurations on MDM or BPM WAS consoles for configuring ISC. If you have already done please delete those additional configurations.
Lets say you have two MDM instances MDM1 , MDM2 and single Process Center instance BPM1.
Steps to be done on WebSphere Administrative Console of MDM1.
1. Create an Alias Destination on MDM Server's SIBus as below:
2. Create JMS Queue on MDM Environment as below:
3. Create JMS Queue Connection Factory on MDM Environment as below:
4. Creation of Foreign Bus Connection on MDM Environment as below:
Steps to be done on WebSphere Administrative Console of MDM2
1.Create a new Service Integration Bus on MDM2. The reason for this to be done is because both MDM environments are identical and have same SIBus names connecting back from BPM will be an issue if BPM has to connect to two SIBuses with same name.
2. For the new SIBus created , add a Bus member. This is required to create a messaging engine for the new bus created.
Steps to be done on Websphere Administrative console of BPM
1. Creation of Foreign Bus Connection on BPM Environment as below:
Repeat the same steps but this time giving details of MDM2 instance. The values to be given in this case are
Name of service Integration bus to connect to (the foreign bus): Set the value to the name of the new SIBus created during step 1 in previous section in MDM2 instance.
So by the end of these steps you would have two foreign bus connections created on BPM. MDM_BPM_LINK_ONE pointing to MDM1 instance and MDM_BPM_LINK_TWO pointing to the new SIBus created on MDM2 instance.
Steps to be done on BPM Process Center console
1. Login to BPM Process Center Console with admin access
Steps to be done on BPM Process Admin Console
1. Login to BPM Process Admin Console with admin access.
SQLs to be run on MDM databases
1. Run these SQLs on the database connected to MDM1 instance
UPDATE CONFIGELEMENT SET VALUE = 'true', LAST_UPDATE_DT = CURRENT_TIMESTAMP WHERE NAME = '/IB
UPDATE CDEVENTDEFTP SET ENABLE_NOTIFY='Y', LAST
2. Run these SQLs on the database connected to MDM2 instance.
UPDATE CONFIGELEMENT SET VALUE = 'true', LAST_UPDATE_DT = CURRENT_TIMESTAMP WHERE NAME = '/IB
UPDATE CDEVENTDEFTP SET ENABLE_NOTIFY='Y', LAST
update configelement set value='true', last
If you give snapshot names in the Process Center Console different than these make sure to change these SQLs as well. Make sure all the SQLs are run successfully.
Restart all the instances MDM1, MDM2 and BPM. You need to restart the Application servers, nodeagents , deployment managers.
Author: Geetha S Pullipaty
Product: Infosphere Master Data Management.
Other prerequisite software: IBM Business Process Manager 8.5.6 , IBM Process Designer 8.5.6, IBM Stewardship Center 11.5.0 installed and configured.
Problem: I added a new relationship type with type code “300000” in cdreltp of MDM and I have two parties with relationship created among them. The screenshot in Explore tab now is:
1. Login to IBM Process Designer with required credentials.
2. Provide edit access to this user to MDM Application Toolkit in the list of toolkits.
Make sure “Allow users to update toolkit” checkbox is checked.
3. Open MDM Application toolkit in designer.
5. Modify the script “Load Label Map”.
6. Add the following line of code at the end of the script.
7. Once done these changes, save all the modifications.
8. Take a new snapshot of MDM Application toolkit
9. Upgrade the dependency of MDM Application toolkit in MDM Stewardship Toolkit and create a new snapshot of MDM Stewardship Toolkit.
10. Upgrade the dependencies of MDM Stewardship Toolkit and MDM Application Toolkit in MDM Party Maintenance process application.
Please make sure not to miss step 9.
11. Reload Search dashboard from Process Portal and search for the same record and go to edit page. The explore tab now looks like
Failed to connect to the JMX port on server
When you first connect from MDM Workbench to WebSphere Application Server (AppServer) where MDM Server is installed, for example to deploy a configuration project or to run a virtual job, you might see this error:
Job Manager Error - Failed to connect to the JMX port on server
There can be several reasons why the connection might fail, for background, here is the stack you are relying on when you connect to the JMX port.
In order for the JMX port connection to be successful, you need every component in this diagram to be in a fully functioning healthy state. And yes, that means there are a lot of places you can check! As a result, it's not practical here to explain every possible area to review, but this should give you some idea of where to start investigating.
To begin, cut the problem in half: there is a message associated with blueprint virtual bridge. Look for this, and it will help you decide whether the problem is more likely to be a runtime issue (below and to the right of the blueprint virtual bridge component) or a configuration issue
1. Look for virtual bridge messages
On the Application Server where MDM is hosted, open SystemOut.log or HPEL logs: if possible restart the AppServer first to make sure you have startup messages:
When the MBean starts successfully, you will see messages like these:
Note that these messages will only appear on startup, so they may not be visible if the logs have wrapped
If you have these success messages the Blueprint virtual bridge is available for JMX requests, and everything to the right of the diagram (MPIJNI, JMS, databases, filesystems) is healthy.
In this case the likely cause of the problems is to the left of the diagram, and probably relates to a configuration issue. More information is available in section 3. When the virtual bridge has started successfully
When the MBean has not started, you see messages like this:
If you have these failure messages the Blueprint virtual bridge is not available. More information is available in the next section, 2. When the virtual bridge has not started
No messages found
If you don't find any messages relating to com.
2. When the virtual bridge has not started
When the blueprint virtual bridge has not started, the next step is to investigate potential runtime issues in one or more of the components on the right side of the diagram.
Note that you can choose whether you use a datastore or filestore for the messaging engine data store: the default is datastore (database).
There may be file system errors, these will usually be reported by the component that depends on the file system, for example the database or the JMS filestore.
In many cases you will be able to find technotes or other links on the internet with information about how to resolve the errors, or if not, contact IBM support and provide the logs that show the errors.
These related links have information about resolving blueprint errors:
3. When the virtual bridge has started successfully
Once you have found the success message, the next step is to investigate the configuration in both WebSphere Application Server and MDM Workbench.
Review the server logs for authorization errors
On the Application Server where MDM is hosted, open SystemOut.log or HPEL logs. Look for errors that reference one or more of:
Errors with any of these codes suggest that you need to re-visit the security configuration in the WebSphere Application Server administrative console, and check userid and password settings in the workbench client. Review the error messages, in many cases you will be able to find technotes or other links on the internet with information about how to resolve them, or if not, contact IBM support and provide the logs that show them.
Review the firewall settings
Verify that you can ping from the Workbench machine to the machine that hosts WebSphere Application Server and MDM Server, using your preferred ping tool.
Optionally you can use "Test Connection" from MDM Workbench, although note that in an ND configuration this tool only checks the dmgr, so it may not be the correct status for the actual server where MDM is hosted.
If you can not connect to the target MDM server, the JMX connection will not work and you need to contact your networking support team to make sure the network is available and if necessary, that appropriate firewall ports are opened.
Review the port and host configuration