The short answer is don't.
Use of pub.flow:clearPipeline is dangerous for the following reasons:
- it blows away everything in the pipeline, but the design time view of the pipeline appears as though the variables are still there
- maintaining the list of exception variables is generally tricky to remember to do, so it is a timebomb waiting to go off
- it's a sign of bad coding, you should properly maintain the pipeline by dropping unused variables when necessary and writing clean services (that only return their listed outputs in the pipeline rather than "hidden" variables"
Alternative
Use scoping of the pipeline to provide a "clean" pipeline for a service to invoke and return its results onto. To do this create a document (record in version4.6) in the pipeline. Map any inputs into that document structure. For your invoke step go to the properties and set the "scope" property to the name of your document.
If the outputs of the service are required: map them out of the structure and then cleanup the structure to avoid leaving junk in the pipeline.
1 Comment
Hide/Show CommentsMay 18, 2005
steveovens
There is one circumstance where it is OK to use clearPipeline, and that is insid…There is one circumstance where it is OK to use clearPipeline, and that is inside (typically at the end of) a Flow service that is to be cached. In this circumstance, you use clearPipeline to deliberately blow away everything in the pipeline except for the variables you explicitly want to return.
The reason for this lies in how the service cache works, and the way that the pipeline is managed for Flow services.
Basically, when a Flow service is called, it receives a copy of the entire state of the pipeline from the calling service - not just the variables you explicitly pass in (this is why using scope can increase performance!). The Flow service modifies the pipeline, typically by adding new variables to it (the results), and then returns the modified pipeline to the calling service. The returned pipeline is then merged with the calling service's pipeline - any existing variables with the same name and type are over-written.
Service cacheing works by "remembering" the output (pipeline) from calling a specific service with a specific set of input values. Subsequent calls to the service that match the same input values are simply returned a copy of the original output pipeline (from when the service was first invoked with those values).
So, if you enable service cacheing on a service and you don't use clearPipeline, you can easily end up with some nasty surprises in your pipeline.
Here's an example of what can happen...
Pipeline before call
doc
LoanApplication
id
1234
INVOKE
x
27
o->
num1
myCachedService.addInts
result
o->
result
y
43
o->
num2
Service Cache
Service name
Input values
Pipeline contents
myCachedService.addInts
num1=27,num2=43
doc (id=1234), x=27, y=43, num1=27, num2=43, result=70
Starting with a new pipeline that has only x and y in it, let's call the cached service again:
x
27
o->
num1
myCachedService.addInts
result
o->
y
43
o->
num2
We get back the expected result (70), but we also get the LoanApplication document (id=1234) and num1 and num2 as well. This may not be a real problem, unless we already had a different LoanApplication document in our pipeline...
Example: Pipeline before call, different LoanApplication in the pipeline
doc
LoanApplication
id
5432
x
27
o->
num1
myCachedService.addInts
result
o->
result
y
43
o->
num2
Pipeline after call:
doc
LoanApplication
id
1234
Our LoanApplication (id=5432) has been overwritten!
x
27
o->
num1
myCachedService.addInts
result
o->
result
y
43
o->
num2
result
70
num1
27
num2
43
To prevent this undesirable behaviour, we need to put a clearPipeline call inside our cached service so that it only ever returns the "result" variable (i.e. clearPipeline, preserve "result"). By doing this, the service cache will only contain the result variable, so that is all that it can merge in to the calling service's pipeline.
Example: Service Cache where clearPipeline is used:
Service Cache
Service name
Input values
Cached pipeline contents
myCachedService.addInts
num1=27,num2=43
result=70
NOTE: This is why you cannot effectively cache adapter services - even though Developer will let you do this. To cache adapter services, you need to write a wrapper service that contains the adapter service you want to cache-enable, plus a clearPipeline statement to ensure that you only return the result of the adapter service and nothing more.