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...
Calling workflows asynchronously via Rest API
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...
- Login to your AO/CloudCenter Suite instance
- Click Suite Admin after logging in or click the 3-linked Diamonds at the top left (CloudCenter Suite Icon) and select Suite Admin
- Click your username in the top right and select "Generate API Key"
- This will generate your key... if you have already done it, *DO NOT* do it again or you will override it! You will get your user id which is your username and your API key which is your password.
- Now go back into AO and you can create your API Target... click New Target under Targets and Select HTTP Endpoint
- Use HTTPS, input your CCS server or hostname, put in your port and then I use /be-console/api as my path. Select or create a basic authentication based user with the credentials you got above and you should be good!
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.
Running Workflows via Pub/Sub
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...
- Create a new Exchange under Exchanges->Add Exchange. It can be a headers or direct. It does not have to be anything fancy. If you know the settings and feel good with them, then customize it how you like!
- Go to Queues and click Add a new queue. Durable is fine and use the basics.
- Then click on that queue and input your exchange and a routing key under "Add bindings to this queue". You can also do all this at the command line of course. You should see a bindings should up after clicking "Bind"
- You are now ready to pub/sub with your workflows!!!
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.
- Go to Events in AO
- Click New Event and select an AMQP Event
- If you do not already have a target for your AMQP server, then create one in the target ID. If you do have one then just select it. Note on ports... when setting up AMQP target, port 5672 is for http and port 5671 is for https, so select which one is best for you.
- Input your queue name that you created above
- If you have any filtering criteria you can also put that here.
- Now on the workflow you want to trigger or the "subscription" workflow, you can click Add on the trigger area and select EVENT and then add this event to it.
- To then "call" this workflow you will need to use the Publish AMQP Message activity on the "publish" workflow. You will call to the exchange name and routing key you defined above and then input your message body. When you run this workflow AO will publish the message to the exchange, AMQP will pass it to the queue, and then your "subscription" workflow will trigger off that message and start running! It is pretty fast and a nice way to do pub/sub or asynchronous workflow handling.
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 tac@cisco.com
Thanks and Happy Automating!!!
--Shaun Roberts
