Quantcast
Channel: VMware Communities : Discussion List - vRealize Orchestrator
Viewing all articles
Browse latest Browse all 6251

5.1 VclHost calls not backwards compatible

$
0
0

I am testing out our existing VCO workflows in a 5.1 environment in order to verify existing functionality and have run into a few problems.  The first problem was using the 1.5 vCD plugin and attempting to call updateSection() on a vApp to modify firewall configuration.  This gave a compatibility mode error, so I decided to upgrade the vCD plugin to 5.1 and try again.  That is when I found that the VclHost.getEntityById() method has been changed to take a finderType instead of entityType for the first parameter.  Both take a string representation but the string representation of objects are different and thus nmot compatible.

 

For example, the EntityType string representation of a Blocking Task object is: "vcloud:blockingTask"  but the FinderType string representation of a Blocking Task object is: "BlockingTask"

 

The worst part is that the VclNotificationHelper class returns objects that can tell you the EntityType, but not the FinderType.  So in 1.5, you could ask the Helper for the id and type and pass those directly to the getEntityById(), like this:

 

var helper = new VclNotificationHelper();
helper.setMessage(messageBody);

var entityLink = helper.getEntityLink();

var returnObject = host.getEntityById(entityLink.type, entityLink.id);

 

In 5.1, it looks like I will have to change every instance of getEntityById to be hard-coded to a specific VclFinderType value.  This porting will be tedious, but not difficult.  Does anyone know if there is an association between EntityTypes and FinderTypes that can be leveraged?


Viewing all articles
Browse latest Browse all 6251

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>