Developing behavior extensions for InfoSphere MDM v11

Special thanks to Stephanie Hazlewood for providing guidance as well as content for some of the sections of this article!

Executive Summary

Many established organizations end up having unmanaged master data. It may be the result of mergers and acquisitions or due to the independent maintenance of information repositories siloed by line of business (LOB) information. In either situation, the result is the same – useful information that could be shared and consistently maintained is not. Unmanaged master data leads to data inconsistency and inaccuracy. IBM Master Data Management (MDM), specifically the physical MDM set of capabilities, allows the enterprise to create a single, trusted record for a party. Similar capabilities exist for mastering product and account information. It can be integrated with content management systems and can also support a co-existence style of master data management sometimes referred to as hybrid MDM capabilities, were a linkages between matched records mastered and maintained in various source systems are created in virtual MDM and then persisted in physical MDM.

One of the most fundamental extension mechanisms of InfoSphere MDM allows for the modification of service behavior. These extensions are commonly referred to as behavior extensions and the incredible flexibility they provide allows for an organization to implement their own “secret sauce” to the over 700 business services provided out of the box with InfoSphere MDM. The purpose of this tutorial is to introduce you to behavior extensions and guide you through the implementation, testing, packaging and deployment of these extensions. You will be introduced to the Open Service Gateway initiative (OSGi)-based extension approach introduced in the InfoSphere MDM Workbench as of version 11.

Introduction

With the release of InfoSphere MDM v11, we adopt the OSGi specification which allows, amongst many other things, extensions to be deployed in a more flexible and modular way. This document will describe a real client behavior extension scenario and step you through all of the following, required steps:

- Extension scenario outline.

- Creation of the extension project.

- Development of the extension code.

- Deployment of the extension onto the MDM server.

- Testing deployed code using remote debugging.

We will then conclude this document with the summary of what you have learned.

Extension scenario

It is often necessary to customize an MDM implementation in order to meet your solution requirements. One of the extension capabilities InfoSphere MDM provides it the ability to implement additional business rules or logic to a particular out-of-the-box service. These types of extensions are referred to as behavior extensions, as they ultimately change the behavior of a service. In this tutorial we will create a behavior extension to the searchPerson transaction.

The searchPerson transaction is used to retrieve information about a person when provided with a set of search criteria. You can filter out the result set by active, inactive or all records that get retrieved by these criteria. Important to note is that this particular search transaction uses exact match and wildcard characters to retrieve the result set. There are separate APIs available for probabilistic searching – this service is not one of them.

Sometimes, the searchPerson transaction response may contain duplicate parties. For example, if a party contains both legal and business names which are identical, and searchPerson transaction uses last name as criteria, - the parent object will be returned twice in the response, as it will be matched by both of the names. While this behavior is acceptable in some circumstances, some cases might more filtering before it is returned. In order to do so, we will create a behavior extension, which will be responsible for processing transaction output and removing any duplicate records in the result set. The InfoSphere MDM Workbench provides us with exactly the right tools to quickly create and deploy such an extension.

Creating extension project

First, create the extension project structure using the wizards provided by MDM Workbench. Go to File -> New -> Other… and search for Development Project wizard:

If you cannot find Development Project wizard within the list, chances are the Workbench has not been installed, please verify using IBM Installation Manager.

When creating your project, make sure to specify a unique project and package names in order to avoid conflict with the existing ones:

Make sure to choose the correct server runtime for your projects, as well as unique name for the CBA project:

Note: You are allowed to choose from the existing CBAs. A single CBA can contain multiple development project bundles.

Click Finish and wait for the wizard to generate the required assets.

At this point, what we have is a skeletal InfoSphere MDM Development project that contains all of the basic facilities to help us create the desired extension. The next step is to create the extension assets and there are two ways of doing so: either by using the behavior extension wizard, or by using the model editor.

Creating a behavior extension using the extension wizard

You can create an extension using a wizard in the MDM Workbench, much like the one used to create a development project:

2. Once in the wizard, select the development project to place the extension under:

Note:A development projects can contain multiple extensions of various types underneath it. You might choose to use development projects to logically group extensions having a similar purpose, type or to facilitate parallel development activities.

3. Within the next window, choose a name and a description for your behavior extension. Choose a Java class name for your extension. This is the class that we will be populating with custom logic in order to achieve desired behavior. Alternatively, if you require to use an IBM Operational Decision Manager (ODM, and previously known as ILOG) rule – specify this associated parameter. ILOG/ODM rule creation is not covered as a part of this tutorial as we will implement the extension in as a Java extension.

4. Within the “Specify details of the trigger” pane, you need to specify the following parameters:

a. Trigger type:

i. ‘Action‘ will cause the behavior extension to trigger whenever chosen transaction is ran by itself or as a part of another transaction. ‘Actions’ are executed at the component level. .

ii. On the other hand, if you are looking to trigger extension only on a specific standalone transaction event (otherwise known as controller level transaction) select ‘Transaction’ trigger type.

iii. ‘Action Category’ trigger type executes behavior extension on various data actions such as add, update, view or all for extensions to be executed at the component level.

iv. ‘Transaction Category’ trigger type will kick off behavior extension when a transaction of specified type is executed, namely inquiry, persistence or all.

b. When to trigger:

i. ‘Trigger before’ will cause the behavior extension to fire of before the work of the transaction is carried out. Sometimes you will hear this referred to as a preExecute extension. It is a typically used when some sort of preparation procedure has to be executed before the rest of the transaction is carried out. An example of such scenario would be preparing data within the business object that is being persisted.

ii. ‘Trigger after’ will cause the behavior extension to run after the transaction work has carried out. Sometimes you will hear this referred to as a postExecute extension. It is typically used in the scenarios where logic implemented in the behavior extension depends on the result of the transaction. Normally any sort of asynchronous notification would be placed in a post behavior extension, as there would be no way to roll it back in case of transaction failure, if it is sent before the transaction is executed.

c. ‘Priority’ parameter indicates the order in which this behavior extension will be triggered. The lower the priority number, the higher the priority. That is, a behavior extension with priority 1 would execute first followed by behavior extension with priority 2, 3 or 4 in that order.

In our scenario we are looking to filter the response of a specific transaction,, namely searchPerson. Therefore we set the trigger type to be ‘Transaction’ with value of searchPerson. Since we are filtering the response of the transaction – we have to trigger our behavior extension after the transaction has gone through, and response became available. Lastly, in our particular example priority does not play a special role, so we will leave it at default of ‘1’.

5. After the above configuration is done, click Next and review the chosen parameters. Note that there is a checkbox at the top of the dialog, allowing you to generate the code based on the specified parameters immediately. For the purposes of this tutorial leave it checked and click Finish. The workbench will generate all of the required assets for you.

Creating a behavior extension using the model editor

If you have used the wizard approach above to create the behavior extension already, please feel free to skip ahead to the section titled, “review generated assets” that follows.

This section describes how to generate a behavior extension using the model editor. To do so, the following steps will guide you through this process:

1. Go to the development project you created earlier and open the module.mdmxmi file under the root folder of the project. Select the model tab within the opened view.

3. Name the behavior extension that has been created as a result ‘PartySearchDuplicateFilter’, and provide appropriate documentation:

4. Now we will create a transaction event definition under behavior extension. Right-click the behavior extension, then select New - > Transaction Event.

5. Once the transaction even has been created, specify the appropriate properties:

a. Because this event is triggered on the personSearch transaction, PersonSearchEvent is appropriate. Recall that sometimes the “trigger before” behavior is referred to as “preExecute” extension.

b. Because ‘Pre’ checkbox stands for preExecute, (more specifically the behavior extension gets executed before the rest of the transaction) leave it unchecked. Similar to the wizard configuration, leave priority as ‘1’, since priority of execution does not affect this behavior extension.

After all of the above configurations are done and reviewed, go ahead and click Generate Code under the Model Actions section of the view, telling workbench to generate configured assets.

Review your generated extension code

Once either of the above methods is used, let us review the generated assets:

Under bestpractices.demo.behavior, we find the PersonSearchDuplicateFilter which is the actual behavior extension Java class that, once configured, will be executed at runtime. We will be providing the implementation that will filter out duplicate person objects from the response of the searchPerson transaction here shortly.

In the OSGI-INF/blueprint/blueprint-generated.xml we can see the OSGi service definition, listing the bestpractices.demo.behaviour.PersonSearchDuplicateFilter class as the extension service.

o EXTENSIONSET table record defines the behavior extension, its associated class bestpractices.demo.behaviour.PersonSearchDuplicateFilter and its priority of ‘1’:

o CDCONDITIONVALTP defines a new condition of transaction name being equal to searchPerson.

o EXTSETCONDVAL connects the above CDCONDITIONVALTP record to the behavior extension record from EXTENSIONSET. Additionally another EXTSETCONDVAL record connects CDCONDITIONVALTP with id of ‘9’, which stands for execution of behavior transaction after transaction.

Let us now move on to developing the extension code required to filter out duplicate person records from the result set returned by the searchPerson transaction.

Develop the extension code

The behavior extension skeleton and supporting configuration assets have now been generated. You add your custom logic, or behavior change, in the execute method of PersonSearchDuplicateFilter class. The objective is simple. We need to go through all of the partySearchResult objects returned by the service, and if a same person object repeats multiple times throughout the result vector – we want to remove it. The following code will achieve just that:

Note: The above implementation is not pagination friendly and pagination will not be covered as a part of this tutorial.

Once you have compiled the code above, you will notice that some of the classes are not found and have to be imported. You cannot simply import TCRMPersonSearchResultBObj because the package containing this business object is not imported for the bundle that we’re working with. To fix that go to BundleContent -> META-INF -> MANIFEST.MF and go to the dependencies tab:

Add com.dwl.tcrm.coreParty.component to the list of imported packages. Now you should be able to import TCRMPersonSearchResultBObj in our behavior extension class to resolve the dependency error.

After recompiling the projects again, you will notice that the PartySearchBehaviorExtensionCBA now contains an error:

This error is occurring because the composite bundle that contains PartySearchBehaviorExtension bundle does not import com.dwl.tcrm.coreParty.component. In order to resolve the error, go to the manifest file of the CBA, which should be located under root folder of the project, and add com.dwl.tcrm.coreParty.component to the list of imported packages. As you recompile – it should resolve the error.

Now that all compilation problems have been resolved, we are ready to deploy our extension onto the server.

Deploying your new behavior extension to MDM

Once the implementation of the behavior extension has been developed, we are ready to deploy it onto the server. There are two steps involved into the deployment:

- Deploying code to the server.

- Executing generated SQLs to insert required metadata.

Deploying code to the server

Our customized behavior extension can be deployed to the server as a Composite Bundle Archive (CBA) as follows:

1. Make sure that the customized code has been built and then export the CBA containing the behavior extension by right clicking the CBA project and selecting ‘Export… -> OSGi Composite Bundle (CBA)’.

2. In the opened view, select PartySearchBehaviorExtension as the bundle to include. Click ‘Browse…’ and navigate to a selected export location and click ‘Save’. If you do not explicitly provide the file name, the wizard will generate the appropriate name automatically.

3. Click ‘Finish’. The CBA containing the behavior extension has now been exported to selected location.

4. At this point, we will assume that the MDM instance is up and running. Let’s open the WebSphere Administrative Console. We are looking to import our new CBA into the internal bundle repository. To do so go to Environment -> OSGi bundle repositories -> Internal bundle repository. In the opened view, click New…, choose Local file system and specify the location of the CBA we’ve exported above. Save your progress.

5. Once the CBA has been imported, attach this new bundle to the MDM application. Go to Applications -> Applications Types -> Business-level applications. Choose MDM application from the opened view. In the next open view, open the MDM .eba file.

6. We are now looking at the properties of the MDM Enterprise Bundle Archive (EBA). In order to attach our CBA, go to Additional Properties section and select Extensions for this composition unit.

7. If this is the first extension that you’ve deployed on your instance, the list of attached extensions will be empty. Let’s now click Add…, and check the CBA we’ve imported above, then click Add. Wait for the addition to complete. Save your changes.

8. You may think that we are done here, but not quite. We’ve only updated the definition of the EBA deployment by adding our extension. The MDM OSGi application itself has not been updated and even if you restart the server, your new behavior extension will not be picked up. So you must update the MDM application to the latest deployment by returning to the EBA properties view.

Before we attached our extension, the button shown above was grayed out; the comment stated that the application is up to date. But since we’ve update our application with a new extension bundle, we need to update it to the latest deployment. Go ahead and click the Update to latest deployment … button.

9. In the next view, you can see that the PartySearchBehaviorExtensionCBA that we’ve attached to the MDM EBA, will now be deployed:

At this point, scroll down and click Ok to proceed. It may take several minutes depending on your system hardware.

10. At this point, WebSphere will take you through three views, offering multiple information summaries of the deployments and several customization options. There is no need to customize anything, go ahead and click Next three times, followed by Finish. At this point the application will update. It may take some time; please allow 5 – 10 minutes to complete depending on underlying hardware. Once it is complete – save your changes. At this point, the MDM application has been updated to the latest deployment which includes our extension.

Now we need to deploy our custom metadata to the database. This metadata will govern the behavior of our extension in ways discussed above.

Deploy metadata onto the MDM database

As mentioned earlier in this tutorial, the Workbench generates database scripts that insert the required configuration into the metadata tables of the MDM repository. This metadata is generated based on the parameters we provided for our behavior extension as part of the Creating extension project section. In order to deploy this metadata to the database, run the database scripts listed under the resources -> sql folder that are appropriate for your database type. Conversely, if you need to remove extension from the server, you would need to run the rollback scripts provided in the same folder.

Note: In the case where some portion of the script fails, please investigate the error, because it may render the extension useless. Potential reasons for an error may include residual data from previous extension (rollback was not run when extension was removed), incorrect database schema, etc.

Once the scripts have been successfully run, you’re your behavior extension has now been successfully deployed. Restart your WebSphere server so that your new metadata gets picked up when the application runs next.

Testing deployed code using remote debugging

Now that all of the aspects of the behavior extensions have been deployed, we are ready to test it out! To do that, run a searchPerson transaction. It is required to have at least one person in the database so that you can actually search and yield a successful search result to trigger your new extension. This test will show us that the extension is successfully deployed. Once the transaction returns as successful, go to the SystemOut.log of the WebSphere server which is located under the log folder of the WebSphere profile where MDM application is deployed. If the extension has deployed correctly, due to the following line in our custom code:

Note: The log message is there for testing purposes only, and depending on the usage of the behavior extension can significantly impede performance. For that reason please make sure to remove such debugging messages or put them into fine logging level before going into production. Such as:

Configuring WebSphere Application Server debug mode

To observe the behavior of our extension more closely, put WebSphere server into the debug mode, and connect MDM Workbench to the said server in order to debug our code step by step. To put your server in debug mode:

Note that ‘7777’ is the debug port to which the MDM Workbench will connect. Make sure this port does not conflict with any other assigned ports on the server, and set it accordingly.

5. Save configuration and restart your server. It is now running in debug mode. Note: If later you observe unexpected performance degradation and do not require debug mode any longer, make sure to take the server out of the debug mode using the same steps.

Configuring MDM Workbench to for remote debugging

Once the server is running in debug mode, we can go back to the MDM Workbench and configure it for debugging:

1. In MDM Workbench, go to Run -> Debug Configurations.

2. Within the Debug Configurations window, double click Remote Java Application. This will create a new Remote Java Application profile.

3. When configuring the Remote Java Application, lets name our configuration ‘MDM Local Instance Debug’. The Project setting does not play a role, you may leave it empty, or whatever the default populated value is. Connection Type should remain as ‘Standard (Socket Attach)’. Lastly Connection Properties should reflect the location of the MDM instance and debug port we’ve chosen above.

We will not cover other tabs because the configuration we’ve done so far is sufficient.

4. Once configuration is complete, hit Apply followed by Debug in order to attach to the MDM instance. The attach process may take a little bit of time depending on the environment. Once it is complete, go to the Debug perspective of your environment. In the debug view, you should observe the connected MDM instance if the attach was successful:

You can see above that the instance is available along with all of the threads.

5. Finally set a break point at the beginning of the behavior extension execute method and observe this breakpoint getting engaged once we run a searchPerson transaction:

6. If you have multiple TCRMPersonSearchResultBObj coming back in the response, step through and observe the duplicates being removed.

As a last point, note that we can debug both local and remote instances as described above, using Eclipse’s Remote Java Application debug capabilities.

Conclusion

In this tutorial we’ve gone through the steps of creating, configuring, deploying and testing a basic yet realistic behavior extension scenario for InfoSphere MDM.

We’ve covered two ways in which an extension template can be created: while the wizard option is straightforward and is preferable for a novice or a simple extension scenario, the model editor allows for more flexibility.

We’ve taken a look at the various configurations that apply to a behavior extension and outlined their effects on its execution. Additionally, we’ve covered the assets that get generated as a result of the configuration.

For the development step, we’ve created and analyzed the implementation of our behavior extension.

And finally, we’ve deployed, tested and debugged our behavior extension to make sure it performs as expected.

All of the above steps constitute a complete development process of an MDM Server behavior extension.

There is a typical workstation install that automatically sets up a full development and test environment, described in the 'Full development environment install' section of the Installing MDM Workbench v11 post, however this approach has some limitations. For example, it will only work if you do not have any trace of the products it installs on your machine already, there are restrictions on which features can be installed, it is not possible to provide passwords, and so on.

The alternative is to manually install the MDM Workbench for MDM configuration and development, and an Operational Server for test purposes. In this example I will install a full development and test environment on Windows, using a DB2 database. The instructions below assume that you do not have any of the prerequisite software installed but, if you do, just skip the relevant steps.

To avoid problems with path lengths, special characters, or Windows virtualised directories, I installed all the software under a C:\IBM directory.

Downloading and extracting install images

These are all the install images I downloaded. See the Download IBM InfoSphere Master Data Management version 11.0 document for more part numbers and information about downloading from Passport Advantage. I extracted the downloads into the folder structure described in the Setting up the installation media topic, with a couple of additional directories as required. If you don't already have anything that can extract .tar.gz files, you can use the unpack option in download director:

Important: If you are about to install MDM but downloaded the install images before 17th October 2013, you must download the product refresh first.

Important: The workbench install will fail if the .tar.gz install images are extracted using WinZip. So far it looks like the Download Director unpack option, WinRAR, and 7-Zip all work but please leave a comment if you have problems with any unzip tools and I'll update the list.

IBM Installation Manager V1.6.0

This is required to install everything except DB2.

Part number: CIM7CML

DB2 Enterprise Server Edition V10.1

I used fix pack 2 to install DB2, available via the DB2 fix pack download page, rather than installing the GA version and upgrading. Alternatively, you could use the following part.

Part number: CI6WEML

Installation Startup Toolkit

This provides the scripts required to create an MDM database.

Part number: CIR9WML

Master Data Management Standard & Advanced Edition

This is the actual MDM Operational Server install.

Part numbers: CIR9NML, CIR9PML, CIR9QML, CIR9RML, CIR9SML

Master Data Management Workbench Standard & Advanced Edition

This is the Rational based workbench used to configure and develop MDM solutions.

Part numbers: CIR9TML, CIR9UML, CIR9VML

Rational Application Developer for WebSphere Software V8.5.1

I installed the workbench into Rational Application Developer but you could use Rational Software Architect for WebSphere Software instead. In either case you need at least version 8.5.1, however there is a known problem with version 8.5.5.

Installing Installation Manager

I ran install.exe to install Installation Manager in GUI mode. After installing Installation Manager you can add the required repositories individually before you run each install, as I did in the video series, or you can add all the repositories in one go as follows.

Create a repository.config file in the directory where you extracted the install images. Copy and paste in this content:

Edit any paths based on the directories you used before saving the file. Now you can add this single repository using the Installation Manager repository preferences and all the packages will show up on the install page.

Note: you may have seen a suggestion to alter Installation Manager's agent data location using the cic.appDataLocation configuration setting, however it is not typically necessary, or a good idea, to change this setting.

Installing the workbench

Installing the workbench is straightforward once you've added the Rational Application Developer and workbench repositories to Installation Manager. Pick a suitable install location, for example C:\IBM\SDP, and you can accept the defaults for everything else.

In the MDM Workbench v11 Installation video I chose to install a few additional features from Rational Application Developer, for example 'JSF' for customising UIs. Depending on what work you'll be doing, you may want to do the same, and you can always use Installation Manager to add extra features later on if required.

I changed the install locations, to C:\IBM\AppServer and C:\IBM\MDMStartupKit respectively, but I accepted the defaults for everything else.

Preparing to install the Operational Server

There are several advantages to manually installing a development and test environment, however the biggest disadvantage compared to a typical install is that the installer does not create an MDM database or WebSphere profile for you. Instead, you have to prepare the database and prepare the application server before starting the install.

Edit SQL files

There are a couple of SQL files provided in the startup toolkit for creating an MDM database on DB2:

CoreData\Full\DB2\Standard\ddl\CreateDB.sql

CoreData\Full\DB2\Standard\ddl\CreateTS.sql

Both these files contain placeholders which need to be replaced with suitable values before use. These are the values I used:

Placeholder

Value

<DBNAME>

MDMDB

<TERRITORY>

US

<DBUSER>

db2admin

<TABLE_MDS4K>

TBS4K

<TABLE_SPACE>

TBS8K

<TABLE_SPMDS>

TBS16K

<INDEX_SPACE>

INDEXSPACE1

<LONG_SPACE>

LONGSPACE1

<TABLE_SPPMD>

EMESPACE1

<TABLE_SPPMI>

EMESPACE2

Notes: Authority will be granted to the user specified by the <DBUSER> value, so this should be different to the user running the scripts. The database name is easy to specify in the installer but here I used the default. The tablespace names need to match the settings used by the installer, and the easiest way to do that for a development environment is to use the values shown above.

The following PowerShell command will fill in the placeholders and I ran it for CreateDB.sql and CreateTS.sql rather than editing the files by hand:

Create database

After editing the SQL files, I ran them using this command in a DB2 Command Window:

db2 -v -td; -f C:\temp\CreateDB.sql

And the same for CreateTS.sql.

Create application server profile

I used the advanced option when creating an application server profile using the Profile Management Tool. I chose not to install the default application, gave the profile a meaningful name and picked the Development tuning setting. Administrative security must be enabled for MDM, and the advantage of creating the profile yourself is that you get to choose the username and password. If you run the Profile Management Tool as administrator, you will also be given the option to run the server process as a Windows process, which isn't necessary for a development environment.

Important: When creating a profile for use with the MDM Workbench, make sure you create it in the default location with a directory name that matches the profile name.

Set DB2_JDBC_DRIVER_PATH WebSphere variable

After creating the application server profile you need to set the DB2_JDBC_DRIVER_PATH variable. The value needs to be the path containing the directory where you installed DB2. I installed DB2 in C:\IBM\SQLLIB, so on my system the DB2_JDBC_DRIVER_PATH variable should be set to C:\IBM.

Important:Do not follow the instructions in the description for this WebSphere variable: the operational server install requires a non-standard setting.

Installing the Operational Server

Now everything should be ready for a successful MDM install, however the operational server installer does not do many checks so there is still a chance that you could encounter problems. When problems do occur, the install will either roll back, requiring a reinstall, or keep going without reporting any issues until the install verification tests fail. This makes it difficult to track down problems so it's worth taking time to make sure everything is configured correctly before starting the install.

Running the install

The MDM Operational Server install is another Installation Manager based install, so add the MDM repository if you haven't already and choose the install option. I changed the installation directory to C:\IBM\MDM to avoid any confusion with the missing space in the default, 'ProgramFiles'.

In the video I chose to install the Business Administration UI feature, and there are other features you may want to select. The remaining panels cover the configuration settings required to set up MDM.

Note: There are several buttons to test connections and retrieve details from the application server during the configuration process which do not report process. It can look like the install has stopped responding but if you use a slightly long single click and wait a few minutes, you should see the status message change when the processing has completed.

Configuration settings

On the Database Configuration page, the Database home setting must match the value of the DB2_JDBC_DRIVER_PATH WebSphere variable, for example C:\IBM on my machine. The rest of the settings on this page should match the MDM database you created earlier.

Pick suitable values for your requirements on the History Configuration page.

Select the Base Edition option on the WebSphere Application Server Configuration page. The settings should match the application server profile you created earlier. You'll need to specify the correct SOAP port setting since the default value is wrong. This is likely to be 8880 if the MDM profile was the first profile you created, but you can check using the AboutThisProfile.txt file in the profile logs directory.

When you've completed all the configuration panels you can start the install. This will take some time to complete.

Troubleshooting

If the install finishes with no errors and there are no errors reported for the install verification tests, the install was successful. If the install fails for some reason, the installation troubleshooting topic will help you debug known install problems. There are several logs which may help with this process, including Installation Manager logs, application server logs, MDM install logs and install verification logs. For example:

C:\ProgramData\IBM\Installation Manager\logs

C:\IBM\AppServer\profiles\MdmDev01\logs\server1\SystemOut.log

C:\IBM\AppServer\profiles\MdmDev01\logs\server1\SystemErr.log

C:\IBM\MDM\mds\logs

C:\IBM\MDM\logs\database

C:\IBM\MDM\IVT\testCases\xml\response

C:\IBM\MDM\IVT\testCases\xml_virtual\response

The exact paths may be different on your system if you chose to install in different locations.

Feedback

I hope you find this post useful but if you do spot any errors or omissions, please leave a comment below. Any hints and tips based on your own install experiences would also be great. If you're having problems installing, the best place to ask questions is on the MDM forum.

Related information

For an up-to-date* list of install related information, see the following wiki page:

Whether you're already familiar with the Workbench or completely new to it there area lot of new changes in v11. So why not check out the MDM Workbench Development tutorial for a detailed step by step guide to developing physical customizations in the new release. It's a great resource if you're looking for more insight into what MDM Workbench offers, going through the stages of designing a model and then deploying it to the MDM Server.

In Version 11 of InfoSphere MDM, some big changes happened. One change that might leave you scratching your head is the addition of new and changed terms for some familiar components. We also have a couple new components, so those might be unfamiliar too. Let's take a quick walk through the changed terms to get you started.

Product names

The first thing that you'll notice is an emphasis on capabilities rather than product names. You might not see these familiar product names anymore:

InfoSphere MDM Server

Initiate Master Data Service (MDS)

Other Initiate product names

Instead, you’ll see references to technical capabilities that those products achieve:

Technical capability

Previous product name

virtual MDM

Initiate Master Data Service

physical MDM

InfoSphere MDM Server

hybrid MDM

InfoSphere MDM Server and Initiate Master Data Service

You might be wondering what exactly these technical capability terms mean. You can use virtual, physical, and hybrid MDM to manage your master data, whether you store that data in a distributed fashion, in a centralized repository, or in a combination of both.

The following definitions show the differences and the relationships among the technical capabilities:

virtual MDM

The management of master data where master data is created in a distributed fashion on source systems and remains fragmented across those systems with a central "indexing" service.

physical MDM

The management of master data where master data is created in (or loaded into), stored in, and accessed from a central system.

hybrid MDM

The management of master data where a coexistence implementation style combines physical and virtual technologies.

Another new area that you’ll notice is a unified server, which is referred to by one common term:

Earlier terms

Current term

InfoSphere MDM Server

Initiate Master Data Service

MDM Hub, MDM Server

master data engine

MDM operational server

The former InfoSphere MDM Server and the former Initiate Master Data Service are combined to share a single infrastructure in the application server. That single infrastructure is called the MDM operational server or operational server for short. The operational server is the software that provides services for managing and taking action on master data. The operational server includes the data models, business rules, and functions that support entity management, security, auditing, and event detection. For detailed descriptions and diagrams, see the architecture and concepts topic.

Records, member records, and entities

Finally, the concepts of entities and records were clarified:

entity

A single unique object in the real world that is being mastered. Examples of an entity are a single person, single product, or single organization.

record

The storage representation of a row of data.

member record

The representation of the entity as it is stored in individual source systems. Information for each member record is stored as a single record or a group of records across related database tables

Depending on your implementation style, these concepts reflect the technical capabilities of virtual, physical, and hybrid MDM. For example, an entity in virtual MDM is assembled dynamically based on the member records by using linkages and then is stored in the MDM database. Conversely, an entity in physical MDM is based on matching records from the source systems that are merged to form the single entity. For details, see the diagrams and definitions for these concepts.

I’ll leave a discussion of hybrid MDM to a future article. If you’d like to read some conceptual topics about hybrid MDM now, see its technical overview.