We have a specific requirement where the output of a delivery task of TN is required for further processes.
We need to access body->Bytes variables.
How to get a handle on that data ?
Regards,
harish
HI Harish - You’ll have to write a custom TN delivery service, which does its own invoke of pub.client:http. This will give you access to /body/Bytes and you can do further processing within the task.There is good documentation on building a custom delivery service.
You’ll be using the services in wm.tn.delivery, especially wm.tn.delivery:registerService
Thanks Sonam.
We are trying to create our own delivery service. However, when we register our custom service using registerService, we are not getting any placeholders in TN Profile configuration to add details like Host /Port etc.Are we missing something or for custom delivery you have to manage all the Host/Port etc. details completely outside TN ?
Regards,
Harish
Hi,
The problem is genuine and i faced it recently. According to webMethods documentation, the processing rule has actions tabs where i want to deliver bizdoc with custom delivery service. Registering custom delivery service will not enable custom delivery tab in the profile of the corresponding partner. Also In my case i want to keep the flexibility that the processing rule should do in actions tab
a) Call B2B service to do some mapping and processing and then routeBizdoc again to processing rule only
b) Routing it again will have a processing rule to have actions deliver document with custom delivery service.
Comming back to delivery service, we took a diff approach to write a delivery serivce which uses wm.tn.deliver service with PreferedProtocol delivery method. One catch here is that, one should call wm.tn.doc.persist service before calling deliver to make it retry. This will return a taskID for you to track things.
With this taskID you can extract the taskStatus, taskOutput, getTask service which help you to get the Output after knowing the task is DONE.
Hope this will help in your case…
Although you can use httpClient service for more customized processing, but you may not get adv of TN analysis for logs.
There are bugs with webMethods TN services and tools… Hope somebody is looking in to this…
Regards
Anand W
Harish -
The custom delivery service does not pass in delivery information. Instead you can set the delivery information in the customer’s TN profile and access it at delivery time.
When our custom delivery service runs, it looks-up the bizdoc receiver’s TN profile (using /bizdoc/ReceiverID) and gets his delivery information. Extracting the profile delivery information from the profile is quite painstaking. 
Note this bug I came across impacting custom delivery services for IS 4.6. It shows up when TN SP1 is installed. The effect of this bug is that if a custom delivery fails, subsequent delivery attempts get an “empty” bizdoc passed in (and fail too). I’ve reported this to WM and they’re working on a fix.
The workaround for this bug is do not drop the bizdoc input to your custom delivery service – keep it until the end of the flow. This seem to magically pass it onto the next run of the delivery service.
- Sonam
Harish wrote:
“We are trying to create our own delivery service. However, when we register our custom service using registerService, we are not getting any placeholders in TN Profile configuration to add details like Host /Port etc.Are we missing something or for custom delivery you have to manage all the Host/Port etc. details completely outside TN ?”
As Sonam implies above, registering a custom delivery service doesn’t create/enable new tabs in TN Profile configuration. That’s not how delivery services work. The Delivery tab is a place holder for information that can be used by ANY delivery service. It’s just that the HTTP info is useful only for the HTTP delivery service, FTP for FTP service, etc.
If your custom delivery service performs special handling but is fundamentally an HTTP delivery service, then it needs to retrieve the delivery info from the TN profile, as Sonam describes.
“Also In my case i want to keep the flexibility that the processing rule should do in actions tab a) Call B2B service to do some mapping and processing and then routeBizdoc again to processing rule only
b) Routing it again will have a processing rule to have actions deliver document with custom delivery service.”
This can be accomplished easily by setting the User Status of the document and defining rules appropriately. Projects I’ve worked on use this to move documents that are the same doc type from one state (map) to the next (deliver).
“we took a diff approach to write a delivery serivce which uses wm.tn.deliver service with PreferedProtocol delivery method.”
If your custom delivery service does this, then why have the custom delivery service? Why not just use the normal delivery facilities? Am I missing something?
Sonam,
Could you please direct me to the documentation about creating custom delivery service.
My requirements is similar but i am just wondering just to get the output, do i need to create the complete new delivery service.
When i send the XML data to my partner, partner in response sends an XML data which contains the status of document. What is the best possible way to retrieve the XML. I am using routeXML to send the data to TN.
Sandip : Look at the section on “Reliable Delivery Services” in the wMTN_ProgrammersRef.pdf guide. For TN Console 4.6, its on page 135 and the PDF file is in the /doc directory of the TN Console installation.
Regards,
Sonam
Sonam,
Do u think it is a better way of implementation, as my requirement is just to get the body->Bytes variables which comes as the response from the partner.
Do we have any utilities which can provide me with this. Or Building a custom delivery service is only an option. Does WM recommends to build delivery service for such request.
regards,
sandip
Also, to add to my previous posting, i am using routeXML in my flow service. I am aware that i can get the response if i use primary HTTP instead of routeXML. But if i do change to primaryHTTP i have other problem.
The XML which i am sending has CDATA in it. So instead of sending the node which i receive to send, directly, if i use node to Document and then to bizdoc to feed to primary HTTP. My that CDATA is not existing in the XML thereby giving invalid XML.
My sample XML which i am sending is as follows,
<?xml>
<note>
<to>kerry</to>
<from>Sandip</from>
<heading>Requisition</heading>
<body>
<![cdata[<?xml>
<ab_req>
<requisitionnumber>1234567890</requisitionnumber>
<job_req_status>2</job_req_status>
<manager>manager name</manager>
</ab_req>
]]>
</body>
</note>
Hi Sonam
In your post on this subject you mentioned
"Note this bug I came across impacting custom delivery services for IS 4.6. It shows up when TN SP1 is installed. The effect of this bug is that if a custom delivery fails, subsequent delivery attempts get an “empty” bizdoc passed in (and fail too). I’ve reported this to WM and they’re working on a fix.
The workaround for this bug is do not drop the bizdoc input to your custom delivery service – keep it until the end of the flow. This seem to magically pass it onto the next run of the delivery service."
Do you know if this is fixed by TNS_4-6_SP1_FIX_51 or some other fix ?
thanks
We had the EXACT issue with 4.6. Turns out you have to go to 6.0 to get the fix and there are no more SP’s of 4.6 coming out AFAIK.
Tried a few workarounds but if TN doesn’t hand you a bizdoc you’re screwed.
Sorry guys - I’ve missed the last few posts in this thread:
Sandip - the custom delivery service is the cleanest way to deliver a document. You can process the body/bytes response from the HTTP client invocation in your custom service.
Kevin - You said:
“Do you know if this is fixed by TNS_4-6_SP1_FIX_51 or some other fix ?”
A few months ago, I spoke to the TN maintenance developer and he said they would issue a fix. However, they didn’t contact me after that on this issue. I haven’t had the chance to look at FIX 51. Here’s the patch list we use:
IS_4-6_FIX_19, IS_4-6_SP2, IS_4-6_SP2_Fix142, TNS_4-6_SP1, TNS_4-6_SP1_FIX_45
Will - in our environment, (IS 4.6 on Linux, IBM 1.3.1 JVM), not “dropping” the bizdoc worked fine. I stress tested this approach with 200-300 simulated deliveries and random failures, but the workaround seems to hold up fine.
Sonam