I agree about the undropped variables… but the caller of your service will have to drop the variables anyhow… Or else they will appear to still be in the pipeline at design time.
Fact is: if you drop a variable, it’s gone, so if you need it, then leave it in there (don’t drop it)… The caller will have to clean 'em up anyhow, and if you’re talking about an “entry point service” then everything in the pipeline gets cleaned up after execution finishes anyhow.
My rules for pipeline variable management:
- at the end of a service make sure there are no variables other than the inputs and outputs left in the pipeline
- always map an output that is required later in the flow to a unique name to avoid overwriting
- cleanup any input variables that are explicitly mapped (or no longer required) in the invoke step itself.
- have a map step at the end of each flow service to cleanup any remaining variables (that are not inputs or outputs)
Going to the complication of using scoping for two strings is a bit overboard. I only use scoping when you want to be able to nicely cleanup after a misbehaved service. Or if you have something that returnes tonnes of output variables and you only want a few of them.
In a large scale: using scoping all over the place is going to be a maintenance nightmare.
If you use scope and you want something from the output, then you’ll need to map them from that document back to the top level of the pipeline.
Regards,
Nathan Lee
WmUnit - The webMethods testing framework.
[url=“http://wwww.customware.net/wmunit”]http://wwww.customware.net/wmunit[/url]
#Integration-Server-and-ESB#webMethods#Flow-and-Java-services