A briefly introduction to Cameron
Upcoming SlideShare
Loading in...5
×
 

A briefly introduction to Cameron

on

  • 4,085 views

Cameron is an asynchronous, parallel, and REST-like workflow engine....

Cameron is an asynchronous, parallel, and REST-like workflow engine.

To achieve that objective, as you will can see, Cameron has been built as an Erlang/OTP application with a REST-like Web API, powered by Misultin, and a Redis-based backend database.

Take a look!

Statistics

Views

Total Views
4,085
Views on SlideShare
1,404
Embed Views
2,681

Actions

Likes
0
Downloads
3
Comments
0

5 Embeds 2,681

http://leandrosilva.com.br 2528
http://www.locawebers.com.br 146
http://www.linkedin.com 3
http://locawebianos.com.br 2
http://translate.googleusercontent.com 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

A briefly introduction to Cameron Presentation Transcript

  • 1. cameronWorkflow Enginehttps://github.com/leandrosilva/cameron Leandro Silva | @codezone 2011
  • 2. What is it?
  • 3. can cascade other is the concrete receives and task is an instance of activity implementation web service json responds of anexecutes in parallel, pipelining output, has one or many is endpoint to a one or many configuration job is an instance of process always has a start url is defines in files has one is built on workflow can run many cameron erlang/otp top of stores data thru logs thru provides web api thru redis is a driver to redo erlang_syslog misultin
  • 4. Process Tree
  • 5. cameron cameron_sup cameron_redo cameron_process_sup cameron_web_server cameron_syslogcameron_process_catalog cameron_job_data cameron_job_scheduler cameron_job_runner spawn_link N Being more handle_task/2 specific... Actually, it spawns many instances of gen_server cameron_job_runner registered as cameron_{uuid}
  • 6. Walking from request to getting things done...
  • 7. repeats thru the step 2.1., passing current task result as payload It means, actually, spawn a new yes cameron_job_runner, supervised by cameron_process_sup 2.1. spawns a has next activities? task handler cameron_job_runner handle_task/2 no 2. runs scheduled job 2.2. POST http://foo.i1/v0.0.1/start x. GET http://cameron.i1/api/foo/key/007/job/a93f89 {"key":"007", "data":"blah", "requestor":"bob"} ← responds 200 and a JSON with the job results ← should respond 200 when sucess 1. POST http://cameron.i1/api/foo/start {"key":"007", "data":"blah", "requestor":"bob"} ← responds 201 and the location 2.3. saves task result url to get job status and results (being sucess or error) requestor cameron instance 1 foo instance 1 1.1. saves the request and schedules a job to run 2.3. saves final results, job is done! redisWhich workflow?Before make a request to a given process workflow, we need to setup it atconfig/process/{environment}.configIn this case: {process, [{foo, {start_activity_url, "http://foo.i1/v0.0.1/start"}}]}.
  • 8. Work in Progress stay tuned...