[Question] Best practices ServiceClient & Dependency Injection

[mVermaat]

Do you have any guidance / best practices when using the ServiceClient in web applications or function apps? These will use dependency injection. Kind of similar to what was done for the HttpClient.

So basically: What is the correct way of using the ServiceClient with Dependency Injection in web applications?

[jordimontana82]

@mVermaat I think that is not coevered in the Dataverse docs (yet) but here's a nice example by Temmy @temmyraharjo:

https://temmyraharjo.wordpress.com/2022/07/09/how-to-make-azure-functions-dataverse-service-client/

[MattB-msft]

Yep. this is on the "To-Do" list for samples for the client,
also, we are internally testing a few different extensions for Dependency injection, one of which we may add to the client in the future.

[mVermaat]

Good to know, thanks for the information. With the current constraints, what is the best approach? I know I can make it 'work' by implementing something like in the link. However I'm not sure what the consequences are for using in example Scoped or Singleton.

[MattB-msft]

Scoped or Singleton uses cases are situational, IE, what are you trying to accomplish in the function or asp.net core app.
We do not have a strong opinion on it and are using both processes in different services.

Mainly what we are testing is memory and isolation management options for us in API services (function and the like), when running at scale over a long period of time. Once we settle on a specific approach, we will build it into the client as an extension. In the meantime, we may provide a sample or 2 on the PowerApps Samples site based on current work.

[jordimontana82]

@MattB-msft was wondering if some samples for this were published to the PowerApps Samples site in the end?

[KimBon]

@MattB-msft any update on this one? where can we see a latest sample or best practices for dependency injection?

[ferodom]

@MattB-msft any updates I am having a hard time with the dependency injection taking about a second to create an instance of service client any suggestions?

this is what I am doing

builder.Services.AddScoped(x =>
new ServiceClient(new ConnectionOptions()
{
ServiceUri = new Uri(datavserseUrl),
AuthenticationType = AuthenticationType.ClientSecret,
ClientId = clientId,
ClientSecret = clientSecret,
})
);

[FarmerenHE]

It works in both Singleton and Scoped setups, depending on your usecase it can be used differently but my recommendation would be to always use it as a singleton.

Scoped:
Pros:
Easy and quick to setup codewise.
Cons:
Takes a long time to create (often >300 ms)
Uses up connections from the connectionpool (primarily an issue with consumption based functions)

Singleton:
Cons:
You need to setup some handling to take care of the cases where the connection fails for one reason or another and then recreate the ServiceClient object and store it in the singleton.
Pros:
You dont need to spend time creating the serviceclient
It can be shared between function instances
Makes handling of API limits easier

If your running on consumptionbased azure functions you have a limit of 600 outbound connections, everytime you scope a new instances of the serviceclient it reserves one or more connections and they have to be unused for 5 minutes to be removed again. - thus making a singleton the only way to go in any sort of high load situation.

Personally I always use it as a singelton in my own custom build framework that ensures a connection is recreated if needed, handles the API limits and share the load between different connections if running in a high performance scenario. (We have tested it to 1400 calls/s sustained for an hour without running into API limits or azure connection limits).

[KimBon]

Thanks already for answering my question!

Are your Azure Functions triggered by new service bus messages? If so how do you control the load and scale out as they can easily lead to too many requests on the side of Dataverse? Ideally, if there is a 429 on Dataverse, new function instances should not be created and the running once should be able to finish in time (assuming consumption plan).

You turn affinity off by default is what you mean? Or you invalidate the cookie once there are issues?

We used to work with multiple identities in one API project, one per functional domain? That is similar to what you are doing?

[FarmerenHE]

We always turn affinity cookie off by default, most environments have 4+ dataverse servers, (and for any larger installation 9 is not unusual) - so just by that one change we have a lot more headroom in API limits, - it does give a potential slower response if we need to query the same data multiple times (or work with pages) but that is corner cases in our usages and we accept a performance penalty in those cases.

We usually find a upper limit of function scaleout where we can handle the usual load of requests, as well as keep it whitin the API limits, that have been enough for us to find a level of max scaling where there is some head room on both API limit and event handling capacity.

We do however try to limit our calls to dataverse as much as possible and make the queries as light as possible (by using queryexpressions and columnset wherever possible). - and the Context for using lambda expressions is a call hog that uses multiple calls for even simple things.

We have the same connectionstring with the same number of users between a large number of different functions, just to keep that part of the infrastructure simple, but yes you could use it that way if you wanted. - we just find that general API projects tend to grow over time and decrease performance to much compared to small lightweight functions with direct access.

[KimBon]

You need to setup some handling to take care of the cases where the connection fails for one reason or another and then recreate the ServiceClient object and store it in the singleton.

@FarmerenHE how do you approach this? Wrapping service client in your own and provide your own methods checking the readiness of the client/connection?

and the Context for using lambda expressions is a call hog that uses multiple calls for even simple things
You mean you are avoiding linq?

[FarmerenHE]

We have our own wrapper that extends IOrganizationServiceAsync2 and passes any calls to the internal ServiceClient (we also have a ton of extensions to make query expressions easier hidden in there).

When it hits API Limits (error 429) its own "IsReady" method invalidates it for the time that the service reports it to be invalid (using the Retry-After key from the errormessage).

Yeah were avoiding Linq alltogether and only using queryexpressions (or fetchxml in some cases) - XrmToolbox have a nice FetchXMLBuilder tool that allows to create the query and export it as QueryExpression, making development of complex queries quite simple.

[rappen]

You're welcome, @FarmerenHE 😉

[khoait]

@FarmerenHE thanks for your valuable insights! are you also tweaking Max Concurrent Calls in the Azure Functions with Service Bus?

[FarmerenHE]

We have just left it running in more or less its default configuration, we usually raise the maximum allowed parallel instances instead (but no more than 2 pr. user as that more than that is usually the place were we start seeing API Limits anyway.

Were running azure functions in consumption plan as we find that have the best performance especially when we also look at the cost

[khoait]

thank you!