Unanswered

Dataverse Web API Patch

(0) Share

Report

Posted on by Jorge_

$apiCallParams =
@{
 URI = "$($dataverseEnvUrl)/api/data/v9.2/parties(a59ca5ea-8f3a-ee11-a81c-0022489a9f93)"

 Headers = @{
 "Authorization" = "$($authResponse.token_type) $($authResponse.access_token)"
 "Content-Type" = "application/json"
 "OData-MaxVersion"="4.0"
 "OData-Version"="4.0"
 "If-Match"='*'
 }

 Method = 'PATCH'
}

$body = 
@{
 'new_number'=11
}

# Call the Dataverse WebAPI
$apiCallRequest = Invoke-RestMethod @apiCallParams -Body $body -ErrorAction Stop
$apiCallResponse = $apiCallRequest

Running this script to update a record in Dataverse.

But getting Error identified in Payload error

new_number is just a text field.

Do you see any error here?

Thanks

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (4)

Answers (0)

Parvez Ghumra 1,579 Moderator on at

Like (0)

Report

Re: Dataverse Web API Patch

@Jorge If you're running this code from a PowerShell script, you might want to consider using the https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell PowerShell module rather than invoking the WebAPI directly. Your code will be much easier to read, maintain and support.

Was this reply helpful? Yes No
codepic 7 on at

Like (0)

Report

Re: Dataverse Web API Patch

Only problem is, that Microsoft.Xrm.Data.PowerShell doesn't support .NET Core which is a requirement if you wish to run the scripts on Linux/MacOs

Was this reply helpful? Yes No
Parvez Ghumra 1,579 Moderator on at

Like (0)

Report

Re: Dataverse Web API Patch

@codepic That's true. An alternative module which I've discovered since my reply above is https://github.com/rnwood/Rnwood.Dataverse.Data.PowerShell that will run on non-Windows machines

Was this reply helpful? Yes No
codepic 7 on at

Like (0)

Report
Re: Dataverse Web API Patch

I don't see a benefit in adding a 3rd party module maintained by a single person to our solution when I know that this person will grow tired of maintaining the module as soon as an official one becomes available. In other words, I prefer communicating via API directly.

Whatever complexity that brings, can be abstracted away by having your own PowerShell module with custom functions within the project structure. Then you can simply add `using module .\path\to\module` on the top of your script and your code will become something like this:

task Check { Get-CoChecks | ForEach-Object { $check = $_ $rules = Get-CoRules $check._check_value $rules | ForEach-Object { $rule = $_ $outcome = Test-CloudResource -Check $check -Rule $rule switch ($outcome) { 'Continue' { return } 'Stop' { break } Default { Set-Outcome ` -Check $check ` -Rule $rule ` -Outcome $outcome } } } } }

This way the adoption of PowerShell in our organization becomes much more approachable to others. Those who need and want to delve deeper into what each of those custom functions do, can do so by CTRL-clicking a function name. But for the rest, they can stick to reading the high-level code which has neither 3rd party module nor an OData call in it. Those who DO delve deeper, are already familiarized themselves with OData APIs. For them, having a direct API call is much more understandable than trying to figure out what some 3rd party module does under the hood.

Was this reply helpful? Yes No