Blogs

MDM Developers

About this blog

The MDM Developers Community is open for any developers using IBM's Master Data Management software to connect with each other, stay posted on the latest MDM technical resources, learn how to get the most out of MDM tools, ask questions, and share tips and answers to technical problems.

Tags

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:

Success scenario

When the MBean starts successfully, you will see messages like these:

RMIConnectorC A ADMC0026I: The RMI Connector is available at port <xxxx>

JMXConnectors I ADMC0058I: The JMX JSR160RMI connector is available at port <xxxx>

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

This message identifies a problem with the JMX MBean listener, but does not in itself identify the root cause: to find the source, look for other messages in the logs with earlier timestamps.

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.ibm.mdm.server.virtualbridge, the most likely reason is that there were messages when the server started, but the logs have wrapped the virtual bridge messages are no longer current. The recommended action is to restart the server and collect the new logs.

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.

Look for Database errors, search the Application Server logs for

SQL

DSRA

Look for JMS errors, the JMX MBean for virtual relies on the SIBus messaging engine, search the Application Server logs for

CWSIS

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.

com.ibm.mdm.server.virtualbridge is waiting for dependencies

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:

LDAP

LTPA

SECJ

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

In the WebSphere application console

Go to Servers -> Server Types -> WebSphere application servers

Select the server where the MDM runtime is installed

Scroll down to the ports section and open it (see the screenshot below)

Make a note of the ports for

BOOTSTRAP_ADDRESS

SOAP_CONNECTOR_ADDRESS

ORB_LISTENER_ADDRESS (if not 0)

In the Workbench

Go to the Servers tab (you may need to add it from Window -> Show View)

There's a new series of blog posts just starting which will be describing how fitting a specific, inflexible, MDM implementation style might cause problems, and how a more adaptive style of MDM could help. The first in the series starts off by reviewing the traditional MDM styles:

In Version 11 of InfoSphere MDM, some big changes happened. One change that might leave you scratching your head is the addition of new and changed terms for some familiar components. We also have a couple new components, so those might be unfamiliar too. Let's take a quick walk through the changed terms to get you started.

Product names

The first thing that you'll notice is an emphasis on capabilities rather than product names. You might not see these familiar product names anymore:

InfoSphere MDM Server

Initiate Master Data Service (MDS)

Other Initiate product names

Instead, you’ll see references to technical capabilities that those products achieve:

Technical capability

Previous product name

virtual MDM

Initiate Master Data Service

physical MDM

InfoSphere MDM Server

hybrid MDM

InfoSphere MDM Server and Initiate Master Data Service

You might be wondering what exactly these technical capability terms mean. You can use virtual, physical, and hybrid MDM to manage your master data, whether you store that data in a distributed fashion, in a centralized repository, or in a combination of both.

The following definitions show the differences and the relationships among the technical capabilities:

virtual MDM

The management of master data where master data is created in a distributed fashion on source systems and remains fragmented across those systems with a central "indexing" service.

physical MDM

The management of master data where master data is created in (or loaded into), stored in, and accessed from a central system.

hybrid MDM

The management of master data where a coexistence implementation style combines physical and virtual technologies.

Another new area that you’ll notice is a unified server, which is referred to by one common term:

Earlier terms

Current term

InfoSphere MDM Server

Initiate Master Data Service

MDM Hub, MDM Server

master data engine

MDM operational server

The former InfoSphere MDM Server and the former Initiate Master Data Service are combined to share a single infrastructure in the application server. That single infrastructure is called the MDM operational server or operational server for short. The operational server is the software that provides services for managing and taking action on master data. The operational server includes the data models, business rules, and functions that support entity management, security, auditing, and event detection. For detailed descriptions and diagrams, see the architecture and concepts topic.

Records, member records, and entities

Finally, the concepts of entities and records were clarified:

entity

A single unique object in the real world that is being mastered. Examples of an entity are a single person, single product, or single organization.

record

The storage representation of a row of data.

member record

The representation of the entity as it is stored in individual source systems. Information for each member record is stored as a single record or a group of records across related database tables

Depending on your implementation style, these concepts reflect the technical capabilities of virtual, physical, and hybrid MDM. For example, an entity in virtual MDM is assembled dynamically based on the member records by using linkages and then is stored in the MDM database. Conversely, an entity in physical MDM is based on matching records from the source systems that are merged to form the single entity. For details, see the diagrams and definitions for these concepts.

I’ll leave a discussion of hybrid MDM to a future article. If you’d like to read some conceptual topics about hybrid MDM now, see its technical overview.