Introduction to Workflow-Fu with VMware vCenter Orchestrator
- Workflow Organization
- Workflow Concepts
- Modifying the Built-In Workflows
- Creating New Workflows
- Workflow Scheduling
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Welcome to the dojo of the workflow. Herein we uncover the core concepts and mysteries that are the workflow and show you how to become one with your inner workflow. That is, by the end of this chapter you will have taken the first steps in your journey to Workflow-Fu mastery. Specifically, you will have learned the following techniques of Workflow-Fu:
- Workflow organization
- Workflow concepts
- Workflow-editing process
- Modifying built-in workflows
- Creating new workflows
- Workflow scheduling
Take a moment to step back and become one with your inner workflow because here we go.
Workflow Organization
Before we begin getting too deep into workflows, it is important to step back for a moment to talk about organizing your workflows. There are a few reasons for organizing workflows and a few strategies behind the organization. First, we talk about a few reasons why it’s important, and then we take a look at the approach that was adopted for the writing of this book.
Beside the fact that I can’t seem to keep my workflows straight, there are a few other reasons to keep your workflows organized. These include the obvious, easier to find and use again later use case. However, also consider you may not be the only person using vCO; therefore, having your workflows in a logical organization will reduce confusion and overhead in bringing other vCO users up to speed. Finally, consider the case where you enable users outside your vSphere management team with vCO web views. Having your workflows laid out well will help reduce confusion for this group of users, as well.
You can also choose to organize them by task, project, or system that the workflows interact with. Suppose, for example, you were creating workflows to tie in with a ticketing system. You would then create a folder specific to that system and then create subfolders and workflows underneath as needed.
You can also organize workflows by organizational roles and assign access rights to each top-level folder based on the role for each set of workflows. This is useful when you need to expose functionality to end users but don’t necessarily want to give away the keys to the kingdom. Do you want everyone to be able to create virtual machines (VMs)? Probably not, at least not without some manner of control or adherence to change control processes. In this case, you can restrict those workflows to the users or groups who must have access.
The approach I’ve taken in the deployment and examples used for this book is to start with a vCO Book top-level folder. This way, I won’t lose the workflows. I then created a subfolder for each use case from Part III, “Amazing Smoothies, Inc. (a.k.a. Real-World Use Case),” to make exporting them for use with the book simple. You can see this in Figure 6.1. When translated according to this description, it roughly maps to a top-level folder for the organization and subfolders for each project.
){kind=link}
Figure 6.1 “vCO Book” workflow organization