VMware Cloud Community
Tyknee
Contributor
Contributor
Jump to solution

Correctly sending custom headers to Invoke a Rest Operation

So I'm very new to vRO (less than 48 hours), but I'm getting the hang of it.

I'm porting a powershell script over to vRO for reasons that I don't want to get into (long political story). I'm having a problem specifying custom headers to the "Invoke a REST operation" workflow within my custom workflow. The specific headers should look like this:

"x-isi-ifs-target-type" = "container"

"x-isi-ifs-access-control" = 770

(the target-type container is mandatory, the other one isn't)

When I look at the Invoke a REST operation workflow, I see that it has some inputs called headerParamX (where X = [0..9]). I've figured that was going to be my key to victory, however no victory has been obtained.

I've created an attribute named fheader1, set the type to string, and put the value at "x-isi-ifs-target-type" = "container". I then bound fheader1 to headerParam0. However when I run the workflow, here is the relevant output:

[2019-04-24 08:02:04.335] [I] ****Headers****

[2019-04-24 08:02:04.337] [I] container

[2019-04-24 08:02:04.338] [I] Wed, 24 Apr 2019 13:50:17 GMT

[2019-04-24 08:02:04.340] [I] 1.0

[2019-04-24 08:02:04.341] [I] timeout=15, max=500

[2019-04-24 08:02:04.342] [I] Apache/2.4.29 (FreeBSD) OpenSSL/1.0.2o-fips mod_fastcgi/mod_fastcgi-SNAP-0910052141

[2019-04-24 08:02:04.344] [I] Wed, 24 Apr 2019 15:02:04 GMT

[2019-04-24 08:02:04.345] [I] GET, PUT, POST, DELETE, HEAD

[2019-04-24 08:02:04.347] [I] application/json

[2019-04-24 08:02:04.348] [I] 0777

[2019-04-24 08:02:04.349] [I] chunked

[2019-04-24 08:02:04.351] [I] Keep-Alive

[2019-04-24 08:02:04.352] [I] "4294967298-18446744073709551615-266"

[2019-04-24 08:02:04.388] [I] Setting defaut content type to: 

[2019-04-24 08:02:04.389] [I]  acceptHeaders null

[2019-04-24 08:02:04.404] [I] Content as string:

{"errors" : [

{

"code" : "AEC_ARG_REQUIRED",

"message" : "'x-isi-ifs-target-type' must be set."

}

]

}

It looks like it sent the parameter container but may not have given it the right name? I'm not sure. I've tried a few different formatting options as well, removing quotes, etc. I've also seen that most people tend to just write their own REST calls in javascript and use "Scriptable task", but that sort of defeats my purpose of trying to put this into a format that "non-scripters" can read (again, long political story).

Please random people from the internet, tell me what I'm doing wrong. My poor hairline can't take it anymore...

0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

If you look at the scripting code of 'Invoke a REST operation' workflow, you will see the following (only the code relevant to headers, the other code omitted)

var headerParams = [headerParam_0, headerParam_1, headerParam_2, headerParam_3, headerParam_4, headerParam_5];

var headerParamNames = restOperation.getHeaderParameters();

for (var k in headerParamNames) {

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

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

}

The actual header assignment is done on line 07 above. So, the header name to be set is taken from the element of array headerParamNames, and the header value is taken from the matching element of array headerParams.

How the array of header values is populated is shown on line 01. The values are coming as input parameters of the workflow - headerParam_0, headerParam_1, etc. When you start the workflow, you should provide these values, in your case container, 770, etc.

The more interesting part if where the header names come from. As shown on line 03 above, they are fetched from the REST operation object itself, and as there is no code to initialize them with your specific header names - x-isi-ifs-target-type, x-isi-ifs-access-control, etc. So you have the following options:

1) Insert some scripting code on line 02 (you may want to duplicate this workflow in order to be able to make changes) to add your header names to REST operation object (perhaps using the scripting method RESTOperation#addMandatoryHeaderParameter(name))

2) Alternatively, replace the code above with your custom code to set the headers directly on request object, using the scripting method RESTRequest#setHeader(name,value)

View solution in original post

0 Kudos
2 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

If you look at the scripting code of 'Invoke a REST operation' workflow, you will see the following (only the code relevant to headers, the other code omitted)

var headerParams = [headerParam_0, headerParam_1, headerParam_2, headerParam_3, headerParam_4, headerParam_5];

var headerParamNames = restOperation.getHeaderParameters();

for (var k in headerParamNames) {

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

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

}

The actual header assignment is done on line 07 above. So, the header name to be set is taken from the element of array headerParamNames, and the header value is taken from the matching element of array headerParams.

How the array of header values is populated is shown on line 01. The values are coming as input parameters of the workflow - headerParam_0, headerParam_1, etc. When you start the workflow, you should provide these values, in your case container, 770, etc.

The more interesting part if where the header names come from. As shown on line 03 above, they are fetched from the REST operation object itself, and as there is no code to initialize them with your specific header names - x-isi-ifs-target-type, x-isi-ifs-access-control, etc. So you have the following options:

1) Insert some scripting code on line 02 (you may want to duplicate this workflow in order to be able to make changes) to add your header names to REST operation object (perhaps using the scripting method RESTOperation#addMandatoryHeaderParameter(name))

2) Alternatively, replace the code above with your custom code to set the headers directly on request object, using the scripting method RESTRequest#setHeader(name,value)

0 Kudos
Tyknee
Contributor
Contributor
Jump to solution

That makes sense, I saw the same thing when I looked at the code.

It seems to be a weird design choice by whoever created the "Invoke a Rest Operation" workflow. I guess I'll just create my own scriptable tasks and go from there.

Thanks for confirming I wasn't crazy!

0 Kudos