Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/kennethkalmer/ruote-rest-rails-client

Extracted from a production app, this is one way to interact with ruote-rest from inside Rails
https://github.com/kennethkalmer/ruote-rest-rails-client

Last synced: about 15 hours ago
JSON representation

Extracted from a production app, this is one way to interact with ruote-rest from inside Rails

Awesome Lists containing this project

README 

        
= Sample ruote-rest client for Rails



This is code extracted from an actual production system and it's very opinionated.



We use ruote-rest extensively in our service provisioning platform. The users interact

with a Rails application which fires off processes to complete certain tasks.



This library might not make any sense to anyone but us, and I quite frankly don't care (yet).



== Don't care?



I'll be building a fresh gem for Rails from the lessons learned here, and it will accompany

the forthcoming ruote-kit project (which is the planned replacement for ruote-rest). This

code will die eventually, it is our first attempt and we learned a lot from using it

every day.



== Getting going



Layer this repo over your rails application.



You'll need the following gems/plugins installed and working:



* delayed_job

* httparty



=== delayed_job



We cannot let the absence of ruote-rest spoil a perfectly good process launch, so all the

launching is handled by delayed_job.



=== httparty



I never bother testing it, but a friend pointed out that the XML generated by ruote-rest

is not ActiveSupport friendly, so I've made a note in ruote-kit to handle this.



== Support



No, you've been warned. Get into #ruote or on the openwferu-users mail list. If convinced,

I'll accept Heineken as payment.



== Example usage



The whole library launches process by means of ActiveRecord callbacks, here is an example



  class Service < ActiveRecord::Base

    belongs_to :broker

    belongs_to :client



    launch_processes



    after_create :service_created!



    private



    def service_created!

      payload = {

        :type => 'Insurance',

        :number => 'I0001'

      }



      ruote_launch_process 'service_created', payload, self.participants

    end



    def self.participants

      { :broker => self.broker, :client => self.client }

    end

  end



Then the process definition might look like this:



  class ServiceProcess0 < OpenWFE::ProcessDefinition

    sequence do

      <%= get_participant(:broker) %> :activity => 'Credit vet'

      <%= get_participant(:client) %> :activity => 'Sign debit order'

      clerk :activity => 'File application'

    end

  end



The 'get_participant()' helper will make a participant name that looks like this:



  Model-ID -> broker-2 or client-30



It pulls the information out the final hash parameter to ruote_launch_process (for

the participant maps).



=== Spec'ing launches



Use mocha to test the launches:



  describe Service, "process launches" do



    describe "when service is created" do

      client = Factory(:client)

      broker = Factory(:broker)



      service = Service.new(:type => 'Insurance', :client => client, :broker => broker)



      expects_process('service_created', { :type => 'Insurance', :number => 'I0001' }, { :client => client, :broker => broker }



      service.save

    end

  end



Using mocha expectations you can set extremely fine controls to test the presence or absence of payload and participant

parameters. The spec_helper.rb file in lib/ruote has plenty more to choose from :)



== In close



I've had to strip a lot of good stuff from the spec's so they don't expose our business

model, but I'm sure you can figure out what else is possible...