Howdy out there in automation land! I hope everyone who is reading this is staying healthy and safe in these interesting times we are living in. It is a perfect time to catch up on some things so how about catching up on some great automations! Or some digital learning like I don't know... this blog :) Today's topic is going to be about ways and methods to do asynchronous workflow runs using Action Orchestrator! But first a quick little shout out for Cisco Live (the digital experience) coming up in early June. It will be June 2nd-3rd and you can register here... no cost! And even better... yours truly will be on the digital experience with a recording of my new breakout session called "How I saved a Bundle by Switching to Automation", or BRKPRG-1220. I hope you readers drop by and check out a longer length session with me as I focus on my thoughts on the practice of finding problems, developing automation solutions and deploying those... of course it will have an AO feel as that will be the backdrop for it... but I do not want to say more yet! Look forward to it in about 1 month.
How about a movie poster for today's blog? Something like...
Very cool right? Old school Arnold. That's for you SNMP Guy. If you do not know him... follow him on twitter, great technical follow and a fellow AO enthusiast! Anyways onto the topic of the day... running workings in an asynchronous (or async) fashion. For those that do not know, this means running it at the same time that something else is going on. In some cases we can run multiple workflows at once that make up a bigger "program". We do not care if the 2nd workflow runs at the same time, or ends earlier than the parent/calling workflow. As long as they are not mutating the same data or same "thing" we are ok with it. We find this extremely useful when dealing with large program sets or when doing some complex things... trust me! So we have two options I will talk about today...
So first we want to try and call our workflows asynchronously with the Rest API. This is pretty straight forward! In simple you can just call the start endpoint with the asynch option like...
https://<your AO server>:<port>/be-console/api/v1/workflows/start?workflow_id=<some workflow id>&sync=false
This will start your workflow in an asynchronous manner. However, to do this in workflows you will need to create a target to make API calls back into your system and you'll need your API key to do such... so follow these easy steps to set it up...
So in trying to help the community... I built a workflow to help make the calling and running of workflows via API easier for you! So let's talk about that right quick... you can download/import it from here: https://github.com/cisco-cx-workflows/cx-ao-shared-workflows/tree/master/AOStartWorkflowViaAPI__definition_workflow_01AP32MLFSTT019UbRkKy93Qo1ATRkUWH1Z
In that you can drag and drop it to other workflows and then just fill out the information! So all you have to do after importing that workflow is drag and drop it, then input your workflow name, put in any inputs (in a json structure), and then leave the sync option as "async". It will form the API call for you and make it and then return to you the workflow instance ID. So easy!
Here is a screenshot on how to use it and of course I have a VOD on it...
And the VOD showing you how to use it will be at the end(as always)... so let's look at your other major asynchronous option.
Or you can call it queuing or message busing, or Publication/Subscription, the list goes on. But basically it is publishing a message to some message broker (in our case we will look at AMQP) and then another workflow triggering off of that message and starting using the data in that message. So what do you need here? Well you do need a "sidecar" VM or another system to be a message broker for your AO system. You have two options with AO... either Kafka or AMQP. I have more and deeper experience with AMQP, and especially RabbitMQ, so I go with that. Is it easy to setup and runs great! Personally I just spin up a CentOS 7.X VM and then install RabbitMQ and I'm off to the races. Here is a tutorial on doing such.
Assuming you have that in place you should have something setup that looks like this:
So here are some steps to help setup your system to work with AO...
So how does it work? Well the first thing I suggest is come up with some message format that makes sense for you. JSON? XML? Random Strings? Whatever makes you happy. I prefer to use JSON, but each to his own. You will use this message format to publish the messages to your bus and then trigger and relay that data over, so make sure it is something that you can parse effectively. (another reason to use JSON).
Next you have to define an event and trigger for the AMQP.
Now that you have seen a couple of great ways to call workflows asynchronously... let's check it out in video fashion so you can follow along and do it yourselves!!
Now... ONTO THE VIDEO!
Recording password: rNdM42bd
Standard End-O-Blog Disclaimer:
Thanks as always to all my wonderful readers and those who continue to stick with and use CPO and AO! I have always wanted to find good questions, scenarios, stories, etc... if you have a question, please ask, if you want to see more, please ask... if you have topic ideas that you want me to blog on, Please ask! I am happy to cater to the readers and make this the best blog you will find :)
AUTOMATION BLOG DISCLAIMER: As always, this is a blog and my (Shaun Roberts) thoughts on CPO, AO, CCS, orchestration, development, devops, and automation, my thoughts on best practices, and my experiences with the products and customers. The above views are in no way representative of Cisco or any of it's partners, etc. None of these views, etc are supported and this is not a place to find standard product support. If you need standard product support please do so via the current call in numbers on Cisco.com or email email@example.com
Thanks and Happy Automating!!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.