jtonline 110000B6Y8 Tags:  mdm-developers community mdm-workbench group blog weblog 1,838 Views
This blog itself replaced an earlier website for sharing MDM Workbench news and now it's time to move on again. In fact, this move was prompted by the MDM Developers community which I am really excited about: Raymond discovered that anyone in the MDM Developers group can use the built-in group blog and posted something to help the community. So while there haven't been any posts here this year, there are already a couple of workbench posts on the group blog. Even better, the new blog is better suited to a much wider range of topics and, because anyone in the community can post, it can keep pace with the evolving nature of MDM development.
Please update your feed reader and bookmarks with the new MDM Developers blog!
jtonline 110000B6Y8 Tags:  ear mdm-developers rational mdm-workbench teamshare draft rsa workspace rad projects 2,545 Views
It's great to be able to kick off the new year with another article from Catherine Griffin. This is a draft which has already proved popular on the MDM Workbench forum, so I'm posting it here with some minor updates which Catherine has added to the Web Services and Extensions sections. Please leave a comment if you have any feedback.
Optimizing your MDM Server workspace using binary modules (DRAFT)
Catherine Griffin, December 2011
IBM Infosphere Master Data Management Server provides a complex data model for Party, Account and Product master data and a large number of services (known as transactions) for querying and modifying master data records. A variety of extension mechanisms are supported to allow the data model and transaction behavior to be customized, or to add completely new transactions if required.
MDM Server includes MDM Server Workbench, tooling which supports development of extensions to MDM Server. The workbench allows you to define the desired data model and transactions and then generates the code required to implement the MDM Server extensions.
MDM Server Workbench is installed as an add-on to Rational Application Developer (RAD). To develop extensions to MDM Server, you need to import into the RAD workspace the MDM Enterprise Application Archive (EAR).
The default development environment setup results in a large number of projects being created in the workspace. 55 projects are created when importing the MDM EAR, and then on top of that you may be creating a number of additional projects for extensions.
The large number of projects in the workspace can be confusing and adds to the overhead of building the code, managing it in source control, and deploying the code.
In this article, I will describe how you can reduce the number of projects in the workspace by changing some of them into binary modules.
The instructions given here apply to the MDM Workbench with MDM Server 9.0.1 (WebSphere version) on RSA 184.108.40.206. If you have different versions, the approach should still work but there may be some differences in the user interface.
Development and Test Environment Setup
Use the MDM Workbench Development and Test Environment Setup wizard to set up your development environment to start with.
When DEST has finished, there are 55 projects in the workspace.
Some of these projects are used for the initial set up of the MDM Server but are not part of the MDM EAR. You do not need to have them in the workspace once the development environment is set up.
Once you are satisfied that your development environment is set up correctly and the IVT is passing, then you can close the following projects:
Closed projects remain in the file system but are by default not visible in the workspace. You can re-open closed projects if you want to re-run the development environment setup later.
Setting up Shared EAR development
Now, in the folder MDM/.settings, create a file named com.ibm.etools.j2ee.teamshare. This is a marker file – the contents do not matter, only the name.
The MDM project contains a number of JAR files which are the modules of the EAR. Some of these are expanded into the workspace as projects, which allows you to modify the files they contain. When the MDM EAR is exported or published to the server, the projects in the workspace replace the JARs in the EAR.
Normally, if you delete a project from the workspace which is an EJB module, Web module or Utility module, then the module is removed from the EAR. But once the teamshare marker file is in place, deleting a project will not remove it from the EAR. As long as the module JAR file is still present in the EAR, the EAR will function just the same as before.
This means that now you have added the teamshare marker file to the EAR, you can delete from the workspace out-of-the-box projects that you don't actually need for extension development. Note that when you delete a project, Eclipse asks if you want to also delete the files from the file system – generally, it is a good idea to delete the files.
A bit of terminology – the JARs in the EAR project are called binary modules.
Working with binary modules
If you have a project in the workspace which is new or modified and want to change it into a binary module, right-click on the MDM project and select Java EE > Repackage Projects to Binary Modules.
The packaged JAR includes any Java source files that were in the source project, but it won't include other files such as a module.mdmxmi file that was in the project root.
The binary module JARs are not automatically updated when you modify the source projects.
If you need to modify files in a binary module, you can just import the project into the workspace from source control and start working with it. If it was an out-of-the-box project which you deleted from the workspace, then to recreate the project, right-click on the MDM project , select Java EE > Extract Binary Modules to Projects.
If you delete from the workspace a utility JAR project, such as BusinessServicesWS, then the corresponding EJB project disappears with it. When you add it back, the EJB project comes along.
Deciding which projects are required
Projects you definitely don't need
The following projects in the workspace are modules that do not need to be expanded as projects:
These projects can now be deleted from the workspace – delete the files from the file system too.
Which of the out-of-the-box MDM Web services are you planning to use in your deployment ?
If you do not intend to use MDM Web services at all, then you can delete from your workspace all projects with names ending in WS, WS_HTTPRouter and WSEJB. If you do this then when you create new module projects you must disable web service generation.
If you do not intend to use the EvaluateTermConditions web service, then the CrossDomainServices* projects can be deleted from your workspace.
If you are using Web services and the test server has security disabled, you will need to modify the WSEJB projects to swap in the _SecurityDisabled versions of the WebSphere deployment descriptor files.
You should keep the WS, WSEJB and WS_HTTPRouter projects for the same module together – all in the workspace, or all as binary modules.
What extensions to MDM Server are you planning to develop?
Depending on what kinds of extension you are developing, some of the out-of-the-box projects are required in the workspace. Projects which are not required can be deleted.
The following projects are always required:
We recommend that you also keep the projects:
If you are generating web services, then you need DWLCommonServicesWSEJB.
If you have references to out-of-the-box entities and are generating web services, then you need the WSEJB project which contains the WSDL files for that entity.
For example, if you introduce a new transaction taking Person as the request object, the PartyWSEJB project is required.
If you are generating web services, then you need DWLCommonServicesWSEJB.
Identify the out-of-the-box modules which define the entities that you are extending. For example, the Person entity is located in Party. Grouping is located in DWLBusinessServices.
Whichever module you are extending, you need all the projects related to it in the workspace. For example, if you are extending Person, that means the projects:
You could do without the WS projects if you are not using web services.
If you are creating a data extension, for example to Person, then the workbench will generate updates to the Party web services to handle the extended data. If you don't want this done, then disable web service generation for the module.
The Party web services are not the only web services affected though, because Person data can also be used in the FinancialServices and Product web services. The workbench will also re-generate these web services if they are in the workspace. If you don't want these web services to be regenerated, you should delete the WS, WS_HTTPRouter and WSEJB projects from the workspace.
If you were extending Person and are accessing Person records with the FinancialServices web services, then you need both the Party web service projects and the FinancialServices web service projects in the workspace – but you could omit the Product web service projects if you don't use those services.
For each WS project in the workspace, you also need in the workspace all the WS and WSEJB projects for the modules listed in the table below in the column Depends on web services.
These are the dependencies between the web services:
Create new module projects as usual. If you do not want to generate web services for the new module, then disable web service generation by editing the mdmgen.xml file before generating code for the first time.
When you generate code, if any errors occur or projects with the same name as out-of-the-box projects have been created in the workspace unexpectedly, then you have deleted from the workspace a project that was needed by code generation. Review which projects are required and correct any problems.
To recover an out-of-the-box project which you may have deleted in error, right-click on the MDM project , select Java EE > Extract Binary Modules to Projects.
Disabling web service generation for a module project
To do so, edit the mdmgen.xml file and locate the line:
<target name="all" depends="sql, implementation, createReferenceModel, webservices, merge" description="--> description">
and change to:
<target name="all" depends="sql, implementation, createReferenceModel, merge" description="--> description">
Save the change and generate code as usual.
Team development process
If different team members are working on different module projects, does everyone have to have all the projects in their workspace, or can each team member just have the projects they are working on?
Every team member should have in their workspace all the base module projects. They don't necessarily need the generated projects for every module – some could be present as binary modules. Note that if you want to do this, you will need a process to ensure that the binary modules are updated regularly from the source projects.
You also need to keep track of the dependencies between modules, which can be complicated (particularly with web services). When deciding which module to add new extensions to, trying to keep these dependencies as simple as possible is a good aim.
Circular dependencies should be avoided!
To generate web services for ModuleB, ModuleAWSEJB is required in the workspace if:
The project ModuleAWS_HTTPRouter is only needed in the workspace if you are generating web service code for ModuleA – in which case, you need all three of the ModuleAWS* projects.
If ModuleA defines a data extension, and ModuleB defines another data extension against the same out-of-the-box module (for example, one extends Person and the other extends Address), then both the projects ModuleAWS and ModuleBWS must be in the workspace when generating code for either. Generally, I would recommend keeping all the data extensions targeting the same out-of-the-box module in one module.
Otherwise, the project ModuleAWS is only needed in the workspace if you are generating web service code for ModuleA.
If your module defines subtypes, then the EJB projects for all of the referenced supertypes must be in the workspace. I would recommend keeping the complete subtype hierarchy in the same module (that is, the root supertype and all its subtypes), as generating web services is not supported otherwise.
I've been writing a tutorial for developerWorks on the topic of how to implement custom query transactions for MDM Server. If you are extending MDM Server this is something you are quite likely to want to do but if you are not familiar with the MDM Server transaction framework you may have trouble figuring out how to get started. The tutorial explains the concepts you need to know in order to develop custom transactions and gives step-by-step instructions for implementing three example transactions illustrating different techniques. This isn't intended to give guidance on best practice and it won't tell you how to solve every problem - but it should help beginners to get to grips with the concepts and the MDM Server framework.
Update: Catherine's article has now been published on developerWorks: Implement custom query transactions for IBM InfoSphere Master Data Management Server
jtonline 110000B6Y8 Tags:  mdm iodgc iod11 conference mdm10 iod information-on-demand 2,101 Views
The wait for Information On Demand 2011 is almost over!
Over the last week Mastering Data Management has been posting about the Master Data Management v10 announcement ahead of IOD, but next week you'll have the chance to find out even more and get hands on with the new features!
If you're at the conference, Anju Willard has sifted through the full MDM roadmap and picked out her top “Must-Attend” MDM sessions, and David Corrigan recommends spending some time in the InfoSphere Demo Center (MR04 in the Expo). If there are any other sessions you think should be a must-see, please leave a comment below and share the details.
In addition to Jay showing the MDM Application Toolkit on station 17 in the InfoSphere demo room, these a just a few sessions you might want to look out for in particular:
For the first time the MDM Developers group is also making an appearance at IOD! Check out Getting Technical: Resources for MDM Developers for more information, or just stop by at the developerWorks booth for a chat: 309-10 on the trade show floor. There are two social media lounges, Connect and Share, which would make an ideal place to meet up with fellow developers if you get the chance. Leave a comment below if you want to arrange a time and place, and grab an exclusive MDM Developers sticker from Jay (station 17 in the demo room) to help pick people out of the crowd:
If, like me, you're not able to be at IOD in person, you needn't be left out; the Information on Demand social media agregator is your window into the social buzz from the conference floor! Plus the IBM Software Channel will be showing the keynote and other general IOD sessions.
It should be an exciting week where-ever you are!
jaylimburn 2700028UUJ Tags:  mdm iod11 applications application toolkit iod powered 2,185 Views
Check out the latest blog entry from Alex Eastman, IBM Product Manager responsible for the new MDM Application Toolkit and find out where you can see the Application Toolkit at Information On Demand 2011:
Update: If you're attending IOD, you can also check out the MDM Application Toolkit in the InfoSphere demo room, where you'll find Jay at station 17.
jtonline 110000B6Y8 Tags:  debugger mdm-workbench mih-workbench test eclipse mih-server websphere mdm-server debugging remote debug 1 Comment 4,576 Views
I recently came across a situation where an MDM extension was working in the local development environment, but was failing on a remote test server. Bharat posted a remote debugging tip on our internal team blog a couple of years ago which can be useful when this sort of thing happens.
If you're using a remote server instead of a local development and test environment, as described in an earlier post, you may be able to simply restart the server in debug using the Servers view in the same way you would for a local server, as shown below:
If that's not possible, for example you need to debug something on a test server, you'll need to restart the server in debug or ask someone to do it for you. In the WebSphere administration console, click Servers > Server Types > WebSphere application servers and select server1. Click on Debugging service under Additional Properties. Check the Enable service at server startup option on this screen:
Note that I'm not using the default port here, which would be 7777 according to the documentation. Restart the server before continuing.
You should be ready to connect the debugger from your workbench using a new debug configuration. Click on the Run > Debug Configurations... menu option and create a new Remote Java Application configuration as shown below:
If you're debugging a specific project, enter it now, otherwise leave the project field blank. Before clicking Debug, make sure you provide the correct host and port details for the server you configured earlier.
jtonline 110000B6Y8 Tags:  video mdm screen-cast mdm-developers screen-recording demo mdm-workbench 3,017 Views
A few people have asked whether there are any recorded demos of the MDM Workbench in the past. I've never found one so, after a bit of experimenting and far too many attempts for such a short clip, I've uploaded the least embarrassing take to developerWorks! This is just a general overview of the workbench to get some initial feedback:
Is this kind of video something that you would find useful, as a series showing how to perform specific tasks in the workbench for example? If you have any suggestions or feedback, please leave a comment below.
The recording is also available to download from the MDM Workbench file collection if it doesn't appear above. (Note: if you have any problem with a missing codec, try updating to a newer version of Windows Media Player. Version 11 should work on Windows XP.)
Update: the video is now also available on YouTube!
Two of the MDM Workbench blog authors have recently moved on and I'd just wanted an opportunity to thank Iain and Matt for their contributions.
Without their great work this blog would certainly not have got off to such a flying start. Here are just two examples of some of their most popular articles:
It's no coincidence that there has been a short break in posts here so I'm on the look out for volunteers to join the team, or to contribute guest articles. Do you use the MDM Workbench and have any stories to share? Are there any tips that would help others? Do you know any MDM Workbench gurus who might be willing to write an article? Please get in touch!
So thank you once again to Iain and Matt, and I hope to be able to introduce some new authors in the future.
Photo © Gisela Giardino (CC BY-SA 2.0)
jtonline 110000B6Y8 Tags:  configuration windows7 faq wiki workbench directory path windows mdm-workbench length dest install folder name test-connection names database mih-workbench directories setup 3,585 Views
On the subject of the FAQ, don't forget that anyone in the MDM Developers group can edit it, so if you have any other tips to share, please do.
What directory names should I use to avoid problems?
There are a number of issues that you may encounter related to the directories used to install software, as well as your workspace location. For example:
To avoid these problems, you should use short, simple, directory names. For example:
Why does testing the database connection cause an error?
You may see the following error when using the "Test Connection" button:
This problem can occur for a couple of reasons: either the RSA install directory contains special characters (see details above) or the system path environment variable has exceeded the Windows limit. If the directory name is not the problem, check whether 'db2' can be found on the path using the Windows Command Prompt. You will see the following message if the DB2 path entries are not being picked up correctly:
'db2' is not recognized as an internal or external command,You can work round the Windows environment variable limit by moving the DB2 path entries to the front of the system path before re-starting RSA and trying the setup again.
jtonline 110000B6Y8 Tags:  load mdmbatch runbatch batch mdm-workbench 4 Comments 5,579 Views
Thanks to Vernon for this post. Hopefully it should help if you need to load large amounts of test data in a development environment, however any feedback would be useful so please leave a comment to let us know how you get on. Also, the following instructions were written for MDM Workbench 8.5 and WebSphere Application Server 6.1, so some changes may be required for more recent versions.
These instructions assume you already have a working development and test environment:
Extract the artifacts from the distribution material
The Batch processor consists of a server side EAR file and a set of batch processor client artifacts. The EAR file and client material can be found in the unpack directory created by DEST, e.g. C:\UNPACK\MDM\installableApps and C:\UNPACK\MDM\BatchProcessor respectively, as shown below.
Set-up the Server
Install the MDMBatch.ear file for the batch processor on the Application Server, using the WAS Application installer. Using default values seem to work pretty well. Once the EAR has been installed bounce the server to make it available.
Set-up the client
To complete the client set-up, you need to configure a script to launch the batch loader. This is described in the next section.
Configure runbatch.bat file
Download runbatch.bat and save it in the \ClientBatchProcessor\bin directory. This is a customised .bat file for invoking the batch loader on Windows. It has two settings which you need to customise for your system:
You can either edit the runbatch.bat file to change the default settings, or you can use environment variables to specify the correct locations, for example:
Run the batch loader
Details of the parameters are provided in the MDM Developers guide, but two parameters are mandatory. The first option defines the input file containing the XML documents, and the second option defines the directory for the log files.
Note: the log directory must exist. I suggest creating a "logs" directory in the bin directory.