v0.6.0

[Mimetis]

The version V0.6 is released !

Nuget packages : https://www.nuget.org/packages?q=Dotmim.Sync

This discussion thread will summarize some of the new functionalities available:

• Orchestrators
• Interceptors - Change generated sync architecture
• Interceptors - Controlling data applying
• Merge PR #353 from @gentledepp to handle Session lost and new interceptor OnSendingChanges properties (replacing Binary with Changes table rows)
• Fixing issue DefaultRequestHeaders is cleared #354 and creating a discussion around Web Authentication technic
• Removing AddRemoteProgress
• Adding Http Interceptors On Client and Server

[Mimetis]

Orchestrators

The base code has been refactored to make things easier to handle, and more compliant with each core component role.

Today a set of new public methods are accessible from both LocalOrchestrator or RemoteOrchestrator (and for some of them from WebClientOrchestrator and WebServerOrchestrator, and not anymore from typed Providers.

This lead to more public and independent methods you can use. You have now access to several methods for managing your sync architecture.
Generaly, you have access to three methods (Create_XXX, Drop_XXX, Exists_XXX) for all the core components :

• Stored Procedures
• Triggers
• Tracking Tables
• Tables
• Schemas
• Scopes

Here is some example using these methods (using the SQL Server AdventureWorks Database Script )

Get a table schema

This method runs on any Orchestrator, but we are using here a RemoteOrchestrator because the client database is empty and getting a table schema from an empty database... well.. :)

var provider = new SqlSyncProvider(serverConnectionString);
var options = new SyncOptions();
var setup = new SyncSetup(new string[] { "ProductCategory", "ProductModel", "Product" });
var orchestrator = new RemoteOrchestrator(provider, options, setup);

// working on the product Table
var productSetupTable = setup.Tables["Product"];

// Getting the table schema
var productTable = await orchestrator.GetTableSchemaAsync(productSetupTable);

foreach (var column in productTable.Columns)
    Console.WriteLine(column);

ProductID - Int32
Name - String
ProductNumber - String
Color - String
StandardCost - Decimal
ListPrice - Decimal
Size - String
Weight - Decimal
ProductCategoryID - Int32
ProductModelID - Int32
SellStartDate - DateTime
SellEndDate - DateTime
DiscontinuedDate - DateTime
ThumbNailPhoto - Byte[]
ThumbnailPhotoFileName - String
rowguid - Guid
ModifiedDate - DateTime

Managing stored procedures

Managing Stored Procedures could be done using:

• LocalOrchestrator.CreateStoredProcedureAsync() : Create a stored procedure using the DbStoredProcedureType enumeration, for one SetupTable argument.
• LocalOrchestrator.ExistStoredProcedureAsync(): Check if a stored procedure already exists, using the DbStoredProcedureType enumeration, for one SetupTable argument.
• LocalOrchestrator.DropStoredProcedureAsync() : Drop a stored procedure using the DbStoredProcedureType enumeration, for one SetupTable argument.
• LocalOrchestrator.CreateStoredProceduresAsync() : Create all stored procedures needed for one SetupTable argument.
• LocalOrchestrator.DropStoredProceduresAsync() : Drop all stored procedures created for one SetupTable argument.

Creating a stored procedure could be done like this:

var provider = new SqlSyncProvider(serverConnectionString);
var options = new SyncOptions();
var setup = new SyncSetup(new string[] { "ProductCategory", "ProductModel", "Product" });
var orchestrator = new RemoteOrchestrator(provider, options, setup);

// working on the product Table
var productSetupTable = setup.Tables["Product"];

var spExists = await orchestrator.ExistStoredProcedureAsync(productSetupTable, DbStoredProcedureType.SelectChanges);
if (!spExists)
    await orchestrator.CreateStoredProcedureAsync(productSetupTable, DbStoredProcedureType.SelectChanges);

Be careful, this stored procedure relies on a tracking table for table Product, but we did not create it, yet.

Creating a tracking table

Continuing on the last sample, we can create in the same way, the tracking table for table Product:

var provider = new SqlSyncProvider(serverConnectionString);
var options = new SyncOptions();
var setup = new SyncSetup(new string[] { "ProductCategory", "ProductModel", "Product" });
var orchestrator = new RemoteOrchestrator(provider, options, setup);

// working on the product Table
var productSetupTable = setup.Tables["Product"];

var spExists = await orchestrator.ExistTrackingTableAsync(productSetupTable);
if (!spExists)
    await orchestrator.CreateTrackingTableAsync(productSetupTable);

Droping a tracking table and a stored procedure

Now we can drop this newly created stored procedure and tracking table:

var trExists = await orchestrator.ExistTrackingTableAsync(productSetupTable);
if (trExists)
    await orchestrator.DropTrackingTableAsync(productSetupTable);

var spExists = await orchestrator.ExistStoredProcedureAsync(productSetupTable, DbStoredProcedureType.SelectChanges);
if (spExists)
    await orchestrator.DropStoredProcedureAsync(productSetupTable, DbStoredProcedureType.SelectChanges);

[Mimetis]

Interceptors - Change generated sync architecture

All interceptors have been refactored to be more useable and resolving some issues reported.

Interceptors on DbCommand will let you change the command used, depending on your requirements

• Interceptors on creating the architecture
• Interceptors when executing sync queries

Let see a straightforward sample : Customizing a tracking table

Adding a new column in a tracking table

The idea here is to add a new column internal_id in the tracking table:

var provider = new SqlSyncProvider(serverConnectionString);
var options = new SyncOptions();
var setup = new SyncSetup(new string[] { "ProductCategory", "ProductModel", "Product" });
var orchestrator = new RemoteOrchestrator(provider, options, setup);

// working on the product Table
var productSetupTable = setup.Tables["Product"];

orchestrator.OnTrackingTableCreating(ttca =>
{
    var addingID = $" ALTER TABLE {ttca.TrackingTableName.Schema().Quoted()} ADD internal_id varchar(10) null";
    ttca.Command.CommandText += addingID;
});

var trExists = await orchestrator.ExistTrackingTableAsync(productSetupTable);
if (!trExists)
    await orchestrator.CreateTrackingTableAsync(productSetupTable);

Ok, now we need to customize the triggers to insert a correct value in the internal_id column

orchestrator.OnTriggerCreating(tca =>
{
    string val;
    if (tca.TriggerType == DbTriggerType.Insert)
        val = "INS";
    else if (tca.TriggerType == DbTriggerType.Delete)
        val = "DEL";
    else
        val = "UPD";

    var cmdText = $"UPDATE Product_tracking " +
                  $"SET Product_tracking.internal_id='{val}' " +
                  $"FROM Product_tracking JOIN Inserted ON Product_tracking.ProductID = Inserted.ProductID;";

    tca.Command.CommandText += Environment.NewLine + cmdText;
});

var trgExists = await orchestrator.ExistTriggerAsync(productSetupTable, DbTriggerType.Insert);
if (!trgExists)
    await orchestrator.CreateTriggerAsync(productSetupTable, DbTriggerType.Insert);

trgExists = await orchestrator.ExistTriggerAsync(productSetupTable, DbTriggerType.Update);
if (!trgExists)
    await orchestrator.CreateTriggerAsync(productSetupTable, DbTriggerType.Update);

trgExists = await orchestrator.ExistTriggerAsync(productSetupTable, DbTriggerType.Delete);
if (!trgExists)
    await orchestrator.CreateTriggerAsync(productSetupTable, DbTriggerType.Delete);

orchestrator.OnTriggerCreating(null);

Here is the Sql script executed for trigger Insert:

CREATE TRIGGER [dbo].[Product_insert_trigger] ON [dbo].[Product] FOR INSERT AS

SET NOCOUNT ON;

-- If row was deleted before, it already exists, so just make an update
UPDATE [side] 
SET  [sync_row_is_tombstone] = 0
	,[update_scope_id] = NULL -- scope id is always NULL when update is made locally
	,[last_change_datetime] = GetUtcDate()
FROM [Product_tracking] [side]
JOIN INSERTED AS [i] ON [side].[ProductID] = [i].[ProductID]

INSERT INTO [Product_tracking] (
	 [ProductID]
	,[update_scope_id]
	,[sync_row_is_tombstone]
	,[last_change_datetime]
) 
SELECT
	 [i].[ProductID]
	,NULL
	,0
	,GetUtcDate()
FROM INSERTED [i]
LEFT JOIN [Product_tracking] [side] ON [i].[ProductID] = [side].[ProductID]
WHERE [side].[ProductID] IS NULL


UPDATE Product_tracking SET Product_tracking.internal_id='INS' 
FROM Product_tracking 
JOIN Inserted ON Product_tracking.ProductID = Inserted.ProductID;

[gentledepp]

Actually, it would be quite nice to have

• the metadata available that dotmim.sync uses to create the tables/stored procedures internally
• and also the internal methods which e.g. take the list of columns of a table (select changes stored procedure) and creates the select list.

Then we could:

1. either add additional columns before the sql is generated. That way, we could add/remove columns before the internal logic of dotmim.sync actually creates the sql command
2. use the internal "sql helper methods" (which create the where filters, the list of columns to be selected, etc.) to manually craft our own sql statement.

While the former approach (1) is much easier to use, the latter (2) would provide a maximum of flexibility.

Note: If you provide all the metadata in the tca variable already, then this is exactly what I'd love to see.

What do you think?

[Mimetis]

I'm providing the DbCommand and the SyncTable (with columns, datatype and so on...) that is used to generate the sql statement.
Honestly, you have the same level of access that each provider already has, to generate the statement :)

You can get the code from the provider you're work with, and do exactly the same thing in the interceptor.

In the interceptor you have the statement generated, but you can override everything and create your own statement, I guess :)

[Mimetis]

For instance, here is the TrackingTable argument, you will be able to use for providing your own statement

public class TrackingTableCreatingArgs : ProgressArgs
{
    public SyncTable Table { get; }
    public ParserName TrackingTableName { get; }
    public bool Cancel { get; set; } = false;
    public DbCommand Command { get; }

    public TrackingTableCreatingArgs(SyncContext context, SyncTable table, 
    ParserName trackingTableName, DbCommand command,
    DbConnection connection = null, DbTransaction transaction = null) : base(context, connection, transaction)
    {
        this.Table = table;
        this.TrackingTableName = trackingTableName;
        this.Command = command;
    }
    public override string Message => $"[{Connection.Database}] [{this.TrackingTableName}] tracking table creating.";
    public override int EventId => SyncEventsId.TrackingTableCreating.Id;

}

• SyncTable : table with all metadatas required to create the tracking table
• TrackingTableName : tracking table name, based on the prefix and suffix you've set in the SyncOptions
• Command : DbCommand prepared and ready to be executed, containing the statement generated
• Cancel : boolean indicating if you want to generate the tracking table or not. If you specify false, the tracking table will not be generated but no error will be raised

[Mimetis]

Interceptors - Controlling data applying

You can use Interceptors to control how your data are applied (or not)
Imagine that, for some reasons, you don't want to delete data that should be deleted.

Here is a quick example:

First of all, making a full sync to be sure we have the same data between the server and one client

var serverProvider = new SqlSyncProvider(serverConnectionString);
var clientProvider = new SqlSyncProvider(clientConnectionString);

// Tables involved in the sync process:
var tables = new string[] {"Product" };

// Creating an agent that will handle all the process
var agent = new SyncAgent(clientProvider, serverProvider, tables);

// First sync to have some rows on client
var s1 = await agent.SynchronizeAsync();
// Write results
Console.WriteLine(s1);

Synchronization done.
        Total changes  uploaded: 0
        Total changes  downloaded: 295
        Total changes  applied: 295
        Total resolved conflicts: 0
        Total duration :0:0:7.324

Now let's imagine we are deleting some rows on the server

var c = serverProvider.CreateConnection();
var cmd = c.CreateCommand();
cmd.Connection = c;
cmd.CommandText = "DELETE FROM Product WHERE ProductId >= 750 AND ProductId < 760";
c.Open();
cmd.ExecuteNonQuery();
c.Close();

Ok, now we are expecting to have around 10 rows to be deleted on the next sync on the client.
But for some reasons, you don't want them to be deleted (it's your choice)
Here is a quick snippet using OnTableChangesApplying interceptor :

// Do not delete product rows
agent.LocalOrchestrator.OnTableChangesApplying(args =>
{
    if (args.State == DataRowState.Deleted && args.Changes.TableName == "Product")
    {
        Console.WriteLine($"Preventing deletion on {args.Changes.Rows.Count} rows.");
        args.Cancel = true;
    }
});

// Second sync
s1 = await agent.SynchronizeAsync();
// Write results
Console.WriteLine(s1);

Second sync result:

Preventing deletion on 10 rows.
Synchronization done.
        Total changes  uploaded: 0
        Total changes  downloaded: 10
        Total changes  applied: 0
        Total resolved conflicts: 0
        Total duration :0:0:0.62

As you can see, the client downloaded 10 rows to be deleted, but nothing has been applied.

[hakakou]

In the code above, args.Changes does not seem to exist in 0.9.3. I was enumerating args.Changes.Rows to get a log of changes and especially the .ToString() on each item was nice because it showed the actual data in each column. Is there a replacement for this?

[Mimetis]

Interceptors on the WebClientOrchestrator & RemoteOrchestrator objects.

First of all, it's not longer necessary to add AddRemoteProgress. This method is deprecated (and is removed in the v6.0 version.)
Now, and by default, you have the events raised by both local and remote orchestrators.

Here is a sample of an output from a 1 st sync to a Web API, from the Client perspective:
Just for illustrate

• [Client] is the name of the local sqlite database.
• [localhost] is the host of the Web API.

This log is coming from a first sync where the [Client] database is not existing yet.

BeginSession:   10:52:18.211     Session Begins [0c622a02-9c2d-4a39-bcd1-7888deb5a859].
ScopeLoading:   10:52:22.944     [localhost] Getting Schema. Scope Name:DefaultScope.
Provisioning:   10:52:23.760     [Client] Provisioned 9 Tables. Provision:Table, TrackingTable, StoredProcedures, Triggers.
ChangesSelecting:       10:52:23.817     [localhost] Sending Changes. Index:0. Rows:0
ChangesSelecting:       10:52:24.531     [localhost] Getting Changes. Index:0. Rows:658
ChangesSelecting:       10:52:24.607     [localhost] Getting Changes. Index:1. Rows:321
ChangesSelecting:       10:52:24.637     [localhost] Getting Changes. Index:2. Rows:29
ChangesSelecting:       10:52:24.654     [localhost] Getting Changes. Index:3. Rows:33
ChangesSelecting:       10:52:24.674     [localhost] Getting Changes. Index:4. Rows:39
ChangesSelecting:       10:52:24.701     [localhost] Getting Changes. Index:5. Rows:55
ChangesSelecting:       10:52:24.723     [localhost] Getting Changes. Index:6. Rows:49
ChangesSelecting:       10:52:24.745     [localhost] Getting Changes. Index:7. Rows:32
ChangesSelecting:       10:52:24.829     [localhost] Getting Changes. Index:8. Rows:758
ChangesSelecting:       10:52:24.895     [localhost] Getting Changes. Index:9. Rows:298
ChangesSelecting:       10:52:25.35      [localhost] Getting Changes. Index:10. Rows:1242
ChangesApplying:        10:52:25.491     [Client] [ProductDescription] [Modified] Applied:658. Conflicts:0.
ChangesApplying:        10:52:25.541     [Client] [ProductDescription] [Modified] Applied:762. Conflicts:0.
ChangesApplying:        10:52:25.698     [Client] [ProductCategory] [Modified] Applied:41. Conflicts:0.
ChangesApplying:        10:52:25.760     [Client] [ProductModel] [Modified] Applied:128. Conflicts:0.
ChangesApplying:        10:52:25.817     [Client] [Product] [Modified] Applied:48. Conflicts:0.
ChangesApplying:        10:52:25.833     [Client] [Product] [Modified] Applied:77. Conflicts:0.
ChangesApplying:        10:52:25.840     [Client] [Product] [Modified] Applied:110. Conflicts:0.
ChangesApplying:        10:52:25.849     [Client] [Product] [Modified] Applied:149. Conflicts:0.
ChangesApplying:        10:52:25.861     [Client] [Product] [Modified] Applied:204. Conflicts:0.
ChangesApplying:        10:52:25.893     [Client] [Product] [Modified] Applied:253. Conflicts:0.
ChangesApplying:        10:52:25.905     [Client] [Product] [Modified] Applied:285. Conflicts:0.
ChangesApplying:        10:52:25.917     [Client] [Product] [Modified] Applied:295. Conflicts:0.
ChangesApplying:        10:52:25.991     [Client] [Address] [Modified] Applied:450. Conflicts:0.
ChangesApplying:        10:52:26.62      [Client] [Customer] [Modified] Applied:298. Conflicts:0.
ChangesApplying:        10:52:26.179     [Client] [Customer] [Modified] Applied:596. Conflicts:0.
ChangesApplying:        10:52:26.215     [Client] [Customer] [Modified] Applied:847. Conflicts:0.
ChangesApplying:        10:52:26.287     [Client] [CustomerAddress] [Modified] Applied:417. Conflicts:0.
ChangesApplying:        10:52:26.346     [Client] [SalesOrderHeader] [Modified] Applied:32. Conflicts:0.
ChangesApplying:        10:52:26.417     [Client] [SalesOrderDetail] [Modified] Applied:542. Conflicts:0.
ChangesApplying:        10:52:26.430     [Client] [Total] Applied:3514. Conflicts:0.
EndSession:     10:52:26.498     Session Ended [0c622a02-9c2d-4a39-bcd1-7888deb5a859].
Synchronization done.
        Total changes  uploaded: 0
        Total changes  downloaded: 3514
        Total changes  applied: 3514
        Total resolved conflicts: 0
        Total duration :0:0:8.295

[Mimetis]

New Interceptors on Web Orchestrators

New interceptors have been added on the web orchestrators WebClientOrchestrator & WebServerOrchestrator.
These orchestrators will let you intercept all the Requests and Responses that will be generated by DMS during a web call.

WebServerOrchestrator

The two first interceptors will intercept basically all requests and responses coming in and out:

• webServerOrchestrator.OnHttpGettingRequest(args => {})
• webServerOrchestrator.OnHttpSendingResponse(args => {})

Each of them will let you access the HttpContext, SyncContext and SessionCache instances:

webServerOrchestrator.OnHttpGettingRequest(args =>
{
    var httpContext = args.HttpContext;
    var syncContext = args.Context;
    var session = args.SessionCache;
});

The two last new web server http interceptors will let you intercept all the calls made when server receives client changes and when server sends back server changes.

• webServerOrchestrator.OnHttpGettingChanges(args => {});
• webServerOrchestrator.OnHttpSendingChanges(args => {});

Here is a quick example using all of them:

var webServerOrchestrator = webServerManager.GetOrchestrator(context);

webServerOrchestrator.OnHttpGettingRequest(req =>
    Console.WriteLine("Receiving Client Request:" + req.Context.SyncStage + ". " + req.HttpContext.Request.Host.Host + "."));

webServerOrchestrator.OnHttpSendingResponse(res =>
    Console.WriteLine("Sending Client Response:" + res.Context.SyncStage + ". " + res.HttpContext.Request.Host.Host));

webServerOrchestrator.OnHttpGettingChanges(args => Console.WriteLine("Getting Client Changes" + args));
webServerOrchestrator.OnHttpSendingChanges(args => Console.WriteLine("Sending Server Changes" + args));

await webServerManager.HandleRequestAsync(context);

Receiving Client Request:ScopeLoading. localhost.
Sending Client Response:Provisioning. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending All Snapshot Changes. Rows:0
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Getting Client Changes[localhost] Getting All Changes. Rows:0
Sending Server Changes[localhost] Sending Batch  Changes. (1/11). Rows:658
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (2/11). Rows:321
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (3/11). Rows:29
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (4/11). Rows:33
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (5/11). Rows:39
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (6/11). Rows:55
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (7/11). Rows:49
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (8/11). Rows:32
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (9/11). Rows:758
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (10/11). Rows:298
Sending Client Response:ChangesSelecting. localhost
Receiving Client Request:ChangesSelecting. localhost.
Sending Server Changes[localhost] Sending Batch  Changes. (11/11). Rows:1242
Sending Client Response:ChangesSelecting. localhost
Synchronization done.

The main differences are that the two first ones will intercept ALL requests coming from the client and the two last one will intercept Only requests where data are exchanged (but you have more detailed)

WebClientOrchestrator

You have pretty much the same Http interceptors on the client side. OnHttpGettingRequest becomes OnHttpSendingRequest and OnHttpSendingResponse becomes OnHttpGettingResponse:

localOrchestrator.OnHttpGettingResponse(req => Console.WriteLine("Receiving Server Response"));
localOrchestrator.OnHttpSendingRequest(res =>Console.WriteLine("Sending Client Request."));
localOrchestrator.OnHttpGettingChanges(args => Console.WriteLine("Getting Server Changes" + args));
localOrchestrator.OnHttpSendingChanges(args => Console.WriteLine("Sending Client Changes" + args));

Sending Client Request.
Receiving Server Response
Sending Client Request.
Receiving Server Response
Sending Client Changes[localhost] Sending All Changes. Rows:0
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (1/11). Rows:658
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (2/11). Rows:321
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (3/11). Rows:29
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (4/11). Rows:33
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (5/11). Rows:39
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (6/11). Rows:55
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (7/11). Rows:49
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (8/11). Rows:32
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (9/11). Rows:758
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (10/11). Rows:298
Sending Client Request.
Receiving Server Response
Getting Server Changes[localhost] Getting Batch Changes. (11/11). Rows:1242
Synchronization done.

Example: Hook Bearer token

This sample is coming from a discussion on discussion #374

The idea is to inject the user identifier UserId in the SyncParameters collection on the server, after having extract this value from a Bearer token.
That way the UserId is not hard coded or store somewhere on the client application, since this value is generated during the authentication part.

As you can see:

• My SyncController is marked with the [Authorize] attribute.
• The orchestrator is only called when we know that the user is authenticated.
• We are injecting the UserId value coming from the bearer into the SyncContext.Parameters.
• Optionally, because we don't want to send back this value to the client, we are removing it when sending the response.

[Authorize]
[ApiController]
[Route("api/[controller]")]
public class SyncController : ControllerBase
{
    // The WebServerManager instance is useful to manage all the Web server orchestrators register in the Startup.cs
    private WebServerManager webServerManager;

    // Injected thanks to Dependency Injection
    public SyncController(WebServerManager webServerManager) => this.webServerManager = webServerManager;

    /// <summary>
    /// This POST handler is mandatory to handle all the sync process
    [HttpPost]
    public async Task Post()
    {
        // If you are using the [Authorize] attribute you don't need to check
        // the User.Identity.IsAuthenticated value
        if (HttpContext.User.Identity.IsAuthenticated)
        {
            var orchestrator = webServerManager.GetOrchestrator(this.HttpContext);

            // on each request coming from the client, just inject the User Id parameter
            orchestrator.OnHttpGettingRequest(args =>
            {
                var pUserId = args.Context.Parameters["UserId"];

                if (pUserId == null)
                    args.Context.Parameters.Add("UserId", this.HttpContext.User.Identity.Name);

            });

            // Because we don't want to send back this value, remove it from the response 
            orchestrator.OnHttpSendingResponse(args =>
            {
                if (args.Context.Parameters.Contains("UserId"))
                    args.Context.Parameters.Remove("UserId");
            });

            await webServerManager.HandleRequestAsync(this.HttpContext);
        }
        else
        {
            this.HttpContext.Response.StatusCode = StatusCodes.Status401Unauthorized;
        }
    }

    /// <summary>
    /// This GET handler is optional. It allows you to see the configuration hosted on the server
    /// The configuration is shown only if Environmenent == Development
    /// </summary>
    [HttpGet]
    [AllowAnonymous]
    public async Task Get() => await webServerManager.HandleRequestAsync(this.HttpContext);
}

[vunder]

Some note. In case you're using Microsoft Auth, this.HttpContext.User.Identity.Name will be null
I would recommend to use in this case some of the claim value. E.g. nameidentifier:

var userId = this.HttpContext.User.Claims.FirstOrDefault(x => x.Type == ClaimTypes.NameIdentifier);

[satpal123]

@Mimetis Seems like I missed the discussion section. This seems good enough for the changes 😊