On Wed, Jan 26, 2011 at 06:05:34AM -0800, Mario Camou wrote:
> Let me elaborate further. I have a set of external devices each of which has
> its own ID (what I previously called the "token"). Here's what we're trying
> to do:
>
> 1. When a message of type 1 is received, start the workflow
> "1-process-message.rb" and store the token of the device that sent the
> message.
OK, no correlation id involved (there is no process instance).
Receiver treat messages of type 1 as launch requests.
> 2. Do some processing and send a message (say, type 2) to the device
> associated with this workflow instance.
Reaching a participant.
Participant emit a type 2 message.
> 3. Wait for said device to reply with a message of type 3 (say, an
> acknowledge)
Participant is waiting for the workitem back.
Receiver treat message of type 3 as following type 2.
> The thing here is, we have multiple such devices that will be processing in
> parallel. So, the token we're using is the device ID and the idea is that if
> we receive a message of type 3 from device X, it should be sent to the FEI
> associated with step 3 of the correct instance of the given workflow.
>
> At the moment the solution has been to store the workitems and all the stuff
> inside our gateway module (the module that connects directly to the devices
> and talks AMQP with Ruote) but I find it rather error-prone, also, I believe
> that the fact that message 3 comes after message 2 should be represented
> only in the workflow (currently that knowledge is also being embedded in the
> gateway -- well it will be as soon as the gateway is finished if we continue
> with this approach).
Yes, it's implicit in ruote, a participant emits a message, a receiver receives
it.
> I'd like to have something like this:
>
> amqp send_message :payload => {:type => 2, :device => ${f:device_id}}
> :wait_for_message => 3
>
> or even
>
> # Assume field device_id has been set somewhere before this point
> set :f => 'expected_message', :value => 3
> amqp send_message :payload => {:type => 2}
No need for those type things (see top of this email).
> and have the participant wait until the proper message is received for the
> given device ID (considering that, at a particular moment in time, there
> might be multiple instances of the participant waiting for the same message
> type from different device IDs). So in this case, my correlation key would
> be (device_id, message_id) and from that info I'd get the FEI back.
Multiple instance of the participant ?
Maybe you'd need to work with a "listen" expression.
I have the impression that you're multiplexing : 1 participant receives 1
workitem, it emits multiple AMQP messages and it waits for all those messages
to come back...
> If a
> message is received for which there is no correlation I should save it in
> case the station is faster than Ruote (i.e., the station replied with the 3
> before Ruote got to the point of expecting message 3... although we should
> be able to handle this in the participant itself which would mean that
> unmatched messages get discarded).
Not possible. Ruote is ready to receive a reply for a participant as soon as
this participant is reached (applied).
> So again, when I get the message in the Receiver, in the second case I could
> look for a workitem with the given expected_message and device_id fields, or
> in the first case I could store that data in the Participant and that's all
> standard Ruby stuff - I could probably use a Hash stored in a class variable
> or singleton, an instance of Rufus::Cloche or some sort of database. I'm
> thinking of using in-memory storage since, for the purposes of this business
> case, if Ruote crashes the world should reset itself, at least as far as
> waiting for messages is concerned... which raises another point, on startup
> I'd need to cancel all the processes that are waiting for a message...
So you're multiplexing. The participant receives a workitem from ruote and then
it sends multiple AMQP messages... This should not appear at all in the process
definition. You should not couple.
sequence do
whatever_amqp
end
The payload is the payload of the current workitem, the rest is resolved by the
participant / receiver implementation pair.
Your message types won't change, if they do, then maybe it's OK to specify them
in the process definitions, but they are merely constants in the
participant/receiver implementations.
> Sorry if this is a bit rambling, I'm kind of thinking my way through this as
> I write.
Please don't overcomplicate it.
Mario, I have the impression that you're in a bad situation and trying to use
ruote without knowing much about it.
Please take the time to run simple examples and then build up wider examples
and then let's resume the conversation.
Best regards,
--
John Mettraux - http://jmettraux.wordpress.com
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
