vRO 7.6 Rest call to vRO

[carl1]

Our vRO logs vanish quickly and I want to write a workflow log collector.  I don't see any way to do this via vRO itself but you can call the vRO REST api and get the logs.  I have tested this code with vRO 8 and it works but for some reason, it fails with vRO 7.6.  Can someone see what I am doing wrong with 7.6?  I keep getting a code 500 and it doesn't seem to matter what the URL is.  If I change it to something invalid, then I get the 404 code as I should.  And yes, the bearer token is good.

Thanks all,
Carl L

var url = "/vco/api/workflows";
System.log(url);
request = vRAHost.createRequest("GET", url);
request.setHeader("Content-Type", "application/json");
request.setHeader("Accept", "application/json");
request.setHeader("Authorization", "Bearer " + loginToken);
var response = request.execute();
if (response.statusCode == 401) {
    throw "Bearer token has expired.";
} else if (response.statusCode != 200) {
    System.log("Response: " + response.contentAsString);
    System.log("Unable to get logs.  Code " + response.statusCode);
    response = null;
 }

[xian_]

How does your vRO7 authenticate? If it's a vRA embedded vRO than should be LDAP, so you'll need basic auth.

The docs:

How the vRealize Orchestrator REST API Works

The API supports a Representational State Transfer (REST) model for accessing a set of resources through a fixed set of operations. Every request to the vRealize Orchestrator REST API must be authorized by an authenticated user. Depending on whether you configure vRealize Orchestrator with LDAP, vCenter Single Sign-On, or OAuth2, the authentication scheme for the vRealize Orchestrator REST API is different.

LDAP Authentication

When vRealize Orchestrator is configured with LDAP, you must apply the HTTP Basic authentication scheme. With the HTTP Basic authentication scheme, you can authenticate against vRealize Orchestrator or a third-party system by including an Authorization header in every HTTP request. You must provide a base64-encoded user name and password in the Authorization header. For details about the HTTP Basic authentication, see RFC 2617. The REST resources expose a data model, supported by a set of client-side libraries that are available in the local Maven repository of vRealize Orchestrator.

Single Sign-On Authentication

If vRealize Orchestrator is configured with the vCenter Single Sign-On (SSO) server, you need a principal holder-of-key (HoK) token to access system objects in vRealize Orchestrator through the REST API. The HoK token is passed as a request Authorization header element. The value must be a GZIP, base64-encoded string.

OAuth2 Authentication

If vRealize Orchestrator is configured with VIDM, you need an OAuth bearer access token to access system objects in vRealize Orchestrator through the REST API. The OAuth bearer token is passed as an Authorization header element request. The value must be Bearer {token}.

[eoinbyrne]

I think you're using the wrong API for vRO 7.6 also

 If you check here - https://code.vmware.com/apis/582/vro-rest -  you will find a Swagger document which gives the complete REST API for the Application server instance.

You can also find this on your deployed node at this address - https://orchestrator_host:port/vco/api/docs/ (this is given the product documentation too btw).

On top of that you might also need to consider what type of Log information you're looking for. On the APIs I've directed you to, to get the workflow log events you must use this API

However this will only give you the cases where your workflow used Server.log to create a Server event (which are persisted to the application DB). Anything written using System.log will not be reported there (they go out to the scripting.log file in /var/log/vco/app-server on the vApp filesystem)

Interestingly, if you really want the scripting and server logs, you can hit the ControlCenter API over REST also. The Swagger documentation will be here on your node - https://[OrchestratorNode]:8283/vco-controlcenter/docs

I don't currently have a 7.6 node available but there is a Logs-Controller branch on that API which can be used to access a dump, to stream/tail the server log file. Authentication to that API follows similar rules to those referenced by @xian_ but IIRC when I did this I used "root" on the node I was playing with.

Anyway, the full transcript of your workflow invocation *could* be constructed if you use the Token ID to filter the Log stream from the Logs-Controller (scripting log lines have the token ID of the invocation embedded in them)

Full disclosure: I was trying to do all of the above for my own purposes in the past but in the end using LogInsight was simpler. I got as far as building a Java desktop app to with a text pane to show log traces in but never got around to completing it. My use case was that I wanted to be able to show workflow invocation lists & script logs to non-vRO users without having to 

- give them filesystem access to the vApp

- give them vRO client access just to view logs

Like I said, LogInsight provided for the requirement in the end & also catered for preservation of older transcripts (my app would only be able to see things that occurred AFTER it had started so no logs from yesterday for example. vRLI aggregates and stores the logs so it can show what happened last week easily) but it was interesting to play about with this stuff 🙂

HTH 

[carl1]

Well, I am getting a Bearer Token so I am assuming that I am getting logged in.

[carl1]

Not sure why you think I am using the wrong API.  I am using the one at https://<vra>/component-registry/services/docs#apis

I know that the /vco/api/workflows is not in there, but even if I change it to /vco/api/workflows/<workflowId>/executions, I still get the 500.  The logs I am looking for (which would be at /vco/api/workflows/<workflowid>/executions/<exid>/logs) are the logs for a particular workflow run (the same as you find in the vRO client).  If I pull the main servers logs, then I will have to scan it for all relevant entries.  I even tried a different URL (/vco/api/tenants/<tenantId>/workflows.  Still a code 500.

Thanks all for the responses.

Carl L.

[xian_ · Accepted solution]

But it's accepted by vRA API only. Let me give you an example what I mean.

vRO API call with basic auth (working fine):

curl -s -k https://vra.corp.local/vco/api/inventory -u Administrator:VMware1!

vRA API call with token (working fine):

curl -s -k -H "Authorization: Bearer $token" 'https://vra.corp.local/catalog-service/api/catalogItemTypes'

They are authenticating differently. From the code you posted I suspect vRO will try to authenticate with the credentials of vRAHost REST host (not the token you provided as header).

So if I try to modify my first vRO API call to use the token (that is valid with the second command), I get error 500 just like you:

curl -k -H "Authorization: Bearer $token" 'https://vra.corp.local/vco/api/inventory'

Fix the auth of the endpoint and you should be fine.