Skip to main content

Azure Durable Functions ⇄ Pulse

Intermediate ⏱ 15 min azure · python · durable activity · 🧪 orchestration validated live

Durable Functions splits work into a deterministic, replayed orchestrator and side-effecting activities — the orchestrator can't do I/O directly, so every external call lives in an activity. Exactly the Temporal constraint: durable engines put I/O in an Activity. Repo example: examples/azure-durable-functions-pulse-bridge/.

HTTP start → order_orchestrator (durable, replayed) → yield call_activity("score_via_pulse") → decide → escalate | auto-approve

The activity does the universal two calls (POST .../x/order-scoring/in, GET .../events/order-scoring.score.out).

Run it locally — the real orchestrator generator​

pulse server start --dev
mkdir app && cp pulse.yaml app/ && (cd app && pulse deploy .)
pip install azure-functions azure-functions-durable requests
PULSE_URL=http://localhost:9090 python run_local.py

run_local.py drives the real orchestrate_order generator from function_app.py: each yield call_activity(...) executes the real activity and feeds the result back — what the Durable runtime does, minus the replay/checkpoint plumbing. So the whole orchestration is validated, not just the Pulse call:

amount= 2500  ->  decision=escalate
amount=  300  ->  decision=auto-approve

Run just the activity standalone: PULSE_URL=... python function_app.py.

Deploying to real Azure​

function_app.py (v2 model) + host.json (extension bundle v4) + requirements.txt are deploy-ready for Azure Functions. The 🧪 status: orchestration proven against live Pulse; the Azure-hosted run needs your subscription.

Next​