Implementing InfoSphere Master Data Management Behavior Extensions

Implementing InfoSphere Master Data Management behavior extensions
1 of 18
developerWorks
Technical topics
Information Management
http://www.ibm.com/developerworks/data/tutorials/dm-0910infospherem...
Technical library
Implementing InfoSphere Master Data Management

behavior extensions
Make master data actionable based on events to deliver business value
This tutorial shows you how to implement behavior extensions for InfoSphere Master Data Management Server using
the InfoSphere Master Data Management Workbench. Behavior extensions provide event capabilities that create
actionable master data and improve the business value of your deployed Master Data Management (MDM) solution.
Share:
Dmitriy Fot is a former IBM software engineer. Dmitriy worked in the area of Master Data Management while a member of the Center of
Excellence for MDM team based in the IBM Boeblingen Lab in Germany. His experience includes numerous integration projects involving
MDM Server and other IBM and non-IBM systems. After joining the IBM Austin Lab, Dmitriy changed his focus towards information security
and participated in several projects in the area of access control, policy-based security, and database security.
Martin Oberhofer joined IBM in the IBM Silicon Valley Labs in the USA at the beginning of 2002 as a software engineer. In an architect role
for Enterprise Information Integration and Master Data Management, he currently works with large enterprises around the globe shaping the
information architecture foundation and solving information-intense business problems. His areas of expertise are Master Data Management,
Enterprise Information Integration, database technologies, Java development, and IT system integration. He is particularly focused on
enterprise information integration in heterogeneous environments also containing SAP applications. He provides Enterprise Information
Architecture workshops to customers and major system integrators. In a Lab Advocate role, he provides expert advise for Information
Management to very large IBM clients. He holds a Masters degree in mathematics from the University of Constance in Germany.
22 October 2009
Before you start

This tutorial is for the InfoSphere Master Data Management Server. When
you implement this comprehensive MDM solution, you may have certain
business requirements that demand a change to the default behavior of an
out-of-the-box MDM business service used to maintain master data such as
customer, product, account, contract, or location. This tutorial shows you
how to implement a behavior extension for an MDM business service
available with InfoSphere Master Data Management Server.
Objectives
The learning objectives of this tutorial are:
Understand how to extend InfoSphere MDM Server to make master data actionable based on events
Gain insight into the structure of MDM services and the various possibilities you have to customize the
MDM services using data additions, data extensions, and behavior extensions
Create and deploy two behavior extensions using the Java extension and the ILOG JRule extension
mechanism
Master the implementation of error types and codes
Prerequisites
This tutorial is written for IT Architects and IT Specialists with an interest in learning more about how to
4/7/2016 4:31 PM
2 of 18
change the out-of-the-box behavior of an InfoSphere Master Data Management Server deployment. The
tutorial assumes that you have some knowledge of and experience with J2EE development. Experience
or familiarity in the following areas will help make the tutorial easier to understand, but even if you are
new to some of these topics, we try to provide enough information to ensure your understanding:
MDM Server Web services
IBM Rational development tools
MDM Workbench
System requirements
To use the tutorial, your system should meet the following requirements:
2 GB memory or more.
15 GB free disk space.
An operating system on which the Rational Software Architect Version 7.0 for WebSphere Software (or
newer) can be installed with the MDM Workbench.
The tutorial has been developed and tested with InfoSphere MDM Server Version 8.5.
Introduction
Many companies today have the need for a Master Data Management (MDM) solution that enables them
to "master" their master data. One example of a business driver would be the ability to bring products to
market faster with a streamlined new product introduction process that is based on a more effective and
consistent authoring process of product master data. Another example would be the ability to improve
cross-sell and up-sell capabilities by leveraging clean and consistent customer and product master data
records and customer-product relationship information.
Once a company deploys foundational MDM capabilities, naturally the question arises as to what are
even more effective and smarter ways to leverage master data for better business results. This is where
the capability to make master data actionable, based on events and notifications, comes into play. Here
are a few examples:
Life events
What if you could use a change of marital status to proactively engage a client and offer an appropriate
mortgage plan?
What if you could react to clients reaching a certain age that puts them into the prime demographic
group for one of your products or services?
4/7/2016 4:31 PM
3 of 18
Financial events
What if you could react to a customer not fulfilling minimal creditability requirements?
What if you could proactively engage with clients if their credit score entitles them to move into the next
higher services tier?
What if you could proactively arrange a client meeting two months before a fixed time deposit contract
expires?
Compliance events
What if you could react right away if a client appears on a black list?
What if you could react right away if a non-obvious relationship has been detected indicating a
potential fraud case?
As indicated by the examples above, making master data actionable based on business rules and
requirements, can improve the value of your MDM deployment. InfoSphere MDM Server includes a set of
capabilities that supports these types of use cases. The key capability in this regard is the ability to
implement a behavior extension using either a Java extension or an extension based on ILOG JRules.
The next two sections of the tutorial introduce a few relevant InfoSphere MDM Server concepts. The
sections after that describe a sample business scenario and provide step-by-step instructions on how to
create, implement, and deploy an InfoSphere MDM Server behavior extension that meets the
requirement of the sample scenario.
Note that this tutorial does not cover integration with external, advanced security mechanisms or external
event management software such as WebSphere Business Events.
InfoSphere Master Data Management Server architecture overview

IBM offers the InfoSphere Master Data Management Server (MDM Server) as a holistic MDM platform.
See references [1], [2], and [3] in the Resources section for links to documentation and overview
information about MDM Server.
Figure 1 shows a high-level overview of some of the most important and relevant components of MDM
Server.
Figure 1. InfoSphere Master Data Management Server
Business level services and master data services

The business level services provide coarse-grained services operating on master data and are
composed of fine-grained master data services. MDM Server has more then 800 out-of-the-box services
that seamlessly support SOA deployments.
4/7/2016 4:31 PM
4 of 18
Data quality management

This component provides data quality functionality such as duplicate prevention and services to support
data governance and data stewardship tasks such as split or merge operations of master data
instances.
Proactive business logic components
This component includes the Event Manager, which provides the core event management functionality.
The Event Manager is an alternative to using behavior extensions for implementing events.
MDM applications
MDM Server includes several MDM applications such as the Data Stewardship application.
Master data repository
The repository is a database server where the MDM services persist the data or read the data from. For
example, DB2 LUW and DB2 z/OS are supported database servers.
MDM design workbench
This is an Eclipse-based, model-driven development tool for implementing additional services or
customizations of existing services for MDM Server.
Extending MDM Server using MDM Workbench

The MDM Workbench
The MDM Workbench is a model-driven development tool for the InfoSphere Master Data Management
Server. The MDM Workbench is based on Rational Software Architect (RSA) for WebSphere Software.
(For a link to a trial download and more information on RSA, see references [4] and [5] in the Resources
section.)
RSA is an Eclipse-based Integrated Development Environment (IDE) for J2EE application development.
(For more details on Eclipse, see reference [6] in the Resources section.) The MDM Workbench itself is a
series of plug-ins for RSA.
This tutorial assumes you already have a Rational Software Architect 7.0 environment available and the
MDM Workbench deployed. (For a complete description of how to get started with the configuration of the
MDM Workbench, see references [7] and [8] in the Resources section.)
Types of extensions
Out-of-the-box, MDM Server has a rich data model and more then 800 MDM business services available.
However, the data model and the services for each deployment need to reflect requirements specific to
the business needs of the enterprise where it is deployed.
This means that you need to adapt the data model by adding new attributes or entities, or by modifying
existing ones. Changes in the data model must also be reflected in the services so that they can operate
on them. Furthermore, you might need to change service behavior to accommodate additional
functionality for life, financial, or compliance events such as those described earlier. Obviously, there are
also other behavior extensions, which are not related to triggering an event, that modify the service
behavior. Finally, service extensions are also required for business rules that are applied to govern
master data and enforce necessary business constraints or proactively act on master data. For all these
requirements, MDM Workbench supports building the necessary extensions. These extensions are
described below.
4/7/2016 4:31 PM
5 of 18
Data additions
This type of extension is used if a new entity is added to the out-of-the-box data model. For example, if
you need to model an oil rig for location master data and you are creating an entity for this, you would
leverage the data addition feature. Note that by implementing this type of extension the corresponding
new create, read, and update services are created as well by the MDM Workbench.
Data extensions
This type of extension is used if an existing entity (for example, a person) needs to be modified by
adding new attributes or changing existing attributes. The MDM Workbench also helps you seamlessly
update the existing services for the changed entity.
Behavior extensions
This type of extension is used when the behavior of a service must change. There are various reasons
why this might be needed, such as changes of critical data attributes, compliance reasons, or business
rules to act on certain events and improve business results.
Query extensions
This type of extension is used to build specific inquiry capabilities for master data entities.
Code tables
This type of extension is used when the range of valid values for an attribute is constrained by the
values found in the related code table.
Error reason
This type of extension is applied if a service fails and a specific new error reason is supposedly returned
to the service consumer. This is most often the case if either new services are added by building a data
addition, or existing services are changed (which would be the case for data extensions or behavior
extensions).
Note that the extensions described above are typically the ones that are most often used, but MDM
Workbench does support other extensions of the MDM Server capabilities.
Behavior extensions
Behavior extensions for MDM Server can be implemented in Java or as ILOG JRules.
Java developers can create behavior extensions that are a subclass of a basic extension class. This is
described in the Java implementation section of the tutorial. By using this approach, Java developers do
not need to learn an ILOG language, such as IRL or TRL.
WebSphere ILOG JRules is a Business Rule Management System (BRMS). It provide extensive
capabilities to create, test, execute, and monitor all business rules. This makes it a seamless task to
manage your most important business systems according to your business rules. (For more information
about ILOG, see references [9] and [10] in the Resources section.) MDM Server supports ILOG rules in
ILOG languages such as IRL, TRL, or BAL. If you have a large number of business rules to manage and
monitor, the ILOG JRules approach offers a state of the art platform to do so and may be the better
strategic choice when compared to using Java-based behavior extensions.
Behavior extensions and Event Manager

As described in the architecture overview section, MDM Server includes the Event Manager as part of its
out-of-the-box proactive business logic components. The Event Manager is an alternative to using
behavior extensions for implementing events. Following are some best practices in regard to choosing
4/7/2016 4:31 PM
6 of 18
when to use the Event Manager and when to implement a behavior extension.
You would typically use the Event Manager when:
The event requires complex processing (for example, an organization hierarchy change). Event
Manager events are asynchronous once fired to the executing service. Therefore once triggered, the
service is not slowed down much because the event is processed by the Event Manager outside of the
service scope.
All periodic time-based events.
Batch processing (for example, DSP processing when a new batch of Dun and Bradstreet customer
record updates or a watch list update is received).
You would typically use behavior extensions when:
The event is related to the single invocation of the service (as opposed to a batch process invoking the
updateParty() service multiple times).
The event requires only simple to moderate logic from a processing perspective. Otherwise, the service
performance might suffer too much.
The behavior changes are not related to triggering events.
Sample scenario
The primary goal of this tutorial is to provide you with some basic hands-on experience and guidelines for
extending the functionality of MDM Server by using behavior extensions. The resources.zip file available
in the Download section contains an MDM extension project that comprises all of the ideas described in
this tutorial. The project is based on a sample scenario in which a development team needs to extend the
MDM functionality in order to comply with the following new business requirement:
MDM Server must track changes to the marital status of all customers. If a customer's status changes to
married, MDM Server must send a message to the customer's personal e-mail, notifying him or her of
new discount opportunities available to customers with families.
Creating an extension in MDM Workbench

You can create MDM behavior extensions manually as well as with the help of development tools. This
section describes the process for creating a behavior extension using the MDM Workbench. The
instructions assume that you have installed the MDM Workbench and that your MDM development and
test environment has been set up properly. At a high level, the process to extend MDM Server using the
MDM Workbench looks like this:
1. Create a new MDM module.
2. Define all the modifications in the module (for example, behavior extensions, data additions, new error
types, new code types, new transactions, etc.).
3. Validate the modifications.
4. Generate the MDM artifacts (source code, SQL queries, and deployment modules)
5. Implement the business logic of the modifications.
6. Package and deploy the modifications.
4/7/2016 4:31 PM
7 of 18
Creating a module project

To start the wizard for creating a new MDM module project from the MDM Workbench, right click in the
Package Explorer, and from the context menu select New > Other > MDM Workbench/MDM Module
Project. This takes you to the MDM Module Project wizard screen, as shown in Figure 2.
Figure 2. MDM Module Project screen
To create a module from the wizard, you must define the project name, the java package name for the
generated classes, the service namespace URI (which is not used for behavior extensions, but will be
used for data additions), and the MDM enterprise application project where extensions must be deployed.
Figure 2 shows the wizard screen with the following information entered for the sample module used in
this tutorial:
Project name: Demo BehaviorExtensions
Use default location is selected
Base Java package name: com.ibm.mdm.demo
Service namespace URI: http://www.ibm.com/xmlns/mdm/demo
EAR project name: MDM
For every new module, MDM Workbench generates a file called module.mdmxmi, which is basically an
XML Metadata Interchange (XMI) representation of the module. The MDM Workbench uses this file later
as the source for EMF-based generation of the required MDM artifacts.
The MDM Workbench screenshot in Figure 3 shows the overview of the newly created MDM module.
One of the important module attributes that you can define after the module is created, is Start ID. Each
module you create must have a unique value for this attribute. This is so that the MDM Workbench can
generate different SQL primary keys for the different database objects it generates the queries for.
Figure 3. Overview of the new MDM module
4/7/2016 4:31 PM
8 of 18
Defining a structure for the module

The MDM module is a container for all the MDM additions and extensions. The module can include the
following objects:
MDM entity
MDM entity extension
MDM behavior extension
MDM query extension
MDM code Table
MDM transaction
MDM inquiry
MDM error type code
MDM error reason
To implement the sample scenario, we created two behavior extensions, one error type code, and two
error reason codes. Figure 4 shows the final structure of the module. Details about the extensions follow
the figure.
Figure 4. The Structure of the MDM module for the sample scenario
Behavior extensions
As discussed previously, you can implement behavior extensions for MDM Server using either Java or an
ILOG JRules rules engine. This tutorial describes how to implement both these types of extensions.
You can add new behavior extensions using the MDM Model Editor. First you create a new folder and
then you create extensions in it. When creating a behavior extension, pay attention to the naming
4/7/2016 4:31 PM
9 of 18
convention you use. The same name will be used as a class name for Java or a rule name for a JRules
implementation.
For the sample scenario we want to build an extension to trigger a notification being sent if a customer's
marital status is changed to married. In MDM Server there are several ways to change the marital status
of a customer. One way is to assign a new relationship of the type Spouse Of, another way is to update
the Marital Status field in the customer's record using a updatePerson service transaction. For the sake
of demonstration, we created two behavior extensions which cover both of these approaches:
MarriageNotificationTriggerJava implemented in Java and triggered when a new spouse relationship
is added.
MarriageNotificationTriggerILog implemented in JRules and triggered when the customer's record is
updated.
Event types
Events are assigned to extensions and determine when the extension code is invoked. Events can be
defined as pre-processing or post-processing. This determines whether the behavior extension code is
invoked before or after the MDM Server executes the transaction. Any extension can be triggered by any
number of events of the same or different event types.
MDM Server supports the following event types:
Action event a specific data action, such as addAddress
Transaction event a specific service transaction, such as updatePerson
Action category all data actions of the same kind, for example, any add action
Transaction category all transactions of the same kind, for example, any inquiry transaction. If the
extension was assigned an event with a transaction category equal to All, it means that the extension
code will be invoked whenever an MDM transaction is executed.
To assign an event to the behavior extension, use the MDM Model Editor. Right click on the extension,
and from the context menu select New > Choose event.
When defining a new event you can assign it a Priority in the form of an integer number. The number is
used to determine the order in which behavior extensions are run if more than one is defined for this
event. Higher numbers indicate lower priority.
Figure 5 shows the completed configuration of the UpdatePersonEvent for the
MarriageNotificationTriggerILog extension.
Figure 5. Creating an event for the MarriageNotificationTriggerILog extension
Error Types
4/7/2016 4:31 PM
10 of 18
The MDM Server code uniquely identifies each error message, using these four parameters:
Component ID identifier assigned to the MDM module
Error type code code assigned to the type of error
Error reason code code assigned to the error reason
Language language code assigned to the error message
MDM Server generally provides a sufficient set of predefined error types and reason codes. Here is the
list of the predefined error types (the list of error reason codes is not shown because it is a fairly long list):
DELERR delete error
DIERR data invalid exception
DKERR duplicate key exception
DRECERR duplicate record exception
FVERR field validation error
INSERR insert exception
READERR read exception
UPDERR update exception
You can also use the MDM Model Editor to create your own error types and error reason codes. For our
sample scenario, we created a new error type called DEMOERR that covers all the errors encountered
by the DemoBehaviorExtensions extension. The dialog for creating the new error type is shown in Figure
6.
Figure 6. Creating a new Error Type
We also created the following two new error reason codes:

NOTIFICATION_SENDING_FAILED error reason for all the errors that occur during notification
sending. The dialog for creating this error reason code is shown in Figure 7.
UNKNOWN_ERROR error reason for all other errors that occur in the extension code. That is, any
errors except for those that occur during notification sending.
Figure 7. New error reason code
4/7/2016 4:31 PM
11 of 18
The Exception handling section describes how to use the error declaration in the extension code.
Generation of MDM artifacts

After you define the structure of the module, you can use tools provided by MDM Workbench to generate
the artifacts required for implementing behavior extensions. Before generating the artifacts, validate your
model by selecting the Validate model action in the MDM Model Editor. After validating your model,
select the Generate code action to create the required artifacts.
Figure 8 shows a screenshot of the MDM Workbench after the Generate code action is executed for the
DemoBehaviorExtensions project.
Figure 8. DemoBehaviorExtensions project after code generation
SQL files with <SCHEMA>
placeholder
After creating your first module project,
the application.mdmxmi file is created in
the main MDM project. Update this file to
set the database schema name.
Otherwise, the generated SQL files will
have the <SCHEMA> placeholder in
place of the actual schema name.
As a result of the Validate model action, the MDM Workbench generates the following code artifacts for
each of the modules that contain behavior extensions:
Java source code that includes classes with reusable constants and a skeleton of the class that
implements the extension's business logic
JRules skeleton file for the extensions implemented using ILOG JRules
SQL queries required to deploy the extensions to the underlying MDM Server
In addition to generating new code artifacts, the MDM Workbench also does the following:
Creates a list of TODO tasks.
Updates the descriptor for the underlying MDM application to
include the extension.
Extends the class path of the existing MDM modules extended by
the behavior extension. This step is irrelevant in the coding stage
but very important for the deployment of the extension. In our
sample scenario, the MDM Workbench modifies the class path of
the PartyEJB module because both of the extensions to
Class path for new extensions

In some cases, the MDM Workbench is
unable to determine which of the existing
MDM modules the extension belongs to.
For example, an extension triggered for
all the transactions (TransactionCategory
= All) does not extend a particular MDM
module. In this case, you must put the
name of the extension's jar file into the
class path of DWLCommonServicesEJB
module.
DemoBehaviorExtensions are triggered by the Party-related

transactions. The change made by the MDM Workbench is shown in Figure 9.
Figure 9. The class path for the PartyEJB module after being changed by MDM Workbench
4/7/2016 4:31 PM
12 of 18
Implementing an extension using Java

General concepts
The idea behind Java-based behavior extensions is fairly simple. You just need to extend and implement
the abstract class as shown in Listing 1.
Listing 1. Common class for MDM behavior extensions
package com.dwl.base.extensionFramework;
public abstract class ClientJavaExtension
{
public abstract void execute
(com.dwl.base.extensionFramework.ExtensionParameters params);
}
You should use the incoming parameter of the ExtensionParameters class (shown in Listing 2) as the
main source of information about the MDM transaction that is being executed. All of the properties of this
class have public accessor methods and can be used in extension code.
Listing 2. Part of the declaration of the ExtensionParameters class
public class ExtensionParameters
{
protected String transactionType;
protected String transactionCategoryType;
protected String actionType;
protected String actionCategoryType;
protected String triggerCategoryType;
protected String lineOfBusiness;
protected String geographicalRegion;
protected String company;
protected DWLControl control;
protected Object workingObjectHierarchy;
protected Object transactionObjectHierarchy;
protected Object additionalDataMap;
protected String[] inquiryParameters;
protected DWLStatus extensionSetStatus;
...
}
The getControl() method of the ExtensionParameters class returns an instance of the
4/7/2016 4:31 PM
13 of 18
com.dwl.base.DWLControl class. You can use the instance of this class to retrieve information from
the DWLControl block of the MDM transaction. This can be the client's user name
(getRequesterName() method), language preferences (getRequesterLanguage() method ),
authentication and security token information, and any additional attributes added by the client application
to the DWLControl block of the MDM transaction.
Working with MDM objects

One of the interesting aspects of developing a behavior extension is getting access to the MDM objects.
When working on the client side, you use MDM transactions whenever you need to read or change an
MDM business object such as Party or Address. But when you are developing a behavior extension, you
are working on the server side. Therefore, there is no need to execute MDM transaction using "heavy"
remote protocols like SOAP or RMI. Instead, when developing an extension, you can use the server-side
API to get access to whatever MDM objects you need.
First , you may need to access the business object that is being processed by the transaction that the
extension is being applied to. This can be done using the getTransactionObjectHierarchy()
method of the ExtensionParameters class. This method returns a full hierarchy of business objects
related to the currently executed transactions. For example, if the current transaction is updatePerson,
then getTransactionObjectHierarchy() returns an instance of the
com.dwl.tcrm.coreParty.component.TCRMPersonBObj class, but if the current transaction is
addPartyRelationship then it returns an instance of the
com.dwl.tcrm.coreParty.component.TCRMPartyRelationshipBObj class.
Another way to get access to MDM objects is to use server-side API classes like TCRMPartyComponent.
These classes provide methods to get access to MDM objects in a way that is similar to how you would
do it using remote transactions. Both of these approaches are shown in Listing 3.
Listing 3. Examples of using the MDM server-side API in extension code
Object txObject = params.getTransactionObjectHierarchy();
if (txObject instanceof TCRMPartyRelationshipBObj)
{
TCRMPartyRelationshipBObj tcrmRelationship =
(TCRMPartyRelationshipBObj) txObject;
//check if new relationship is of type SpouseOf
if (RELATIONSHIP_TYPE_SPOUSEOF.equalsIgnoreCase(
tcrmRelationship.getRelationshipType()))
{
emailSender.sendMessage(
tcrmRelationship.getRelationshipFromValue(),
params.getControl());
emailSender.sendMessage(
tcrmRelationship.getRelationshipToValue(),
params.getControl());
}
}
...
public void sendMessage(String partyId, DWLControl control) throws Exception
{
...
TCRMPartyComponent partyComponent = (TCRMPartyComponent)
TCRMClassFactory.getTCRMComponent("party_component");
// find a legal name of a customer
Vector tcrmNames = partyComponent.getAllPersonNames(partyId, "1", control);
...
Vector tcrmContactMethods =
partyComponent.getAllPartyContactMethods(partyId, "1", control);
if (tcrmContactMethods != null && !tcrmContactMethods.isEmpty())
{
for (Iterator iterator = tcrmContactMethods.iterator();
iterator.hasNext();)
{
TCRMPartyContactMethodBObj tcrmPartyContactMethod =
(TCRMPartyContactMethodBObj) iterator.next();
4/7/2016 4:31 PM
14 of 18
TCRMContactMethodBObj tcrmContactMethod =
tcrmPartyContactMethod.getTCRMContactMethodBObj();
String contactMethodType =
emptyIfNull(tcrmContactMethod.getContactMethodType());
if (contactMethodType.equalsIgnoreCase(CONTACT_METHOD_TYPE_EMAIL))
{
email = tcrmContactMethod.getReferenceNumber();
break;
}
}
}
...
}
Logging
To get access to MDM logs, use the IDWLLogger class provided by MDM server. You can either create a
new instance of the logger or reuse an instance provided by the ExtensionParameters class. Both of
these approaches are demonstrated in Listing 4.
Listing 4. Using IDWLLoggeri in extension code
class MyExtension extends ClientJavaExtensionSet
{
private final IDWLLogger logger;
public MarriageNotificationTriggerJava()
{
logger = DWLLoggerManager.getLogger(MyExtension.class);
logger.finest("Debug message");
logger.infor("Info message");
logger.fatal("Error message")
}
public void execute(ExtensionParameters params)
{
IDWLLogger plogger = params.getLogger();
plogger.finest("Debug message from another logger instance");
}
}
Exception handling
As you can see in Listing 1, the declaration of the execute() method of the ClientJavaExtension
class does not imply any exception throwing. Therefore, you must handle all of the exceptions that occur
in the extension code, inside the extension. Listing 5 provides an example of proper exception handling in
extension code. This kind of exception handling guarantees that MDM Server will rollback the underlying
transaction and the MDM Client will get a proper error message. In our example, we use the error type
and reason code from the same MDM module as the extension code.
Listing 5. Common exception handling in extension Code
private static final String ERROR_REASON_TYPE = "DEMOERR";
/**
Method provides a proper handling of exceptions
thrown out in the extension code
@param errorReason Valid values are:
DemoBehaviorExtensionsErrorReasonCode.NOTIFICATION_SENDING_FAILED
DemoBehaviorExtensionsErrorReasonCode.UNKNOWN_ERROR
*/
private void handleException(Exception exception,
String errorReason,
ExtensionParameters params)
{
logger.error(exception);
DWLStatus status = new DWLStatus();
DWLError error = errorHandler.getErrorMessage(
DemoBehaviorExtensionsComponentID.MARRIAGE_NOTIFICATION_TRIGGER_JAVA,
ERROR_REASON_TYPE,
errorReason,
params.getControl(),
new String[0]);
error.setThrowable(new TCRMException(exception.getLocalizedMessage()));
status.addError(error);
status.setStatus(DWLStatus.FATAL);
params.setExtensionSetStatus(status);
params.setSkipExecutionFlag(true);
}
Implementing an extension using ILOG JRules
4/7/2016 4:31 PM
15 of 18
An alternative to implementing extensions with Java, is to use a rules engines to extend the functionality
of MDM Server. MDM Server provides a default ILOG JRules rule engine. If required, you can replace
this rules engine with another rules engine. When you create a behavior extension through the rules
engine, the adapter asserts a rule fact that includes the extension parameters and the current business
object. It then calls on the rules engine to activate the rules. The results of executing the rule, including
any error status, are ultimately returned to the originating controller method. For more information on
rules and rule engines, see "Chapter 6, Configuring external business rules," of the MDM Developer's
Guide. (This document is included as part of the MDM Server installation.)
This tutorial describes how to create behavior extensions in ILOG JRules. Implementing business rules
consists of developing the rule script in the form of a JRules .ilr file, registering that file with the Extension
Handler, and then defining under what conditions to activate the rules in that rule set. If you create your
extensions using MDM Workbench, it generates all the SQL scripts required for the registration. If you
know the JRules syntax, you can develop the rules script in any text editor, but for production use of
JRules, you should use the ILOG enterprise business rule management tools.
In the sample scenario, we implement a single rule, triggered by the updatePerson transaction. Event
assignments work in the same way as for Java-based behavior extensions, which is described in the
Event types section. The .ilr file can include a ruleset with several rules. The decision on which of the
rules must be executed is made by the rules engine based on the rule conditions.
Listing 6 shows the source code of the rule. In the example, the rule condition says that extensions must
be executed only if the updatePerson transaction is called and the value of the maritalStatusType field
was changed to 1, which means that the person is now married. In the body of the rule, we reuse the
Java code for Java-based extensions to send a notification to the customer's personal email.
Listing 6. Behavior extension implemented in ILOG JRules
import
import
import
import
import
import
import
import
import
import
import
import
java.util.*;
javax.mail.*;
javax.naming.*;
com.dwl.base.*;
com.dwl.base.error.*;
com.dwl.base.extensionFramework.*;
com.dwl.base.logging.*;
com.dwl.tcrm.coreParty.component.*;
com.dwl.tcrm.exception.*;
com.dwl.tcrm.utilities.*;
com.ibm.mdm.demo.*;
com.ibm.mdm.demo.constant.*;
ruleset MarriageNotificationTriggerILog
{
IDWLLogger logger = ExtensionParameters.getLogger();
};
function String rulesetName()
{
return ("MarriageNotificationTriggerILog");
}
rule UpdatePersonRule
{
when
{
?x:ExtensionParameters(getActionType().equalsIgnoreCase("updatePerson"));
?p:TCRMPersonBObj(hasChanged("MaritalStatusType") == true; a
getMaritalStatusType().equalsIgnoreCase("1"));
}
then
{
logger.finest("Entered rule extension code");
MarriageNotificationSender ?sender = new MarriageNotificationSender();
sender.sendMessage(p.getPartyId(), x.getControl());
logger.finest("Exiting rule extension code");
}
};
4/7/2016 4:31 PM
16 of 18
Extension deployment
Final extension deployment includes two steps:
Registering extensions in the MDM Server extension framework
Packaging and deployment of Java-based extensions on the application server
To register the extensions in the extension framework, you need to
execute the SQL script generated by the MDM Workbench. This
script includes a number of SQL INSERT statements that populate
the MDM back-end database with all the data required for the
proper functioning of the extension. Usually, you can find the script
in the resources folder of the extension project (for the sample
project, the script is at esources/db2
/DemoBehaviorExtensions_MetaData_DB2.sqlin). To execute the
script you can use the following command:
db2 -tvf <FILE_PATH>
For extensions implemented in ILOG JRules, the deployment

process would be finished at this stage, but Java-based extensions
must also be deployed on the application server.
The simplest way to deploy an extension to the application server is
to redeploy the whole MDM Server using the MDM Workbench
Using J2EE Resources in

extension code
The J2EE Application MDM Server can
leverage all of the capabilities and
resources of the underlying J2EE
application server. The same applies to
MDM extensions. However, extensions to
the behavior of existing J2EE modules do
not have their own J2EE deployment
descriptors. Therefore if you need to use
a J2EE resource (for example,
javax.jdbc.DataSource, or
javax.mail.Session), you need to declare
the resources in the descriptor of an
existing MDM module where the
extended transactions are located. In the
sample project, the extension code uses
the javax.mail.Session object, which is
declared in the deployment descriptor for
the PartyEJB module.
deployment wizard. To start the wizard, right click in Package

Explorer, and from the context menu select New > Other > MDM Workbench > MDM Development and
Test Environment. This takes you to the dialog shown in Figure 10.
Figure 10. MDM Workbench deployment wizard
4/7/2016 4:31 PM
17 of 18
While redeploying the whole MDM Server is the simplest way to deploy an extension, it is not always the
most practical or efficient way to do so. Extension developers will likely need to deploy their extensions
quite often, and repeatedly redeploying the MDM Server would take too much of their time. In this case,
you can instead manually build a jar file for the extension and deploy just this file on the MDM Server
using the WebSphere Application Server Console or hot redeployment options.
Summary
Conclusion
In this tutorial we introduced the concept of behavior extensions and how to implement them with the
MDM Workbench for the InfoSphere Master Data Management Server.
Acknowledgment
The authors would like to thank their colleague and mentor Ivan Milman for his suggestions and feedback
on this tutorial. We would also like to thank Catherine Griffin for her valuable feedback on this tutorial.
Download
Description
Name
Size
Sample Files used in Tutorial
resources.zip
28KB
Resources
Dig deeper into Information

management on
4/7/2016 4:31 PM
18 of 18
Learn
developerWorks
[1] Enterprise Master Data Management: An SOA Approach to Managing

Core Information This book provides an authoritative, vendor-independent
Overview
MDM technical reference for practitioners: architects, technical analysts,

consultants, solution designers, and senior IT decision makers.
Technical library (tutorials and more)
[2] IBM InfoSphere Master Data Management Server Information Center

contains documentation for MDM Server.
Community
[3] The InfoSphere Master Data Management Server website provides more
details on the MDM Server offering and MDM solutions.
[4] Trial: Rational Software Architect for WebSphere Software provides a link
you can use to download a 30-day trial version of the software.
New to Information management
Forums
Downloads
Products
Events
developerWorks Premium
Exclusive tools to build your next
great app. Learn more.
[5] Rational Software Architect Information Center contains documentation for

the Rational Software Architect.
[6] Eclipse Web site.
[7] MDM Workbench White Paper provides more details on the MDM
Workbench.
[8] The MDM Workbench Web site provides more details on the MDM
developerWorks Labs
Technical resources for innovators
and early adopters to experiment
with.
IBM evaluation software

Evaluate IBM software and
solutions, and transform
challenges into opportunities.
Workbench offering.
[9] The ILOG Web site.
[10] The ILOG JRules Web site provides more details on ILOG JRules.
Get products and technologies
Download IBM product evaluation versions or explore the online trials in the
IBM SOA Sandbox and get your hands on application development tools and
middleware products from DB2, Lotus, Rational, Tivoli, and
WebSphere.
Discuss
Participate in the discussion forum.
Participate in the discussion on MDM Server MDM Server and on MDM
Workbench.
Participate in the discussion on Rational Development Tools: Rational Forum
and on Rational Software Architect.
4/7/2016 4:31 PM

Implementing InfoSphere Master Data Management Behavior Extensions

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing InfoSphere Master Data Management Behavior Extensions

Uploaded by

Copyright:

Available Formats

Implementing InfoSphere Master Data Management behavior extensions