Re-Deploy VA Not Working
I am finding that the REST API call to re-deploy a virtual asset is not working for me. I have some fairly sophisticated scripts running against the API to generate virtual assets and responders, so I am fairly certain my process is not the problem. I am making a POST request to /soavirt/api/v6/virtualAssets/redeployments with a payload of { "ids": [ "/VirtualAssets/mypath/myvirtualasset.pva" ]} as per the documentation. It returns an empty 200 response, however the VA is not redeployed. I can tell because my data source is not refreshed.
I double-checked the ID I am using by getting the VA information from the REST API.
I was going to watch the traffic coming out of the Environment Manager tool but I could not find an option there to re-deploy a virtual asset.
Has anyone else experienced this? Thanks,
JT
Comments
-
Hi,
The redeployments API works on a virtual asset deployment and in your example, you have specified a file id to a pva location. To find the virtual asset's deployment id you need to use the GET /virtualAssets resource and find the deployment you want. That resource will list all virtual assets so you may want to use the query parameter to filter the uses based on pva file location, use the file id path. In the response from GET virtualAssets It will have an id field that is a UUID string that you then send to the redeployments API.
Hope this helps!
0 -
Got it. Works! Thanks. Have a great weekend.
0 -
You too!
0 -
I'm back at this spot. I understand that the redeployments API utilizes a UUID that is associated with the VA I want to deploy, however when I make the GET call to see all of the VAs that are deployed, the VA I need is not there. It was created through the API on a server that is configured with auto.deploy=false. I guess what I need at this point is to know how to "deploy" a VA, not "redeploy".
Thanks,
JT
0 -
Hi,
For a server that doesn't automatically create a deployment for a pva file one can be created for it using the POST /virtualAssets or the POST /virtualAssets/{id} resources.
The outline for API calls to depoy a pva file and create a deployment for it would
POST /files/upload?id=/VirtualAssets/my.pva&deploy=false
POST /virtualAssetsThe query parameter "deploy" on the POST /files/uploads resource can be used to make the process consistent across all servers regardless if they are configured for auto-deployment or not.
If using the resource POST /virtualAssets/{id} then you can explicitly assign a string value that will be used instead of the autogenerated UUID. If the same {id} value is used a second time an error will be returned indicating that id is in use.
As a general workflow for when a deployment may or may not exist then the outline of API calls would be something along these lines
POST /files/upload?id=/VirtualAssets/my.pva&deploy=false
GET /virtualAssets?pvaLocation={pva file id}if deployment exists, then redeploy
POST /virtualAssets/redeployments
or
PUT /virtualAssets/{id}/enabled false
PUT /virtualAssets/{id}/enabled trueelse if no deployment exists, then create one
POST /virtualAssets
or
POST /virtualAssets/{id}Hope this helps!
1 -
Thank you so much! Will try this first thing in the AM. Much appreciated! JT
0 -
Happy to confirm this works. I am using POST /virtualAssets/{id}
Question regarding the calls to create and update the virtual asset.... if we are doing this in a non-autodeploy environment, does that mean the interaction is all just work servers until we call for the deployment? Does CTP/EM DB get involved prior to the deployment? THanks, JT
0 -
Hi,
I am not quite sure I understand. The set of API calls will work consistently for both auto-deploy and non-auto-deploy environments.
The more fine-grained behavior is that when the file is uploaded with "deploy=false" the server will not load the new pva.
If a deployment already existed then it will still be running with the old pva data. When redeployment is called then the deployment will load the newly upload pva.
If no deployment existed then nothing will be created in either auto or non-auto deployment server.
As far as CTP there is an option for it to be "notified" of virtual asset deployment so when that is enabled CTP would be notified when the deployment is redeployed or the new deployment is created. Prior to that, CTP doesn't know about the changed/new pva file.
Hope this helps!
0 -
If I add a message responder to a deployed virtual asset, does that consume more resources than if it was added to a non-deployed virtual asset?
JT
0 -
Hi,
When a virtual asset is deployed its configuration from the pva file is loaded into memory, so adding a responder would increase the amount of memory needed to load that responder. Responders typically are small and they generally don't take up much memory.
Is there some other resource consumption that you are concerned about?
0 -
I'm going to start making API calls in an env that typically has only had responder calls. Current config is auto-deploy false. Thought I might have to have that changed to true, but with your solution we do not. I was mainly curious to know if the API calls consume more/different resources if they are acting on a deployed vs not-deployed VA.
0 -
Hi,
The REST API calls don't really consume more/different resources regardless of the asset being deployed or not.
0 -
awesome thanks!
0 -
it's very nice that you can specify the deployment id
0 -
Yes! We use it all the time too!
0 -
I'd imagine if you stick to a strict convention you can do things like redeploys without having to first get the VA
how do you guys use it?
0 -
Right! For us, it helps us be able to quickly remove a virtual asset (DELETE /virtualAssets/{id}) and deploy a fresh copy without needing to do complicated checking to see if was present or not.
1