Hello,
I want to carry some customized data in TN, i.e. I want to populate a customized data when route the data TN and pass it to the processing rule or customized delivery service. At the same time I want to set the “tn.clean.routePipeline=true” to drop the unnecessary parameters. So can any one give me some advice? Thanks.
What sort of data do you want to use?
Extended fields within the TN profiles might be appropriate to use. For that matter, some of the standard fields may be helpful–TN doesn’t use a lot of them on its own, but defines many fields that wM thought would be generally useful. You simply need to call a TN service to retrieve them for a given partner. For example, we used the Contacts settings to store e-mail addresses for different types of contacts (e.g. Support) to know what partner e-mail address to use when an error occurred.
A custom TPA might also be useful.
Thank you reamon,
The extended fields within the TN profiles are partner related. I have some fields which are document related but not inclueded in the bizdoc. Such as, we have a field MessageCategory to indicate the data type is XML, Flat File Or Binary Data, we can know the data type before submiting the data to TN. Of course, I can judge it in the processing rule according to the TN document type. But I think it will be better if it can be passed to the processing rule directly. Thanks again!
Right. Your original query wasn’t clear about what type of data you were interested in, so that’s why I suggested extended fields as one possibility.
Document type recognition within TN is what does this. What benefit are you looking for by knowing about the doc type before passing to TN? Part of the point of TN is having it figure out what your document type is before invoking the service specified within the rule. That way your service doesn’t need to do this logic.
The document type isn’t determined by the processing rule. It can be one of the conditions of your rule, which is effectively “passing the document type to the rule.”
Am I misunderstanding what you’re attempting to do? Are there other data elements that you need to track/use?
I am sorry for not made my question clear, and I will try to describe it clearly by the following example.
We will receive the BOM data from App1 in the XML format, and the BOM data from App2 in the Flat File format. In the processing rules, we will call the same processing service to do the data processing. And in the service, we will Branch On the MessageCategory(XML or FF) to execuate the XML or FF processing sequence. Then we will set up a processing rule with the Document Type “Any” in TN.
In this example, the thing I want is passing the MessageCategory to the processing rule directly, but not estimating it in the processing rule according to the TN Document Type. Hope I have made my question clear. Thank you.
“in the service, we will Branch On the MessageCategory(XML or FF) to execuate the XML or FF processing sequence.”
I guess you are in the right direction handling this kind of processing that checks in the xml content or has bizdoc attribute that comes with the extra identifier say MessageCategory (XML or FF) in the processing service flow depends on the value calls the appropriate custom translation service…But i dont think you can do this intelligent division in single processing rule itself…
HTH,
RMG
Why do you want to do it this way? Presumably the XML and the FF formats are different enough that after the branch you’ll have two distinct sets of steps to do the processing/transformation. You might consider putting the processing of each format into its own service.
You may want to consider a different approach. Generally speaking, a processing rule should be as specific as possible to avoid confusion and errant processing when new doc types/partners are added to the system.
Why do you want to make the processing decision in your service? Why not use the processing rule for what it was designed–to make the decision on which service to call based on sender, receiver and doc type. With what you’ve described so far, there doesn’t seem to be a compelling reason for a single service to handle both a FF and an XML document. You should have two different services, one for each. Those services may end up using other common services to do the work but at the top level they should probably be separate.
Thanks a lot for your advice, it is very useful for me.
I also think I should separate the processing services. And back to my original question,is there a way I could carry the customized data to the processing rules? The customized data may be a String, a IS Document or any other type data in the webMethods. At the same time I want to set the “tn.clean.routePipeline=true” to drop the unnecessary parameters. Thanks again.