It's best to think of your workers as completely separate entities from Ruby code or your Rails app. In this sense, they need to be able to configure themselves to external services when they run. So if it has to connect to a database or use global attributes, you'll want to have the worker be able to access this configuration information as if it were running outside your application (which it is).

SimpleWorker Access Keys

SimpleWorker configuration is done in a configuration block and its simplest form looks like this:

Gem v1.X

SimpleWorker.configure do |config|
  config.access_key = ACCESS_KEY
  config.secret_key = SECRET_KEY
end

The access_key and secret_key are the only required configuration attributes, the rest is optional. (Your SimpleWorker ACCESS_KEY and SECRET_KEY can be found on each project's project page in the SimpleWorker dashboard.)

Gem v2.X

SimpleWorker.configure do |config|
  config.token = TOKEN
  config.project_id = PROJECT_ID
end

Get your config token at http://www.simpleworker.com/tokens

If you are using SimpleWorker in a Ruby on Rails application, you would add the config block above to yourdevelopment.rb and production.rb.

(We recommend you use different SimpleWorker projects for development and production. Each project has unique keys so make sure you assign them appropriately in the config blocks.)

Configuring Databases

You can set db access keys as part of an init() method of your worker class or you can include it within the config block like the keys above. See our knowledge base section on configuring databases to learn how to use your database with SimpleWorker.

Note that each worker/job is a standalone unit of work so if you run 20 concurrent workers, you'd create 20 connections to your database.

We recommend that you look to group a number of database tasks together into a single worker to better amortize the configuration time.

Setting Global Attributes

Attributes can be set in your configuration block so that they will automatically be set in all of your workers that have these attributes defined. This approach is great for taking care of attributes that all of your workers will use as well as for situations where the keys might change between environments.

As an example, if you were to include the following as part of your config block, then these values will be set in all your worker objects that have those attributes defined.

SimpleWorker.config do |config|
  ...
  config.global_attributes[:db_user] = "admin"
  config.global_attributes[:db_pass] = "notarealsecurepassword"
end

In your worker, you would simply have the attributes defined as follows:

attr_accessor :db_user, :db_pass

Now when you use these attributes in your worker, they will be set to "admin" and "notarealsecurepassword" automatically.

Changing Attributes By Environment

You can also set up global config attributes to read from a file. For example:

ACCOUNTS = YAML.load_file("#{::Rails.root}/config/accounts.yml")[Rails.env]

SimpleWorker.config do |config|
    ...
    config.global_attributes[:twilio_key] = ACCOUNTS[:twilio_key]
    config.global_attributes[:twilio_secret] = ACCOUNTS[:twilio_secret]
end

Then in your worker, just add:

attr_accessor :twilio_key, :twilio_secret

When you call queue, the global attributes will automatically be set on those attributes so you don't need to set them every time you use the worker.

Avoid Rails References in your Workers

Because workers are running separate from your application, you want to avoid using Rails environment references in your worker. If you do, you'll likely get an uninitialized constant error as the worker tries to resolve the references in the SimpleWorker cloud. (Exceptions are Rails.env and Rails.version. See below.)

By way of example, do not do the following:

class IncorrectWorker < SimpleWorker::Base
  merge "#{Rails.root}/vendor/plugins/.../somefile.rb"

  def run
   
  end
end

It may work when you run_local, but when you queue or schedule the worker, you'll get something like the following:

uninitialized constant IncorrectWorker::Rails

Accessing Rails.env and Rails.version

Exceptions to the "not referencing Rails constants in your workers" rule are Rails.env and Rails.version. These are available in your worker provided you're running within a Rails app. (Note though that your worker is still running independent of a Rails environment.)

# This is OK to do in your worker.
if Rails.env == 'development'
  do_something
elsif Rails.env == 'test'
  do_something_else
elsif Rails.env == 'production'
  do_someother_thing
end