Query Saga Data For UI

[Jesse Inskeep]

I have a saga that is started by an “OrderCreated” event. I then have two handlers for an “OrderAccepted” or “OrderDeclined” commands. 

The saga data associated with the “OrderCreated” saga has about 10-15 properties that are set via the “OrderCreated” event. 

I now need to build a dashboard that shows all orders that have not been accepted or denied. The UI will show all the sagas and give two buttons, one for accept and one for denied. These would send the respective command to the saga for processing. When the command is received, each will kick off an event for this and mark the saga as complete. 

Here is my question………. 

Do I query the saga data directly (stored in RavenDB)? Or do I setup a separate database (most likely MSSQL) and store the data there used for the UI? 

Option 1: Separate Database for UI 

Doing a separate database seems like a waste as the saga data and SQL data will be identical to each other. In this case I would get rid of the saga and probably just have 3 different handlers that all received an injection for a repository.

Option 2: UI Queries RavenDb Saga Data 

With this option I am mostly concerned about how to query the saga data. At this point my UI layer would have to reference my “backend” layer (which houses the saga) to get a reference to the model used to persist the data to RavenDb. This triggers some alarms that something is modeled wrong. 

Thoughts, opinions and recommendations are welcome! J

[Kijana Woodard]

My first question would be: why do you need/want a saga for this?

Is this just an example?

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5839b4c4-02d5-4aeb-9686-fe6cf308e63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Inskeep]

This is mostly an example but does relate pretty closely with a component I am working on right now.

I defaulted the architecture of this component to a saga based on doing so much NServiceBus work over the last couple months. It just seemed to be the default of "these messages are all correlated together so they go in a saga."

I'm realizing this is probably not the right answer. There should probably just be 3 different handlers and a SQL table or two that the handlers write the data to. Using a saga for this is just unnecessarily complicating things....

On Monday, December 29, 2014 1:49:13 PM UTC-6, Kijana Woodard wrote:

My first question would be: why do you need/want a saga for this?

Is this just an example?

On Mon, Dec 29, 2014 at 1:46 PM, Jesse Inskeep <jessea...@gmail.com> wrote:

I have a saga that is started by an “OrderCreated” event. I then have two handlers for an “OrderAccepted” or “OrderDeclined” commands. 

The saga data associated with the “OrderCreated” saga has about 10-15 properties that are set via the “OrderCreated” event. 

I now need to build a dashboard that shows all orders that have not been accepted or denied. The UI will show all the sagas and give two buttons, one for accept and one for denied. These would send the respective command to the saga for processing. When the command is received, each will kick off an event for this and mark the saga as complete. 

Here is my question………. 

Do I query the saga data directly (stored in RavenDB)? Or do I setup a separate database (most likely MSSQL) and store the data there used for the UI? 

Option 1: Separate Database for UI 

Doing a separate database seems like a waste as the saga data and SQL data will be identical to each other. In this case I would get rid of the saga and probably just have 3 different handlers that all received an injection for a repository.

Option 2: UI Queries RavenDb Saga Data 

With this option I am mostly concerned about how to query the saga data. At this point my UI layer would have to reference my “backend” layer (which houses the saga) to get a reference to the model used to persist the data to RavenDb. This triggers some alarms that something is modeled wrong. 

Thoughts, opinions and recommendations are welcome! J

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.

[Mauro Servienti]

This is mostly an example but does relate pretty closely with a component I am working on right now.

I defaulted the architecture of this component to a saga based on doing so much NServiceBus work over the last couple months. It just seemed to be the default of "these messages are all correlated together so they go in a saga."

I'm realizing this is probably not the right answer. There should probably just be 3 different handlers and a SQL table or two that the handlers write the data to. Using a saga for this is just unnecessarily complicating things....

Maybe in this case yes, but generally speaking in these scenarios you can setup a saga that handles the entire long running process and then setup some handlers that react to saga state changes and update one or more read model(s) for the UI.

You can obviously query the saga data in the storage, I see 2 possible issues:

- the way data are stored is an implementation detail that can change over time;

- SagaData may not contain all the required data, from the UI point of view, a saga handling the order process may keep track of the “payment id” and the status of te payment but it is not interested in keeping track of the amount payed on the other hand the UI may want to view the payed amount along with other data

On Monday, December 29, 2014 1:49:13 PM UTC-6, Kijana Woodard wrote:

My first question would be: why do you need/want a saga for this?

Is this just an example?

On Mon, Dec 29, 2014 at 1:46 PM, Jesse Inskeep <jessea...@gmail.com> wrote:

I have a saga that is started by an “OrderCreated” event. I then have two handlers for an “OrderAccepted” or “OrderDeclined” commands. 

The saga data associated with the “OrderCreated” saga has about 10-15 properties that are set via the “OrderCreated” event. 

I now need to build a dashboard that shows all orders that have not been accepted or denied. The UI will show all the sagas and give two buttons, one for accept and one for denied. These would send the respective command to the saga for processing. When the command is received, each will kick off an event for this and mark the saga as complete. 

Here is my question………. 

Do I query the saga data directly (stored in RavenDB)? Or do I setup a separate database (most likely MSSQL) and store the data there used for the UI? 

Option 1: Separate Database for UI 

Doing a separate database seems like a waste as the saga data and SQL data will be identical to each other. In this case I would get rid of the saga and probably just have 3 different handlers that all received an injection for a repository.

Option 2: UI Queries RavenDb Saga Data 

With this option I am mostly concerned about how to query the saga data. At this point my UI layer would have to reference my “backend” layer (which houses the saga) to get a reference to the model used to persist the data to RavenDb. This triggers some alarms that something is modeled wrong. 

Thoughts, opinions and recommendations are welcome! J

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5839b4c4-02d5-4aeb-9686-fe6cf308e63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.

To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/8df14f34-0d82-49ab-8712-39caa03b8603%40googlegroups.com.

[Kijana Woodard]

Agreed on using handlers for read models instead of querying saga data directly.

---

From: Mauro Servienti
Sent: ‎12/‎30/‎2014 2:59 AM
To: particula...@googlegroups.com
Subject: Re: [particularsoftware] Query Saga Data For UI

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/etPan.54a26963.10af00a7.331%40Rowlf.

[Jesse Inskeep]

Here is another scenario that we are running into......

 During the day the saga receives a stream of transactions that have all the data needed for the batch. We correlate all the messages via a “RequestDate” property and kickoff a timeout when the first message is received for +25 hrs after the “RequestDate”.

 We have a simple DTO (about 10-15 properties) that is filled out via the transaction message that is received and the  saga data has a List<DTO> property and adds a new item to the list for each transaction received.

 At the timeout (1 a.m. the next day), we run the list of records into a batch process that groups them together, runs calculations and then drops a text file of the output and marks the saga as complete (or sets a flag property of “HasBenProcessed”).

This system will experience a pretty high throughput over the next couple years, 150-200K messages per day in some instances.

Everything works great now, but the same as before is we need to build out some type of admin to see the data that is in the sagas. The admin will need to give a quick overview of which days we have a batch file for (the correlation is via a “RequestDate” property) with how many records are in the list.

 Additionally we will need a more detailed report that would show all the details for each row in the batch file.

 So same as before..... should we build the admin and query the RavenDB saga data directly? Or are we mis-using sagas in which most of this data should be stored in a SQL table and the saga trimmed down to just initiate commands to handlers that do each different step of this process?

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/8df14f34-0d82-49ab-8712-39caa03b8603%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.

To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.

[Jimmy Bogard]

In these scenarios, what typically happens is the needs for managing the process start to conflict with the data needs for reporting on the process. What I wind up doing is raising events from my saga, and event handlers that can then create those read models. What you likely don't want to have happen is contention for reporting/processing. It's lessened somewhat as you'd be using Raven for its secondary indexes. But I still would rather have a separate reporting model, since there might be additional context that you don't have inside a saga (i.e., you've sent a message to kick the saga off, but the saga hasn't received it/errored out, so there's no saga instance).

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.

To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/df5563f6-c776-4d22-8f5e-23ef6606b677%40googlegroups.com.

[Udi Dahan]

Since we're talking about admin/support users, I'd probably start simple and query the RavenDB saga data directly.

That being said, I'd keep an eye out to see if/when UI concerns start to bleed back into the saga data and then look at creating a more engineered solution.

-- Udi

[Kijana Woodard]

One approach would be to use a Transformer to provide a little separation between the Saga model and the desired view model.

--

You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.

To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/3b9dfbb6-09ca-43b8-a1d4-8abe9bb8af3a%40googlegroups.com.

[Jesse Inskeep]

Kijana - I've never heard of a "Transformer" before. Is this a pattern to apply or a feature or RavenDB? Can you provide a little more information about this approach?

[Mauro Servienti]

Hey Jesse,

it is a RavenDB feature, it is a way to transform (and potentially join) data on the fly at query time at the server, I talked about that and all the 'projection' related features at the RavenDB Conf last year: https://www.youtube.com/watch?v=pxCgQHtlg38

(It was my second talk ever in English, so do not kill the pianist)

.m

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/120f8601-3b0e-43ec-803c-382eee51b00e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mauro Servienti

[Kijana Woodard]

Sorry, I meant to reply yesterday: http://ravendb.net/docs/article-page/3.0/csharp/transformers/what-are-transformers

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/CAKhTcw15c7qQbL7ffYCUb-M%2Buba1eqU0%3DxM%3DqV1fWEU0wNumkw%40mail.gmail.com.

[Daniel Marbach]

Hi all,

We updated the doco to summarize what we recommend for querying saga data

http://docs.particular.net/nservicebus/sagas/#querying-saga-data

Regards

Daniel