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.
2. Do some processing and send a message (say, type 2) to the device
associated with this workflow instance.
3. Wait for said device to reply with a message of type 3 (say, an
acknowledge)
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).
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}
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. 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).
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...
Sorry if this is a bit rambling, I'm kind of thinking my way through this as
I write.
Cheers!
--
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
