implementing infosphere master data management behavior extensions

8/18/2019 Implementing InfoSphere Master Data Management Behavior Extensions

1/18

Share:

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 createactionable master data and improve the business value of your deployed Master Data Management (MDM) solution.

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 startThis 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 anout-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 theMDM 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

developerWorksdeveloperWorks Technical topicsTechnical topics Information ManagementInformation Management Technical libraryTechnical library

Implementing InfoSphere Master Data ManagementImplementing InfoSphere Master Data Managementbehavior extensionsbehavior extensionsMake master data actionable based on events to deliver business value

ementing InfoSphere Master Data Management behavior extensions http://www.ibm.com/developerworks/data/tutorials/dm-0910infos

8 4/7/2016

http://www.ibm.com/developerworks/data/tutorials/dm-0910infospherem...http://www.ibm.com/developerworks/data/tutorials/dm-0910infospherem...


2/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.

IntroductionMany 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?


8 4/7/2016



3/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 overviewIBM 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.


8 4/7/2016



4/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 WorkbenchThe 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.


8 4/7/2016



5/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


8 4/7/2016



6/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 scenarioThe 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 WorkbenchYou 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 theMDM Workbench looks like this:

Create a new MDM module.1.

Define all the modifications in the module (for example, behavior extensions, data additions, new error

types, new code types, new transactions, etc.).

2.

Validate the modifications.3.

Generate the MDM artifacts (source code, SQL queries, and deployment modules)4.

Implement the business logic of the modifications.5.

Package and deploy the modifications.6.


8 4/7/2016



7/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 anXML 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


8 4/7/2016

http://www.ibm.com/xmlns/mdm/demohttp://www.ibm.com/developerworks/data/tutorials/dm-0910infospherem...http://www.ibm.com/developerworks/data/tutorials/dm-0910infospherem...http://www.ibm.com/xmlns/mdm/demo


8/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


8 4/7/2016



9/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 extensioncode 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


8 4/7/2016



10/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


18 4/7/2016



11/18

SQL files with

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 willhave the placeholder in

place of the actual schema name.

Class path for new extensionsIn 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.

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

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 bythe 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

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


18 4/7/2016



12/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 extensionspackage 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


18 4/7/2016



13/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 codeObject 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();


18 4/7/2016



14/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 Codeprivate static final String ERROR_REASON_TYPE = "DEMOERR";/**Method provides a proper handling of exceptionsthrown out in the extension code

@param errorReason Valid values are:DemoBehaviorExtensionsErrorReasonCode.NOTIFICATION_SENDING_FAILEDDemoBehaviorExtensionsErrorReasonCode.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


18 4/7/2016



15/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 theEvent 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 JRulesimport java.util.*;import javax.mail.*;

import javax.naming.*;import com.dwl.base.*;import com.dwl.base.error.*;import com.dwl.base.extensionFramework.*;import com.dwl.base.logging.*;import com.dwl.tcrm.coreParty.component.*;

import com.dwl.tcrm.exception.*;import com.dwl.tcrm.utilities.*;import com.ibm.mdm.demo.*;import 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"); }

};


18 4/7/2016



16/18

Using J2EE Resources in

extension codeThe 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.

Extension deploymentFinal 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. Thisscript 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

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

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


18 4/7/2016



17/18

Resources Dig deeper into Informationmanagement on

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


18 4/7/2016



18/18

Learn

[1] Enterprise Master Data Management: An SOA Approach to Managing

Core Information This book provides an authoritative, vendor-independent

MDM technical reference for practitioners: architects, technical analysts,

consultants, solution designers, and senior IT decision makers.

[2] IBM InfoSphere Master Data Management Server Information Center

contains documentation for MDM Server.

[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.

[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

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.

developerWorks

Overview

New to Information management

Technical library ( tutorials and more)

Forums

Community

Downloads

Products

Events

developerWorks Premium

Exclusive tools to build your next

great app. Learn more.

developerWorks Labs

Technical resources for innovators

and early adopters to experiment

with.

IBM evaluation software

Evaluate IBM software and

solutions, and transformchallenges into opportunities.


implementing infosphere master data management behavior extensions

Documents