Configuration and Deployment of External Rules in MDM Workbench 11.4

Body

IBM InfoSphere MDM provides a set of out-of-the-box entity processing rules, like 'partyMatch' or 'collapseParties'. These rules are extendible and this blog entry will walk through the process of extending one of them – 'collapsePartiesWithRules'.

Assuming that a development project has already been created in the workspace, code for the project has been generated and setup SQL scripts have been ran – create a new package in the project's 'src' folder (For example: 'com.ibm.mdm.customRules'). Within that package create a new java class (For example: 'CustomCollapse.java'). As we are looking at extending 'collapsePartiesWithRules' the Java class should extend the 'CollapsePartiesWithRules' class and its 'execute' method should be overridden.

Within the new class the default 'collapse' can be used by calling the 'collapseObjectsSurvivingRules()' method on the TCRM component and supplying the parties that need collapsing inside a 'Vector' object. Additional behaviour can be defined as well.

The created package and Java class should then be added to the 'blueprint.xml' file present in the development project as follows:

 

<?xml version="1.0" encoding="UTF-8"?>

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0&quot; default-activation="eager">

<bean id="RuleLocatorBean" scope="singleton" class="com.dwl.base.externalrule.RuleLocatorImpl">

<property name="bpBundle" ref="blueprintBundle"/>

<argument>

<list>

<bean class="com.ibm.mdm.customRules.CustomCollapse"/>

</list>

</argument>

</bean>

<service id="ExternalRuleLocatorService" ref="RuleLocatorBean" interface="com.dwl.base.externalrule.RuleLocator" ranking="50">

<service-properties>

<entry key="rule.java.impl">

<list>

<value>com.ibm.mdm.customRules.CustomCollapse</value>

</list>

</entry>

</service-properties>

</service>

</blueprint>

 

The following packages also need to be added to the 'manifest.mf' file of the project to export the package that contains the external rule class:

 

Export-Package: com.ibm.mdm.customRules

Import-package: com.dwl.base.externalrule

 

The below packages also need to be added to the 'compositebundle.mf' file so that the rule framework can find the new class:

 

CompositeBundle-ExportService: com.dwl.base.externalrule.RuleLocator

Export-Package: com.ibm.mdm.customRules

Import-Package: com.dwl.tcrm.externalrule

 

Export the 'CBA' using the wizard and deploy it to the server (instructions for one of the approaches to deploying a CBA can be found here).

To make the system use the modified rule an update to the database needs to be run. Search the 'JAVAIMPL' table for an entry with the 'JAVA_CLASSNAME' of 'com.dwl.tcrm.externalrule.CollapsePartiesWithRules' and note the rule id ('1038' in this case). Run the following sql to update the class name to the updated rule:

 

UPDATE SCHEMA.JAVAIMPL SET JAVA_CLASSNAME = 'com.ibm.mdm.customRules.CustomCollapse', LAST_UPDATE_DT = CURRENT_TIMESTAMP WHERE EXT_RULE_IMPL_ID = 1038;

 

Restart the server.

The next step would be to re-configure the Optimized Transparent SQL (OTS) queries. OTS queries allow the 'SELECT' statements used to retrieve data from the database to be customized and optimized for a given deployment.

The 'INQLVL' table defines the set of OTS capable entities and their associated inquiry levels. Depending on the types of the objects that will be collapsed – the appropriate 'GROUP_NAME' should be looked up. In this example we will be working with Organizations.

 

 

The values to note are 'INQLVL_ID' and 'INQLVL'. It's worth noting that the 'SELECT' statements themselves are not stored in this table, but rather are contained within 'INQLVLQUERY' table.

 

 

Each combination of Entity-Inquiry Level contains one or more 'SELECT' statements within the table. These statements are also associated with a 'BUSINESS_TX_TP_CD' value (32) which is derived from the 'CDBUSINESSTXTP' table and defines the associated query transaction.

The 'CDINQLVLQUERYTP' table defines the possible type code values for entries in the 'INQLVLQUERY' table.

 

 

'CDBUSINESSTXTP' table contains a list of available transactions and associated 'BUSINESS_TX_TP_CD' values.

 

 

The OTS queries need to be re-generated and updated to include the extended fields after the customized CBA has been deployed, otherwise those fields will be omitted from the response. The 'add' and 'update' transactions are not affected as they are not query transactions. There exists an 'updateInqLevel' transaction to re-build these queries.

For each Inquiry Level Id resolved above a single 'updateInqLevel' transaction needs to be ran against the server. The following fields need to be filled out: InquiryLevelId (from the 'INQLVL' table), InquiryLevelLastUpdateDate (from the 'INQLVL' table), GenerateQuery (set to 'Y' to rebuild the queries) and BusinessTxType (from the 'INQLVLQUERY' table). So for Organization (inquiry level 3) the following transaction will be used:

 

<?xml version="1.0" encoding="UTF-8"?>

<DWLAdminService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:noNamespaceSchemaLocation="DWLAdminService.xsd">

<RequestControl>

<requestID>1000</requestID>

<DWLControl>

<requesterName>cusadmin</requesterName>

<requesterLanguage>100</requesterLanguage>

</DWLControl>

</RequestControl>

<DWLTx>

<DWLTxType>updateInqLevel</DWLTxType>

<DWLTxObject>DWLInqLevelBObj</DWLTxObject>

<DWLObject>

<DWLInqLevelBObj>

<InquiryLevelId>1012</InquiryLevelId>

<InquiryLevelLastUpdateDate>2005-04-13 11:11:28.205001</InquiryLevelLastUpdateDate>

<GenerateQuery>Y</GenerateQuery>

<BusinessTxType>32</BusinessTxType>

</DWLInqLevelBObj>

</DWLObject>

</DWLTx>

</DWLAdminService>

 

The response produced will contain two unusual characteristics. Here is what it will look like:

 

<?xml version="1.0" encoding="UTF-8"?>

<DWLAdminService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:noNamespaceSchemaLocation="DWLAdminResponse.xsd">

<ResponseControl>

<ResultCode>SUCCESS</ResultCode>

<ServiceTime>1108</ServiceTime>

<DWLControl>

<requesterLanguage>100</requesterLanguage>

<requesterLocale>en</requesterLocale>

<requesterName>mdmadmin</requesterName>

<requestID>1000</requestID>

<userRole>mdm_admin</userRole>

<requesterTimeZone>America/New_York</requesterTimeZone>

</DWLControl>

</ResponseControl>

<TxResponse>

<RequestType>updateInqLevel</RequestType>

<TxResult>

<ResultCode>SUCCESS</ResultCode>

</TxResult>

<ResponseObject>

<DWLInqLevelBObj>

<InquiryLevelId>1013</InquiryLevelId>

<Application>TCRM</Application>

<GroupName>Organization</GroupName>

<InquiryLevel>4</InquiryLevel>

<CumulativeIndicator>Y</CumulativeIndicator>

<Description>Level 4 Organization Objects</Description>

<InquiryLevelLastUpdateDate>2005-04-13 11:11:28.205003</InquiryLevelLastUpdateDate>

<DWLStatus>

<Status>5</Status>

<DWLError>

<ComponentType>99</ComponentType>

<ErrorMessage>The data submitted already exists on the database; no update applied.</ErrorMessage>

<ErrorType>DRECERR</ErrorType>

<LanguageCode>100</LanguageCode>

<ReasonCode>603</ReasonCode>

<Severity>5</Severity>

<SeverityValue>Warning</SeverityValue>

</DWLError>

</DWLStatus>

</DWLInqLevelBObj>

</ResponseObject>

</TxResponse>

</DWLAdminService>

 

Because the transaction does not make any changes to the 'INQLVL' table itself – the last update date does not get changed and the transaction reports an error stating that the data has not been updated. However, the contents of the 'INQLVLQUERY' table shows that the changes have been applied and both the queries and the last update date have changed.

Custom rules should now work and transactions implementing these rules should return the contents of the default and extended fields.