VMware Cloud Community
mscott10
Contributor
Contributor
‎12-06-2017 11:20 AM

Approval Policy not being created when using vRA API

I've been trying to create an Approval Policy using the REST API but I'm having a bit of trouble. I'm using the correct request + method and am even getting a response status code of 201 from the server but I can't see the newly created policy under Administration > Approval Policies.

I've used sources such as vRealize Automation - Approval Service - Samples - VMware {code} or the vRealize Automation API documentation that comes with vRA but those lead me to where I'm at currently.

Any ideas why this might be happening?

Thanks

0 Kudos
6 Replies
jasnyder
Hot Shot
Hot Shot
‎12-06-2017 12:13 PM

Here's an example payload that works in vRA 7.2 in a POST request to /approval-service/api/policies

{ 

   "name":"Test Approval 2",

   "description":"",

   "policyType":{ 

      "id":"com.vmware.cafe.catalog.request.catalogitem",

      "name":"Service Catalog - Catalog Item Request",

      "description":"",

      "serviceTypeId":"com.vmware.csp.core.cafe.catalog",

      "classId":"catalogItemRequest",

      "phaseTypes":[ 

         { 

            "id":"com.vmware.cafe.catalog.request.pre",

            "name":"Pre Approval",

            "description":"Approvals sought before a request is fulfilled.",

            "phaseOrder":0,

            "allowUpdates":true

         },

         { 

            "id":"com.vmware.cafe.catalog.request.post",

            "name":"Post Approval",

            "description":"Approvals sought after a request has been fulfilled.",

            "phaseOrder":1,

            "allowUpdates":false

         }

      ]

   },

   "state":"PUBLISHED",

   "phases":[ 

      { 

         "phasetype":{ 

            "id":"com.vmware.cafe.catalog.request.pre",

            "name":"Pre Approval",

            "description":"Approvals sought before a request is fulfilled.",

            "phaseOrder":0,

            "allowUpdates":true

         },

         "levels":[ 

            { 

               "name":"Level-1",

               "description":"",

               "approvers":[ 

                  { 

                     "displayName":"admin user",

                     "value":"admin@vsphere.local",

                     "type":"USER"

                  }

               ],

               "approvalMode":"ANY",

               "criteria":{ 

                  "type":"and",

                  "subClauses":[ 

                     { 

                        "type":"expression",

                        "operator":{ 

                           "type":"contains"

                        },

                        "leftOperand":{ 

                           "type":"path",

                           "path":"organization.subTenant~name"

                        },

                        "rightOperand":{ 

                           "type":"constant",

                           "value":{ 

                              "type":"string",

                              "value":"MTD-BG"

                           }

                        }

                     },

                     { 

                        "type":"expression",

                        "operator":{ 

                           "type":"greaterThan"

                        },

                        "leftOperand":{ 

                           "type":"path",

                           "path":"dateSubmitted"

                        },

                        "rightOperand":{ 

                           "type":"constant",

                           "value":{ 

                              "type":"dateTime",

                              "value":"2017-12-04T14:45:00.000-0500"

                           }

                        }

                     }

                  ]

               },

               "editSchema":{ 

                  "fields":[ 

                     { 

                        "type":"embedded",

                        "definition":{ 

                           "id":"provider-custom-property-1",

                           "label":"Property Label",

                           "description":"Property Description",

                           "dataType":{ 

                              "type":"primitive",

                              "typeId":"STRING"

                           },

                           "isMultiValued":false,

                           "state":{ 

                              "dependencies":[ 

                              ],

                              "facets":[ 

                              ]

                           },

                           "columns":[ 

                           ]

                        }

                     }

                  ]

               },

               "levelNumber":1,

               "external":false

            }

         ],

         "description":"Approvals sought before a request is fulfilled.",

         "name":"Pre Approval"

      },

      { 

         "phasetype":{ 

            "id":"com.vmware.cafe.catalog.request.post",

            "name":"Post Approval",

            "description":"Approvals sought after a request has been fulfilled.",

            "phaseOrder":1,

            "allowUpdates":false

         },

         "levels":[ 

            { 

               "name":"Post Approval Level 1",

               "description":"",

               "approvers":[ 

                  { 

                     "displayName":"admin user",

                     "value":"admin@vsphere.local",

                     "type":"USER"

                  }

               ],

               "approvalMode":"ANY",

               "criteria":{ 

                  "type":"constantClause",

                  "value":{ 

                     "type":"boolean",

                     "value":true

                  }

               },

               "editSchema":{ 

                  "fields":[ 

                  ]

               },

               "levelNumber":1,

               "external":false

            }

         ],

         "description":"Approvals sought after a request has been fulfilled.",

         "name":"Post Approval"

      }

   ]

}

After the post, the item shows up in the Approval Policies list:

pastedImage_1.png

Policy settings in the UI match what was posted to the API:

pastedImage_3.png

And if I edit an entitlement, I can select the policy from the list:

pastedImage_4.png

Hopefully this sample payload helps decipher what you need to do.  If you're still having problems, post a more detailed example of the approval policy you're trying to create (i.e. # of levels, conditions, type, etc.)

0 Kudos
mscott10
Contributor
Contributor
‎12-06-2017 01:32 PM

The json you provided worked however, I'm still at a loss for why what I'm doing doesn't. My use case is to get one approval policy from a tenant and create that same policy in another tenant. I've been testing using tenants on the same vRA instance but they may be on different instances in the future. Any ideas why a policy taken out of vRA can't then be created/inserted back into it in a different tenant?

I can show the json I get from a GET request for a test policy if needed. I see no way to style the text in markup so its hard to read.

0 Kudos
jasnyder
Hot Shot
Hot Shot
‎12-06-2017 02:29 PM

When you're doing the POST to the new tenant, are you grabbing a new identity token from /identity/api/tokens that reflects the change in the tenant?  Depending on how you have permissions setup as far as who is a tenant administrator, you may also need to provide a different username and password.

If I had to guess, perhaps you're using the same token to grab a copy of the policy and then posting it back as the same user to the same tenant?  The system shows HTTP 201, and does indeed process the change but all it's doing is overwriting the same approval policy with a copy of itself.  Thus it looks like it's not doing anything?

There isn't anything in the approval policy definition that ties it to a tenant, so this information must be inferred based on the auth token.

0 Kudos
mscott10
Contributor
Contributor
‎12-07-2017 05:24 AM

Yep, I am getting a new token for the tenant I am trying to create the Approval Policy in. The process is to get the source fqdn, tenant, username, and password which are used to get an identity token from a source. Next any content is exported via the api (in this case approval policy). Then using a new fqdn, tenant, username, and password I get a new identity token from a destination. The new token is used with any POST into the new tenant to create the new approval policy. In my test use case the tenants, usernames, and passwords are different for the source and destination but both tenants sit on the same fqdn.

Something weird I've just noticed is that in the source tenant the 'last updated by' and 'last updated date' change to match the destination user and date when I tried to post to the destination tenant. I'm thinking that since there is an id field with any exported approval policy then vRA, internally, is seeing that this approval already policy exists when I'm trying to create a new one so it clashes with the old one?

I've been able to use this same process successfully with other vRA types such as property groups/defs and the process I've been using identical save different api requests.

0 Kudos
jasnyder
Hot Shot
Hot Shot
‎12-07-2017 07:33 AM

That sounds odd for sure.  I tested the procedure you outlined putting the exact same definition, name and all, into two tenants, and the only difference was that the updated/created fields were different users (and the approval policy was in a different tenant, obviously).

To clarify - I think you're saying this is the case, but just wanted to be sure - the usernames for each tenant are different, correct?  For example, you don't have the same LDAP directory source in each tenant and have the same user configured with access in both tenants, right?

I tested on vRA 7.2.

What version are you using?

Just to double-check what's happening, you can SSH into the vRA appliance and access the database to see what's in the approvalpolicy table:

# su postgres

postgres@vra7201:/> psql

psql.bin (9.5.4 (VMware Postgres 9.5.4.0-4303132 release))

Type "help" for help.

postgres=# \c vcac

You are now connected to database "vcac" as user "postgres".

vcac=# SELECT * FROM approvalpolicy;

You should be able to see the approval policy ID and the tenant ID, and just verify that a new record is not being created when you do your operation, but instead the old one is being updated.

0 Kudos
mscott10
Contributor
Contributor
‎12-07-2017 07:53 AM

Yep, the usernames for each tenant are different. The username for the source tenant does not have access to the destination tenant and the destination username does not have access to the source tenant. This is why I think it's even more strange that I can go into the source tenant and see those two fields changed - most notably the last updated field changed to show a user that doesn't have access to that tenant.

The vRA Applicance version is 7.3.0.1650 (build 5604410).

As for double checking to see the approvalpolicy table, I don't have that level of access but I may be able to speak to someone who can check it out if they have time.

0 Kudos