Automating F5 AFM Using vCO Dynamic Types and vCAC – Part 2

This post is a continuation of Automating F5 AFM Using vCO Dynamic Types and vCAC – Part 1. In this post I will cover how the F5 Dynamic Object types were created and how to leverage these objects with vCAC.
Again a big thanks to Christophe Decanini and Marc Chisinevski for this example.

vCO F5 BIG-IP Dynamic Types Demo Package can be downloaded from -> com.definedbysoftware.DT.F5.package


Using the Dynamic Types Plugin Generator with F5->

So first things first we need to set up the Dynamic Types plugin with the F5 BIG-IP using the Dynamic Type Plugin Generator. Now although this is not a completely straight forward task (as the BIG-IP REST API requires custom serializedObject Actions) the reward of leveraging an inventory of objects for lists and trees are worth it.

The best part about of the use of Christophe Decanini’s Dynamic Type Plugin Generator is that is basically makes any REST API into a vCO Plugin 🙂 For the F5 this then allows us to create a vCO inventory of anything supported by the REST API not just the LTM module like the existing F5 vCO Plugin.
Dynamic Types are probably best described by Christophe post on XaaS as…
“Dynamic Types is a new vCO feature shipped starting with vCO 5.5.1 (experimental) allowing creating inventory types dynamically without doing any Java development. It brings together the quick implementation of the REST / SOAP plug-ins with the convenience of using inventory objects leveraged by vCAC XaaS.”

It is also important to note that Dynamic Types are now fully supported as of vCO 5.5.2.

To get started simply ensure you have an F5 BIG-IP you can connect to (preferably running at least version 11.5) and have downloaded and installed both Christophe’s Dynamic Type Plugin Generator and the demo package com.definedbysoftware.DT.F5.package.

The F5 Dynamic Types demo package essentially includes some example serializedObject Actions for parsing the BIG-IP JSON as well as this AFM Address List example workflow. In this early release of the package I have included serializedObject Actions for the following use cases:

  • AFM Address Lists – https://<BIG-IP.IP>/mgmt/tm/security/firewall/address-list
  • LTM Virtual Servers – https://<BIG-IP.IP>/mgmt/tm/ltm/virtual/?expandSubcollections=true
  • LTM Pools – https://<BIG-IP.IP>/mgmt/tm/ltm/pool/?expandSubcollections=true
  • LTM Nodes – https://<BIG-IP.IP>/mgmt/tm/ltm/node

You will notice above that some of the URL’s include the ?expandSubcollections=true flag. This is used to all the REST call to expand subcollections and return details of linked objects as nested JSON objects. This is very useful as without it you would need to do a second REST call to get the members of a pool for example.


Setting up the Dynamic Types Plugin Generator with F5->

So this process is based on Christophe’s Dynamic Type Plugin Generator Tutorial and as such I’m not going to repeat all the content in that post. Instead I’ll focus on what is different from the Twitter example and how you can create your own serializedObject Actions.

1. Setup your Dynamic Types Namespace and matching REST Host using Workflow “-1- Create a plug-in”. The only real things to consider here are:

  • Use a high level URL such as “https://<BIG-IP.IP>/mgmt/tm”. This allows the one REST host (and namespace) to be used for multiple F5 modules.
  • Use Basic Authentication.

2. Now the fun begins with the plugin creation. Run Workflow “-2- Create a new plug-in type”.
Select your created Dynamic Type namespace and enter a name for the root folder and type name. I have also uploaded a neat little F5 icon which adds a bit of style.


3. Now we need to provide URL’s, seralizedObject Actions and validate the output for the findAll, findbyID and findRelations functions for the plugin. For AFM all URL’s start with “https://<BIG-IP.IP>/mgmt/tm/security/firewall”  and in this case we are going down to the /address-list/ URL.


4. After submitting the findAll request for Address-Lists you should get valid response content which matches a string similar to the one below.


Before we move on to the next step I will explain why I have provided the custom serialzeActions. If you copy the provided JSON response into a JSON viewer you will see a structure similar to the one below.

You will notice that the JSON response starts off with a nested list for each Address List. This format is used across the entire BIG-IP platform and because the actual content we need is down a second level the provided GetPropertiesFromSerializedObject action will not provide the information we need.

However having thought of this Christophe has provided an option to use a custom action to parse the JSON response. These actions provided in my demo package above which can be used to parse the response. I have included some sample actions which can be used for AFM Address-Lists, LTM Virtual Servers, LTM Pools and LTM nodes. The reason the actions are specific to varies functions is that I am selecting which properties to push back to the plugin generator as it is rare that you will want all of them.

If you wish to use these actions for other F5 modules simply duplicate them and change the property matching accordingly. Match what properties you wish to return based by first looking at the response in a JSON viewer.


5. After selecting the getF5AddressListAFM action the check properties validate should show what properties have been found. In my case the nodes show as below. If you’re happy accept the result and we move on to find an object by ID.

name : AppServers
id : AppServers
description : Application Servers
selfLink : https://localhost/mgmt/tm/security/firewall/address-list/~Common~AppServers?ver=11.5.1
kind : tm:security:firewall:address-list:address-liststate
generationID : 1255
addresses :,,


6. Under the findbyID method we need to provide a URL on how to just retrieve one item by its ID. For BIG-IP this is usually the exact same URL followed by /~<Partition>~<ObjectName>/. In our case the getF5AddressListAFM action is setting the name of the object to the ID property so the URL is simply https://<BIG-IP.IP>/mgmt/tm/security/firewall/address-list/~Common~{ID}


7. The GET should then return a valid JSON response for which you are then prompted to provide another deserialized definition. You will need to supply the getF5AddressListObjAFM action which is different to the action provided with the findAll. This is because when selecting an object by its ID the nested list format is not used. You could use the default action however using my provided action will save you having to adjust the properties accessors to match the previous findAll query.


8. Once complete you are prompted with the final stage for findRelation. The URL and custom action simply match the findAll step.

9. In the final step you are prompted if you would only like to use properties found in both findAll, findbyID and findRelation. You can simply answer Yes as the JSON parse actions collect the same properties for each step so there should be no difference.

10. Bam! That should be all there is to it and you will have a object in your vCO inventory for each AFM Address List with a comma separate property for each IP that is in list.



Setting up the vCO AFM Workflow and vCAC Custom Action->

So with the F5 Address List objects now setup we can start to leverage them for vCO and vCAC workflows.

1. So before we configure the demo workflow F5 Add IP address to AFM Address List – Dynamic Type we need to setup another REST operation for PUT. BIG-IP use both PUT and POST depending on the location. See the BIG-IP REST User Guide for details. Simply use the Add REST operation workflow and the Template URL should match that of the findbyID URL that was used earlier with either PUT or POST as the method.


2. Edit the F5 Add IP address to AFM Address List – Dynamic Type workflow and update the Attributes for restOperationGET and restOperationPUT pointing them at your own F5 REST operations for GET and PUT based on findbyID.

3. Edit the workflow Inputs and update the Parameter for F5Address List and point it to the newly created Address List type. Note: Remember to use the type its self not the folder.


4. Give the workflow a whirl by Right Clicking on an Address List object and selecting Run workflow… The Address List should then be automatically populated and you only need to select a VM. Note this workflow uses VMtools to get the IP address so the VM must be powered on. Once the workflow is complete reload the Dynamic Types and the VMs IP address should now be in the list 🙂


5. Now onto vCAC. The following is based on the latest and greatest vCAC 6.1 however it is basically the same process for 6.0.
Under Advanced Services Designer create a new Resource Action and select the F5 Add IP address to AFM Address List – Dynamic Type workflow. The resource type should automatically map to the input type of VM.


6. In the details tab if your using vCAC 6.1 you can leverage the new state functionality have only have the action available if the VM is powered on.


7. Edit the form field to set the type as a List.


Your done 🙂


Happy Automating…. Chris Slater out.

Leave a comment

1 Comment

  1. Phil Barlow

     /  September 11, 2014

    Chris, great set of posts, really useful material and pretty straight forward to follow.


Leave a Reply

Your email address will not be published. Required fields are marked *