2

I building multitenancy into the unit of work for a set of services. I want to keep the tenancy question out of the way of day-to-day business domain work, and I do not want to touch every existing consumer in the system (I am retrofitting the multitenancy onto a system without any prior concept of a tenant).

Most messages in the system will be contexted by a tenant. However, there will be some infrastructure messages which will not be, particularly for the purpose of automating tenant creation. I need a way of determining whether to use a tenant-contexted unit of work, or a infrastructure unit of work uncontexted by a tenant because the way I interact with the database is different depending on whether I have tenant context. The unit of work is built in the process of spinning up the dependencies of the consumer.

As such I need a way of peeking at the message or its metadata before consuming it, and specifically, I need to be able to peek at it during the dependency building. I was intended to have a tag interface to mark tenant management messages out from normal business domain messages, but any form of identifying the difference could work. If I am in a unit of work resulting from an HTTP request, I can look at WebApi's HttpContext.Current and see the headers of the current request, etc. How do I do something analogous to this if I am in a unit of work resulting from messaging?

I see there is a way to intercept messages with BeforeConsumingMessage() but I need a way of correlating it to the current unit of work I am spinning up and I'm not seeing how that would work for me. Pseudocode for what I am trying to do:

if MessageContext.Message.GetType() = typeof<ITenantInfrastructureMessage>:
    database = new Database(...)
else:
    tenantId = MessageContext.Headers.TenantId;
    database = new TenantDatabase(..., tenantId)

I am working in C#/.NET using MassTransit with RabbitMQ and Autofac with MassTransit's built-in support for both.

Keith Pinson
  • 7,835
  • 7
  • 61
  • 104

1 Answers1

2

Your best option is to override at the IConsumerFactory<T> extension point, and extract the tenant from the message (either via a message header, or some message property) and register that in the container child lifetime scope so that subsequent resolutions from the actual consumer class (and it's dependencies) are properly matched to the tenant in the message.

In our systems, we have a TenantContext that is registered in a newly created LifetimeScope (we're using Autofac), after which we resolve the consume from the child scope, and the dependencies that use the tenant context get the proper value since it's registered as part of building the child container for the message scope.

It works extremely well, we even built up extension methods to make it easy for developers registering consumers to specify "tenant context providers" that go from a message type to the proper tenant id, which is used to build the TenantContext.

You can do similar things with activity factories in Courier routing slips (which are a specialization of a consumer).

Chris Patterson
  • 28,659
  • 3
  • 47
  • 59
  • I was hoping to hear from you. :) – Keith Pinson May 04 '15 at 19:57
  • So basically a decorator pattern, right? I haven't figured out quite what the seam for injecting the wrapped `IConsumerFactory` is though... I'll keep looking. – Keith Pinson May 04 '15 at 20:02
  • Okay, so it looks like I need to create an alternative to the `LoadFrom(...)` extension method from `AutofacExtensions` which will use an alternative to `AutofacConsumerFactoryConfigurator` which will allow me to inject a wrapped version of the `AutofacConsumerFactory` so I can create a scope, set something on it, and pass it down to the factory. – Keith Pinson May 04 '15 at 21:09
  • Excellent, glad to hear it! :) – Chris Patterson May 05 '15 at 20:21