Components - query and persistence factories

The following is a description of the changes to how InfoSphere® MDM Custom Domain Hub uses and handles query and persistence factories.

Before OSGi

If you have written your own component's controllers or business proxies, it is likely that you have complete control of how these access each other. You can directly invoke a controller type object from a business proxy, or you can invoke a component type object directly from a controller type object.

You might also have been using the InfoSphere MDM Custom Domain Hub generic mechanism for obtaining a component. This mechanism is used when the implementing class for a component can change. For example, when obtaining the InfoSphere MDM Custom Domain Hub Party component, one of the most commonly used components in InfoSphere MDM Custom Domain Hub, the correct approach is to do so like this:

IParty partyComp = (IParty) TCRMClassFactory.
						getTCRMComponent("party_component");

The reason for this is that the party component is often overridden and extended with additional capabilities. The string "party_component" is used to identify the Party Component, irrespective of the Java™ class behind it. The Java class that is the party component is mapped to the string “party_component” in the TCRM.properties resource file as is shown as follows:

##################################
# BUSINESS COMPONENT CLASSES     #
##################################
address_component=com.dwl.tcrm.coreParty.component.TCRMAddressComponent
contract_history_component=com.dwl.tcrm.financial.component.TCRMContractHistoryComponent
suspect_component=com.dwl.tcrm.coreParty.component.TCRMSuspectComponent

# set value as com.ibm.mdm.eme.party.EMEPartyMatcher if eME configured
party_searcher_component=com.dwl.tcrm.coreParty.component.TCRMPartySearcher
probabilistic_party_searcher_component = com.ibm.mdm.eme.party.EMEProbabilisticPartySearcher

contactmethod_component=com.dwl.tcrm.coreParty.component.TCRMContactMethodComponent
contract_component=com.dwl.tcrm.financial.component.TCRMContractComponent
financialprofile_component=com.dwl.tcrm.coreParty.component.TCRMFinancialProfileComponent
party_component=com.dwl.tcrm.coreParty.component.TCRMPartyComponent
customer_tail_component=com.dwl.tcrm.tail.TCRMTAILComponent

Notice how all of the basic component type classes employ an identifier string and map it to a Java class. That is the common mechanism.

With OSGi

If you have replaced any of the default InfoSphere MDM Custom Domain Hub settings for these components with your own, you must do so using a blueprint configuration. For example, imagine a scenario where you’ve extended the default Party component object with a new one of your own design. You’ve created com.abc.PartyComponentExtend, and you want to replace the default party component with your own. The default Party component is com.dwl.tcrm.coreParty.component.TCRMPartyComponent. The following is the blueprint service definition you will create:

<service id="ComponentFactoryService"
		interface="com.ibm.mdm.common.component.api.ComponentFactoryService"
		ranking="10” >
	<service-properties>
		<entry key="business.component">
			<list>
				<value>party_component</value>
			</list>
		</entry>
	</service-properties>
	<bean class="com.ibm.mdm.common.component.ComponentFactoryServiceImpl">
		<argument ref="blueprintContainer"/>
		<argument>
			<map>
				<entry key="party_component"> 
							<bean class="com.abc.PartyComponentExtended"/>
				</entry>
			</map>
		</argument>
	</bean>
</service>

In the example blueprint XML, you must use the ranking="10" setting to ensure you your component factory overrides the original one that creates the original Party component, then you must then relate your new party component class to the party_component string. Remember, that string means the party component, regardless of its implementation.

The following is a list of all the component names in InfoSphere MDM Custom Domain Hub. If you have overridden any of these in the various properties files, then you must create a factory service similar to the previous example so that InfoSphere MDM Custom Domain Hub can find and use it.

Component names

access_date_value_component
admin_accessToken_component
admin_component_ef
admin_component_error_handling
admin_component_ev
admin_component_extrule
admin_component_product
admin_component_rov_data
admin_component_rov_rule
admin_component_rov_user
admin_component_sec
admin_em_component
admin_federated_component
admin_metadata_component
agreement_spec_component
alert_component
alert_history_component
billing_summary_component
business_key_collector_component
campaign_component
category_component
claim_component
codetype_admin_component
codetype_component
commonService_TAIL_component
compliance_requirement_component
contentreference_component
contract_business_services_component
contract_component
contract_history_component
crossdomainservices_component
entity_compliance_component
entity_role_component
event_component
generic_grouping_component
grouping_component
hierarchy_component
history_component
hybrid_entity_component
input_stream_collector_component
inquiry_level_collector_component
interaction_component
lob_component
map_simplifier_collector_component
mdmserverprofile_component
metadata_transformation_component
metadata_transformation_data_collector_component
privacy_preference_component
product_category_component
product_component
product_datasteward_component
productcontractrelationship_component
productnls_component
productpartyrole_component
productsuspect_component
producttype_component
questionnaire_component
searchabledynamicattribute_component
sourceValue_Component
spec_component
specformat_component
specuse_component
synchronizeservice_component
tail_transaction_component
task_component
taskdefinition_component
termcondition_component
termcondition_evaluation_component
termconditionnls_component
transaction_metadata_component
transformation_component
value_component
workbasket_component

The following is a sample blueprint for InfoSphere MDM Custom Domain Hub components that you can use. Replace ranking="XX", name_of_component, and java class of component with the text relevant to you:

<service id="ComponentFactoryService"
		interface="com.ibm.mdm.common.component.api.ComponentFactoryService"
		ranking="XX" >
	<service-properties>
		<entry key="business.component">
			<list>
				<value>name_of_component</value>
			</list>
		</entry>
	</service-properties>
	<bean class="com.ibm.mdm.common.component.ComponentFactoryServiceImpl">
		<argument ref="blueprintContainer"/>
		<argument>
			<map>
				<entry key="name_of_component"> 
							<bean class="java class of component"/>
				</entry>
			</map>
		</argument>
	</bean>
</service>

BObjQueryFactory and BObjPersistenceFactory lookup and retrieval information

BObjQueryFactory and BObjPersistenceFactory instances can be retrieved using their corresponding brokers:

BObjQueryFactoryBroker.getBObjQueryFactory(“<BObjQueryFactory key / interface name>”);
BObjPersistenceFactoryBroker.getBObjPersistenceFactory(“<BObjPersistenceFactory key / interface name>”);

For example:

(CommonEntitySamplesModuleBObjQueryFactory) BObjQueryFactoryBroker.getBObjQueryFactory(CommonEntitySamplesModuleBObjQueryFactory.class.getName());

Also, if you have used the following approach to access one of your custom components --

TCRMClassFactory.getTCRMComponent(<your component name>)

-- then you must configure a blueprint service using the template from earlier in this topic. If you have written any new Query or Persistence Factories without using the MDM Workbench, then you must likewise create services for your query factories:

<service id="BObjQueryFactoryService" 
	interface=” com.ibm.mdm.common.servicefactory.api.BObjQueryFactory”>
	<bean class="com.ibm.mdm.common.servicefactory.BObjQueryFactoryImpl">
		<argument>
			<map>
				<entry key="query factory interface name">
					<bean class=" query factory class name "/>
				</entry>
			</map>
		</argument>
		<argument ref="blueprintBundle"/>
	</bean>
</service>
<service id="BObjPersistenceFactoryService" 
	interface="com.ibm.mdm.common.servicefactory.api.BObjPersistenceFactory">
	<bean class="com.ibm.mdm.common.servicefactory.BObjPersistenceFactoryImpl">
		<argument>
			<map>
				<entry 	key="persistence factory interface name">
					<bean class="persistence factory class name"/>
				</entry>
			</map>
		</argument>
		<argument ref="blueprintBundle"/>
	</bean>
</service>

For example, suppose you have overridden the default InfoSphere MDM Custom Domain Hub query and persistence mechanism for the Address Entity. You must create a new factory for it. The Query and Persistence mechanism for the Address entity is the PartyAddressBObjQuery, and the Query and Persistence factories are the PartyModuleBObjQueryFactory and PartyModuleBObjPersistenceFactory with a single implementation for both: PartyModuleBObjQueryFactoryImpl. Your new implementation will look something like this:

<service id="BObjQueryFactoryService" 
	interface="com.ibm.mdm.common.servicefactory.api.BObjQueryFactory">
	<bean class="com.ibm.mdm.common.servicefactory.BObjQueryFactoryImpl">
		<argument>
			<map>
				<entry
					key="com.dwl.tcrm.coreParty.bobj.query.PartyModuleBObjQueryFactory">
					<bean class="x.y.z.myNewPartyQueryFactoryImpl"/>
				</entry>
			</map>
		</argument>
		<argument ref="blueprintBundle"/>
	</bean>
</service>
<service id="BObjPersistenceFactoryService" 
	interface="com.ibm.mdm.common.servicefactory.api.BObjPersistenceFactory">
	<bean class="com.ibm.mdm.common.servicefactory.BObjPersistenceFactoryImpl">
		<argument>
			<map>
				<entry 
				key="com.dwl.tcrm.coreParty.bobj.query.PartyModuleBObjPersistenceFactory">
					<bean class="x.y.z.myNewPartyQueryFactoryImpl"/>
				</entry>
			</map>
		</argument>
		<argument ref="blueprintBundle"/>
	</bean>
</service>

Last updated: 9 Dec 2016