VMware Cloud Community
Henrique_Cicuto
Enthusiast
Enthusiast
Jump to solution

vCACCAFEEntitiesFinder returns different type of data when called by vRA

Good evening,

I´ve created a workflow which is called during the vRA Machine Provisioned state.

The workflow starts with:

var resources = vCACCAFEEntitiesFinder.findCatalogResources(vRAHost);

vRAHost is a vCACCAFE:VCACHost type.

1) If it runs directly from Orchestrator, it works.

2) If it runs through vRA call, it does not work.

A System.log(resources) showed me this:

1) System.log when executed from Orchestrator (I see what is expected):

          DynamicWrapper (Instance) : [vCACCAFECatalogResource]-[class com.vmware.vcac.catalog.rest.stubs.v7_0.CatalogResource] -- VALUE : com.vmware.vcac.catalog.rest.stubs.v7_0.CatalogResource@86163617,DynamicWrapper (Instance) : [vCACCAFECatalogResource]-[class com.vmware.vcac.catalog.rest.stubs.v7_0.CatalogResource] -- VALUE : com.vmware.vcac.catalog.rest.stubs.v7_0.CatalogResource@153f9124

2) System.log when called by vRA:

[Formatar disco de VM do vRA/{com.mycompany/getVraDiskInfo} (11/11/16 00:44:24)]


That is the name of the workflow, the action and the execution timestamp. It appears to be the workflow token information. I see this and I go all "What the...?"


Just as an additional test, I re-run the failed token, the INPUTs are filled in with what was provided by vRA and IT WORKS JUST FINE!!!


I tried running this piece of code through an action, Scripted Task and the behavior is always the same.


Has anyone seen anything like it before? I just can´t grasp what is going on here.

Thank you very much.

Reply
0 Kudos
1 Solution

Accepted Solutions
Henrique_Cicuto
Enthusiast
Enthusiast
Jump to solution

Managed to solve it.

The issue was timing related:

- The workflow is called when machine reaches "Machine Provisioned" state;

- The code gets the provisioned catalog item based on the machine data;


The workflow was executing that part at the exact time after "Machine Provisioned" and before the catalog item being created, therefore the "weird" output was actually an empty value or something like that.


I added a sleep timer before the code and it´s working now (although not like I wanted it to).


Now I have another issue, but this one is now solved.

Thank you very much for all the support.


View solution in original post

Reply
0 Kudos
5 Replies
drummoau
Enthusiast
Enthusiast
Jump to solution

What is populating your vRAHost input?

Reply
0 Kudos
Henrique_Cicuto
Enthusiast
Enthusiast
Jump to solution

Hi,

Being a vCACCAFE:VCACHost type, it contains the connection to the vRA appliance and the default tenant: [https://<vra_portal_address>] [vsphere.local]. This connection uses a shared session.


I set it up as a configuration element at first, but even declaring it directly as an attribute within the workflow gave the same result.

Reply
0 Kudos
drummoau
Enthusiast
Enthusiast
Jump to solution

So it's not vRA trying to provide the vCACCAFEHost value when it calls the workflow?

Are you able to attach the workflow? I haven't experienced anything like this.

Reply
0 Kudos
Henrique_Cicuto
Enthusiast
Enthusiast
Jump to solution

Hehe, me neither. It is indeed very weird.

Below the code I developed. I´m also attaching two screenshots with the "weird" content and the "correct" content.

You can use this inside an Action and return diskInfo or directly into a Scriptable Task. The return is a Composite Type composed by String Arrays.

vRAHost is an INPUT/ATTRIBUTE of vCACCAFE:VCACHOST

vmId is an INPUT of the vRA virtual machine ID (not vCenter VM ID)

===============================================================

var resources = vCACCAFEEntitiesFinder.findCatalogResources(vRAHost);

var binding;

var vmData;

var vmDisks;

var drive;


var diskInfo = new Object();

diskInfo.id = new Array;

diskInfo.drive = new Array;

diskInfo.capacity = new Array;

diskInfo.label = new Array;

for (var i in resources)

{

     binding = resources[i].providerBinding.getBindingId();

     if (binding == vmId)

      {

           vmData = resources[i].resourceData;

           break;

      }

}

vmDisks = vmData.get("DISK_VOLUMES").value;

for (var j in vmDisks)

{

      if (vmDisks[j].getValue().get("DISK_DRIVE") != null)

      {

           diskInfo.id.push(vmDisks[j].getValue().get("DISK_INPUT_ID").value);

          diskInfo.drive.push(vmDisks[j].getValue().get("DISK_DRIVE").value);

          diskInfo.capacity.push(vmDisks[j].getValue().get("DISK_CAPACITY").value);

          diskInfo.label.push(vmDisks[j].getValue().get("DISK_LABEL").value);

      }

}

===============================================================


And once again:


1) If vRA calls it, it returns something weird within "resources";

2) If I re-run the failed token within Orchestrator Client, it works just fine;

3) If I run it directly through Orchestrator it works just fine.

Reply
0 Kudos
Henrique_Cicuto
Enthusiast
Enthusiast
Jump to solution

Managed to solve it.

The issue was timing related:

- The workflow is called when machine reaches "Machine Provisioned" state;

- The code gets the provisioned catalog item based on the machine data;


The workflow was executing that part at the exact time after "Machine Provisioned" and before the catalog item being created, therefore the "weird" output was actually an empty value or something like that.


I added a sleep timer before the code and it´s working now (although not like I wanted it to).


Now I have another issue, but this one is now solved.

Thank you very much for all the support.


Reply
0 Kudos