Darren Sullivan 2700057QUX Visits (94)
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
bakleks 270007PVJ3 Visits (277)
IBM InfoSphere MDM provides a set of out-of-the-box entity processing rules, like 'partyMatch' or 'collapseParties'. These rules are extendible and this blog entry will walk through the process of extending one of them – 'col
Assuming that a development project has already been created in the workspace, code for the project has been generated and setup SQL scripts have been ran – create a new package in the project's 'src' folder (For example: 'com
Within the new class the default 'collapse' can be used by calling the 'col
The created package and Java class should then be added to the 'blueprint.xml' file present in the development project as follows:
<?xml version="1.0" encoding="UTF-8"?>
<property name="bpBundle" ref=
The following packages also need to be added to the 'manifest.mf' file of the project to export the package that contains the external rule class:
The below packages also need to be added to the 'com
Export the 'CBA' using the wizard and deploy it to the server (instructions for one of the approaches to deploying a CBA can be found here).
To make the system use the modified rule an update to the database needs to be run. Search the 'JAVAIMPL' table for an entry with the 'JAVA_CLASSNAME' of 'com
UPDATE SCHEMA.JAVAIMPL SET JAVA_CLASSNAME = 'com
Restart the server.
The next step would be to re-configure the Optimized Transparent SQL (OTS) queries. OTS queries allow the 'SELECT' statements used to retrieve data from the database to be customized and optimized for a given deployment.
The 'INQLVL' table defines the set of OTS capable entities and their associated inquiry levels. Depending on the types of the objects that will be collapsed – the appropriate 'GROUP_NAME' should be looked up. In this example we will be working with Organizations.
The values to note are 'INQLVL_ID' and 'INQLVL'. It's worth noting that the 'SELECT' statements themselves are not stored in this table, but rather are contained within 'INQLVLQUERY' table.
Each combination of Entity-Inquiry Level contains one or more 'SELECT' statements within the table. These statements are also associated with a 'BUSINESS_TX_TP_CD' value (32) which is derived from the 'CDBUSINESSTXTP' table and defines the associated query transaction.
The 'CDINQLVLQUERYTP' table defines the possible type code values for entries in the 'INQLVLQUERY' table.
'CDBUSINESSTXTP' table contains a list of available transactions and associated 'BUSINESS_TX_TP_CD' values.
The OTS queries need to be re-generated and updated to include the extended fields after the customized CBA has been deployed, otherwise those fields will be omitted from the response. The 'add' and 'update' transactions are not affected as they are not query transactions. There exists an 'updateInqLevel' transaction to re-build these queries.
For each Inquiry Level Id resolved above a single 'updateInqLevel' transaction needs to be ran against the server. The following fields need to be filled out: InquiryLevelId (from the 'INQLVL' table), Inqu
<?xml version="1.0" encoding="UTF-8"?>
The response produced will contain two unusual characteristics. Here is what it will look like:
<?xml version="1.0" encoding="UTF-8"?>
<Description>Level 4 Organization Obje
<ErrorMessage>The data submitted already exists on the database; no update appl
Because the transaction does not make any changes to the 'INQLVL' table itself – the last update date does not get changed and the transaction reports an error stating that the data has not been updated. However, the contents of the 'INQLVLQUERY' table shows that the changes have been applied and both the queries and the last update date have changed.
Custom rules should now work and transactions implementing these rules should return the contents of the default and extended fields.
Dany Drouin 270004VXKT Visits (788)
MDM AE pMDM with RESTful web services
Previously, interactions with MDM Operational server were possible with EJB/RMI, JMS, JAX-WS and JAX-
Possible payloads that are accepted are application/xml and application/json. JSON support was added in v11.4 FP1.
It is important to note that all REST interaction are using one RESTful service “MDMWSRESTful”, PUT method type only and accessed via URI http
The same xml request/response payload used for EJB/RMI is used for REST interactions.
For the full list of capabilities and supported request headers consult the following documentation link:
Interacting with MDMRESTful service
Here’s a sample client leveraging Apache Wink demonstrating an MDM RESTful call:
The above code will submitting an MDM xml payload and expecting back an xml response.
This is determined by the ‘Content-type’ and ‘Accept’ http header properties.
Here’s a look at a getParty xml payload and response:
The same request/response as JSON, using application/json, as both content-type and accept:
The default MDM JSON model is actually based on the core XML schema model (MDMCommon.xsd and MDMDomains.xsd). Internally, MDM will validate the JSON using these schemas.
We use a “Mapped notation” api to build the JSON. A couple things to note about this implementation:
Don’t want to write any code to test your MDM services?
Choose “PUT” as the HTTP method
curl --user "mdmadmin:mdmadmin" -X PUT
Doug Cowie 270005CYF0 Visits (476)
From version 11.4 FixPack 3 the MDM Application Toolkit has a new hierarchy widget, which replaces the now deprecated MDM Tree coach view.
This new widget, the MDM Hierarchy coach view uses the latest in web visualisation technology to render hierarchies in BPM coaches. As well as using this new technology the MDM Hierarchy coach view also has a new method of interacting with the MDM operational server.
To highlight some of the new features, this post presents a step-by-step guide of how to get up and running with the new MDM Hierarchy coach view. I will assume a degree of familiarity with IBM BPM, in particular Process Designer.
Step 1: Drag and drop the MDM Hierarchy coach view from the palette onto the canvas, it is listed under the MDMAT grouping.
Switch to the configuration tab. You will notice that most of the fields have default values. In the rootNodeId field enter the values for the hierarchy and a node in the hierarchy in the format <hie
Step 2: Press the “Run” button in BPM. This will launch a browser, showing the coach you have just created. The hierarchy will be visible, and should render data if it has been set up correctly.
That is all that is required to get the MDM Hierarchy coach view up and running.
The coach view has a set of other configuration options; please see the documentation for more details on the configuration options.
The MDM Hierarchy coach view can be augmented by connecting it to a set of other coach views, which provide pop-up dialogs with additional behaviour that complements the hierarchy. These are the MDM Hierarchy Dialog Add, the MDM Hierarchy Dialog Details, the MDM Hierarchy Dialog Error and MDM Hierarchy Dialog MultiParent.
While each of these coach views can be added independently, the instructions below will guide you through adding them all.
Step 1: Adding the other coach views.
Drag and drop the MDM Hierarchy Dialog Add, the MDM Hierarchy Dialog Details, the MDM Hierarchy Dialog Error and MDM Hierarchy Dialog MultiParent on to the canvas that contains the MDM Hierarchy coach view.
Step 2: Create a new MDM_
Switch to the variables tab. Create a new Private variable, call it “events”. Change the Variable Type to MDM_
Step 3: Configure all of the widgets to use the same, shared event framework. Switch back to the Coaches view. For each coach, select it on the canvas, then select the Configuration tab at the bottom.
Locate the EventFramework configuration option; click the purple button next to the label. Then click the Select button to the right hand side. Find the variable you created in Step 2 (events) and select it. Do this for each of the widgets.
Step 4: Configure the visibility for each of the dialog coach views; this step should not be performed on the MDM Hierarchy coach view.
Select the coach view, then click the Visibility tab at the bottom. Leave source as “Value” then press the purple button next to the Visibility label. Press the Select button, then expand the events variable, expand the appropriate event, then select the visibility entry. Each of the different dialogs should be configured against its specific event. The MDM Hierarchy Dialog Add should be configured to use the addNode event; the MDM Hierarchy Dialog Details should be configured to use the nodeDetails event; the MDM Hierarchy Dialog MuliParent should be configured to use the multiParent event; the MDM Hierarchy Error Details should be configured to use the error event.
Step 5: Click the “Run” button in BPM.
The tree now has additional behaviour, if you right click on a node a pop-up dialog should now appear that will display additional data about the node. The add button on this dialog will launch the add dialog that can be used to add nodes into the hierarchy. If a node in the hierarchy has multiple parents in the hierarchy an icon indicating this is displayed to the right of the node, the MultiParent dialog will be launched if that icon is clicked and allows users to re-focus the hierarchy on the different parent nodes.
This brief post has demonstrated how to use the new MDM Hierarchy and associated coach views. In future posts more advanced topics, such as replacing the ajax service which supply the data to the hierarchy, and how to create custom widgets that use the event framework will be explored.
S Eggleston 2700002CDU Visits (955)
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.
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