Hello,

Does anybody know how to specify a constant argument while invoking a custom service to extract an attribute from a document type?

We are trying to use a custom service to fetch the SenderID and ReceiverID from a TN XML document and transform it. We have created a custom service implementing the I/O as “wm.tn.rec:StringAttributeTransformService”, what creates 3 input parameters: values, isArray and arg.
There is no problem when passing the results of a XQL to the parameter “values” (done automatically by TN) but we are experiencing that we cannot pass anything to the parameter “arg” (if we specify the input, it is deleted once the Edit Attribute screen is loaded again).
Trading Networks documentation has a hole in this functionallity, as only “Optional arguments that you can define” is written regarding this argument.

Has somebody used this functionallity and knows how it should be done?

Thanks in advance and regards.

You can set the value for ‘arg’ in TN. For that you have an extra button
‘Set Inputs’ aside the ‘Edit service’ button. I think you have to use an XQL-query
in order to extract a value for the ‘arg’ parameter. You can find a description in the docs.

Regards, André

Thanks a lot for your response.

Anyway, the problem is while trying to pass a constant value to this input instead of an XQL query. Our intention is to reuse the same service for similar document types extractions, but we have to indicate somehow the document type that has triggered the execution of the extracting service to it.

Do you know if that’s possible?

Regards,
Albert.

Problem fixed.

It seems there was some cache problems and that’s why we couldn’t use the parameter args.

The solution has been unselecting the custom service in the extraction window on TN and selecting it again. This way, you can specify both XQL or constants as input parameters (I’m allways surprised about this kind of webMethods problems…).

Anyway, thanks for your support.

This caching is often an delicate point;

You could also extract the domument type in the processing flow using
%bizdoc/DocType/TypeName% and %rule/RuleName% contains the rule
name.
Its interesting to see what kind of data is coming into the pipe when
a processing flow is triggered. You might find that out using the
pub.flow:savePipelineToFile and pub.flow:restorePipelineToFile services.

It’d be my preffered way to uses these values.

Bye!

Yes, it is really anoying to see that something begins to work because of a reason as silly as reopen a window or even seing that something deleted is applied (xsl transformations, for exemple)!

As far as the extraction is concerned, is a good point what you say but I always prefere not to link a flow with the name of the document or the rule for maintenability reasons.

Thanks for your response and regards.