Outbox with dapper orm

#1

Hi All,

our scenario : we do the following in our handler

  1. SaveAnOrder()
    –>This calls a facade
    → the domain facade calls a sql helper class which uses Dapper ORM to
    save the order to the db
  2. Finally raise an “OrderCreated” Event

Questions

  1. From what I have read about the Outbox pattern, the same transaction and connection should be used between the dapper ORM and Outbox, if this the case, what are my options to enable outbox here

    a) should i send the context context.SynchronizedStorageSession.MyPersistenceSession(), to my
    the façade layer which will in turn send it into the SQL Dapper class and use the connection and
    transaction object?

    the problem with the above approach is that
    1. my façade class and ORM class is taking a dependency on the NserviceBus,
    2. assuming even if were to convince everybody, how are we going to mock the the
      context.SynchronizedStorageSession.MyPersistenceSession() in unit tests.
    3. And how do we pass this dependency during my ORM integration tests ?

  2. Can we use ASB transport along with SQL persistence outbox ? or does it have to SQL transport
    and SQL persistence ?

  3. Does SQLPersistence support Azure Managed Identity ?

  4. Can we dispose the connection and transaction (using statement) that we get from the context.SynchronizedStorageSession.MyPersistenceSession() ?, basically dapper methods are extension methods on the connection object ?

  5. I could only find EntityFramework ORM examples, any pointers on how we can accomplish the same thing with dapper ? any example would be really helpful.

Thanks -Nen

#2

You don’t have to take a dependency on NServiceBus. You can create your own “storagecontext” and initialize that in a NServiceBus pipeline behavior:

Yes, that is possible. The outbox requires the same storage as persistence but the transport can be different.

I’ll look into this and get back to you.

No, you should not dispose these as the lifetime of these is controlled by NServiceBus. You don’t own the objects (injected) thus not dispose them.

Take a look at this example. It should how to obtain transaction information, initialize a helper object in a pipeline behavior and have this injected via DI in the resolved object graph.

#3

SQL Persistence is initialized in code: SQL Persistence - SQL Server dialect • Sql Persistence • Particular Docs

You should just assign the connection its AccessToken property:

var accessToken = FetchAccessToken(); // Must fetch the Azure Managed Identity access token 

var persistence = endpointConfiguration.UsePersistence<SqlPersistence>();
persistence.ConnectionBuilder(
    connectionBuilder: () =>
    {
        var conn = new SqlConnection("Data Source=<AZURE-SQL-SERVERNAME>; Initial Catalog=<DATABASE>;");
        conn.AccessToken = accessToken; // Assign token in addition to creating the connection.
        return conn;
    });
#4

@ramonsmits thank you !!,

Regarding Transactions:

do i commit transaction or does nservicebus take care of it.

in my handler i am trying to insert rows into multiple SQL tables and need have a transaction around this.

and finally send an event out.

do i encapsulate the around my 2 multiple statements and finally do a trans.commit ?

Thanks -Nen

#5

The transaction that you would retrieve via the mentioned sample is managed by NServiceBus. Meaning, it is shared. You should not commit or roll back this transaction or close the connection.

In general you should not catch errors yourself and rollback transactions as this would conflicht with the recoverability mechanism from NServiceBus.

I think it would also be good to few the following guidance on transactions and recoverability:

Transport transactions:

Persistence connection sharing:

Recoverability (errors, exceptions, retries)

– Ramon