This is the second part in the series of blogpost on automation and transaction management using Microsoft automation technologies, which in this case can be applied to Azure Automation, SMA and Orchestrator.
In this post we will talk about the key to a successful automation management, and that is the use of a contract in you transactions (in the first post, we refer to this as an “Order”). If you are into coding, you might have come across something called a “DTO”, which have the following explanation:
”Data Transfer Object. A distributed transaction involving one or more transaction resources implemented using object-oriented technology.”
Some more information could be found here: https://msdn.microsoft.com/en-us/library/ms978717.aspx
In our case, we want to keep track of the transaction and have a well-defined contract that could be posted between the different technologies as a DTO. Since most (if not all) our solutions in these automation technologies use PowerShell, we use a XML or JSON format to store our objects, because it’s easy to translate and easy to read. In this post we will present this DTO as XML.
So how is this DTO structured?
Well as a start we use “Order” as the root node in the contract. And then extend this with the sections below to hold other valuable information:
<?xml version="1.0" encoding="UTF-8"?> <Order> <TransactionId>SR235</TransactionId> <TransactionName>CreateUser</TransactionName> <Category>HR</Category> <Data> <CI Id="RIUL"> <FirstName>Richard</FirstName> <LastName>Ulfvin</LastName> <UserName>RIUL</UserName> </CI> </Data> <State> <ExitCode>0</ExitCode> <ErrorMessage></ErrorMessage> <LogLevel>3</LogLevel> <LogEntry></LogEntry> <LogPath>\\MyFileServer\HR\CreateUser</LogPath> </State> <Validations> <IsLocalUser>TRUE</IsLocalUser> </Validations> <Variables> <DomainController>ServerName</DomainController </Variables> <Actions> <Action Name="CreateUser" State="Pending" TargetId="RIUL" Source="ManageADUser" /> </Actions> </Order>
So, how do we actually use this contract?
First we need to set the TransactionId from the source that triggers the transaction, in most case this is some sort of CMS/CMDB, like Service Manager, Service Now etc (but could also be from VS Build). We could also set the transaction name to the corresponding service request. Category could also be used, like in this example it´s “HR”.
In the Data block, we store the information about the objects that we want to create, delete or modify, note that this could be one or more, in the example it’s a user. We use the term Configuration Item for objects in our DTO, this aligns with CMS/CMDB naming and will be referred to as CI in the rest of this blogpost.
Next is the section about State. This is to keep track of the transaction and know what happens, and also for us to hock up routing and be able to place the transaction in a “rollback” or “rerun” behavior. In this section we also store our exit codes and error messages if something goes wrong. We could also set up a log handler in this section, either to disk or if we can, to a web endpoint, hence the option LogPath. In the example, we log everything locally and use the log level 3, which for us means verbose output.
Under Validation, we store things that we want the transaction to make a “choice of path”. If for instance we would like to create a Virtual Machine, the placement on datacenters could be entered here, and then we could make a decision to trigger runbooks up in azure or keep running in local automation engines.
The Variables section is used for storing centrally managed information that are used for all the CIs you need to interact with. This could be the name of the Domain Controller to interact with when you create users or which exchange server web service to use when you need to create distribution lists. This could also hold information about different subscriptions and even encrypted credentials protected with certificates.
Finally Actions! This is where we append all the actions we need to do for the entire transaction to be fulfilled. This is usually all the single runbooks entered that need to be run for all CI’s we need to act upon (the CIs are linked with the TargetId entry in the example).
So, if the users of the HR department would fill in information about the user to onboard and add a property to also create an account for Office 365, we might add a validation entry with the name “IsO365User” and then later on dynamically append some more actions on the fly that could be named “CreateO365User” and “AppendO365Licence” and maybe handle these steps in a runbook called “ManageO365User“. Also if some of these runbooks fails, we could set the state to “Failed” and store the DTO in some place where we monitor for rerun behavior or rollbacks.
I hope this blogpost gave you an idea of how to use DTOs and how they can be implemented to solve more complex transaction logic. In a future post we will show you more practical implementations and also share some code with you on GitHub.
Best Regards,
Richard
The post Automation and transaction concepts part 2 appeared first on Addlevel.