Hi John I never had a chance to thank you for the lengthy reply back in May, and I have some more questions with a better defined example in this case. For the sake of clarity I've truncated this entire email, readers can go back to the old messages at http://groups.google.com/group/openwferu-users/browse_thread/thread/345490e4bb9aad22/a4130f0956e267b4
Since we last spoke we've been using XMPP with great success in our background processes, we also continue to use queuing services with as much success. However things have started to become clearer to me in terms of separating the business processes from the underlying code implementations. It's become more clear that we need something like ruote for one specific project, where XMPP already plays a massive role in the underlying infrastructure (but thats not key to the discussion). Some background first. The system runs the biggest wholesale ISP in South Africa. We have various levels of users and provision services from various providers. We've identified workflow management as the key to making the current iteration a success. With workflows used loosely, I mean something more than just acts_as_state_machine. We already have well defined states in place, since they're also key for us. States are current used in two ways, the first to affect service availability, and the second to indicate it's step in the workflow. The latter bothers me still, feels like we're bending AASM to do something it's not really meant to. But first a sample workflow. Who is involved? * Staff (of our clients) * Client * Support (our own staff, various tiers and areas of responsibility) * Bots (XMPP consumers that perform said actions) Process of provisioning generic automated service: 1. Staff provisions service 2. Client approves provisioning based on whatever criteria (internal to their business, we don't care), might be auto-approved based on Staff member 3. Automation: XMPP blasts out to specific bot who performs actions and reports back 4. Support member reviews results from the bot, intervenes manually if required (upstream API failed, servers down, whatever reason) Process of provisioning manual service 1 & 2 as above 3. Support member validates documentation 4. Documentation might flow up and down between Support and Client (would loop unless all requirements as met, or would be cancelled) 5. Process applied for with third party, waiting for third-part providers (might take several days) 6. Process finishes (successfully or failed) 7. Communicated to client the result of above 8. Client might need to confirm receiving equipment or testing functionality before we close the worklow, might jump back into another part of the service if something is not satisfactory. Process of transferring services from our competitors (yes it happens often :) ) 1 & 2 as per first example 3. Automation will happen, but services would on hold 4. Documentation and technical conversations up and down (think domain transfer here with EPP codes, etc...) 5. Process completes or fails based on whatever reason (non-technological reason) 6. Service provisioned if successful Key to how we build our systems is using several independent process scattered over a couple of servers. All Ruby at this stage, but as I pointed out in my blog series, any component can ultimately be replaced by another piece of technology if needed (not foreseen, but future proofed). The core is a single Rails application from where humans would interact with all the processes involved. What I can't seem to figure out (be it a mental block or whatever other reason), is how to use ruote to manage these processes. Would ruote take over the communication between the processes, or do we stick to XMPP/AMQP and have WorkItems in the message paylods? Are the process definitions kept in a single repo and shared among each utility involved in the process? Are the actors actually related to how we pass WorkItems around (ie, ActiveRecord, or XMPP, or AMQP/SQS)? I've been reading the other newbie mails as well, but seems everyone has solved that part of the problem for themselves and moved on. I guess what I'm asking for is the names of classes that would by inserted in the various point above, considering it is a vastly distributed system with independent components running all over the show. Thanks a lot, I know its a mouthful. -- Kenneth Kalmer [EMAIL PROTECTED] http://opensourcery.co.za --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
