You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the new SDK version, a set of decorators were introduced which simplifies the way you register activities and workflows.
Describe the solution you'd like
an updated documentation will all parameters per class and its methods, plus example which uses the new decorators,
and also, all the possible methods of DaprWorkflowContext, not only call_activity but also create_timer, call_child_workflow, wait_for_external_event, continue_as_new, when_all, when_any
the same goes for DaprWorkflowClient, not only schedule_new_workflow but also for raise_workflow_event, terminate_workflow, pause_workflow, resume_workflow.
I would also write some recommendations regarding scalability, when using workflows does it means that all activities should be in the same pod? do we call it synchronously or asynchronously? how each activity scale independently from other activities? should they be called via service invocation or pub/sub event to accomplish that or its built-in inside the workflow mechanism?
@guybartal PRs welcome. The workflow SDK is not considered stable (yet) - and the main contributors to the workflow sub-SDK are not currently actively working on the SDK.
I'm the main overall Python SDK maintainer, but I'm not the right person to provide these examples for the Workflow SDK.
What content needs to be created or modified?
In the new SDK version, a set of decorators were introduced which simplifies the way you register activities and workflows.
Describe the solution you'd like
an updated documentation will all parameters per class and its methods, plus example which uses the new decorators,
and also, all the possible methods of
DaprWorkflowContext
, not onlycall_activity
but alsocreate_timer
,call_child_workflow
,wait_for_external_event
,continue_as_new
,when_all
,when_any
the same goes for
DaprWorkflowClient
, not onlyschedule_new_workflow
but also forraise_workflow_event
,terminate_workflow
,pause_workflow
,resume_workflow
.Important note
I would also write some recommendations regarding scalability, when using workflows does it means that all activities should be in the same pod? do we call it synchronously or asynchronously? how each activity scale independently from other activities? should they be called via service invocation or pub/sub event to accomplish that or its built-in inside the workflow mechanism?
Where should the new material be placed?
here
The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos
not yet
Additional context
@yaron2 's session
The text was updated successfully, but these errors were encountered: