Can't get (playground-tested) GraphQL mutation working in SDK #45
-
I have the following mutation working in the API playground that triggers an on demand backup. I have not been able to get this to work in the Powershell SDK though (best attempt and errors, bottom). I am pretty sure it's getting hung up on the var syntax. working: Powershell -- not working: Invoke-Rsc -GqlQuery "mutation TakeAzureVMSnapshotMutation ($input : StartCreateAzureNativeVirtualMachineSnapshotsJobInput!) {startCreateAzureNativeVirtualMachineSnapshotsJob(input : $input) {jobIds {jobId __typename} errors {error __typename} __typename}" -Var '{"input" : { Invoke-Rsc : Cannot bind parameter 'Var'. Cannot convert the "{"input" : {"virtualMachineRubrikIds" : ["11111111-1111-1111-1111-1111111111111" ], At line:1 char:263
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Try putting your mutation in a var or @ here string. It looks like there are GraphQL variables in your mutation so they may be getting evaluated as powershell variables. Put the mutation into a var, write-host the variable to make sure it's what you want it to be. The do the invoke with the var. Also, you have double quotes inside a double quote, so the query as you are presenting it is getting chopped. I changed the quotes around the var to single quote instead of double quote since there are already double quote inside the string which is JSON. EDIT: I updated the query to single quote for the string as well. Now it's working. If you put single quotes, the string will be whatever is inside the pair of quotes, if you put double quotes and there is text that looks like a powershell var (ie $input), it will try to evaluate what $input should be, but since it's $null, it just outputs nothing instead of the string $input. try something like:
Also, to confirm the $var is correct, you can convertto-json and confirm it converts properly to a hashtable
|
Beta Was this translation helpful? Give feedback.
-
Your account team will be reaching out with this same info soon. Make sure you are on the most up to date version of the SDK, as there have been lots of changes. When I first looked at your query, your approach made logical sense. I ran it internally and got an error telling me you could not take an on demand snapshot for that workload. I then looked at the API code capture content from an on-demand snapshot via the UI and noticed it was using a different query. When I asked why, it is because not all objects have been implemented into the generic TakeOnDemand snapshot query operation yet. So...the better approach is to use the object specific query instead. So the change I made was to go from I also prefer to use the objects just from an ease of use perspective. Its easier to read and troubleshoot.
Hope this helps. |
Beta Was this translation helpful? Give feedback.
Your account team will be reaching out with this same info soon.
Make sure you are on the most up to date version of the SDK, as there have been lots of changes.
When I first looked at your query, your approach made logical sense. I ran it internally and got an error telling me you could not take an on demand snapshot for that workload. I then looked at the API code capture content from an on-demand snapshot via the UI and noticed it was using a different query. When I asked why, it is because not all objects have been implemented into the generic TakeOnDemand snapshot query operation yet. So...the better approach is to use the object specific query instead.
So the change I made was to go…