Skip to content

External

External data seeding can be seen as DataGathering counterpart: while data gathering feature aims to retrieve required data from another service, external data seeding is responsible for seeding data from one service to another, while ensuring this process is completed in a resilient way.

Yet, there's quite a few things that must be configured from the module's API. First and foremost, a DbContext must be specified so the module can register the required type configurations.

C#
1
2
3
4
5
6
7
8
9
public class MyServiceApplicationModule : SuiteAspNetApplicationModule
{
    public override void SetupModule(IModuleBuilder builder)
    {
        base.SetupModule(builder);
        builder.DependsOn<DataSeedingModule, DataSeedingModuleOptions>(opts => opts.SetDbContextType<MyDbContext>());

    }
}

One thing to notice is this module (and particularly the external seeding feature) is commonly used by client modules, which do not have a DbContext type specified by themselves. For these cases, an IConfigureOptions works as a safe pattern for chaining the DbContext type.

C#
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
public class ConfigureDataSeedingModule : IConfigureOptions<DataSeedingModuleOptions>
{
    private readonly IOptions<MyClientModuleOptions> moduleOptions;

    public ConfigureDataSeedingModule(IOptions<MyClientModuleOptions> moduleOptions)
    {
        this.moduleOptions = moduleOptions;
    }

    public void Configure(DataSeedingModuleOptions options)
    {
        if (this.moduleOptions.Value.TargetDbContext is not { } dbContextType)
        {
            throw new InvalidOperationException("Some fancy and descriptive error message");
        }

        options.SetDbContextType(dbContextType);
    }
}

This allows the DataSeeding module to inherit the DbContext type that is set to your client module.

Additionally, a version is required to be specified. The recommended approach here is to define it from your application's appsettings.json file as follows:

JSON
1
2
3
4
5
{
    "DataSeedingModuleOptions": {
        "ExternalDataSeedingVersionId": "b8240000-add4-54e1-38e1-08dac7fd286a"
    }
}

Note

Versioning is still an experimental feature, which aims to behave similar as EF Core migrations versioning work. You will find out we're not quite there yet, but this is a good start.

Now lets move forward. The module's API can be used as follows:

C#
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class MyServiceApplicationModule : SuiteAspNetApplicationModule
{
    public override void SetupModule(IModuleBuilder builder)
    {
        base.SetupModule(builder);
        builder.DependsOn<DataSeedingModule, DataSeedingModuleOptions>(opts => {
            opts.ExposeForExternalSeeding<T, TMessage, TResponse, TDataSource>(
                    e => e.CorrelationId);
        });
    }
}

Lets break this down:

  • T is the type being attempted to seed from the client's perspective. Usually a DTO containing the data that should be mapped to a message.
  • TMessage is the message to be used for creating the required entities.
  • TResponse is the response message we expect if using the default Request/Response seeding strategy.
  • TDataSource is the IDataSource implementation that holds the data to be seeded. DataSources are described here.

The method receives two arguments:

  • A correlationId selector lambda expression
  • A value indicating whether to contribute with health-checks (see below).

Important

An AutoMapper profile from T to TMessage is required for the module to properly map the DTO to the message type. No further configuration is required but to define the profile, which will be auto-discovered.

Note

As stated, the default seeding strategy uses request/response. A future version of this module will allow to override this behavior to use your own custom implementation.

Note

It is suggested, yet not required, to use special "create if not exist" messages here, so an eventual service restart will not override changes made by the users to the seeded data.

HealthChecks

External DataSeeding is capable to contribute to health checks. By default, every type exposed for data seeding through the module's API will be included in this validation.