Update the Service URL and HTTP header in the Rest Post snap

Is there a way we can programmatically update the Service URL and HTTP header in the Rest Post snap, after copying a pipeline, which has a Rest Post Snap, from one project folder to another?

Hi @PulseAmit :

There are a couple of ways to achieve this. One way would be to define the Service URL and HTTP header(s) as pipeline parameters, and then expression enable those fields in the REST snap referencing those parameters (ex: _serviceurl for serviceurl pipeline parameter). You would then update the pipeline parameters of the pipeline you copied to the other project.

Another way, albeit a bit brute force, would be to export the pipeline, modify the field values in the exported json, and then import the modified pipeline into the other project folder.

Let me know if you want more details on either. Others may have craftier solutions.

Hi @mbowen ,

Thank You for the response.

Just wanted to give you an overview of the issue that arises due to the Service URL and HTTP header in the Rest Post snap.

When we copy any Pipeline from a PROD environment to a Non-PROD environment there is a wizard which asks for accounts. But It’ll not ask for any details regarding Rest Post Snap. So, we have to manually add the account and other details manually to the rest post-snap.

After adding an account on rest post-snap we also need to add Service URL and X API Key on the same snap and that is a manual process.

Service URL and Keys are Environment specific.

Is there any way where we automate this thing in Snaplogic?

Please Provide any possible solution around it to reduce manual intervention.

You can also refer to a ticket that is already open with Snaplogic Support.
Link: https://snaplogic.zendesk.com/hc/en-us/requests/42642

Just to let you know,
The other community post asking for The Migration of assets from one environment to another in Snaplogic is also address the same issue,

Link: The Migration of assets from one environment to other in Snaplogic

Let me know if you need more clarity on this.

Thank you,
Amit A.

@mbowen

Have you got a chance to review my response?

Let me know if you need anything else on this from my end.

waiting for a response from your side.

Thank You,
Amit A.

@PulseAmit

The account is optional for the REST POST snap which is probably why the wizard doesn’t prompt for it.

An expression library may help us here. The thinking is that we’ll define the REST account, Service URL, X API key, and whatever other common properties in this library (ex: env.expr)

You’ll see an Expression Library section in the pipeline parameters dialog. That’s where we’ll attach the expression lib.

We can then reference these expressions in the snap. Specifically, we can update the REST POST snap Service URL, HTTP Header, and Account reference to refer to these expressions.

As long as the relative path-ing to the expression library is the same across environments (orgs), I think this will work.

This is new to me too, so others who have deep kung-fu with this, please don’t hesitate to chime in. Here’s a link to our documentation of this:

https://docs-snaplogic.atlassian.net/wiki/spaces/SD/pages/1438110/Expression+Libraries

Thank you for creating a Support ticket for this. That actually will ensure more support cycles are devoted to this issue. Community has a weaker SLA.

I should be able to prepare an example later today, tomorrow for sure (Wed, 8/18).

@PulseAmit

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.

@mbowen ,

Thanks for the update and provide your findings with an Expression Library.

Specifically, Your experiment with expression libraries really helps us in implementing the solution in the Pipeline.

I’ll respond to the same thread If we face any issue in pipeline development going forward.

Regards,
Amit A.