process manager

[Douglas Gugino]

I have a process manager that "wakes up" at a certain time and polls a feed (more confusion on that later).  NOW it has something to do with some stuff ....

Should this process manager service append a "Command Given (aka Request)" to a "downstream called service"s input stream OR should the "called service" subscribe to the event the process manager documents for itself OR to some sort of projection OR do I have my terminology all screwed up (likely).  

NOTE: I expect that the "called service" would append a "Result Returned (aka Response)" to the upstream process manager service input stream OR the upstream process manager service would subscribe the event the "called service" documents for itself OR do I have my terminology all screwed up (again most likely).

Help - I'm a domain expert stuck in a communication do loop with developers.

[Chris Berthold]

I'm still new to this so i would back this up with some additional resources but heres my noob go at it.

A Saga or Process Manager suggests that there is a long running process or human work flow that prevents certain events within the domain from satisfying the invariant (hoping I said that correctly).  If you were to think of Amazon as a shopping cart you would send your order and acknowledgement of the order is the OrderAccepted event.  As part of submitting the order the OrderConfirmationProcessManager is created.  This process may be having a human check over the order, might be credit card processing and adding authorization hold, or checking the inventory and add allocations.  It might also have an "awakening" that has a timeout at which it fails.  My understanding is that the process manager will do things that satisfy the workflow it has and then will update the aggregate(s) that started that process.  In this case it may update the order aggregate with OrderConfirmed.  This may also send out external events to a bus to send out an email or update a UI.  Long-lived is all relative.  To Amazon 200ms might be long-lived. That will be the driving decision to which may  be the correct way to satisfy the request.  In general you can think of a REST call Request/Response to be a synchronous process in which we believe the call will be returned in a relatively short process and mostly successful.  Otherwise we have an Out/In queue or a contracted Out/In(callback) service endpoint or combination there-of to get an asynchronous process.  The queue would be the choice where you may have peak loads that you need to normalize.  In a service bus these concepts are handled under the covers.  Hope that helps.

[Greg Young]

It basically boils down to (correct me if I am wrong):

should the process manager emit an event or should it send a command?

Both are valid options the difference between a command and an event
is the semantics around how you handle it.

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Douglas Gugino]

Sounds right to me ... do you agree with my characterizations that follow?  My concept (subject to check) is that any 'process manager service' - wakes up (perhaps receipt of a timing "command given" that is appended to its self-subscribed input event stream; perhaps a timeout; etcetera – more confusion on that later) - would left fold on that stream, determine a status (state if you will), then perform whatever function it must and then, based on state and the “event, find the next step in its process.

 

GREG - I am picturing the grid in the Microsoft CQRS guidance document.

 

Then the 'process manager service' documents that next step on its stream (by appending to its own 'self-subscribed' stream).

 

Now I am confused by the panoply of options - and always am amused by the many 'blocking' issues developers love to raise :).

 

Anyway - let's consider the next service to be a "unit of work" service - it subscribed to the process manager's "Command Given", puts that event on its 'self-subscribed' stream and interprets it as a "Command Received".  Left fold, perform any function; decide by its simple ‘unit of work’ process grid; if it doesn't guide anything downstream - it documents an event that is the result of what it did with the "Command Received".

 

Assuming it is the upstream process manager that needs to hear ... that process manager service is subscribed to that event?

 

So I've just succeeded in confusing myself with the panoply.  I believe I want to use the competing (server side) subscription here with ONLY ONE consumer!

 

Realize this is hard for me to describe ... much easier on a whiteboard.

[Greg Young]

DoShitBird {
foo : 'bar'
}

ShitBirdReceived {
foo : 'bar'
}

The only difference is in how you can handle them? Are you allowed to
throw an exception?

[Douglas Gugino]

man - my developers could write any code that I tell them to ?  lol -   We've struggled with the use of event store as queuing .. I am certain I've got it - at least as much as I do right now!  However I don't write code and would love to have certain (shouldn't be blocking) issues explained to them.  The recent Wrox book was good in that it showed them how to do snapshots with sample C# code.  I would love to learn F# myself.

You understand my description ... so I will push forward with confidence (at least in the concept) of what I described above.

[Douglas Gugino]

Greg   what are the difference between "emitting an event" (I'm asuming something else is subscribed to it) VERSUS sending a command (does that mean you append to a specific stream?)  .....

[Douglas Gugino]

thanks Chris ... my desire is for ONE exact implementation of such things .. frustrating for me not to have something very exact.  Then my team could talk the same.  I don't code - and an internal lack of shared concepts is a black hole

[Ben Kloosterman]

I thought Greg explained that quite well in his example so im not sure of the question. 

One is a do verb that can fail , the other is past tense verb has been done  so cant fail - you cant change what has happened..  If you have a name what "it" will be called than you will know where it fits. 

Ben

[Douglas Gugino]

He did and you did - I've got the concepts - just want to confirm my understanding of the implementation - unless you can explain the different ways to "turn the screw" I can't guide my developers to what fits the domain!   So ... I will continue to put myself out there and show my ignorance ....

One is a Command Given event - written by the process manager to its own aggregate/event stream AND the subscriber (perhaps a competing/server side/subscriber client) gets a "call back?" so it knows that the event was written.  Is that 'emitting' ?

The other is appending the "command given" to the specific downstream processes' aggregate/event stream?

[Greg Young]

"The other is appending the "command given" to the specific downstream
processes' aggregate/event stream?"

I would tend to do this. An alternative (ES specific) would be to have
the consumer listen to the $et-{type} stream assuming it only
processed this one type of event

[Douglas Gugino]

thanks Greg - does google have a 'whiteboard' available to us :) OR I would like to buy some on the phone consulting time - I am sure that within 30 minutes the alternatives could be laid out clearly for me.  I have lots of ignorance left ...

Is there a preferred "case statement" lookup implementation that the process manager (or - my words - unit of work(ers)) do to decide what to do with STATE and either a Command Given, Result Arrived. or Event of Interest (that just showed up on my aggregate/event stream) ?

I imagine that F# would be so much clearer for me to understand ... C# is confusing .... still any suggested technique ?

[Douglas Gugino]

must a ES competing consumer only listen to $et ?   what of certain $et's on a specific aggregrate/event stream ?   

[Greg Young]

I am normally fairly busy but drop me an email offline and we can
likely work something out in the next week or two.

Greg