Webclient SDK Scenarios

Context

As discussed in the External Integrations recipe, WebClient SDK is one of the options to build scripts inside Sitecore Content Hub. There are further use-cases where this will be utalized.

The provided code is intended as a guideline and must be tailored to suit your specific implementation requirements. Please ensure thorough end-to-end testing is conducted to validate its functionality and performance in your environment.

Execution

Impersonating Another User

By default, any scripted CRUD operations will be logged as the authenticated user (created by, modified by, etc.). In many scenarios this may not be ideal, or for entities that should be related to another User, may not work at all.

The Webclient SDK and the Scripting SDK, both offer a way to impersonate another user, an example in the below:

You will then use this new client to perform activities. Note that this user will likely have far fewer permissions than the Superuser account you are using by default. We recommend the use of try catch blocks and Exception handling as methods such as SaveAsync may fail due to lack of permissions - example:

Parallel Execution - prevent throttling and reduce time “penalties”

The following is only applicable to external integrations (WebSDK and Fluent SDK, not applicable to internal Scripting SDK) because they interact with a Content Hub instance though REST API.

In case of large migrations or external integrations that are executing bulk CRUD operations, it can take a long time if your dataset is large. Therefore, usually integrations implement some parallelization to speed things up. Below is an example using the 'Polly' library to perform actions in parallel. The maximum number of threads and maximum requests per second can be configured.

Content Hub will throttle your requests per second automatically (by the Web Client SDK), so experimentation may be necessary to find a good balance. Also, be aware that the resilience related actions can be activated with "LogResilience" in the Diagnostics Client

Throttling the WebSDK is already supporting the retry mechanisms that come in handy when throttling kicks in from the backend. In case of bulk parallel executions done through WebSDK, ContentHub will respond with a HTTP 429 (Too Many Requests) in case 15 calls per second (per API integration user) is exceeded. Also in WebSDK we have the possibility to configure the "Retry-After" header to determine how long to wait before retrying.

However, in case of lots of parallel requests, even if we set Retry-After header value equal to 0 (zero), we still have the redundant penalty of a "lost" request leading to retry mechanism to kick in. Meaning that 16th call is “lost” and adds up to the entire time of execution but also the other currently parallel executing threads will start to fail until the overall call rate is back again reduced to 15 calls per second. It would be more efficient to have a way to avoid any "lost" calls and even to prevent the throttling to kick in.

With that in mind,you can present the throttling from even happening by queueing the requests of the client.

Prevention of throttling to kick in eliminates the "penalty of overhead" by retrying. It uses the SetDelegatingHandlerFactory method of the WebSDK.

Raw Queries

Sometimes you may need to perform ‘raw’ API calls. Reasons may include: the API feature you require is not present in the SDK, or where you have a requirement to get and parse json responses. This allows you to leverage the REST API from the web client SDK.

Be careful with making calls in this way, as some APIs are intended for internal Content Hub use and may be decommissioned or repurposed at any time. Refer to the API reference for details.

Related Recipes

Related Documentation