Outboxer 1.1.0

--- This update requires a new migration to be added ---

Outboxer

Available at GitHub

This lib intends to provide a simple and broker agnostic Outbox Pattern implementation.

The only requirement to use Outboxer is to use Entity Framework as we use its built-in Unit-Of-Work to assure everything is saved at the same time and guarantee consistency.

To use Outboxer follow these steps

• Make sure your DbContext inherits OutboxerContext<T>. If the name of your context is StudentsContext, your class should look like this.

public class StudentsContext : OutboxerContext<StudentsContext>
{
    public StudentsContext(DbContextOptions<StudentsContext> options,
        ITransactionalMessageContainer transactionalMessageContainer) : base(options, transactionalMessageContainer)
    {
    }

    // Your code
}

• Run dotnet ef migrations add/dotnet ef database update to create the outbox table

• Register Outboxer using services.AddOutboxer<StudentsContext>(); at your Startup.cs or Program.cs(.net core 6+)

• To be broker agnostic means that you'll have to implement your own broker communication mechanism. Make sure your class implements the IBrokerPublisher interface. All your sending logic should be inside Publish method.

• Register your custom broker communication class on DI container using services.AddScoped<IBrokerPublisher, MyBrokerImplementation>(). You can use AddSingleton as well.

• To publish a message inject the interface IPublisher and use the Publish method like this await _publisher.Publish(new Entry("studentsQueue", messageContent));. The content will just be added to outbox and enqueued on your broker if the database commit runs fine.

Important warnings

If the BackgroundWorker that sends the messages gets restarted it will re-enqueue ALL the messages with ENQUEUED status at the outbox table. This normaly just occurs when the app gets restarted, yet it is a good idea to implement idempotency at your consumers.

Currently there is no Dead-Letter implementation. If a message reaches the maximum amount of retries it will rest in the table with FAILED status. DLQ Handling to be implemented in next version.

Messages Status

• 1 - Pending
• 2 - Enqueued
• 3 - Delivered
• 4 - Failed

Changelog

v1.1.0 - Fixing bug that was preventing the persistence of Destination and Retries on the outbox table. - REQUIRES MIGRATION