topic Re: Exporting/Importing recipes best practices in Workato Pros Discussion Board

Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 13:53:05 GMT

[Dec 12, 2020] Mike Power (CRM Enterprise Architect at American University) posted:

Does anyone have “best practices” or steps they follow when it comes to properly exporting recipes/dependencies and then importing them into their test or prod environment in Workato? We’re still relatively new to Workato and thus far our few attempts have had a lot of recipes being duplicated, extra connections being created, dependencies being pulled in that aren’t needed or haven’t changed, etc.

It's been a bit messy, which makes me think we’re just doing something wrong.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 13:54:20 GMT

[Dec 12, 2020] Deven Maru (CSM at Workato) replied:

Hi Mike,

The typical flow is:

Create manifest, choose assets that make up your integration
Export package using the manifest
Create target folder in test or prod environment where you want to import the integration
Import the package that you exported earlier

Manifest represents and includes the assets related to your integration including the dependencies. Once a manifest is created, you can create packages every time you want to deploy a new version of the recipe.

Between dev, test and prod environments, the recipes and connections are references by name. So, if you change the name of the recipe or connection in dev, package it up and import it, then it will create the recipe with the new name.

If you're just modifying recipes (changing logic, mapping, transformations etc.) then the manifest does not need to be updated. You just need to export when you're ready to deploy a new version.

If you've added a new recipe, connection or other assets like a lookup table then the manifest will show you a message to review the manifest. You must include those new assets into the manifest by selecting them. Packages built after the manifest update will include the new assets.

If you do not want to deploy everything that's included in a manifest then you have two choices:

Edit the manifest to only include what you want for the immediate deployment need
Create a new manifest to include the limited assets you want to include

Packages will always pull in the dependencies automatically. Once a connection is imported for the first time, later imports will not overwrite the connection even if it is included in the package.

Hope this helps. If it helps, we can jump on a call and walk through what you're seeing. I product manage this feature so definitely want to know more details about the issues you're facing.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 13:56:34 GMT

[Dec 17, 2020] Manuel Roldan-Vega (Integration Architecture Team Leader at Vanoris) replied:

One of the things we're trying to do to make this process easier is to name the Connections, and the SDK Connectors exactly the same between Dev and Prod. This is helping this process significantly. Before we had connections named like Salesforce Dev and Salesforce Prod. Now we moved to call them both just 'Salesforce'. This allows it to automatically be mapped to the right connection when importing it to Prod.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 13:58:31 GMT

[Dec 18, 2020] Mike Power (CRM Enterprise Architect at American University) replied:

Thanks Manuel, yes we decided just the other day to do the same after we noticed that was one of the causes of our problems.

Deven/Workato, I have one enhancement request, and one question

A security role for "export only". This way developers can export their recipes and check them into Git for source control. Since the security role must be export/import together, then either our Workato Admin must check our code into Git, which is a pain for them, or all the developers can do both export/import, which makes Change Management more difficult
We have 2 recipes:

Home/Sub1/ parentRecipe

Home/Sub2/ childRecipe

Both were already in Production.
We wanted to move a change that was made in parentRecipe. When we did the export and picked Sub1 as the "Source Folder" for our manifest, it wouldn't build the package b/c it said a callable recipe had to be a child folder.
If we re-created the manifest and picked "Home" as the source folder, and still only selected parentRecipe, then it built ok.
This seems a little strange… either we can or can’t select a single asset to move. Is this by design, so that certain folders can be locked down? Or is it unintentional?

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 13:59:17 GMT

[Dec 18, 2020] Deven Maru (CSM at Workato) replied: Hi Mike,

1. We are working on enhancing the lifecycle management experience. In the new experience we're integrating the environments (test, prod) as integral to the development lifecycle stages. For example, you won't need to separately login to the test and production environment. The deployment will be easier without the need for manifest creation and export/import.

2.Yes it was by design to now allow export if the dependencies were not contained within the same folder. We're also enhancing it to now use soft links instead of hard links to dependencies. In this case, you'll be able to take Sub1/parentRecipe and Sub2/childRecipe and deploy them independently even though the parent recipe calls the child recipe. This will give you flexibility on how you manage changes to both recipes and deploying them.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 13:59:49 GMT

[Dec 18, 2020] Mike Power (CRM Enterprise Architect at American University) replied: Thanks for the response Deven. When will the new recipe lifecycle experience be available?

It sounds like a better experience, though I don’t think it solves the problem of having the ability to export (only) for source control?

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:01:20 GMT

[Dec 19, 2020] Deven Maru (CSM at Workato) replied: Mike, in your process, do you want to check into source control before the deployment? We are targeting the new enhancements in the first half of next year.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:01:42 GMT

[Dec 19, 2020] Mike Power (CRM Enterprise Architect at American University) replied: I think comparing the recipe to be pushed out before it is deployed can be helpful b/c that way you can confirm that the only changes in the package are the ones you expected.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:02:15 GMT

[Jan 9, 2021] Deven Maru (CSM at Workato) replied: We have visual diff in the roadmap. At this time I do not have an ETA but will look into it to see where it fits in the prioritization.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:04:12 GMT

[Jan 9, 2021] John Zink from Bain Capital replied: I second that! If it worked for versions history of a recipe that’d be great as well.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:04:42 GMT

[Jan 9, 2021] Deven Maru (CSM at Workato) replied: Thanks for the feedback John. I'll review if the same module can be reused for recipe version comparison as well.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:18:17 GMT

[Jan 9, 2021] Gary Wilkinson (Director, Enterprise Architecture at ePlus) replied:

Hi Deven,

I think we may have previously discussed this, count ePlus as another customer who is very much in favor of the “Diff” feature and looking forward to its rollout.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:18:42 GMT

[Jan 9, 2021] Deven Maru (CSM at Workato) replied: Hi Gary,

Yes, we have. Will definitely keep you posted on it.

Re: Exporting/Importing recipes best practices

jessica-lie — Fri, 15 Jan 2021 14:19:12 GMT

[Jan 9, 2021] Gary Wilkinson (Director, Enterprise Architecture at ePlus) replied: I was assuming it would include comparing versions in the version history and not just across manifests (since those seem to be going away).