Hi,

I am working on writting some generic services that calls any map service and returns the transformed output. The input/output can be of any format(XML.EDI or FF). Following

Approach 1 :
Get the content, do an appropriate convertToValues in the handler service and call the actual map service that takes the converToValues output and maps to another IS document.
Map service : input - IS document(any format) output - IS document(any format)
handler service : input - string(edi,ff or xml) output string(edi,ff or xml)
pros : map service developer need not wory about converToValues or converToString
cons : iterate feature of the converToValues cannot be used as it depends upon the schema which is map dependant

Approach 2 :
Get the content as string, call the map service which does the convertToValues internally

Map service : input - string(edi, ff or xml) output - IS document(any format)
handler service : input - string(edi,ff or xml) output string(edi,ff or xml)
pros : can use the iterate feature of convertToValues
cons : map service developer need to write converToValues/convertToString for each map

Appreciate your inputs on this.

I think what you trying to do in both options is simply create a generic document handler to handle any type of document. To accomplish this, you would need to have some sort of identifier that indicates the document that it is, then dynamically call the appropriate sub-handlers based on the document type. I would receive the document as an object so there isn’t a set structure.

After receipt, there would need to be a service (either something pub.xml:getXMLNodeType or comparable) that would indicate the document type, and trigger the appropriate next step. You may also need to enlist some “ifExists” type commands to check the field contents.

I would also use a canonical within most of the general document processing in order to make the most of the reusability.

Hope that helps a little…or at least leads you in a good direction.

There is another approach that may be easier in the long run. Integration Server has a number of content handlers built-in.

When a client submits a document into integration server, the content type is normally specified and the appropriate content handler parses the file.

Here is a quick overview of the three major content handlers in Integration Server:

XML: application/xml
Flatfile: application/x-flatfile
EDI: application/EDIStream; application/EDI; application/X12; application/UNEDIFACT

Back to the issue of using your own content handler.

Let’s say you have a customer who cannot send you fully qualified xml files. You could write and register a content handler and assign it a new content type of application/brokenXML or something like that.

When the customer sends the xml file over and specifies the content type of application/brokenXML, the new content handler will take over.

Only one content handler of a given type can be registered at any time.

You can change the built-in content handler (NOT RECOMMENDED OF COURSE) for a given type by using the java API to unregister and then register your content handler.

Igor Androsov wrote an excellent eZine article on this site regarding the creation of custom content handlers.

HTH,

Ray

I think you may have answered your own question:

If using the iterate facility of convertToValues is something that is needed by a number of the map services, then have the maps do the convertToValues call.

Actually, you cannot reliable use convertToValues for all types of documents without knowing the doc type (e.g. sometimes you won’t get a list in the structure when you should). It must be known so that the proper structure is created.

Another thought: have the map services accept whichever data type they want (string/stream/byte array OR IS document) and have the config that your generic dispatcher is using indicate which form the called map service wants.

Handler service:

• I assume you’re using a config file of some sort to know which map service to invoke.
• Reads a config file for received doc type and/or sender/receiver (are you using TN?)
• Config indicates which service to call and which form (string,stream,IS document) the map service wants
• Get the content from the bizdoc as a string, stream or IS doc as indicated
• Invoke the map service passing “sourceDocument” (IS doc). Map service returns “targetDocument”

Map services:

• Accept an input var named “sourceDocument”. sourceDocument can be declared as a specific IS doc type if that’s what’s expected.
• Maps the source document to “targetDocument”. The map should also return the name of the targetDocument’s doc type so that the handler service can properly do convertToString.

Using TN to facilitate this “transformation engine” may be helpful, even if docs are being moved around via broker (making some assumptions based on your previous posts)–otherwise you’re going to re-invent some of the wheel (doc recognition, logging, etc.).

HTH