In part 1 of this short series, I set the scene for a blueprint VM requiring a DNS record to be created in AWS Route53. I documented the vRO resource and configuration elements that would be needed, along with a handful of actions. In the final part, we tackle the main workflow plus

an extremely important plugin which brings the entire solution together.

Other posts in this series:

1. Part 1
2. Part 2

Plugin

To be able to communicate with AWS we will need to be able to hash and encrypt our API requests. Unfortunately, vRealize Orchestrator has no way to natively do this, so requires a third-party plugin.

Thankfully VMware has already thought of this and has created the crypto plugin, which can be found at https://github.com/vmware/o11n-plugin-crypto.

Download and install the plugin in the vRO Control Center (on port 8283):

Main Workflow

Create a new workflow called Modify Route53 DNS. Create four inputs all of type string:

• inAction
• inRecord
• inTtl
• inType
• inValue

As we will be presenting this workflow as XaaS in vRealize Automation, take a few minutes to adjust the presentation – this will save having to do it later. For example, I present the user with a set of predefined answers for the inAction input of “CREATE” and “DELETE”.

Add the following attributes:

• attAccessKey
• attAmzAuthDate
• attAmzDate
• attAuthString
• attBody
• attCanonicalRequestHash
• attHashedPayload
• attHostedZone
• attHttpRequestMethod
• attRegion
• attRestHost
• attSecretKey
• attService
• attSignature
• attSignedHeaders
• attSigningKey
• attStringToSign
• attUrl
• attXmlConfigBody

All these are of type string, except for attRestHost (type: Any) and attXmlConfigBody (type: Resource Element).

Link the attAccessKey and attSecretKey configurations to the login configuration elements we created in part 1. Repeat the procedure for the attHostedZone, attRegion, attService and attUrl configurations. Set attXmlConfigBody to the route53.xml XML file we uploaded. Finally, set attHttpRequestMethod to POST.

Create a scriptable task on the canvas. Call it “Define Request Body” and bind all the available inputs, along with the attXmlConfigBody attribute. Set attBody as the out attribute:

Paste in the following code:

Task 1

Create another scriptable task called “Task 1”. Drag the following in attributes in:

• attBody
• attHostedZone
• attHttpRequestMethod
• attUrl
• And the following

And the following out attributes:

• attAmzDate
• attCanonicalRequestHash
• attHashedPayload
• attSignedHeaders

Paste in the following code:

Task 2

Repeat the same process for Task 2.

In attributes:

• attAmzDate
• attCanonicalRequest
• attRegion
• attService

Out attributes:

• attAmzAuthDate
• attStringtoSign

Code:

Signing Key

Now we have calculated our string to sign, we need to produce the signing key.

Drag an action element onto the canvas and select the getSigningKey we created in part 1. Match the inputs with the corresponding in attributes, and map the action output to the attSigningKey out attribute:

Now our workflow is starting to take shape!

Task 3

In task 3 we take our string and sign it. Create another scriptable task and call it “Task 3”.

Add two in attributes, attSigningKey and attStringToSign. Map the out attribute to attSignature.

Paste in the following code:

Task 4

The last of the tasks is to put all our data together to form the auth string. This requires the following in attributes:

• attAccessKey
• attAmzAuthDate
• attRegion
• attService
• attSignature
• attSignedHeaders

The out attribute is simply the attAuthString:

Finally, paste in the following code:

Creating the REST Host

Now we have completed all of the AWS API tasks we need to build our REST request and submit it. To do this, drag another action to the canvas and select the createRestHost.

Select the inUrl in attribute and map the out attribute to attRestHost.

Submitting the Request

Now we come to the part where we submit our request.

Finally, create one last scriptable task called “Submit Request”. Use the following in attributes:

• attAmzDate
• attAuthString
• attBody
• attHashedPayload
• attHostedZone
• attRestHost

Paste in the following code:

When complete, the main workflow should look something like this:

Run the Workflow

To confirm the workflow works as expected, run it manually before publishing in vRA:

If all goes well it should create a record in Route53:

If not, retrace your steps to see what you might have missed.

Publish XaaS

Now we have authored our workflow in vRO, it is time to publish it in vRealize Automation.

Navigate to the Design tab in vRA 7.x and click XaaS, followed by XaaS Blueprints. Click New, and then drill-down to find your workflow. Click Next >

Make any changes as needed, then click Next >

If you have taken the time to improve the workflow presentation this will be reflected here. Otherwise, that will need to be done now, and re-done should you ever need to re-generate the form.

Once you’re happy with the layout, click Next >. As there will be no resource type to output, click Next > followed by Finish.

Please note: don’t forget to publish your XaaS Blueprint! That gets me. Every. Single. Time.

Finally, publish your blueprint in the catalog ready for your users…

…and request it: