storage_participant.proceed question

[denis....@bluewaterbrand.com]

Hello,

After calling @dashboard.storage_participant.proceed(workitem), what is the best way to check if ruote successfully proceeded to the next participant? 

I tried following the method calls in the ruote source code to see if the proceed method (in Ruote::StorageParticipant) returns a value that would indicate this, but wasn't able to determine whether it does or not.

Thanks,
Denis

[John Mettraux]

On Thu, Sep 19, 2013 at 12:05:14PM -0700, denis....@bluewaterbrand.com wrote:
>
> After calling @dashboard.storage_participant.proceed(workitem), what is the
> best way to check if ruote successfully proceeded to the next participant?

Hello Denis,

short answer first.

There is no best way. What if there is no next participant?

> I tried following the method calls in the ruote source code to see if the
> proceed method (in Ruote::StorageParticipant) returns a value that would
> indicate this, but wasn't able to determine whether it does or not.

No, it doesn't not. The proceed method simply hands back the workitem to the
engine.

When you hand a package to the FedEx guy, he isn't able to tell you if the
package was successfully delivered to the recipient. (Well he is, the packet
hasn't been delivered yet, it's still in his hands).


Long answer now.

When testing, I do use Dashboard#wait_for(:participant_name) as in
https://github.com/jmettraux/ruote/blob/7a26fdeaa362/test/functional/eft_14_cursor.rb#L400-L421

When testing, I know what will happen next, so I wait explicitely for that
thing (reached participant, terminated, 1 step, ...) to happen.

But this is testing.

In production, if you start encoding expectations about the process
definition into the code, you'll end up having to modify the code as well
when making changes to the process definition.

I don't know what is your use case, let me make up one just for the sake of
this email response.
Participant A receives a workitem, he can choose between B and C (next
participant name). He chooses B. The UI you wrapped around that storage
participant / decision could then proceed the workitem and poll B or C
(StorageParticipant#by_participant(name)) to determine if the workitem
reached it.

Aunt Maribel sent a package to Uncle Joe, she then calls repeatedly Uncle Joe
to determine if the packet arrived. "Maribel, dear sister, I fully
understand, me neither, no trust in the postal service..."


Best regards,

--
John Mettraux - http://lambda.io/jmettraux

[denis....@bluewaterbrand.com]

Hi John,

My use case is this - we have ruote behind a Rails application.  We have a participant that makes a web request to another app to retrieve some data that takes a while to retrieve.  The participant then sits and waits until the other app calls back to the Rails app via a web callback, letting it know that the data is ready for download and that ruote should move onto the next step in the process (i.e. the "download data" step).

The web callback uses @dashboard.storage_participant.proceed(workitem) to programatically "complete" the "request data" step, so that ruote can move onto the "download data" step.  The callback needs to know if the "request data" step was successfully "completed" so that it can return a 200 response to the other app, letting it know the callback was received and the process has moved on.

Due to the asynchronous nature of ruote, perhaps the web callback should just return a 200 as long as the request was received and ruote was successfully told to proceed to the next step.  Then, we would use some other mechanism to handle the case where ruote was unable to move to the next step for some reason.  Or, perhaps there's a better way to accomplish what we're trying to do.

Denis

[John Mettraux]

On Thu, Sep 19, 2013 at 03:26:46PM -0700, denis....@bluewaterbrand.com wrote:
>
> (...)

>
> Due to the asynchronous nature of ruote, perhaps the web callback should
> just return a 200 as long as the request was received and ruote was
> successfully told to proceed to the next step. Then, we would use some
> other mechanism to handle the case where ruote was unable to move to the
> next step for some reason. Or, perhaps there's a better way to accomplish
> what we're trying to do.

Hello,

I would immediately respond with 200.

Responding with 202 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)
might be better, but you then would have to put your HTTP hat on and rethink
your interactions.

A service should do its job and not care about the result's further
processing. Unless you want to stop orchestrating and let the services
coordinate.