Business process automation sounds grand. In practice, the useful examples are usually rather ordinary: copying approved data into another system, raising a purchase request, sending a renewal reminder, or moving a case to the next person. That is exactly why Ruby is a good fit. It gives me enough structure to make the workflow dependable without burying a modest problem under an elaborate platform.<\/p>\n\n\n\n
When I approach business process automation with Ruby, I do not begin with the code. I begin by asking what must still be true<\/a> when the network is slow, a worker stops halfway through, or somebody submits the same request twice. The happy path is rarely the difficult part. Trust comes from what the automation does around the edges.<\/p>\n\n\n\n In this article, I will sketch a purchase-approval workflow. The example is deliberately small, but the design applies equally well to onboarding, invoice processing, account reviews and other internal operations.<\/p>\n\n\n\n Before I create a class, I write down six things: the trigger, the input, the decision, the action, the exception path and the evidence left behind. If one of those is vague, the process is not ready to automate.<\/p>\n\n\n\n I am wary of workflows that mix all six concerns in a controller or one long background job. They may work on Tuesday morning and become impossible to reason about when something fails on Friday evening. I prefer a small policy object for the business decision and separate code for transport, persistence and reporting.<\/p>\n\n\n\n A routing rule should read like a rule. Here is a deliberately simple version:<\/p>\n\n\n\n The numbers are examples, not universal recommendations. What matters is that the rule is explicit, testable and independent of the HTTP client or queue. A reviewer can understand it without following a trail through callbacks.<\/p>\n\n\n\n I would also validate the request before it reaches this object. Missing currency, a negative amount or an unknown supplier should not become a mysterious queue failure. Reject bad input at the boundary and explain what the user can correct.<\/p>\n\n\n\n Calling another system can take seconds, and sometimes it does not return at all. In a Rails application I normally move that work into Active Job. The current Rails guide to Active Job<\/a> covers queueing, recurring tasks, concurrency controls, error reporting and retry behaviour. Rails 8 uses the database-backed Solid Queue as its default production backend, although Active Job can sit over other queue adapters.<\/p>\n\n\n\n Retries need judgement. A timeout is often worth retrying; invalid input usually is not. I set a finite attempt count, allow delays to grow and make terminal failures visible to an operator. Retrying forever is not resilience. It is a way of hiding a broken process.<\/p>\n\n\n\n I also enqueue only after the request has been committed to the database. Otherwise a fast worker may try to load a row that the web transaction has not finished creating.<\/p>\n\n\n\n This is the rule I would most want a team to remember: background work can be delivered more than once. A worker can complete the remote request and die before saving the response locally. Another worker then sees an unfinished record and tries again.<\/p>\n\n\n\n The local guard in the job helps, but it does not close that gap. If the receiving API supports idempotency keys, I send a stable key derived from the local record:<\/p>\n\n\n\n The remote system should return the original result when it sees that key again rather than creating a second approval. If an API offers no such feature, I look for another stable deduplication mechanism. Hope is not a duplicate-prevention strategy.<\/p>\n\n\n\n The standard library is quite capable of this kind of integration. The Net::HTTP documentation<\/a> is worth reading before adding another dependency simply to make one request. For a larger client, I would add typed errors, response validation, authentication and tests around every status the remote service promises.<\/p>\n\n\n\n Governance is often treated as paperwork added after an automation has been built. I think it belongs in the model from the beginning. The code should make it possible to answer who initiated an action, which rule ran, what data crossed the system boundary, whether a person approved it and how the decision can be reversed.<\/p>\n\n\n\n Whether the work is internal or supported by a specialist, I would insist on a few practical controls:<\/p>\n\n\n\n A human checkpoint should be a real state in the workflow, not an email sent into the void. I like statuses such as A log line saying \u201cjob completed\u201d tells me almost nothing. I want a run identifier, the record involved, the route selected, the duration and the outcome. I do not want access tokens, full request bodies or personal data copied into logs for convenience.<\/p>\n\n\n\n Rails applications can use Active Support instrumentation to publish and subscribe to workflow events:<\/p>\n\n\n\n Metrics should answer operational questions. How many requests are waiting? How old is the oldest one? Which route fails most often? What percentage still needs manual correction? A dashboard full of queue internals can be technically impressive while saying very little about whether the business process works.<\/p>\n\n\n\n I start with the policy because it is cheap to test and expensive to misunderstand:<\/p>\n\n\n\n Then I test the less comfortable scenarios: the same job runs twice, the API times out after accepting the request, the response omits an expected field, the local record is deleted, and an operator pauses the process. Those tests describe the real contract of the automation far better than another demonstration of the happy path.<\/p>\n\n\n\nStart by drawing the boundary<\/h2>\n\n\n\n
\n
Keep business rules visible<\/h2>\n\n\n\n
class ApprovalPolicy\n def route_for(amount_cents:, regulated_supplier:)\n return :compliance_review if regulated_supplier\n return :director_review if amount_cents >= 500_000\n return :manager_review if amount_cents >= 100_000\n\n :automatic_approval\n end\nend\n<\/code><\/pre>\n\n\n\nMove slow work out of the request<\/h2>\n\n\n\n
class ProcessPurchaseRequestJob < ApplicationJob\n queue_as :operations\n\n retry_on Net::OpenTimeout,\n Net::ReadTimeout,\n wait: :polynomially_longer,\n attempts: 5\n\n discard_on ActiveJob::DeserializationError\n\n def perform(purchase_request_id)\n purchase_request = PurchaseRequest.find(purchase_request_id)\n return if purchase_request.approval_submitted_at?\n\n response = ApprovalGateway.new.submit(purchase_request)\n\n purchase_request.with_lock do\n return if purchase_request.approval_submitted_at?\n\n purchase_request.update!(\n external_approval_id: response.fetch(\"id\"),\n approval_submitted_at: Time.current\n )\n\n AuditEvent.create!(\n subject: purchase_request,\n action: \"approval_submitted\",\n details: { external_id: response.fetch(\"id\") }\n )\n end\n end\nend\n<\/code><\/pre>\n\n\n\nAssume every job can run twice<\/h2>\n\n\n\n
require \"json\"\nrequire \"net\/http\"\n\nclass ApprovalGateway\n ENDPOINT = URI(\"https:\/\/api.example.test\/v1\/approval_requests\")\n\n def submit(purchase_request)\n request = Net::HTTP::Post.new(ENDPOINT)\n request[\"Content-Type\"] = \"application\/json\"\n request[\"Idempotency-Key\"] =\n \"purchase-request:#{purchase_request.id}\"\n\n request.body = JSON.generate(\n supplier: purchase_request.supplier_name,\n amount_cents: purchase_request.amount_cents,\n currency: purchase_request.currency\n )\n\n http = Net::HTTP.new(ENDPOINT.host, ENDPOINT.port)\n http.use_ssl = true\n http.open_timeout = 2\n http.read_timeout = 5\n\n response = http.request(request)\n raise \"Approval API returned #{response.code}\" unless response.is_a?(Net::HTTPSuccess)\n\n JSON.parse(response.body)\n end\nend\n<\/code><\/pre>\n\n\n\nGovernance belongs in the workflow<\/h2>\n\n\n\n
\n
awaiting_manager_review<\/code> and awaiting_compliance_review<\/code> because they can be queried, measured and shown in an interface. That makes unfinished work visible.<\/p>\n\n\n\nLog decisions, not secrets<\/h2>\n\n\n\n
ActiveSupport::Notifications.instrument(\n \"approval_request.automation\",\n purchase_request_id: purchase_request.id,\n route: route\n) do\n ApprovalGateway.new.submit(purchase_request)\nend\n<\/code><\/pre>\n\n\n\nTest the rule and the awkward cases<\/h2>\n\n\n\n
require \"test_helper\"\n\nclass ApprovalPolicyTest < ActiveSupport::TestCase\n test \"routes a regulated supplier to compliance\" do\n route = ApprovalPolicy.new.route_for(\n amount_cents: 25_000,\n regulated_supplier: true\n )\n\n assert_equal :compliance_review, route\n end\n\n test \"routes a large request to a director\" do\n route = ApprovalPolicy.new.route_for(\n amount_cents: 600_000,\n regulated_supplier: false\n )\n\n assert_equal :director_review, route\n end\nend\n<\/code><\/pre>\n\n\n\n