vRealize Automation Requests missing in Inventory in vRO and vCACCAFEEntitiesFinder.getCatalogItemRequests errors

[Hazenet]

HI all

I am running a VRA 7.3.0 (build 5604410) with a embedded vRO 7.3.0 (build 5481809) and default vCACCAFE plugin version 7.3.0 (build 5482658).

This is a lab environment.
So I have only 2 accounts in the vRA.

Both accounts have been given every possible permission in vRA (Tenant Admin, IaaS Admin, Fabric Group Admin, Business Group Manager and every role box ticked)

My own personal account (which is also given vRO Admin rights) and a service-account

If I login into vRO Client I see the "Default" vCACCAFE connection which uses a "Per User" authentication.

But the Requests folder in the Inventory is empty (even though the same user can se multiple requests in the vRA web gui)

I have tried to create a vCACCAFE connection against the same vRA server, but using "Shared" authentication instead, using the service account.

Same issue.

If I try to find Requests in JavaScript it fails.

Code:

var requests = vCACCAFEEntitiesFinder.getCatalogItemRequests(vraHost)

Result:

java.lang.NullPointerException (Workflow:Test - vRA Request / Scriptable task (item1)#54823)

Code:

var request = vCACCAFEEntitiesFinder.getCatalogItemRequest(vraHost, "9c1ee6e1-0c23-4b5e-abea-2b1b30ca21eb")

Result:

[2017-10-12 10:14:05.969] [E] Error in (Workflow:Test - vRA Request / Scriptable task (item1)#54823) 404 
[2017-10-12 10:14:05.991] [E] Workflow execution stack:
***
item: 'Test - vRA Request/item1', state: 'failed', business state: 'null', exception: '404  (Workflow:Test - vRA Request / Scriptable task (item1)#54823)'
workflow: 'Test - vRA Request' (e2b61589-c46c-4ccc-99aa-5e644147bf6f) 
|  'attribute': name=vraHost type=vCACCAFE:VCACHost value=dunes://service.dunes.ch/CustomSDKObject?id='e036d3ab-d4af-4d3c-b7e7-2f67d664f863'&dunesName='vCACCAFE:VCACHost'
|  'no inputs'
|  'no outputs'
*** End of execution stack.

[daphnissov · Accepted solution]

Hey Mads, this sounds suspiciously like the broken functionality acknowledged in this version of the café plugin. Install the updated one from here which will bring it up to build 7.3.0.5743786.

[iiliev]

Yes, this is the same issue.

One clarification for the KB article mentioned above. It talks about uploading and installing of KB2150546_o11nplugin-vcaccafe.dar. If you do this, you'll end up with two copies of the same plug-in, which will cause issues at runtime. So before uploading the patched plug-in, please rename the file from KB2150546_o11nplugin-vcaccafe.dar to o11nplugin-vcaccafe.dar

[daphnissov]

In my tests, I do not see this behavior. The plug-in prefaced with "KB" replaces the existing one in the file system, and Control Center only reflects the new plug-in.

find / -iname *vcaccafe.dar
/var/lib/vco/app-server/temp/dars/KB2150546_o11nplugin-vcaccafe.dar
/usr/lib/vco/app-server/plugins/KB2150546_o11nplugin-vcaccafe.dar

[iiliev]

Hmm, I recall seeing a PR opened about some issue with changed plug-in name. Perhaps it was about an upgrade scenario, where RPM command wasn't able to recognize that KB2150546_o11nplugin-vcaccafe.dar and o11nplugin-vcaccafe.dar are in fact one and the same plug-in.