Asynchronous API

[pierceboggan]

As a .NET developer, I expect to be able to use the async/await keywords to perform data operations asynchronously.

This is especially important when working with data-intensive applications and populating UI from a data source (such as Common Data Service) so my UI thread does not lock while fetching data.

[BetimBeja]

It would be really nice to have an implementation of IOrganizationService{Async} since the use case for the CdsServiceClient is for external clients, and not for the implementation of Plugin or Code Activity logic.

For the time being an IOrganizationService{Async} interface is not available from Microsoft that I am aware of.

[jordimontana82]

Not aware of any, and not because we didn't request that previously! : ) It would be nice to get this added, if possibly the external .Execute method is exposed as async, then all the other requests could "inherit" from that implementation really...

[MattB-msft]

Async support is being discussed at several levels for this lib.
Note that this lib does use WebAPI for some operations currently, and will use it more so over time as issues are resolved to support cross compatibility.

[MattB-msft]

So .. wow... time flys... been many days since the last post on this thread and I wanted to bring it up to date.

After much deliberation and discussion, (and most of the team getting side tracked supporting customers though the current global situation), we have finally come to a decision on Async Support for this client.

Here is the deal folks.

We are going to Add Async Support to the CdsServiceClient ( soon to be renamed around the Dataverse naming ).
There are a few caveats:

• Its Client Side only.. We are not adding async supports to the main SDK for Plugins.
• Its Going to have a split implementation while we continue forward on our WebAPI port.
• • that means that requests that go though the SOAP organization Service will use a Task.Run Pattern to approximate Async, and requests that go though the WebAPI will use the http Async pattern.

The first update that will contain this will drop with the name change in the next few weeks ( or sooner depending on time to focus )

Will be looking forward to your feedback as we progress.

thanks
MattB.

[rajyraman]

Fantastic news @MattB-msft.

[MattB-msft]

First version of this has been posted in the current nuget drop along with a number of other fixes.
Again this is a WIP, feedback is appreciated.

[mathiasbl]

Hey Matt, can we get a async version of ExecuteWebRequest?

PowerPlatform-DataverseServiceClient/src/GeneralTools/DataverseClient/Client/ServiceClient.cs

Line 4905 in 9f25d39

public HttpResponseMessage ExecuteWebRequest(HttpMethod method, string queryString, string body, Dictionary<string, List<string>> customHeaders, string contentType = default(string))

[BetimBeja]

@MattB-msft shouldn't accessing Result of an async call like that be forbidden? This type of use can cause deadlocks...

PowerPlatform-DataverseServiceClient/src/GeneralTools/DataverseClient/Client/ServiceClient.cs

Line 4930 in 9f25d39

var result = Command_WebExecuteAsync(queryString, body, method, customHeaders, contentType, string.Empty).Result;

[MattB-msft]

@mathiasbl
Yes, ExecuteWebRequestAsync is coming soon.

@BetimBeja
Yes and No as it depends on how your call patterns work,
Today we encourage cloning for each distinct thread, thus trying to keep each operation from stepping on each other operation.

Folks sometimes, knowingly or not, implement something that attempts to call a single instance of the connection from multiple threads concurrently. Most of the time this is not noticeable as Dataverse's API is really fast. However if you hit a longer running operation, or you get yourself into a race type condition, it can happen.

We handle that in the WCF path already.

Use of this flow ( ExecuteWebRequest) is very limited currently, and thus we didn't add it as part of the async work we did in the first pass, and given the apparent low usage of this we chose not to alter the current logic till we added the async version of the method in and just went with this. We actually need to deal with it in a number of helper methods today beyond just this one :)

We will soon add locking logic around this flow similar to the way we have it for the root of the NonAsync WCF call to deal with 2 competing threads calling it while its waiting on something to come back. That should close the door to the threadlock issue, unless the developer uses the disable safeties option.

Hope that helps clarify whats going on there.

[MattB-msft]

As a heads up, next drop ( starting 0.5.x ) will include an substantially updated Async Implementation for the older API implementation,

[MattB-msft]

0.5.x is posted, Please give it a go.

[hivanov]

@MattB-msft, would it be possible to also add Async support around OrganizationServiceContext, so it's usable with EntityFrameworkCore's .AsAsyncEnumerable() and friends?
Furthermore, for web services, it's especially useful not to have the async -> sync -> async transition, and to support cancellation tokens all the way down to the HTTP request being made.

[MattB-msft]

add Async support around OrganizationServiceContext, so it's usable with EntityFrameworkCore's .AsAsyncEnumerable() and friends?

We have extensively explored this as part of the work we did to enabled async operations in the dataverse client, short answer this is a substantial work based on the current service infrastructure, to the point where the cost and disruption risk to the platform far outweigh the benefits of it. We will reopen this exploration as the platform itself evolves and we evolve the Organization Service API platform hosts.

async -> sync -> async transition, and to support cancellation tokens all the way down to the HTTP request being made.

The API for the PowerPlatform itself ( with a few exceptions ) is a Sync API. That said, we do support cancelation up to the point where the request is sent where the underlying protocol will support it.

[cristian-eriomenco]

Its ok. Lack of support on this platform means its fate is decided. With LLMs creating apps from scratch in no time, meanwhile after 6 years MS is still debating the need for Async APIs, I can not see one good reason why onboarding on power platform. The plugins are still on 4.6.2. OrgContext is WCF. Entity tracking can't track properties. No open telemetry. No detailed logs/traces/dependency tracking. What are we discussing here at all?