pjank
Contributor
Contributor

getEntityById() won't work for network entity type?

Hi,

I'm using the notification helper (VCloud 1.5 plug-in) to parse a notification on the AMQP bus from VCD.  The subsequent call to VclHost.getEntityById() works fine if the entity type is for a vApp or a vAppTemplate, but returns null if the type is VclEntityType.NETWORK.value (which is 'vcloud:network').  For example, the following code returns a vApp object just fine if that is the owner of the task, but the same code returns null for the network object when it is the task owner:

//Get Notification Helper
var helper = new VclNotificationHelper();
helper.setMessage(messageBody);

//Get Entity
var ownerType = helper.getTaskOwnerLink().type;
System.debug("ownerType: " + ownerType);
var ownerId = helper.getTaskOwnerLink().id;
System.debug("ownerId: " + ownerId);
var network = host.getEntityById(ownerType, ownerId)
System.log("network: " + network);

The debug lines properly output: "ownerType: vcloud:network" and "ownerId: urn:vcloud:network:34dc3815-30c8-4bb1-9242-df6c485fb56b"  Does anyone know of a way to load up the network object in the 1.5 plug-in once I have the id?

0 Kudos
5 Replies
TimLawrence
Enthusiast
Enthusiast

Hi,

I am having the same issue although my code is not quite as elegant as yours 🙂

The Network object never gets set. I tried using both "type" & "xsi:type". Neither worked.

var xDoc = XMLManager.fromString(sXML);

var Params=xDoc.getElementsByTagName("ns6:Params");

if (Params.length ==1){

var sType=Params.item(0).getAttribute("xsi:type");

var sID=Params.item(0).getAttribute("id");

}else{

System.error("Unable to Establish Network ID");

}

var oNet = Host.getEntityById(sType,sID);
if (! oNet){System.error("Object Not Set");}
System.log(oNet.name)
0 Kudos
TimLawrence
Enthusiast
Enthusiast

Actually,

I take that back. If I manually set sType to "vcloud:network" then it works.

Not sure if I can get this from the message or the task xml?

Tim

0 Kudos
pjank
Contributor
Contributor

Hi Tim,

Depending on which message you are working with, it is likely that the proper type is available there.  In my case the network object was the task owner, so my reference to VclNotifcationHelper.getTaskOwnerLink().type will return "vcloud:network" as expected.  Alternately, you can use the getTaskOwnerLinkType() call or VclEntityType.NETWORK.value for a static reference to the correct type.

Since you saw success, I decided to take another look at it and I think my problem was due to the state of the specific vApp network object when the message came accross.  If I choose some non-changing org network from the inventory, this works fine for me as well.  By the way, as a work-around, I was able to get a handle to the network object by using the Query Service instead.  It is a little more work to setup the query, and I had to search by name, then filter the results by id, but in the end it worked, so that is also another option for accomplishing something liike this.  An example for using the Query Service to find a network would be something like this:

var queryService = host.getQueryService();
var expression = new VclExpression(VclQueryVAppNetworkField.NAME, network.name, VclExpressionType.EQUALS);
var filter = new VclFilter(expression);
var params = new VclQueryParams();
params.setFilter(filter);
var resultSet = queryService.queryRecords(VclQueryRecordType.VAPPNETWORK, params);
while (resultSet != null) {
    var records = resultSet.getRecords(new VclQueryResultVAppNetworkRecord());
    System.log(records.length + " records found");
    for (i = 0; i < records.length; i++) {
        System.log("name:" + records[i].name);
        System.log("id" + records[i].id);
    }
    resultSet = resultSet.getNextPage();
}

0 Kudos
TimLawrence
Enthusiast
Enthusiast

Hi,

Thanks for your response. Useful to have those methods to receive the type.

Another issue I have which you may or may not have an idea on is this:

I am using the network objects along with blocking tasks to try and identify when External IPs are removed from a network (and hence check them in to my IPAM database).

  1. User removes IP and clicks save
  2. The task is blocked and a message is sent out on the AMQP bus
  3. Orchestrator workflow retrieves the message and gets the blocking task object.
  4. Whilst the task is still blocked I get the task object and retrieve the network object.
  5. I use .toXml() on the network object to get the list of currently configured external IPs and add them to an array
  6. I allow the blocking task to resume. Once complete I call .Xml() again to get the new list of external IPs in a nother array
  7. I diff my 2 IP address arrays to hopefully see what has been added/removed.

This all works (code-wise) except for the fact that the XML that is returned from the network object is always the same.

It looks as though the XML is updated as soon as the task is completed and perhaps is just commited once the task is unblocked.

The only other way I can think of to do this is to save the task definition, force the task to fail, grab the network XML and then fire a new task with the same definition.

Feels like a pretty rubbish way of doing it though.

any ideas?

I might post this in the main forum too.

Thanks

Tim

0 Kudos
pjank
Contributor
Contributor

Hey Tim,

I have run into similar issues before with the local object being cached.  Many of the Vcl classes include a method entitled updateInternalState() which you can execute on your local object instance in order to force it to go sync with the actual server-side object.  The blocking task would definitely keep the update from occuring at first, but once you resume it, it would have to be something else hiding the update from you.  I'm not sure which type of network object you are querying specifically, but I would definitely check and see if the update method call exists for it and give it a try.

Cheers,

Peter

0 Kudos