It's not the perfect tool, but we are striving to make it better.
Ask HN: How do you handle long-running workflows at your company?
11–20 of 84 posts
Re: Ask HN: How do you handle long-running workflows at your company?
#12Our system is based on the Camunda process engine (in a Java EE environment). There's a central process server (or cluster) running the process engine, with events to start process instances. Workflows are defined using bpmn and then executed by the engine. Errors are reported to the process engine as "Incident", which then show up in the management ui/apis. These can be retried any number of times. We also have an o…
Re: Ask HN: How do you handle long-running workflows at your company?
#13Re: Ask HN: How do you handle long-running workflows at your company?
#14Re: Ask HN: How do you handle long-running workflows at your company?
#15The whole thing can generate its own graph by inspecting dependencies, and we use dagre to draw pretty process workflows with status, interactions and monitoring.
Re: Ask HN: How do you handle long-running workflows at your company?
#16Re: Ask HN: How do you handle long-running workflows at your company?
#17Long running jobs are a rarity, so we usually spin up a new RabbitMQ cluster and services, but tie those services back to the main write/read stores. This allows regular operations to still occur, but we can monitor the bulk process and commit resources to it in a more isolated fashion.
Errors end up in error queues in Rabbit, and can be dumped back in to be reprocessed if appropriate (or just ignored if it's a side effect we don't care about).
Once it's setup and running, it works well enough. Spinning up a new rabbit cluster and service instances is currently manual, but since we've moved to Kubernetes I'm hoping this can be automated almost entirely.