Best way to stucture a fetch order process

I have the idea to poll a Shop API for new orders. Every new order should be transfered to a ERP system.
What’s the best way to structure that process?

Should everything covered in one workflow with several activities?
Or is there a way to have a workflow to fetch the orders and a second workflow to transfer them to the ERP system (maybe a child-workflow)?

Can the event system be used to start a second workflow for every new order?

I assume that you don’t have control over Shop API and polling is the only option.

I’m not sure how complex the transfer process itself. Let’s say it requires a workflow per order to manage.

Then I would have a polling worklflow that runs an activity that periodically polls the Shop API. This activity can run an infinite polling loop and heartbeat back to Temporal to prove that it is still alive. If the heartbeat stops the activity will be retried on a different worker automatically. Hearbeat can include some additional data if needed. The data from the last successful heartbeat is available to the activity when it is retried.

When activity finds a new order it would start a new workflow with OrderId as WorkflowId. As workflow id is guaranteed to be unique by Temporal it would ensure that only one such workflow per order is started.

One additional question…

Should the startet workflow in the polling activity be a “Child Workflow” or a new workflow generated by the client like in a starter?

An activity cannot start a child workflow directly, it would need to return, and then its workflow would start a child. When the number of children is bounded and there is a need to track their completion it could make sense. But in your case, the polling workflow is expected to start an unbounded number of transfer order workflows and doesn’t really need to perform any action on their completion. So I would recommend starting them from activity directly using workflow client.

4 Likes