Accessing different bounded context data from saga

Question

I created a saga with NServiceBus that request external service for customer's information and make timeout. After timeout expire that saga check if external service has response. In response I have data of corresponding customers and now I have situations where I must check if that corresponding customer exists in our system (if he doesn't - I must create him) after that I must create some additional audit entity that refer to that customer (if I have all needed information to create them).

I wonder how i should check if a specific customer exists and when not how to create him.

I have a few ideas so far:

invoke WCF service from inside the message handler (check, create)
send message via NSB to Customer bounded context and wait for response with ID.

Can you describe what your first message is? That may influence the answer. — Udi Dahan
Is external service also an NSB endpoint (the Customer BC) or is it an RPC-like web service? — eulerfx
@eulerfx - External service that I request is RPC-like web service provided by external company. Customer BC in our system will be available as NSB endpoint and WCF (especialy for UI layer). — Sławomir Rosiek
Retrieving customer data is a query from the perspective of the saga (I assume this is in BC different from Customer BC). I would encapsulate this responsibility in the Customer BC, such that it handles the call to external service and creates/updates local data as needed. The saga would then issue a query to a service in the Customer BC when it needs customer data. NSB isn't meant to handle queries, because typically queries require an immediate response. — eulerfx

Udi Dahan Udi Dahan · Accepted Answer · 2012-08-31T07:09:35

You could leverage the NServiceBus message handling pipeline for this. Have a handler from your "Customer Service" configured to run first, which checks for the existence of the customer and creates them if necessary, finally setting the CustomerID property on the original message being handled so that the next handler will know what it is.

This gives you the benefit of transactional consistency around the whole process.

The publish/subscribe model you described could also work. I don't like it as much because you 're going into a kind of request/response over events and it isn't clear who is really responsible for the customer info (as the data needed is coming from a publisher not responsible for the customer).

It's hard to be more prescriptive without going in depth into your domain.

Accessing different bounded context data from saga

1 Answers