If you have completed the first two parts of this blog series you should now have NSX registered as a REST host, a REST operation created to GET the firewall rules, and a workflow object that we can use in other workflows.
We are going to need to add another REST operation and create another workflow that will allow us to create new firewall rules.
Step One – Add a REST operation
Start the workflow “Add a REST operation”.
Select the NSX REST host object and enter a friendly name. The HTTP method will be POST and the Content Type will be application\xml. I’ve heard that JSON is easier but I will dig into that another time. For the Template URL you should use “4.0/firewall/globalroot-0/config/layer3sections/{sectionid}/rules”. The NSX distributed firewall lets you create sections of rules. In order to create a new rule you have to pass the section ID. You can create a variable that will be required by this REST operation placing it in curly braces in your Template URL string. As you can see “{sectionid}” will be expected when we run this REST operation.
We won’t be able to test this just yet as a HTTP POST takes a bit more effort than a simple GET. We’ll move on to creating a workflow to utilize this operation.
STEP Two – Create the REST workflow
Find and execute the “Generate a new workflow from a REST operation” workflow. You will need to select the REST operation that was just selected and the folder you want the workflow to be under.
Before we use this new workflow we need to make a couple of modifications. In order to actually POST the firewall rule we need to send the proper headers and content. There is a concept called “optimistic locking” or “optimistic concurrency control” that is used. In the GET workflow that we created in part two of this blog series an ETag or “entity tag” value was returned in the response headers. The same value is also returned in the XML output of the GET request as “generationNumber”. When we run our workflow we have to match the ETag value in the sending headers. This ensures that the resource we are trying to modify hasn’t been changed by something else.
Execute the workflow that was create in part two and take a look at the logs.
Notice the ETag value listed as “generationNumber” and we also have the section ID value that we will need to pass to the new workflow. There will be multiple section IDs returned so you will use the one that corresponds to the firewall section that you want to update.
Now that we know we have to match the ETag header let’s edit the workflow and add an input parameter. Right click the workflow, select edit, and then select the Inputs tab.
Now select the yellow arrow under Parameters to add a new one. It will add the parameter with a generic name. Select the name to rename it to something more meaningful.
Adding the ETag parameter is only the first step. We also need to tell the workflow what to do with it. Select the Schema tab, then the Scripting task object, and then the In tab.
We need to bind the parameter we just created to the Scripting task object. There is a small button that looks like two circles with a line connecting them. Select that to bind the new parameter.
This will bring up the Chooser window to select the new parameter.
We also need to modify the script to send the ETag value in the headers. Select the Scripting tab.
Notice the section “//Customize the request here”. We need to insert some code that sends the proper ETag value. Add the following code to that section:
request.setHeader("If-Match", etagnum ); System.log("If-Match: " + '"' + etagnum + '"' );
Almost ready to test but first we need to actually define the content that we are going to POST. For now we will use this sample XML.
<firewallRule disabled="enabled" logged="false"><name>virtuallygone-test</name><action>allow</action><notes></notes></firewallRule>
Note that you will need to modify the XML to use the correct section ID in your environment. Now, let’s put it all together and test this workflow.
Step Three – Test the REST workflow
We now have everything we need to run a test. Select the workflow and start it. You will need to grab the generationNumber from the XML logs of the earlier example and enter it here as the etag number. This number is specific to your environment.
Enter in the appropriate section id number.
Add in the snippet of XML code.
And if all is well you will once again get the green check mark of success!
Stay tuned for part three…
VirtuallyGone 