S Eggleston 2700002CDU Visits (280)
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
When you installed MDM server, the install deployed a JMX MBean which should be listening on the AppServer ports for incoming JMX requests. The workbench acts as a JMX client, and this error means it can't make the connection.
There can be several reasons why it might not be able to connect, here are some configuration aspects you should check:
Port / host configuration
Confirm that you have the correct configuration in the Workbench server settings
WebSphere ND configuration
The Workbench does not support integration with WebSphere Application Server ND for administration and for deploying CBAs, due to restrictions in the underlying products.
Workbench does support integration for deploying virtual configuration and running virtual jobs, but the default settings do not work: for WebSphere ND you need to disable the IPC port as shown in the screen capture.
Make sure that the RMI and SOAP ports are correct for the target server: they must be for an application server, and not the deployment manager (dmgr) or node agent.
You can only run virtual jobs on one server at a time, that target server can be a member of a cluster, but it will not provide cluster capabilities such as failover or workload balancing.
jtonline 110000B6Y8 Visits (1393)
There's a new seri
vwilburn 100000F865 Visits (2067)
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.
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:
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:
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.
The management of master data where master data is created in (or loaded into), stored in, and accessed from a central system.
The management of master data where a coexistence implementation style combines physical and virtual technologies.
Server and engine terms
Another new area that you’ll notice is a unified server, which is referred to by one common term:
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 arch
Records, member records, and entities
Finally, the concepts of entities and records were clarified:
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.
The storage representation of a row of data.
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 diag
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.
Some helpful links: