Skip to end of metadata
Go to start of metadata

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.

Labels
  • None
  1. May 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.