VMware Cloud Community
mooreb0314
Contributor
Contributor
Jump to solution

HTTP-REST Invoke a REST Operation Workflow Issues/Questions

I am looking for help in working with the HTTP-REST workflows. I want to add an Authorization header added to my already created REST Operation so I can provide the header param value when running the Invoke a REST operation workflow inside other workflows. It looks like I should be able to do this since the Invoke a REST operation workflow has a line of code var headerParamNames = restOperation.getHeaderParameters(); //line 8 which is used when setting the headers on the request. When running that workflow, I can set what I want the value for the authorization header to the header_param_0 input, however, that does nothing because my REST Operation has no actual header parameters. Ex: System.log(restOperation.getHeaderParameters() // prints nothing. How do I actually add header parameters to my REST Operations so I can utilize the header_param_0 input.

Is this how the below code should behave?

var tmpOperation = restOperation.newOperationFromThis()

tmpOperation.addMandatoryHeaderParameter("Authorization")

System.log(tmpOperation.isHeaderParamMandatory("Authorization")) // prints true

System.log(tmpOperation.getHeaderParameters(); // prints nothing... why?

I know I am able to create my own requests and set my own header on the REST Request Object, however I want to use the Invoke a REST Operation workflow that is provided by VMware because I'm not sure what Rest Operation I will be running at the start of the workflow as well as the headers needed.

It also appears that since you cannot add header parameters to a REST Operation from the Add a REST operation workflow, the below lines 28-31 on the Invoke a REST operation workflow will never be used in any circumstance.​

for (var k in headerParamNames) {

   System.log(" SET headers: " + headerParamNames[k] + " : " + headerParams[k]);

   request.setHeader(headerParamNames[k], headerParams[k]);

}

To me, it looks like you cannot invoke any REST Operations that use additional headers besides Accept and Content-Type from the Invoke a REST operation workflow. Please someone tell me I'm missing something obvious.

I guess all of the above can be addressed by one question: How do you set up a Rest Operation so that RESTOperation.getHeaderParameters() returns something other than null?

Also, com.vmware.library.http-rest.configuration/getHeaderParametersCount has a typo on line 1. return operation.getHeaderParameters().lenght; should be .length. Returns undefined otherwise. (vRO v7.3.0.5481809). Because of this, the Presentation for the Invoke REST operation will never ask you to enter the header parameter values even if you do some how have header parameters on your REST Operation.

Tags (2)
Reply
0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

Looking at getHeaderParameters() source code, the answer of your last question is "No" - there seems to be a bug in the implementation which needs to be fixed and new build of the plug-in to be released. The typo in getHeaderParametersCount() script action will also be fixed in this new plug-in build.

I'll open a PR to track these two issue.

View solution in original post

6 Replies
mooreb0314
Contributor
Contributor
Jump to solution

I think what I'll have to do is copy the Invoke a REST operation workflow and fix the issues that are present in it. Remove the Presentation referencing VMware's action with a syntax error, remove any mention of RESTOperation.getHeaderParameters() since I believe that always returns null, and have an array of HeaderParamName : HeaderParam instead of only HeaderParams.

I would like to know if anyone is able to have the getHeaderParameters() method return anything but null.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

Looking at getHeaderParameters() source code, the answer of your last question is "No" - there seems to be a bug in the implementation which needs to be fixed and new build of the plug-in to be released. The typo in getHeaderParametersCount() script action will also be fixed in this new plug-in build.

I'll open a PR to track these two issue.

mooreb0314
Contributor
Contributor
Jump to solution

Does this also change the Add a REST operation workflow so we can add additional headers? There is no option in the workflow or the Update a REST operation workflow either.​

Thanks for your help!

Reply
0 Kudos
PetarGeorgiev
VMware Employee
VMware Employee
Jump to solution

Hello all,

To clear the situation we need to mention that the state at getHeaderParameters() is populated by the the Swagger process engine of the REST plugin - when you add  a REST Host  defined by Swagger spec the swagger processor engine will examine the defined operations add there expected parameters. If there ware defined header parameters they will be available by the getHeaderParameters(). The result of getHeaderParameters() method by design could not be mutated by direct scripting API interaction, it is populated form the Swagger processor engine.

The  setHeader() method of "RESTRequest" object  type will be useful at described use case.

Additionally the typo fix will be available at the next official build of the vRO REST plugin.

Best Regards,

Petar

Reply
0 Kudos
mooreb0314
Contributor
Contributor
Jump to solution

Okay, just so I understand. Any REST Operation that requires additional headers present (i.e Authorization: Bearer token), cannot be ran from the Invoke a REST operation workflow, unless you added the REST Host by Swagger spec?

Is there any plan to add the functionality to add additional headers to REST Operations inside the Add a REST operation workflow?

Reply
0 Kudos
PetarGeorgiev
VMware Employee
VMware Employee
Jump to solution

Hello,

At this moment setHeader method of RESTRequest  (not RESTOperation) scripting type could be used to explicit setting of additional header parameters. The  setHeader method of RESTRequest  is be able to set the authentication header.

Best Regards,

Petar

Reply
0 Kudos