Are you executing child pipelines on a completely different Snaplex from the parent? If not, here would be my recommendations for the Snaplex setting in the PipelineExecute snap:
- Always start with leaving the property blank. When the property is blank, the child pipeline is executed on the same Snaplex node as the parent pipeline. That means there is no network traffic needed to start the child pipeline on another node. So, the execution will be a bit faster and more reliable.
- If you have done some performance testing and find an improvement in performance by running the children on other nodes in the Snaplex, then toggle the property to be an expression and set the value to
pipe.plexPath variable is set to the path of the Snaplex where the parent pipeline is running.
So, in both of those cases, there is no need to set the property to something org-specific and there is less to worry about for the person importing the pipeline.
If you do need to run the pipeline on a different Snaplex from the parent pipeline, then there are a couple of strategies here as well:
- Use a relative path for the Snaplex name and try to use the same Snaplex names in your dev/qa/stage/prod orgs. For example, if the Snaplex property is set to ‘cloud’, the pipeline will be run on the Snaplex named cloud in the shared directory of the current org.
- Use a pipeline parameter or expression library to specify the path to the plex. For more complicated setups, you might want to create an expression library file that contains the details of the environment and import that into the pipeline. In this model, each org would have its own version of the library with the appropriate settings for the environment. The pipeline can then be moved around to each org without needing to be updated.
Now, all that being said, to your original point:
Yes, the import wizard in Designer should ensure that the Snaplex path is valid and prompt for an update. I’ll file a bug.