Meraki’s Dashboard is a powerful tool for network management and monitoring, but it’s limited by the very thing that makes it powerful. It has to be everything to everyone and that granularity can make it overwhelming to use on a day-to-day basis. All enterprises, large and small, have their own way of doing things and this pertains to network management and monitoring as well. This is where the power of Meraki’s Dashboard API comes into play.
45-minute webinar introduces you to the Meraki Dashboard API
On August 22nd at 11:00 AM EST, I will walk through everything you need to know to get started managing multiple organizations and the 1-to-N networks that fall under those organizations. We will start with an introduction to the Meraki Dashboard so we have context for the domain we will be working within.
Then we will move into API documentation and specific resources you’ll need to take into consideration when taking on the task of managing multiple organizations via APIs and code. After we have a comfort level with those APIs we will see how to actually implement those calls in code, and tie them into a collaborative automation framework that allows for seamless management and monitoring between multiple networks.
Now, if you’d like to do a little cursory research prior to this webinar, check out some of many Meraki resources available to you from DevNet:
- Meraki Developer Hub
- Getting Started with Meraki Learning Lab Module
- Code Exchange to get your projects started!
I can’t wait to see you all there! @theDeNap
Since the Meraki API doesn’t support conditional updates, how is it possible to avoid conflicting updates when multiple automations (apps) run against the same Organization/Networks? Seems intractable and a curiously large oversight.
Excellent question and one I personally hadn't considered fully in the last few years working with Meraki. The usual conversations I have tend to be an organization where one person/team is managing the Meraki deployment and any updates are run through them OR people who are just being introduced to programmability. I'm now VERY curious as I suspect this scenario could occur with direct dashboard access as well. I'm definitely going to talk to the product team about this as concurrent management is arguably a benefit of SDN.
Off the type of my head, one could build a message queue into their application and add in logic to check for conflicts (though, to your point, that would be a monumental effort to be bulletproof). Post-call unit testing with rollback could be easier, however that would be the best proactive solution.
I'm curious as to the scenario you encountered that prompted the question. If you'd like to share that would be greatly appreciated! If it's more academic curiosity, then thank you and I'll definitely be following up on that (and if I get answers before next Thursday I will address in the webinar)