bakleks 270007PVJ3 Visits (95)
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 (486)
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 (302)
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 (595)
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:
Verify AppServer status
If the target AppServer is not in full health, this affects the availability of the JMX connection. Review the SystemOut.log or HPEL logs: if possible restart the AppServer first to make sure you have startup messages:
If the MBean has started successfully, you should see messages like this:
If the MBean has not started, you may see messages like this:
Here are some suggestions of possible causes: note that this list is not exhaustive
In many cases you will be able to fine technotes or other links on the internet with information about how to resolve these kinds of errors.
If you are not able to resolve issues in SystemOut / HPEL, contact IBM support, and include a copy of the AppServer logs.
New configuration: verify port / host settings
If the AppServer is healthy, and you have found the success message below, there may be a configuration problem.
Review the port and host configuration in the workbench
Doug Cowie 270005CYF0 Visits (484)
Have you ever tried to start a BPM server on linux only to be greeted by the following incomprehensible error?