Doug Cowie 270005CYF0 Visits (922)
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.
Mike Cobbett 11000061J8 Visits (3696)
MDM Workbench v11 is here !
With huge pride, we have just shipped the version eleven of MDM, including the new unified MDM Workbench v11. It's been nearly 2 years in the making, and represents the biggest change to the MDM tooling in recent years. In this article we outline these changes and give the reader familiar with previous MDM tools a gentle introduction to what they can expect when they get their hands on the new tools.
The main changes made for v11 workbench can broadly be categorized under the titles unification, simplification and integration.
Unification is a drive to combine the tools from the v10.1 standard edition (formerly Initiate tools) and the tools from the v10.1 advanced edition into a single set of tools which run in the same Rational Application Developer (RAD) environment. Where the tools were inconsistent, or overlap existed we adopted common approach to make sure both sets of tools work together in a unified tooling environment.
An example of unification: Consistent use of the perspectives, showing the new MDM development perspective.
We want all the tools to be simpler. We aim to cut the time it takes to get value out of the MDM platform; automating where possible to relieve solution developers of repetitive tasks and reducing the amount of knowledge needs to get something working.
Toward this goal the workbench has made these changes :
An example of the way version is simpler can be seen by comparing a version 10.1 workspace against a version 11 workspace:
"No man is an island" as the saying goes, and the same is true for products. MDM tools now play a wider role in enabling the ingestion and distribution of information in an MDM solution.
Enhancements in this area include:
For example: Our list of export wizards has been expanded to help push MDM metadata to more remote systems.
In summary, we hope you like the changes we've made to the tools, and hope you find that creating, configuring and developing an MDM solution is now quicker and easier than ever before.
For more detailed information, and a complete treatment of the MDM version 11 release, please refer to the info
Dave_Kelsey 100000BGBR Visits (2441)
No results found is a common response to a search request, but how do you detect this in your BPM process ?
A “No Results Found” situation causes an exception to be thrown which means you can detect it using an intermediate error event, but you need to be able to handle a real errors as well as a no results found which is a special kind of exception.
Here we have a simple example of a search human service which applies equally to Physical and Virtual MDM Server.
There is an intermediate error event attached to the do search nested service that calls the MDM Search integration service. The gateway decision determines whether it is a no results found or not.
To determine how to configure the decision gateway we need to have a look at the format of the exception we get when a no results found is generated and this differs slightly between virtual and physical MDM Server.
Handling a Virtual MDM Server response
A sample of part of the xml format of the exception is shown here
Here is is the reason code we are interested in. So the decision gateway configuration looks like this
The decision logic being
extracts the reason code and checks for ENOREC.
Handling Physical MDM Response
The implementation remains the same, the test within the decision gateway needs to be altered as the location of the reason code is different to virtual. In this example the reason code that is checked is applicable to a Party or Person Search, however it is possible that the reason code will be different for different types of physical search.
A sample of part of the xml format of the exception is shown here
Here we see the reason code we are interested in is nested under the <errors> tag within an < element>.
So in this case we need the decision logic to be
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.
jaylimburn 2700028UUJ Visits (2731)
I mentioned in my developerWorks status at the middle of last year that I was working on a redbook on MDM and BPM integration. Well I am pleased to announce that this redbook has now finally been published!
The redbook titled : 'Aligning MDM and BPM for Master Data Governance, Stewardship and Enterprise processes' provides a detailed insight into the business benefits of running MDM and BPM projects side by side. It explains how combining the benefits of IBM InfoSphere MDM and IBM Business Process Manager to provide a platform for Master Data Governance and Stewardship, providing you with an industry lead
We'd love to hear what you think....
Doug Cowie 270005CYF0 Visits (1260)
Have you ever tried to start a BPM server on linux only to be greeted by the following incomprehensible error?