requestCatalogItem doesn't work anymore after Upgrade form 6.1.x to 6.2 in vCO

[svenherren]

Hi everybody i was upgrading our environment from vCAC 6.1.x to vRealize Automation 6.2. Everything went good.

We use advanced service blueprint which triggers a request in vCO 5.5.2.1. All went well in vCAC 6.1. Now after the upgrade at the command

System.getModule("com.vmware.library.vcaccafe.request").requestCatalogItem...

we receive this error/exception: ( [Rest Error]: {Status code: 400}, {Error code: 20117} , {Error Source: null}, {Error Msg: The data specified within the request is invalid.}, {System Msg: The data specified within the request is invalid.} )  ( [Rest Error]: {Status code: 400}, {Error code: 50505} , {Error Source: null}, {Error Msg: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING}, {System Msg: Infrastructure service provider error} )

I have seen, that there is a newer vCAC 6.2 plugin for vCO available. But this plugin requires vCO 6.0 as stated in its release notes. Unfortunately i cannot find vCO 6.0 anywhere in the downloads from VMware. And the vCAC vCO plugin 6.2 cannot be installed on vCO 5.5.2.1 I'm not sure if using plugin 6.2 and vCO 6.0 (wher is it?)  will resolve the problem above or if it is now related to vCAC 6.2.

Any hints are greatly apreciated

Thanks in advance, Sven

[gmuleshkov]

Hi Sven,

The new version of the plugin works with vCO 6.0. This is the version that is embedded in vCAC 6.2. The new version of the plugin is installed in the embedded vCO by default.

Could you please try to run your workflow on the embedded vCO.

Hope this helps.

Regards,

Georgi

[svenherren]

Hi Georgi

thanks. This is not possible, since we use a distributed environment and configured an external Orchestrator. Migrating the workflow and it's sub-workflows and modules to the internal Orchestrator and reconfiguring of all would be a major project.

As there is an explicit download for the 6.2 plugin, there must be an Orchestrator Appliance 6.0 somewhere, too (Unfortunately i cannot find it anywhere on the VMware download pages). Otherwise it does not make sence to publish a dedicated 6.2 plugin, if everyone would have to use the builtin orchestrator of vCAC 6.2 in which it this plugin is already included

This external Orchestrator must have been released on Dezember 9. See Release notes of vCAC 6.2 plugin.

https://www.vmware.com/support/orchestrator/doc/vcac-plugin-62-release-notes.html

VMware vRealize Orchestrator 6.0.0 (formerly vCenter Orchestrator) | 9 December 2014 | Build 2289455

Reagrds

Sven

[Speed_Racer12]

I have the same issue.  Did you ever find a solution?

Thanks,

Steve

[svenherren]

Hi Steve,

i opened a case at VMware. There will be a fix for this in Version 6.2.2. In the mean time there is a workaround. You can bypass signature validation on the IaaS server. Then it works again.

1) In C:\Program Files (x86)\VMware\vCAC\Web API\Web.config, add the following lines to the section:

<add key="DisableMessageSignatureCheck" value="true"/>

<add key="DisableBodyHashCheck" value="true"/>

<add key="DisableSAMLTokenSignatureCheck" value="true"/>

2) Add the same lines to the section in C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Web\Web.config.

3) Add the same lines to the section in C:\Program Files (x86)\VMware\vCAC\Server\Website\Web.config.

4) Restart all IaaS servers. Once they're back up, restart the identity appliance, and then the vCAC VA.

Regards Sven

[stvkpln]

Have you reviewed this KB? http://kb.vmware.com/kb/2100951

While the 6.1 plugin works fine (for most cases) against vRA 6.2, if you want to stay on vCO 5.5... If you're going to deploy the 6.2 plugin, it does require upgrading to vRO 6.0 (appliance -- no Windows standalone install yet). The only way to obtain the standalone upgrade package for the appliance is via the process noted in that KB.

[svenherren]

Hi stvkpln,

yes you are right what's related to vRO. One can get standalone vRO 6 if you open a SR at VMware. Otherwise vCO 5.5.x will work for most cases with vRA 6.2

The thing on top in here about not being able to send a cat request after upgrading was not related to vCO/vRO. It also happened when requesting a blueprint within vRA UI in our environment. VMware engineering discovered a bug that IaaS part of vRA is interpreting JSON messages in some circumstances the wrong way. There is a workaround disbaling signature validation checking on IaaS server. The bug will be fixed in version 6.2.2 which will be released later on.

Regards Sven