cancel
Showing results for 
Search instead for 
Did you mean: 

Exporting/Importing recipes best practices

jessica-lie
Workato employee
Workato employee

[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.

13 REPLIES 13

jessica-lie
Workato employee
Workato employee

[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.

jessica-lie
Workato employee
Workato employee

[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.

[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

  1. 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
  2. We have 2 recipes:

Home/Sub1/ parentRecipe

Home/Sub2/ childRecipe

    1. Both were already in Production.
    2. 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. 
    3. If we re-created the manifest and picked "Home" as the source folder, and still only selected parentRecipe, then it built ok.
    4. 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?

jessica-lie
Workato employee
Workato employee

[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.