we have an existing class that has an implmentation of CosmosDB, with CreateCustomer, UpdateCustomer, DeleteCustomer, ReadCustomer methods, we now want to implement a saga to onboard new customers, which involves.
Creating a New Azure SQL Database (http call)
Updating the InHouse CRM System (http call)
Update a SQL Server DB table
…etc
at the same time, we want to maintain the entire provisioning history to in the CosmosDB Customer container and do analytics on the customer container and read and generate reports.
Questions
Can we leverage our existing implementation of the customer class in the handlers?
Can the existing implementation participate in the outbox transactions?
Should the SagaData be a customer container ? or should we use a different container, if its same container how can we read it from another system ?
any example and guidance on this would be helpful.
That should be possible as long as your existing class is using the batching API. Otherwise you would have to switch it to using the batch API. Once it is using the batching API you can “wire up” the batch to the synchronized storage session.
Are you using dependency injection with that class? All components resolved within the scope of an incoming message will have access to ICosmosStorageSession and there you have access to the transactional batch that is managed by NServiceBus. So you can either directly inject that inferface into your customer DB access layer or add a scoped dependency that resolves the batch from that interface.
In case you want more specific help you can either share some code snippets here and we can walk you through it or raise a support case where we can dive into more specific cases if there are concerns regarding sharing code in this public forum.
That’s a tricky one to answer and it depends. Does the saga data need to be stored transactionally as well? Maybe even together with the customer data? Transactions cannot cross containers so that would be one thing to take into account.
in the same container we will have 2 doctypes, 1 holds the customer saga data and the other doctype holds the customer data…etc, both sharing the same partionid so when reading the data, we read from the customer data doctype and will update our custom cosmos class to use the session api.