Our latest release just went live and it represents a big step for our customers toward building workflows that integrate services and provide an orchestration layer for web applications.
We've made it easier to use Zenaton workflows to integrate with both SAAS services and internal web applications - regardless of the programming language. And, it is no longer required to install an agent or SDK within an applications to launch or interact with workflows - like sending events.
Read the full release notes.
Your Zenaton project
Workflows are now written in their own project and interact with any web applications using the [new] Zenaton API or http/API calls inside workflow tasks. This allows your Zenaton project to have its own - faster and independent - deployment cycle and flexible hosting options so that it does not need to be hosted in the same place as your applications - way more on that below!
Interact with workflows from any web app:
You can now launch workflows, send events or manage workflow execution from any ANY web application using the shiny new Zenaton GraphQL API. This allows you to integrate triggers or actions in any application regardless of programming language or where it is hosted!
Easier integrations with third party APIs and internal applications:
You can now call and interact with any API inside workflow tasks using the third party SDK (if its included in your Zenaton project) or an Axios client or other...This allows you to trigger actions within your own applications by calling an http endpoint - all within a workflow task. This provides a more granular level of control over API calls and interactions with internal systems since workflow tasks include automatic and manual retries and monitoring.
New workflow helpers for Node.js SDK
We've added workflow helpers that can be used inside workflows to manage the logic and workflow execution. These actions used to be included as tasks but by adding them to the workflow syntax, there is less code to write, they are more readable and easy to follow and reduce the risk of errors.
- terminate the current workflow or another one
- send an event to the current workflow or another one
- pause or resume the current workflow
- get current date, get random value, and use console.log
Workflows in Node.js only
We have started the transition for workflows to be written only in node.js using our Node.js SDK and interact with applications in other languages via our SDKs (coming soon) and http clients.
Orchestration and Integration
We've made some major changes to how workflows are managed and hosted in order to align their usage with the value of connecting services and providing an orchestration layer for your application and processes that span applications in multiple programming languages.
A few examples of things that just got easier:
- Workflows that receive events from multiple applications that are written in different languages (ie. micro-services architecture) .
- Workflows with intensive data processes that require auto-scaling - those tasks can now be managed entirely on your own infrastructure and tooling.
- Any workflow that triggers actions in third party APIs which offer an SDK (slack, sendgrid, twilio, etc) when a sequence of events happens within your applications.
Recommendations and Guidelines
As workflows will now be written and hosted within their own project, we are also introducing a new way to modularize tasks and workflow logic.
Workflow Tasks: By introducing the ability to process actions within your own application via HTTP endpoints you can now write a workflow task to make a request to these endpoints and leave the processing within your application.
This provides the benefit of separating the control logic from the actions and allows you to keeping the business logic inside your own applications and just trigger it from a Zenaton workflow.
This also provides flexibility to manage the processing within your own infrastructure and tools to easily scale the load coming from your Zenaton workflows, as with any other HTTP traffic.
[Workflow tasks that manage 3rd party service interactions provide the same level of control. You can write Zenaton tasks calling the HTTP APIs of your 3rd party services, or use any official or community-written NodeJS SDK for the 3rd party services you want to use.]
Hosting and Deployment
- Workflows are now written inside your Zenaton project where the agent will be installed and any other dependencies (third party SDKs, etc) .
- Your Zenaton project can be hosted independently (ie. Heroku or Clever Cloud) or on the same servers/hosting solution as your application.
- We recommend to separate workflows and tasks from your main application code, even if it is also using NodeJS.
By moving workflows outside of your applications, it will allow faster iterations and deployments if it is decoupled from your main codebase. It allows it to be deployed independently and reduce the overall friction of writing new workflows or updating existing ones.
In order to create a Zenaton project there are just a few steps:
- Create a new Node.js project
- Install the Node SDK
- Write or add your workflows
- Deploy ( see guidelines below)
We have two recommendations regarding hosting:
- Heroku (or CleverCloud)
Simple, fast and easy: We recommend using Heroku or CleverCloud. They have very good support and they provide the easiest deployment experience.
We will gradually add "Deploy to Heroku" buttons on all of our content, allowing new users to fork, deploy and discover the Zenaton platform quicker than ever, and allowing existing users to run sample workflows and example projects in a few seconds.
Deploying to Heroku can be done in a very few steps:
- Create a new application
- Add our buildpack, which will install the Zenaton Agent for you
- Add a zenaton dyno in your Procfile
- Start running your workflow
Heroku provides two different ways to do these steps. You can either do this using the user interface on heroku.com, or you can use their CLI to run a few commands to set everything up.
- Your application hosting solution
If you are calling a lot of http endpoints within your application and would require an authentication layer in your app you can choose to deploy your Zenaton project n the same servers / in the same infrastructure as your applications which wouldn't require this because of networking based restrictions