- Cisco Employee,
This comes as the initial installment of a weekly(hopefully) blog posting by myself and maybe other people of interest in the Cisco TEO Community. We plan to provide tips, tricks, best practices, and all kinds of other good reading for your enhancement of the Tidal Enterprise Orchestrator product.
We believe TEO to be the tops as far as automation software in the industry and look forward to providing customers with best in class support and best in class software.
Shaun's Thoughts on Process Authoring
There are so many things you can do with process authoring and creating your own content. Do you want to orchestrate the top 10% of your mundane IT tasks? Do you want to be alerted to bad conditions in your environment? It can all be done. When starting the process authoring cycle I tend to follow this model:
1) Find an issue that I can address with some solution that is repeatable Is there a service that always needs to be on? Can I turn it back on automatically? Is there an issue I need to monitor in one of my systems?
2) Write/draw a flow diagram that displays how I would handle the above issue from start to finish. Include all "if/then" type breakpoints
3) Next look at what settings should be configuration/variable. Then create the global variables for those. Is there a threshold that could vary per system? Is there a place where I need to configure some table type data?
4) Then look at how the process should begin. Do I need to run this every 5 minutes on a schedule or do I need to trigger off some event? The event could be a windows event log entry, CCMS alert, other task, etc
5) Then follow the flow diagram from step 2 and the process almost begins to write itself. Knowing/having this flow is vital to successful process authoring.
6) Review the process once written and test it and see if you can break it!
Other Thoughts: Knowing the limitations of the software you are interfacing with and the software you are using is vital to successful process authoring. If you cannot start and get "writer's block" even after doing your flow diagram, open a new process and write something simple. Write a process to execute a command at a windows prompt and report back the results. It is vital to get yourself in the process authoring mentality before attempting to take on a large scale/multiple process project inside of TEO.
Quick Hitter:In doing monitoring type process I think it is important to do the monitoring in one process and if the issue arises raise an alert. Then have a second process that triggers off that alert and does some form of automated recovery. Having multiple processes is never a bad thing and can help spread out process load from an authoring standpoint.
Shaun's Weekly Tip - Archival Setting for Debug Use
Sometimes support(or you) will need to debug a process. Many of the processes we deliver(and even some you/your team might author) will have the Archival option disabled. If you look at a process's properties and then go to the options tab you will see a checkbox for "Archive completed instances". If unchecked when your process runs, the process's activity instances will not be saved to the database, only the overall state of the process. So if you ran multiple database queries inside that process you could not see the output of these queries via the Operations area after the process ran. (Support many times will refer to this as Persistence being off/on)
If you ever need to debug one of these processes you need to open the process and check the box next to the above setting and then save the process. Much of the delivered SAP content comes with this unchecked as saving all the leftover activity instances is not really needed and can add extra database overhead. Creating a process from scratch will always have this checked. It is a best practice, in my opinion, to uncheck this if you have a process which does nothing more than monitor something and raises an alert on it. (much similar to the way the Incident Analysis for SAP content works) For further or more in-depth information on this feature please see the external tech note or contact support. (external tech note is #112204)
Shaun's Weekly Q/A
Ever week I will pick a handful of questions from you, the reading TEO public, to answer in this part of the blog. They can come from comments posted below or via an inbox I have setup at [email protected]
The e-mail inbox will not be responded to and is not a place to send bug/issue questions, more of a place to send quick hitter type questions or thoughts about the week's blog post. The most insightful/best e-mail/comment will win "Comment of the Week" honors for the following week's blog post.
Please also let me know if you like the format of this blog and what else you would like to see/know about. Feel free to give any ideas as to future blog posts, etc and I will be happy to post them. I hope to do more how-tos, best practices, tips, tricks, and hopefully some interviews of the important people behind the scenes of TEO. My hope is to have a once/week blog entry here on TEO!
WEEKLY TEO BLOG DISCLAIMER: As always, this is a blog and my (Shaun Roberts) thoughts on TEO, my thoughts on best practices, and my experiences with the product 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 (650-475-4600 or 877-55-TIDAL) or via e-mail at [email protected] (please include your Cisco ID when emailing in)
Thanks to all for reading and happy automating!
TEO Support Team Lead