MDM Notification Framework and Types of Notification

Notification types and contents

Notification messages are constructed based on the notification type. A number of notification types are provided with InfoSphere® MDM out-of-the-box.

The existing notification business objects are defined as OSGi services using the CommonServiceFactory service pattern. The following are the default notification types.

NotificationType.nt1=com.dwl.tcrm.coreParty.notification.A1PartySelectedNotification
NotificationType.nt2=com.dwl.tcrm.coreParty.notification.SuspectIdentificationNotification
NotificationType.nt3=com.dwl.tcrm.coreParty.notification.AutoSuspectReIdentificationNotification
NotificationType.nt4=com.dwl.tcrm.coreParty.notification.ManualSuspectEntryAdjustmentNotification
NotificationType.nt5=com.dwl.tcrm.coreParty.notification.ElementChangeNotification
NotificationType.nt6=com.dwl.tcrm.coreParty.notification.DeletePartyHistoryNotification
NotificationType.nt7=com.dwl.tcrm.coreParty.notification.PendingCDCRequestNotification
NotificationType.nt9=com.ibm.mdm.suspect.notification.EntitySuspectNotification
NotificationType.nt10=com.ibm.mdm.suspect.notification.EntitySuspectNotification
NotificationType.nt11=com.ibm.mdm.suspect.notification.EntitySuspectNotification

Here is a sample blueprint service definition of a notification type:

<service id="A1PartySelectedNotification" interface="com.ibm.mdm.common.servicefactory.api.CommonServiceFactory">
  <service-properties>
   <entry key="common.service" value="NotificationType.nt1"/>
  </service-properties>
  <bean class="com.ibm.mdm.common.servicefactory.CommonServiceFactoryImpl">
   <argument type="java.lang.Class" value="com.dwl.base.notification.CommonNotification"/>
   <argument type="java.lang.Class" value="com.dwl.tcrm.coreParty.notification.A1PartySelectedNotification" />   
   <argument ref="blueprintBundle"/>   
  </bean>
 </service>

The following table shows the information included within each type of notification object:

Table 1. Information included with each notification object

Notification Type	Notification Value	Information Included
nt1	A1 Party Selected	Details of original source party passed to Add Party transaction Details of A1 matched party selected List of other A1 matched parties found (exceptional case)
nt2	Suspect Identification	Source party Suspects marked to source party
nt3	Auto Suspect Re-identification	Reason for Re-Identification (critical data change | critical data add | collapse parties | split party) Before/After image if critical data change Image if critical data add Source party New suspects to source party created Existing suspects to source party updated Deleted suspects
nt4	Manual Suspect Entry Adjustment	Source/Target Parties Before Status After Status
nt5	Element Change	Element Name Element Identifier Before and After Images of Element's Value.
nt6	Delete Party History	Note of ‘Party history has been deleted for this party'. PartyId Additional Information
nt7	Pending Critical Data Change Request	Element name Before update After update
nt9	Update Product Suspects	Source product List of suspects before update List of suspects after update
nt10	Delete Product Suspects	Source product List of deleted suspects
nt11	Add Product Suspects	Source product List of added suspects
ntem	Event Manager to the Topic	Notification message for the happened Event

Evergreening

Evergreening is one part of DWL application. As the name suggests that its motive is to keep the information always up to date. This is basically a matching process where information of customers coming from different sources are matched implementing some logic. Ever greening is run 24/7.  As per the degree of matching between records the matches are divided into three classes:

·         A1 match

When there is a very high degree of matching between two or more records then it is called A1 match. Whenever there is any A1 match between records then these records are merged and one single record is generated as per logic.

·         B match

This is also known as “LEVEL 2” match. Here the degree of matching is less than A1. When this match is found between records then some additional processing is performed on the records.

Locating and importing the InfoSphere MDM Probabilistic Matching Engine model

The InfoSphere® MDM Probabilistic Matching Engine model consists of the data model definitions and associated algorithms that are used for matching MDM data.

About this task

The model definitions and matching algorithms can be extracted from com.ibm.mdm.mds.pme.configuration_11.x.x.jar bundle located in the <workbench install folder>\com.ibm.mdm.tools\server_bundles\mdm\ folder.

Procedure

1. Extract the contents of the com.ibm.mdm.mds.pme.configuration_11.x.x.jar file to a local file system, then extract the resultingmdmpme.config.zip file.
2. In the MDM Workbench, in the MDM Configuration perspective, click Master Data Management > New Configuration Project.
3. Specify Party as the project name to create a new virtual MDM project with the name Party.
   Note: By convention, the new project name should be the same as the name of the .imm file that is part of the import.

   If a different name is required, the configuration element /IBM/BusinessServices/PME/configuration will need to be modified accordingly. For more information, see Specifying a different InfoSphere MDM Probabilistic Matching Engine configuration
4. Click Next to continue and accept all default selections.
5. Delete the party.imm file that the New Virtual Hub Project wizard has just created.
6. Exit, then restart the MDM Workbench.
7. Select File > Import, then select General > File System as the import source.
8. To define the From Directory, browse and select the configuration directory extracted from the mdmpme.config.zip file. Select all the contents of the directory to import.
9. Specify Party as the Into Folder.
10. Click Finish. The Workbench will import all of the selected files.
11. If you are asked if you wish to overwrite existing files, select Yes.
    Tip: If you are importing over an existing configuration and encounter errors during the import process, delete the .alg and .imm files, then reimport the project.
12. Refresh the Party project in the MDM Workbench.

Reference:IBM website

Configuring the InfoSphere MDM Probabilistic Matching Engine in the Configuration and Management component

There is nothing you need to do to enable suspect processing with InfoSphere® MDM Probabilistic Matching Engine in the configuration repository. However, you do need to make sure that the InfoSphere MDM Probabilistic Matching Engine indices are kept synchronized with InfoSphere MDM data.

About this task

The index synchronization is configured using the configuration element /IBM/DWLCommonServices/DerivedDataSynchronization/enabled.

Procedure

In the Configuration and Management component, edit the value of the configuration element /IBM/DWLCommonServices/DerivedDataSynchronization/enabled to ensure that the value is true.

Note: The default value of this configuration element is false.

By changing the value of /IBM/DWLCommonServices/DerivedDataSynchronization/enabled to true, the InfoSphere MDM Probabilistic Matching Engineindices will be kept synchronized with InfoSphere MDM data.

Parser DWLTransaction failed. The format of the message is not correct or an application error occurred

Processing Request ...
com.dwl.base.exception.DWLResponseException: <?xml version="1.0" encoding="UTF-8"?>
<TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ECHResponse.xsd">
<ResponseControl>
<ResultCode>FATAL</ResultCode>
<ServiceTime>271</ServiceTime>
<DWLControl>
<requesterLanguage>100</requesterLanguage>
<requestID>377043104908177375</requestID>
</DWLControl>
</ResponseControl>
<TxResponse>
<RequestType>processTx</RequestType>
<TxResult>
<ResultCode>FATAL</ResultCode>
<DWLError>
<ComponentType>106</ComponentType>
<ErrorMessage>Parser DWLTransaction failed. The format of the message is not correct or an application error occurred.</ErrorMessage>
<ErrorType>READERR</ErrorType>
<LanguageCode>100</LanguageCode>
<ReasonCode>4928</ReasonCode>
<Severity>0</Severity>
<Throwable>com.dwl.base.requestHandler.exception.RequestParserException: [Exception_myErrorHandler_SAXParseError:] The parsing of the XML failed at the following position. XML = org.xml.sax.SAXParseException: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of &apos;http://www.ibm.com/mdm/schema,GenericStatusTypeBObj&apos;.; line number = 31; column number = 114</Throwable>
</DWLError>
</TxResult>
</TxResponse>
</TCRMService>
at com.dwl.base.requestHandler.DWLServiceControllerBase.processRequest(DWLServiceControllerBase.java:272)
at com.dwl.base.d





Resolution:

Since it looks like it's referring to a schema , go to the server,

Application servers > server1 > Process definition > Java Virtual Machine

Check to see teh classpath is having the references to the CustomerResources/../..xsd and properties that are part of the current workspace. 

If so , make sure they are updated and don't have any discrepancies. 

com/dwl/base/requestHandler/beans/DWLServiceController: First component in name DWLServiceController not found.

Connecting to iiop://localhost:2812 ...
Looking up com/dwl/base/requestHandler/beans/DWLServiceController ...
May 7, 2015 8:41:32 PM null null
WARNING: WSVR0072W
May 7, 2015 8:41:32 PM null null
WARNING: WSVR0072W
May 7, 2015 8:41:32 PM null null
WARNING: WSVR0072W
May 7, 2015 8:41:32 PM null null
WARNING: WSVR0072W
javax.naming.NameNotFoundException: Context: PCNode04Cell/nodes/PCNode04/servers/server1, name: com/dwl/base/requestHandler/beans/DWLServiceController: First component in name DWLServiceController not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.mapNotFoundException(CNContextImpl.java:4365)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1794)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1749)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1500)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:637)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:165)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:179)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
at com.dwl.verification.DWLServiceControllerTester.<init>(DWLServiceControllerTester.java:70)
at com.dwl.verification.DWLServiceControllerTester.main(DWLServiceControllerTester.java:134)
Caused by: org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:95)
at com.ibm.WsnOptimizedNaming._NamingContextStub.resolve_complete_info(_NamingContextStub.java:506)
at com.ibm.ws.naming.jndicos.CNContextImpl$2.run(CNContextImpl.java:2797)
at com.ibm.ws.naming.jndicos.CNContextImpl$2.run(CNContextImpl.java:2793)
at com.ibm.ws.naming.util.CommonHelpers.retry(CommonHelpers.java:763)
at com.ibm.ws.naming.jndicos.CNContextImpl.cosResolve(CNContextImpl.java:2791)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1790)
... 8 more

The above error comes when the application has not started. Check port, application start status, in the WAS console, restart application and test again. 

MDM Implementation styles

Implementation styles

Custom transactions can be implemented in two different ways, either as a business proxy transactions or as component transactions. These styles correspond to adding the custom logic at different points in the InfoSphere MDM request handling process.

Business proxy transactions add logic just before the controller level. They call other transactions at the controller level, but they cannot call other business proxies. Business proxy transactions can only call other transactions at the controller level and cannot call other business proxies.

Business proxy transactions have the following properties:

• They can add logic just before the controller level.
• They only call other transactions at the controller level.
• They cannot call other business proxies

Component transactions are called at the component level. Component transactions can only call other transactions at the component level and can call other custom component transactions.

Component transactions:

• are called at the component level
• can only call other transactions at the component level
• can call other custom component transactions

The distinction between calling transactions at the controller level and the component level is important when calling the out-of-the-box transactions since some of them have different semantics at the controller level. In general, for transactions with both coarse-grained and fine-grained variants, the coarse-grained variant is only available at the controller level.