Parameterize Connectors

[tm_argon]

We're looking for a way to "parameterize" the fields of connectors in Workato. What do I mean? Here's an example:

• We're building a custom app that will utilize Workato API management to make calls into a single recipe
• That recipe will, among other things, connect to a third-party application (via REST) where *each client* of our app will have a designated hostname for the API (as well as a designated API key). NOTE: We don't control this, it's the nature of the service we're using that it's set up this way
• When interacting with this third-party application, the API calls will be exactly the same across invocations, regardless of which client is being used. The only difference will be the hostnames and API keys used
• We'll be maintaining a lookup table in Workato that will map a client "identifier" to the corresponding hostname/API combination
• The calling app that we're building will pass this identifier via the Workato API endpoint that fronts the recipe
• The recipe would then look up the hostname/API key information from the passed in identifier

This is where we're running into a problem. Rather than having "x" number of connections defined and the recipe have a bunch of "if" blocks to choose the correct connector based on the client identifier, we'd rather have a *single* connector where the hostname and the auth info could be programmatically set in the recipe before we actually start using the connection.

So, imagine we set two variables at the start of the recipe:

- hostname
- apiToken

and somehow in the connector set up, we could parameterize these. Something along the lines of:

Is this at all possible? If not, what are our alternatives here? Since the number of clients using our app can grow over time, it doesn't seem reasonable for us to have to go in and update the recipe with new connectors each time we onboard a new client.

Thanks.

- Terence

[Prudvi]

Hi @tm_argon,
I dont think we can parameterized the connectors as they are interlinked to Triggers/Action.
This is not a Ideal solution, but if the request and response structure remains same for all your clients.
I would suggest if you can use Execute Python Code action.
The code will accept variables where you can pass your hostname and api_key to the HTTP server.

import requests
from requests.auth import HTTPDigestAuth
import json

# Replace with the correct URL
url = "http://api_url"

# It is a good practice not to hardcode the credentials. So ask the user to enter credentials at runtime
myResponse = requests.get(url,auth=HTTPDigestAuth(raw_input("username: "), raw_input("Password: ")), verify=True)
#print (myResponse.status_code)

# For successful API call, response code will be 200 (OK)
if(myResponse.ok):

# Loading the response data into a dict variable
# json.loads takes in only binary or string variables so using content to fetch binary content
# Loads (Load String) takes a Json file and converts into python data structure (dict or list, depending on JSON)
jData = json.loads(myResponse.content)

print("The response contains {0} properties".format(len(jData)))
print("\n")
for key in jData:
print key + " : " + jData[key]
else:
# If response code is not ok (200), print the resulting http error code with description
myResponse.raise_for_status()

Something similar as above code.
 Regards,
Prudvi

[Abhinav]

Hi @tm_argon ,

You can use Workato's Runtime User Connections to support your use case.

1. Create an HTTP call within a recipe function and enable runtime user connections in the recipe function settings.

2. In the Main recipe, call the recipe function and configure the HTTP connection using either connectionName  or  connectionId.
3. For authorization, pass it as a parameter to the recipe function and dynamically use it in the HTTP step.

Refer to workato Documentation for more details:

https://docs.workato.com/features/runtime-user-connections/using-runtime-user-connections-in-recipe-...

[blakesha]

Maaate!! Awesome work. Used that pattern to resolve another issue (metadata driven ingestion framework for SQL Server connections)