Below is my experiment with expression libraries which seems hopeful. Honestly though, this seems a pretty common problem, and maybe our support team can reach out to other teams which have experience migrating assets from one org to another. There must be some canned solutions out there. I haven’t tried using the migration pipeline in the article I linked to, but that seems pretty helpful too.
Here is my project structure:
Organization: PROD
+ ProjectSpace1
+ shared
basic-auth-rest-account1 (REST Basic Auth Account)
+ conf
env.expr
+ Project1
rest post pipeline
Organization: DEV
+ ProjectSpaceDev
+ shared
(no REST account defined)
+ conf
env.expr
+ ProjectDev
rest post pipeline
Here are the definitions of the expression libs (env.expr)
PROD (env.expr):
{
"serviceUrl": "http://127.0.0.1:8001/prod",
"accounts": {
"RestAccount": x => "../shared/basic-auth-rest-account1"
}
}
DEV (env.expr):
{
"serviceUrl": "http://127.0.0.1:8001/test",
"accounts": {
"RestAccount": x => ""
}
}
Pipeline is just a single REST POST snap defining the Service URL and Account Reference via expressions. Observe how the expression library is attached in the pipeline parameters dialog with an alias (“env”). The PROD lib defines a REST account whereas DEV doesn’t, but it could.
With this configuration, I was able to export/import my pipeline from one org to another, and have it run in the target org using the expression values for that environment/organization.
The cool thing is that I didn’t have to modify the REST POST snap. However, you can see the configuration is somewhat fragile and depends on common configuration patterns (ex: relative pathing, etc). I’m not sure of your organization project workspace structure, but maybe you can leverage some of this with other community inputs, plus help from support.
