Using drop variables

, ,
1

I am testing 2 input variables, adding them by calling addints service. In the pipeline out, I dropped the input variables. Now, I want to show the input variables on a dsp page like 2+3=5. How can I do that?

The results I am getting from dsp page are:

before invoke
6 + 7 =

within invoke
+ = 13

after invoke:
+ =

Thanks for your help

2

Well, you’re cleaning them up by dropping them, so they’re no long available… My recommendation is to leave both the output variables AND the input variables in the pipeline for any given service.

My reasoning behind this is that the caller will have to clean up the pipeline anyhow.

So simple answer: don’t drop them and you’ll be able to access them in a DSP.

Regards,
Nathan Lee
WmUnit - The webMethods testing framework.
[url=“http://wwww.customware.net/wmunit”]http://wwww.customware.net/wmunit[/url]

3

I know this. But in large scale project, undropping variables can cause more memory consumption and performance degradation. I thought of using the scope tag here, and using the variables from out of scope but it didn’t work. Just curious to know if there is some way to use variables from pipelineIn if they are dropped in pipelineOut. There may be such requirements in a project.

4

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]

5

Thanks