Two services that are causing me problems.

==========
wm.tn.doc.xml:bizdocToRecord

• Declared Input: bizdoc
• Declared Output: boundNode

Problem: Unfortunately, the service leaves an undeclared output -
recordName. Worse, it drops its input variable bizdoc on the third
step!

=====
wm.tn.doc.xml:<strong>recordToBizdoc</strong>

• Declared Input: boundNode, doctypeIdentifier, rootTag, htmlEncode,
  recordName, generateRequiredTags, TN_parms
• Declared Output: bizdoc, TN_parms

Problem: ALL inputs got dropped, except for TN_parms.

=====
I think both of these are unacceptable. Leaving undeclared variables in the
pipeline cause problems for services which call these. They interfer with
services called later – e.g. Calling bizdocToRecord, and another service which
accepts recordName as optional input, will result in error if the 2nd
service is process another input record. Pretty much, variables are popping up
beyond developers’ control. Dropping input variables is again problematic.
Developers don’t expect their variables (which still shows up in their pipeline
when developing) have actually disappeared. The disappearance of variables being
decided by webMehods, rather than the developer.

On TN 6.*, the services are protected by the
<wmprivate> ACL, so takes a bit of work to fix. I’ve
raised the issue w/wM support, but they are telling me that “it’s the correct
behavior”. What to do? What to do? Code my own services? I don’t really want to
modify them, as they could very well get overwritten during an upgrade. Any
thoughts on these?

1. Built-in TN services inject undeclared variables into your pipeline?
   –> If so, welcome to the wonderful world of undocumented internal WM services and pipeline fun! You can use alternative variables names. Or call problematic internal WM services using wrapper services which have pub.flow:clearPipeline as the final step.

2. Built-in TN services “drop” input variables and you cannot refer to them anymore?
   –> This should not be a problem - the calling service retains a reference to anything mapped in, so you should be able to use the original references.

Sonam,

Too much garbage in the pipeline, yes, that’s pretty much something we have to deal with. As for built-in services dropping variables – It is a problem. Example

1. wm.tn.doc:view == Returns bizdoc
2. wm.tn.doc.xml:bizdocToRecord.
   – We pass bizdoc to service, bizdoc got dropped in there.
3. wm.tn.doc:updateAttributes (or relateDocuments, or other services that takes bizdoc)
   – Error! We have nothing to update anymore.

I think the worse part is that (I’m relying on my unreliable memory) IS 4.6 SP1 or earlier might be okay. That is, bizdocToRecord didn’t drop it’s input bizdoc. But somewhere along the line (probably IS46_SP2) the new behavior was introduced. Can you imagine having to look at every built-in service to make sure that they didn’t drop their input variables? I know you can keep a copy of everything in the pipeline, but that clutters up the pipeline, and potentially creates conflicts with some services (especially SAP RFC calls). Adding clearPipeline to everything that might get confused by too many variables in the pipeline? <b>Arggggs<b>. I think it’s just not an acceptable behavior, especially for webMethods… 8(