Hello Mario, Hello Nathan,
+1 for Nathan's answer.
I will try to complement a bit / be more technical.
Ruote is written in Ruby, this programming language has many advantages, among
them :
- you can write / test something very quickly, then turn that into a production
thing or discard it
- the Ruby ecosystem has lots of libraries, usually there are more than one
library for a given problem/domain/... It's very very rich
For me this makes experimentation / integration very easy.
It's a bit unfortunate, but Rails has this slogan "convention over
configuration" which is sometimes passed to adjacent systems as "you have to
adapt to it". Some devs then go into a "that's the way to do it, it's magical"
and build religion around stuff.
Ruote-amqp comes with a very straightforward way of doing things : serialize as
JSON, publish... fetch, deserialize, pass back to engine.
You are not limited to that. Please do not limit your imagination.
Quoting Nathan :
> The ruote-amqp gem is designed for you to add your own message handlers
> that do that kind of thing
I.e you can override the #encode_workitem of RuoteAMQP::ParticipantProxy and
#decode_workitem of RuoteAMQP::Receiver.
Or you can completely go off-tracks and do :
---8<---
class MarioParticipant
def initialize(opts)
@opts = opts
end
def consume(workitem)
MQ.queue(@opts[:queue], :durable => true).publish(
"workitem:" + workitem.fei.sid, :persistent => true)
end
def cancel(fei, flavour)
MQ.queue(@opts[:queue], :durable => true).publish(
"cancel:" + fei.sid, :persistent => true)
end
end
class MarioReceiver < Ruote::Receiver
def initialize(engine_worker_or_storage, opts)
super
MQ.queue(opts[:queue], :durable => true).subscribe do |msg|
handle(msg) unless AMQP.closing?
end
end
protected
def handle(msg)
fei = msg.split(':').last
workitem = workitem(fei)
workitem.fields['back'] = 'from AMQP'
reply_to_engine(workitem)
end
end
--->8---
So the "correlation" thing you want is the "fei" (flow expression id). That's
how the engine can map something to a workitem / flow expression.
In that code example, given the fei, the workitem is fetched from the engine
(wel the storage) directly, 'decorated' and 'replied to the engine'.
> I've worked with other workflow systems (specifically, Sun/Oracle JavaCAPS)
> in which the incoming/outgoing messages are completely disassociated from
> the workitems.
In ruote, the incoming/outgoing messages are completely disassociated from the
system.
You can write a participant/receiver couple that ships info by donkey, ruote
will never know and never care. Ruote dispatches workitems to participants and
receives them back, sometimes. The rest is unicorns, dragons and elfs, but
ruote never cares, the participant (and sometimes receiver) implementations do.
I hope this helps, 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
