Dynamic Inputs in IntegrationHub Actions

#IntegrationHub , #Dynamic Input , #Data Gathering Action

Dave Slusher

3 minute read

In a recent Live Coding Happy Hour we attempted to create some Dynamic Choices and Data Gathering Actions. That effort ran into some technical hurdles during the session but they have been sorted now. There are parts of this that are a little finicky, so I will walk through the necessary pieces.

Why Use Dynamic Choices?

The use case of this example is a good one for showing the power and necessity of Dynamic Choices. For Linode specifically, the data centers they have, the VM types they offer and the boot images they support are not a fixed list. These values change over time just often enough to be troublesome. They change often enough that it would be a drag to have a hardcoded list of any of these choices. No one wants to have to republish a spoke because a new version of Ubuntu has been released. With the Dynamic Choice, none of these lists have to be maintained by the Spoke developer.

Create the Data Gathering Action

To start with, there must exist a Data Gathering Action before it can be configured into a Dynamic Input. Here is what is the definition of what makes an Action specifically a Data Gathering Action:

  1. The Action contains a REST step
  2. The output of whatever API is accessed is formatted into a JSON object that is
  3. An array of {“label”:“”, “name”:“”} fields contained in a key named “data”
  4. That is returned from the action output in a field named “output” of type JSON

If these conditions are true, then the Action will be selectable from Dynamic Inputs.

Here is an example of one of these Data Gathering Actions I built for my Linode Spoke.

Data Gathering Action to collect Linode regions

Having created that, the action is now selectable when configuring a Dynamic Choice.

Configuring the Dynamic Choice to use Data Gathering Action

Once those are configured, that makes the Data Gathering Action get run at Flow edit time. Note that this is not something for the runtime of the Flow, this is for setting up the Flow in the first place. When choosing that option for the Action inside a Flow, the API will be called and the values filled out.

The Dynamic Choice in All Its Glory

This is the full JSON packet that is generating the above choice list.

{data=
[{name=ca-central, label=CA - ca-central},
{name=eu-central, label=DE - eu-central},
{name=ap-west, label=IN - ap-west},
{name=ap-northeast, label=JP - ap-northeast},
{name=ap-south, label=SG - ap-south},
{name=eu-west, label=UK - eu-west},
{name=us-central, label=US - us-central},
{name=us-east, label=US - us-east},
{name=us-southeast, label=US - us-southeast},
{name=us-west, label=US - us-west}]}

For this Spoke, I have now created the three Data Gathering Actions cited above. It was a bit tricky to get going but once the format of the JSON was understood, it got very cool very quickly. I can now create new Dynamic Choices at will, limited only by the API and input needs of the Actions I build. The dream is alive!

Conclusion

This is one of the features we have been calling out in the New York promotional material but until last week I had never tried to build an operating version myself. Having now done it, I can attest this is an efficient way to build a great user experience for the consumers of your Actions. I continue to dig through the API trying to find more lists that I can add because it is fun.

I hope you find value in this feature as well. Feel free to look at my Actions in the Linode Spoke if you need some examples. Whether you run into challenges or build a great use case, let us know about it in the comments. Happy developing!

Comments