One of the things I do as a standard thing in all of my workflows is explicit external logging of attributes and input parameters. Stripping down the code to the bare minimum, it's:
var inParamsWf = workflow.currentWorkflow.inParameters;
var inParamsWfToken = workflow.getInputParameters();
for (var i = 0; i < inParamsWfToken.keys.length; i++) {
for (var j = 0; j < inParamsWfToken.get(inParamsWfToken.keys[i]).length; j++) {
var eventMessage = inParamsWfToken.keys[i] + "[" + j + "]=" + inParamsWfToken.get(inParamsWfToken.keys[i])[j];
System.getModule("com.snip.general").newLogEvent(eventMessage,"info",true,null);
}
}
When encountering a tag, this used to properly log to my target like:
[11-18-2019 20:53:50 UTC] [INFO] tag=DynamicWrapper (Instance) : [com_vmware_cis_tagging_tag__model]-[class com.vmware.o11n.plugin.vapi.model.VapiObjectWrapper] -- VALUE : com.vmware.o11n.plugin.vapi.model.VapiObjectWrapper@734331fa[{category_id=urn:vmomi:InventoryServiceCategory:92911c61-ea01-4a3a-8bfe-5db733aa835d:GLOBAL, name=snip, description=, id=urn:vmomi:InventoryServiceTag:09480590-db58-4636-a77b-d7c59a623ce0:GLOBAL, used_by=[Ljava.lang.Object;@69f1b6b8}]
At some point in the past couple of months something changed which resulted in this code breaking when the input parameter encountered is of type com_vmware_cis_tagging_tag__model. I have not done enough testing to see if it extends to other tag related objects or other objects provided by vAPI. Now the default vRO logging throws:
[2020-01-21 09:05:36.222] [E] Cannot create com_vmware_cis_tagging_tag__model object : java.lang.NullPointerException
[2020-01-21 09:05:36.231] [E] Workflow execution stack:
***
item: 'New workflow27/item1', state: 'failed', business state: 'null', exception: 'Cannot create com_vmware_cis_tagging_tag__model object : java.lang.NullPointerException'
workflow: 'get tag loop' (56cfb3e4-43f7-4eff-997a-6badbb3a6788)
| 'attribute': name=uri type=string value=https://snip/api
| 'attribute': name=val type=string value=01083
| 'attribute': name=cat type=string value=Loc.Id
| 'attribute': name=tag type=VAPI:com_vmware_cis_tagging_tag__model value={"@class":"com_vmware_cis_tagging_tag__model","category_id":"urn:vmomi:InventoryServiceCategory:46f42579-a698-42d4-9c24-1e91232bd9ed:GLOBAL","name":"01083","description":"","id":"urn:vmomi:InventoryServiceTag:54a85756-3c1a-498e-bc35-5e8339c73f12:GLOBAL","used_by":[]}
| 'attribute': name=counter type=number value=0.0
| 'input': name=loop type=boolean value=false
| 'input': name=loops type=number value=1.0
| 'input': name=wait type=number value=1.0
| 'no outputs'
--workflow: 'New workflow27' (692f9b87-334f-47b1-b93e-c417f2be8887)
| 'input': name=arg_in_0 type=VAPI:com_vmware_cis_tagging_tag__model value={"@class":"com_vmware_cis_tagging_tag__model","category_id":"urn:vmomi:InventoryServiceCategory:46f42579-a698-42d4-9c24-1e91232bd9ed:GLOBAL","name":"01083","description":"","id":"urn:vmomi:InventoryServiceTag:54a85756-3c1a-498e-bc35-5e8339c73f12:GLOBAL","used_by":[]}
| 'no outputs'
| 'no attributes'
*** End of execution stack.
Since the last time it worked, vCenter, the vSphere plugin for vRO, and vRO itself have all been updated, so I'm not sure to which it is related.
Current vCenter verison is 6.5.0.30000-14389939. Current vRO vSphere plugin version is 6.5.0.15225986. Current vRO version is 7.4.0.15273518. vAPI plugin is 7.4.0.7235596, which is what came with vRO. I do not recall the previous versions of each when everything was working, though vCenter was 6.5.something and vRO was 7.4.something.
Are there any known issues between the aforementioned components which may result in this type of behavior? Just from looking at the proper logging versus the error, I see that "used_by" parameter is populated in the good log and absent in the error. And it refers to Java, which is the error being thrown by vRO.
For now I can probably add exceptions to my logging action based on the parameter type, but I don't know how many different types I could end up finding which behave this way now, so it could just go on and on and on.
