Parse request

When you invoke InfoSphere® MDM Custom Domain Hub, you must supply a java.util.Map type object describing the transaction context.

An example of this is the following:

Map context = new HashMap();
    context.put("TargetApplication","tcrm");
    context.put("RequestType", "standard");
    context.put("ResponseType", "standard");
    context.put("Parser", "TCRMService");
    context.put("Constructor", "TCRMService");
    context.put("OperationType", "All");

One of the transaction context entries specifies a name that describes that parser that you intend for InfoSphere MDM Custom Domain Hub to use.

Before OSGi

############################
# Parser Factory is internal and is not passed through the context
#
# ParserFactory.<TargetApplication property value>.<RequestType property value>
#
ParserFactory.tcrm.standard=com.dwl.base.requestHandler.DWLParserFactory
ParserFactory.tcrm=com.dwl.base.requestHandler.DWLParserFactory

ParserFactory.tcrm.xml=com.dwl.base.requestHandler.DWLParserFactory
############################
# Parser
#
# Parser.<TargetApplication property value>.<Parser property value>
#
# The key without the Parser property value can be used to define
# the default value if nothing was supplied.
#
Parser.tcrm.TCRMService=com.dwl.tcrm.coreParty.xmlHandler.XMLRequestParser
Parser.tcrm=com.dwl.tcrm.coreParty.xmlHandler.XMLRequestParser

The InfoSphere MDM Custom Domain Hub request response framework would assemble a property key, such as ParserFactory.tcrm.standard using the information included in the transaction context. It would use it to look up the relevant parser factory in the DWLComon.properties resource bundle and then use reflection to construct that parser factory. The default parser factory, in turn, would look up the relevant parser using another string such as Parser.tcrm.TCRMService.

Using OSGi

There are two ways that you may have supplied your own parsers. The most common way is to reuse the InfoSphere MDM Custom Domain Hub request parser factory and to plug your additional parser(s) into it. If you did that, then this is the blueprint pattern you should use to declare your parsers and register them with the InfoSphere MDM parser factory:

<service id="ParserFactory" 
	interface="com.dwl.base.requestHandler.interfaces.IRequestParserFactory">
	<service-properties>						
		<entry key="parser">
			<list>
		 		<value>MyCustomParser</value>
		 		<value>MyOtherCustomParser</value>
		 	</list>
		 </entry>
	</service-properties>		
	<bean class="com.ibm.mdm.base.requestHandler.ParserFactoryServiceImpl" >
		<property name="bpContainer" ref="blueprintContainer"></property>
		<property name="bpBundle" ref="blueprintBundle"></property>
	</bean>
</service>
<bean id="Parser.MyCustomParser" class="x.y.z.MyCustomParserImpl" scope="prototype"/>
<bean id="Parser.MyOtherCustomParser" class="x.y.z.MyOtherCustomParserImpl" scope="prototype"/>

In this blueprint example, you declare a parser factory service as an OSGi service and list the names of the parsers that it will construct. The default parser factory that InfoSphere MDM Custom Domain Hub uses for its own parsers is com.ibm.mdm.base.requestHandler.ParserFactoryServiceImpl expects all the parsers that it will create to be specified as blueprint beans. In this example, there are two parsers you are supplying: MyCustomParser, and MyOtherCustomParser. Each of these parsers must be specified in the same blueprint file as follows:

<bean id="Parser.MyCustomParser" class="x.y.z.MyCustomParserImpl" scope="prototype"/>
<bean id="Parser.MyOtherCustomParser" class="x.y.z.MyOtherCustomParserImpl" scope="prototype"/>

The second way is to define a separate parser factory for your custom parsers. If you did that, then you must use the following blueprint sample to define your parser factory:

<service id="ParserFactory" 
	interface="com.dwl.base.requestHandler.interfaces.IRequestParserFactory">
	<service-properties>						
		<entry key="parser">
			<list>
		 		<value>A name describing a parser this factory creates</value>
		 		<value>Another name </value>
		 		<value>Add as many of these as you need</value>
		 	</list>
		 </entry>
	</service-properties>		
	<bean class="the fully qualified class name that is your parser factory" >
	</bean>
</service>

That represents the basic parser template. If there is more than one type of parser that your parser factory might create, you can employ OSGi blueprint techniques that allow you to configure which parser you want the factory to construct. For example, you can specify additional bean-type classes in the blueprint file for your parser factory and allow the factory to retrieve the beans. This is the approach illustrated in this topic with the standard InfoSphere MDM Custom Domain Hub XML parser. You can also inject several different parsers into the parser factory when your bundle starts, or you can hard code the your parser factory to return only one parser. However, the essential mechanism continues to be based on the transaction context. The parser manager in InfoSphere MDM Custom Domain Hub will look for a parser factory OSGi service based on the name in the transaction context.

Last updated: 9 Dec 2016