iwf

iWF project - main & server repo

iWF is a platform providing an all-in-one tooling for building long-running business application. It provides an abstraction for persistence(database, elasticSearch) and more! It aims to provide clean, simple and easy to use interface, like an iPhone.

It will not make you a 10x developer...but you may feel like one!

We call long running application Workflow.

It's a simple and powerful WorkflowAsCode general purpose workflow engine.

The server is back by Cadence/Temporal as an interpreter.

Related projects:

• API definition between SDKs and server. Any languages can be supported as long as implementing it.
• iWF Java SDK
• iWF Java Samples
• iWF Golang SDK, WIP, Contribution is welcome.
• More SDKs? Contribution is welcome.

Community & Help

• Github Discussion
  • Best for Q&A, support/help, general discusion, and annoucement
• StackOverflow
  • Best for Q&A and general discusion
• Github Issues
  • Best for reporting bugs and feature requests
• For any questions & consultant email to: qlong.seattle@gmail.com

Table of contents

• Why you would need iWF
  • If you are familar with Cadence/Temporal
  • If you are not
• What is iWF
  • Basic Concepts & Usage
  • Advanced Concepts & Usage
• How to run this server
  • Using docker image & docker-compose
  • How to build & run locally
  • How to use in production
• Development
  • Development Plan
• Some history

Why you would need iWF

If you are familar with Cadence/Temporal

• See Slide deck for what problems it is solving
• See Design doc for how it works

If you are not

• Check out this doc to understand some history

iWF is an application platform that provides you a comprehensive tooling:

• WorkflowAsCode for highly flexibile/customizable business logic
• Parallel execution of multiple threads of business
• Persistence storage for intermediate states stored as "dataObjects"
• Persistence searchable attributes that can be used for flexible searching, even full text searching, backed by ElasticSearch
• Receiving data from external system by Signal
• Durable timer, and cron job scheduling
• Reset workflow to let you recover the workflows from bad states easily
• Highly testable and easy to maintain
• ...

What is iWF

Basic Concepts & Usage

iWF lets you build long-running applications by implementing the workflow interface, e.g. Java Workflow interface.

The key elements of a workflow are WorkflowState. A workflow can contain any number of WorkflowStates.

A WorkflowState is implemented with two APIs: start and decide. start API is invoked immediately when a WorkflowState is started. It will return some Commands to server. When the requested Commands are completed, decide API will be triggered.

These are the two basic command types:

• SignalCommand: will be waiting for a signal from external to the workflow signal channel. External application can use SignalWorkflow API to signal a workflow.
• TimerCommand: will be waiting for a durable timer to fire.

Note that start API can return multiple commands, and choose different DeciderTriggerType for triggering decide API:

• AllCommandCompleted: this will wait for all command completed
• AnyCommandCompleted: this will wait for any command completed

iWF provides the below persistence APIs when implementing the WorkflowState:

• DataObject is for
  • sharing some data values across the workflow
  • can be retrieved by external application using GetDataObjects API
  • can be viewed in Cadence/Temporal WebUI in QueryHandler tab
• SearchAttribute is similarly:
  • sharing some data values across the workflow
  • can be retrieved by external application using GetSearchAttributes API
  • search for workflows by external application using SearchWorkflow API
  • search for workflows in Cadence/Temporal WebUI in Advanced tab
  • search attribute type must be registered in Cadence/Temporal server before using for searching because it is backed up ElasticSearch
  • the data types supported are limited as server has to understand the value for indexing
  • See Temporal doc and Cadence doc to understand more about SearchAttribute
• StateLocal is for
  • passing some data values from state API to decide API in the same WorkflowState execution
  • recording some events that can be useful for debugging using Workflow history. Usually you may want to record the input/output of the dependency RPC calls.

Advanced Concepts & Usage

On top of the above basic concepts, you may want to deeply customize your workflow by using the below features.

More advanced command types

• InterStateChannelCommand: will be waiting for a value being published from another state(internally in the same workflow)
• [Future] LongRunninngActivityCommand: will schedule a long-running activity like hours/days with capability to recover from previous states

How to run this server

Using docker image & docker-compose

Checkout this repo, go to the docker-compose folder and run it:

cd docker-compose && docker-compose up

This by default will run Temporal server with it. And it will also register a default namespace and required search attributes by iWF. Link to WebUI: http://localhost:8233/namespaces/default/workflows

By default, iWF server is serving port 8801, server URL is http://localhost:8801/ )

How to build & run locally

• Run make bins to build the binary iwf-server
• Then run ./iwf-server start to run the service . This defaults to serve workflows APIs with Temporal interpreter implementation. It requires to have local Temporal setup. See Run with local Temporal.
• Alternatively, run ./iwf-server --config config/development_cadence.yaml start to run with local Cadence. See below instructions for setting up local Cadence.
• Run make integTests to run all integration tests. This by default requires to have both local Cadence and Temporal to be set up.

How to use in production

Option 1: use as library to customize your startup

Particularly, use the api and interpreter that are exposed as the api service and workflow service.

Development

Any contribution is welcome.

How to update IDL and the generated code

1. Install openapi-generator using Homebrew if you haven't. See more documentation
2. Check out the idl submodule by running the command: git submodule update --init --recursive
3. Run the command git submodule update --remote --merge to update IDL to the latest commit
4. Run make idl-code-gen to refresh the generated code

Run with local Temporalite

1. Run a local Temporalite following the instruction. If you see error error setting up schema, try use command temporalite start --namespace default -f my_test.db instead to start.
2. Register a default namespace

tctl --ns default n re

1. Go to http://localhost:8233/ for Temporal WebUI

NOTE: alternatively, go to Temporal-dockercompose to run with docker

1. Register system search attributes required by iWF server

tctl adm cl asa -n IwfWorkflowType -t Keyword
tctl adm cl asa -n IwfGlobalWorkflowVersion -t Int
tctl adm cl asa -n IwfExecutingStateIds -t Keyword

4 For attribute_test.go integTests, you need to register search attributes:

tctl adm cl asa -n CustomKeywordField -t Keyword
tctl adm cl asa -n CustomIntField -t Int

Run with local Cadence

1. Run a local Cadence server following the instructions

docker-compose -f docker-compose-es-v7.yml up

1. Register a new domain if not haven cadence --do default domain register
2. Register system search attributes required by iWF server

cadence adm cl asa --search_attr_key IwfGlobalWorkflowVersion --search_attr_type 2
cadence adm cl asa --search_attr_key IwfExecutingStateIds --search_attr_type 0
cadence adm cl asa --search_attr_key IwfWorkflowType --search_attr_type 0

1. Go to Cadence http://localhost:8088/domains/default/workflows?range=last-30-days

Development Plan

1.0

• Start workflow API
• Executing start/decide APIs and completing workflow
• Parallel execution of multiple states
• Timer command
• Signal command
• SearchAttributeRW
• DataObjectRW
• StateLocal
• Signal workflow API
• Query workflow API
• Get workflow API
• Search workflow API
• Cancel workflow API

1.1

• Reset workflow API (Cadence only, TODO for Temporal)
• Command type(s) for inter-state communications (e.g. internal channel)
• AnyCommandCompleted Decider trigger type
• More workflow start options: IdReusePolicy, initial search attributes/memo, cron schedule, retry, etc
• StateOption: Start/Decide API timeout and retry
• Reset workflow by stateId

1.2

• Decider trigger type: AnyCommandClosed
• WaitForMoreResults in StateDecision
• Skip timer API for testing/operation
• LongRunningActivityCommand
• Failing workflow details
• Auto ContinueAsNew
• StateOption: more PersistenceLoadingPolicy
• StateOption: more CommandCarryOverPolicy

Some history

AWS published SWF in 2012 and then moved to Step Functions in 2016 because they found it’s too hard to support SWF. Cadence & Temporal continued the idea of SWF and became much more powerful. However, AWS is right that the programming of SWF/Cadence/Temporal is hard to adopt because of leaking too many internals. Inspired by Step Function, iWF is created to provide equivalent power of Cadence/Temporal, but hiding all the internal details and provide clean and simple API to use.