Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
In Part 1 and Part 2 of this series, we created three inputs for our vRealize Automation blueprint: Production, WordPress, SOX compliance. These three inputs correspond to property groups that allow us to associate multiple custom properties to a single input. Using property groups allows us the ability to templatize how each input affects the outcome of a request. In this article, the Genie that we’ve previously released from the proverbial bottle is about to take form, as we walk through how these three inputs come together to determine the outcome of our request.
Let’s look at how the different input options impact the different modules.
| Module | Environment | Application | Compliance | Convention | Outcome(Prod, WordPress, SOX) |
| Naming | Prod = pDev = dLab = l | WordPress = wpMSSQL = ms | None = nSox = s | {{env}}{{app}}{{comp}} | pwps |
| IPAM Network | Prod = prodDev = devLab = lab | Wordpress = webMSSQL = db | None = nullSox = sox | {{env}}{{app}}{{comp}} | prodwebsox |
| vCenter Folder | Prod = PRODDev = DEVLab = LAB | Wordpress = WORDPRESSMSSQL = MSSQL | None = nullSox = SOX | \{{env}}\{{app}}\{{comp}} | \PROD\WORDPRESS\SOX |
| vSphere Tags | ProdDevLab | WordPressWeb ServerMicrosoft SQLDatabase | No ComplianceSOX Compliance | See vSphere tagging below | ProdWordpressWeb ServerSOX |
To read the full article please visit the SovLabs Blog here.