If you've used previous versions of the workbench, one of the first changes you'll hit is that you no longer need to run the developer environment setup tool when you create a new workspace. In version 11, no projects need to be imported into the workspace, and you use the same installer to setup a local test server on your development machine as you would to install a production system.
Full development environment install
If you have a completely clean machine, the simplest way to get started is to use the workbench typical install. This will install DB2, Rational Application Developer, and WebSphere Application Server, along with MDM Server and the workbench, i.e. everything you need for a full development and test environment in one go. Here's how to get everything ready to run a typical install...
Firstly, you'll need to download all the typical install images. The following part numbers are required for a full MDM Workbench v11 typical install:
CIM6NEN, CIM6PEN, CIR9NML, CIR9PML, CIR9QML, CIR9RML, CIR9SML, CIR9TML, CIR9UML, CIR9VML, CIE5FML, CIE5GML, CIE5HML, CIE5IML, CI6XNML, CI6XPML, CI6XQML
Important: If you are about to install MDM but downloaded the install images before 17th October 2013, you must download the product refresh first.
Once you have all the install images downloaded, the contents must be extracted into a specific dire
After extracting all the install images, open the install launchpad, which you can find in the MDM\disk1 directory (there are 32 and 64 bit versions). The typical workbench install link is right at the bottom of the launchpad:
When the install starts, you should be able to click through all the panels without changing anything:
Make sure you confirm that the IVT tests pass at the end of the install and, if they did, you're ready to start developing for MDM v11!
Note: you should change the defa
Workbench only install
If you don't want a local server to test changes on, installing the workbench is much quicker, since DB2, WebSphere Application Server and the server install are not required. In this case, you'll only need the following part numbers:
CIM7CML, CIR9TML, CIR9UML, CIR9VML, CIE5FML, CIE5GML, CIE5HML, CIE5IML
The launchpad doesn't support this scenario, so you have to install Installation Manager manually, add
Alternatively, you can use the Installation Manager command line to install Rational Application Developer and the workbench in one step. For example, assuming you extract the install images in the same structure as for a typical install:
imcl install com.
A typical install is ideal for demos or evaluating MDM but to set up developer environments I would recommend installing manually. You'll also need to do this if the typical install does not support your environment. The following blog post describes the manual install process:
There is also a wiki page with an up-to-date* list of install related information.
(* Please update it if it's not up-to-date!)
Nic Townsend 2700051ED4 Visits (2583)
This blog post details how to use the template models provided in MDM Workbench to create and deploy a new Virtual Configuration Project to an Operational Server, and then deploy the sample data supplied in the template model.
Creating a new Virtual Configuration Project
Creating a connection to the Operational Server
Deploy the new Configuration Project:
Processing and loading the sample data:
Mike Cobbett 11000061J8 Visits (2870)
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
bakleks 270007PVJ3 Visits (1446)
This document outlines how Physical MDM customisations can be built from source artefacts in an automated build and test system. This document does not aim to be a complete guide on this topic, but rather to point the way to how some detailed steps can be implemented using examples.
The MDM Advanced or Standard editions both include the MDM Workbench. In version 11.0 and beyond the MDM Workbench is used by solution developers to create artefacts which customise the MDM solution for the physical, virtual and hybrid implementation styles. These source code artefacts are typically built into a Composite Bundle Archive (CBA) and deployed to WebSphere where they augment the functionality already available in the MDM Server Enterprise Business Application (EBA).
A good practice amongst MDM solution developers is to create an automated build process such that customisation source code is checked-in to a code control repository, and an automated build process takes those source files and builds the CBA ready for deploying onto post-build test systems, placing built artefacts into a second repository or shared file system.
Some automated systems take this “build” concept further, by automating the deployment of such built artefacts to test systems, which in turn report back on the “health” of the build, how many tests passed and failed, and generally quickly provide valuable feedback to developers whether recent changes broke the solution or not. Project managers overseeing such projects are able to reduce project risk by adopting this continuous delivery processes, and changes to MDM solutions become more reliable and safer as a result.
To add MDM solutions to such a continuous build environment it is necessary to:
This article is mostly concerned with step #7 – building source artefacts.
2. Materials and prerequisites
This article is accompanied by a collection of example scripts. We do not intend that these are used directly, but as an example of how you may wish to implement your own automated build process.
The current solution consists of four main files:
In order for the scripts to work, the machine running the scripts needs to have the following products installed:
To run the Ant scripts the user needs to run mdm_wb_build.xml as a build file.
The script contains only the “runBuild” target.
The target checks that necessary properties, such as Eclipse Home, date and time stamps and output folder prefix are set. Provided these properties do exist, it creates a folder based on OutputFolderPrefix and date and time, within which “logs”, “CBAExport” and “workspace” folders are created.
The logs folder contains “MDM
generateDevProject: BUILD SUCCESSFUL
workspaceBuild: BUILD SUCCESSFUL
exportCBA: BUILD SUCCESSFUL
End of report.
The CBAExport folder contains all of the exported CBAs.
The workspace folder contains a local copy of build artefacts.
After the directories have been created, the script checks which operating system it is running on and sets the isLinux or isWindows property to “true” as appropriate and calls either runAnt.sh or runAnt.bat to run a headless Eclipse process. The relevant file (either the batch or the shell script) should be available by default in the bin directory in the Eclipse installation directory.
The runAnt script then sets up the log files, environment variables and runs a second script “mdm
3. Step breakdown of the automated build and test system
Given that automated building and testing of MDM solutions is a worthwhile goal, the following sections provide some guidance in some of these areas where actions specific to the MDM tools and development/build environment are necessary, and some points of discussion are presented where choices exist.
3.1 Identify the pieces of the solution which represent the “source code” for the solution.
The source code for an MDM solution will be made up of a collection of Eclipse projects and their contents. MDM development, MDM configuration, MDM hybrid mapping, MDM service tailoring, MDM custom interface, MDM metadata and other MDM-specific projects types. CBA projects will add to the list.
MDM Development projects contain a “module.mdmxmi” file, which contains a model of the customizations which the project aims to create. This file should always be considered to be source code.
At some point the mdmxmi file will be used to generate Java, XML, SQL and other file artefacts, and there are a few different approaches you can take for these files:
The current solution is to only consider files which have been manually changed as “source code”, and “generate artefacts” from the mdmxmi model as part of the automated build process itself. This approach demands that the MDM workbench tools are installed as part of the build environment, because the “generate artefacts” process that turns .mdmxmi files into other artefacts will be a necessary part of the build process.
A project “MDM
3.2 Create a source code repository.
There are many choices regarding which product to use as a source code repository and covering them is not the aim of this document.
3.3 Recognize when a consistent set of code has been checked-in, at which point a “build” is started.
This event may be triggered manually, automated overnight, or whenever a change-set is delivered to the code stream. The capturing of this event is often specific to the code control system being used, though some solution teams augment this by adding a web page that enables build requests to be manually requested.
3.4 Create a build environment.
A build environment should include RAD (or RSA) which can be called in a “headless” manner such that functionality within RAD can be used without a user-interface being present.
MDM Workbench will be required in addition to RAD to perform a complete build of “module.mdmxmi” files.
For the list of platforms that MDM Workbench v11.0 and onwards support – refer to the product release documentation.
3.5. The build environment “boot-straps” itself.
A small script is responsible for “boot-strapping” the process by it checking-out the other build scripts which in turn build the artefacts from solution developers.
3.6 The build scripts check out the artefacts from code control to the local file system.
These actions are specific to the code control system so will not be discussed further here.
3.7. The source artefacts are processed, transforming them into built artefacts.
This phase of the automated system typically consists of a hierarchy of Ant files which decomposes the overall build process into many smaller steps and “Ant targets”. The Maven framework is a common choice of technology to oversee this phase.
These Ant files can be categorized into two types:
For a detailed walkthrough of specific implementations of the build process refer to the Ant scripts provided with this blog entry.
3.8. The build process often executes “unit tests” to further validate that the solution artefacts are healthy and do what they are expected to do.
The tools and approaches used to execute unit tests vary widely dependent on technology choice. Simple Java JUnit tests offer one simple solution, which can be invoked with scripts once the tests and tested code are built.
3.9 Built artefacts are published to a repository.
Every build against which build metadata can be gathered and reported is versioned by the publish process. Build logs, unit test results and results of other tests indicating the “health” of the build are gathered and published to the repository as well.
Products such as Rational Asset Manager can be used here, or for a really basic solution a simple shared folder on a network drive may suffice.
3.10 Automated deploy and test health of overall build.
If the build is considered “good” then further automation can be added to deploy the built solution to a test environment, with higher-level tests (functional and end-to-end system tests) exercising the solution further. Such tests can also report back to the build repository on the health of each build.
The automated deployment of entire systems for testing is often one of the most complex areas of the whole continuous development process. Products such as Rational Urban Code Deploy (UCD) can be used for this stage of the process, though for some environments a set of (reasonably complex) scripts might be sufficient.
For the MDM pieces, we are mostly concerned with deploying and un-deploying SQL scripts, depl
Prior to deploying extensions to the server, it is often necessary to modify the database. This is possible using the SQL scripts found in the MDMSharedResources project in the built workspace. Rollback scripts in the same location should be applied once testing is complete to reset the database back to a known good state.
For CBA deployment, Jython scripts can be used to manipulate the WebSphere server. Detailed documentation of these steps can be found in the WebSphere documentation.
Nic Townsend 2700051ED4 Visits (2230)
MDM v11.3 leverages IBM BPM technology to provide a data stewardship framework under a single UI. However, it may be desirable to modify this UI to match the look and feel of your existing solutions. While BPM Process Designer allows you to restructure page layout with the Coach designer, the best way to modify the look and feel of a Coach is with CSS.
BPM provides three ways to alter CSS out of the box from within Process Designer:
However, there are occasions where these approaches are not suitable:
The ideal way to insert CSS into a Coach would be to load the CSS as a managed file in BPM - that way you only need to edit the managed file and all Coaches that reference the CSS would use the latest version (pending updated snapshots). Unfortunately, BPM does not offer the mechanism out of the box.
Update 05/11 - If you upload a HTML file to BPM that consists of <style> tags wrapping the CSS, you can use the "Managed File" option of the Custom HTML component to load the "HTML" CSS into the Coach. However, this does not work if the HTML file is inside a .zip archive, or if the CSS needs to reference local resources.
By using this method call, you can get a relative URL to the managed file in BPM - eg
Using the above technique, I created a HTML file containing a <script> that would create a link to the URL for a CSS file in the document's <head> element. I then used the "Managed File" option on a Custom HTML component to load the script into a Coach. This meant that my CSS file was referenced inside the <head> element.
You can use this principle to load your own custom CSS files into a Coach. Custom CSS files can be used to override BPM Coach Views or Coaches, or alternatively CSS files can be used to override the MDM Coach Views supplied with MDM V11 onwards.
As an example, I present an updated solution to:
Dave_Kelsey 100000BGBR Visits (1906)
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
From an early MDM Workbench news site, the MDM Developers community has evolved and grown to a group of over 200 members, and it would be great to take a break from the usual posts and forum discussions to find out more about some of you with a quick blog interview. Whether you're a new member or a long term contributor, please say hi and tell us a little about yourself.
Feel free to leave a comment and answer any of the following questions that resonate with you, or add your own questions instead. This is just a casual blog interview and meant to be more like a real world conversation, rather than a formal resume or biography!
For fun, and a bit of encouragement, I have a few limited edition MDM Developer community stickers to give away!
Here are a few questions to get you started:
Update: Unfortunately no one replied in time to claim the ticket that prompted this blog post. Luckily if you're one of the first to reply, you could still get one of these, much more exclusive, MDM Developers stickers!
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 (2049)
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....
S Eggleston 2700002CDU Visits (307)
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.
You may have seen the recent tech talks that the team here have been producing for our clients. In these tech talks an IBM expert will talk through a specific MDM topic in great detail sharing the deep expertise of the architects and developers that are living and breathing the technology. These tech talks are provided for free and just require a simple registration process to allow you to attend. All sessions are recorded and replays will be available shortly afterwards.
One area of keen interest to our clients has been concerning the Stewardship and Governance capabilities provided by MDM, specifically the IBM Stewardship Center, that was released in MDM 11.3. So it falls to me to host the next MDM tech talk on June 23rd. In this session I will be discussing the new capabilities offered by the IBM Stewardship Center, how we are changing the game for stewardship teams looking to evolve their organization to be more reactive to data quality events, engaging line of business users to provide input to data quality issues and adding advanced business rules and intelligence to automate events from across the entire data quality landscape.
A one hour tech talk is no where near enough time to do such a broad and important area justice however, we will spend some time up front explaining IBM's perspective on Information Governance and how IBM's InfoSphere portfolio provides the market leading integrated suite of comprehensive governance capabilities that can flex to suit your specific industry requirements. We will dive into the IBM Stewardship Center and its comprehensive workflow engine, providing collaboration and orchestration across the enterprise and touch on the MDM Application Toolkit, a suite of accelerators designed and built by some of our development ninja's to make creating custom governance workflows and quick and easy experience....and if we have time we may even have a live demo of the latest version of the Stewardship Center. During the session the live chat will be open allowing you to ask questions and I will have a team of experts ready to respond in real time.
If your organization is trying to address the growing focus on Information Governance, if you are trying to figure out how to make your Stewardship organization more efficient, or you just wanted to take a look at one of the coolest new features from the MDM team then don't miss the Mast
As of version 10.1, MDM is secured by default. This means that using the Web Service Explorer to test your web service will not be possible. Whilst there are many web service testing tools out there like SOAPUI, there is one that is included within the MDM Workbench that you can use, the Generic Service Client. The following steps detail how to invoke the required MDM web service :
This will then open the following editor :
The responses are saved and can be rerun, but if you want more functionality you'll probably need to look at Rational Performance Tester
InfoSphere Master Data Management operational server v11.x OSGi best practices and troubleshooting guide
Dany Drouin 270004VXKT Visits (2109)
InfoSphere Master Data Management operational server v11.x OSGi best practices and troubleshooting guide
Note: This preview only covers the initial set up of the MDM Workbench. The
The goal of this article is to show best practices and optimal development practices for developing with the InfoSphere MDM operational server. We will discuss common OSGi patterns, troubleshooting, including failures and resolution, as well as how to best deploy MDM composite bundle (CBA) extensions.
The InfoSphere MDM version v11 operational server is based on an enterprise OSGi architecture, which is modular in nature. The benefits of a modular architecture application design include reducing complexity, reducing time to delivery, and increasing serviceability. The Java EE infrastructure leveraged in previous versions of InfoSphere MDM had limited ability to enforce or encourage a modular design.
The advantage of a modular MDM application is to allow customization to be deployed without having to alter the core MDM application. Instead, customizations are attached in the form of extensions to the core MDM application. This is done using composite bundles, or CBA files.
Optimal workspace operational server configurations
The InfoSphere MDM Workbench is a tool that supports development of customizations and extensions to MDM operational server. The MDM Workbench allows you to define the desired data model and transactions and then generates the code required to implement the MDM Server extensions.
When using workbench to build and deploy your MDM customizations and extensions, there are a few workspace configurations to consider for achieving the best performance and development experience.
ThomasRogers 270006MA78 Visits (1780)
Whether you're already familiar with the Workbench or completely new to it there are a lot of new changes in v11. So why not check out the MDM
There's also a major new addition to the Wiki if you're looking for more information on installing MDM on Linux head over t
jtonline 110000B6Y8 Visits (1882)
Before the MDM Developers group got going a few authors from the IBM development team posted on the MDM Workbench blog. Now that this group blog has a few posts as well it makes sense to combine the two, so we won't be posting to the separate MDM Workbench blog in the future.
This blog is for more than just the workbench but the biggest advantage is that it is much easier for anyone to contribute: any member of the group can write a blog post! If you have something to share that you think the community would find useful, give it a try. It's a great way to get early feedback on something that may turn in to a full developerWorks article over time. If you do write a post, just let me know as soon as you are ready for it to be published.
These are just a selection of some of the popular posts from the old blog:
And don't forget, there are still forums available for questions and discussions:
MDM –WebServices Security enablement and validating request with backend LDAP on WAS
This document is step by step documentation to setup and turn on Global security for InfoSphere MDM:
1. MDM server using LDAP on WAS Enabling Global Security for WAS BASE Edition
Log into the WebSphere admin console
Enabling Global Security for WAS ND Edition
Log into the WebSphere admin console
The port number is the port for that specific profile, server1 for that profile needs
to be started in order to access the admin console
2. Start server and rite click on server, select “Administration”, after that click on “Run administrative console
3. This will start administrative console
4. Click on Security tab and then click on the global security
5. In WAS7.x Click on Security tab in the left hand and then select Global Security under it, at rite hand side click on “Enable administrative security” By default all three security options are selected, deselect the two other options then “Enable administrative security”
6. IN WAS6.x, Click on the “Security -> Secure administration, applications, and infrastructure” then at the rite hand side click on “Standalone the LDAP registry”
7. Select Advanced Lightweight Directory Access Protocol (LDAP) user registry settings under the additional properties options group
8. Configuration of the LDAP details by filling in the required details we can get these from the administrators
9. Save the configuration by clicking on Save
10. Configure the contents taking input from the Administrators as per your client setup
11. Save the configurations by clicking on the save button
12. Once details are filled first check the connection by clicking on the test connection
13. Save the configurations by clicking on the save button
14. If the connection is tested and it is successful we can enable the security but make sure to uncheck the ‘Use java 2 security’ we don’t need this in our configuration
15. Save the configurations.
16. Save changes to master configuration. Restart the server. This will enable the global security in your WAS and it will start expecting the user authorization data name/password
17. The next step is to create the WAS security enabled MDM ear.
By default the security is enabled in the MDM ear, in case it is disabled we can ENABLE it by following the below step
On the RAD console click on ctrl+R this will open window listing all the files containing *.xmi. This will also have file having enable and disabled contents. To enable the security just copy the content in file .xmi
18. Once the security is enabled MDM.ear can be published to test our connection with proper user id and password from SOAP UI
19. The next step is to make our SOAP request changes to accept authentication data (use
20. Download the SOAPUI, and install it.
21. Start SOAPUI and select the option “New Soap UI Project” after clicking on File option
22. Now select the appropriate WSDL, depending on service, for example party related services I have select PartyService.wsdl at “C:\
23. Open appropriate service and in SOAP UI and select Aut tab at the bottom of the request :
24. This will pop up a window where we can enter the details as configured for your LDAP user details and password
25. Rite click on the SOAP request and select “Add WSS Username Token” this will pop up a window where select the “password text option“ this will generate the soap header with security information in it.
26. Fill in the remaining fields in it, it will generate the SOAP request as mentioned below.
27. Test the service with SOAP authentication containing data.
jaylimburn 2700028UUJ Visits (1220)
I recently found myself in a tricky situation. I had built a demo using a back level version of the MDM Standard Edition engine. I had beautifully created some dummy data specific to the demo, which included a lovely complex set of h
Here are the steps:
This saved me a huge amount of time in my specific scenario and stopped me having to remember how to configure the Individual sample data and link the enti
cgriffin 120000CMTR Visits (1574)
With MDM Workbench 9.0.x, you may find that web service deployment classes are not generated for data extensions. This causes runtime errors when invoking web services affected by data extensions, typically a class not found error referring to a class name with suffix _Ser, _Deser, or _Helper. Classes with these names should be generated when you run Prepare for Deployment on WSEJB projects. If these classes are not generated, the web service won't work.
To resolve this error, right-click on PartyWSEJB (you need to repeat this for each affected WSEJB project), select Properties. Select Project Facets. Check the facet: WebSphere EJB (Extended). Save changes, and run Prepare for Deployment on the WSEJB project.
I have added this information to the MDM Workbench FAQ. Thanks to Bark Bakker, for finding the workaround.
If you know of a good solution to a common problem, then please do add it to the MDM Workbench FAQ so that other users can benefit. And if you are having problems, please look at the MDM Workbench FAQ before posting to the MDM Workbench newsgroup, as you may find an answer there.
RaymondMari 0600011YW5 Visits (1448)
Requirements for Developer Machine
Developers working with the MIH Workbench require a large software stack. This requirement can
have resource implications for the hardware used by the development team. It is recommended that
each developer's machine meet the following specifications:
One of the following;
· Windows 7
· Windows XP
One of the following;
· IBM Rational Software Architect v7.5.4
· IBM Rational Application Developer v7
· InfoSphere Master Information Hub (MIH) Workbench plugin
· InfoSphere Master Information Hub distribution file MIH9
o VMware workstation v8
o One of the following
When possible, it is recommended that developers use a 64-bit version of Windows
running on a Virtual machine with up to 4GB of memory. MIH Workbench can work
with less powerful hardware, but productivity may be impacted by the demands of the
large software stack.
Doug Cowie 270005CYF0 Visits (308)
Have you ever tried to start a BPM server on linux only to be greeted by the following incomprehensible error?