project-safari / zebra

lab resource inventory and reservation system
Apache License 2.0
6 stars 8 forks source link

Workflow for Zebra #163

Open evaachim opened 1 year ago

evaachim commented 1 year ago

Ideas for implementing a temporal workflow for Zebra.

evaachim commented 1 year ago

Temporal can begin once one of the criteria is met.

Can check if a given user exists to verify

Can check the status to verify

Based on status / requests

evaachim commented 1 year ago

Preferably, both a synchronous and an asynchronous execution will be used.

evaachim commented 1 year ago

workflow --> is the criteria met? --> Yes --> which one? --> resource requested --> execute activity --> login occurs --> execute activity

--> No --> don't execute activity

evaachim commented 1 year ago

func Workflow(ctx workflow.Context, resource zebra.Resource, store Zebra.Store) (string, error){

options := workflow.ActivityOptions{
    // some options.
}

execute ActivityLoggedIn
executeActivityRequested

}

func ActivityRequested(ctx context.Context, store zebra.Store, email string) (string, error) { if requested{ execute RequestedActivitiesInWorkflow } }

func ActivityLoggedIn(ctx context.Context, store zebra.Store, email string) (string, error) { if userLoggedIn{ execute LoginActivitiesInWorkflow } }

evaachim commented 1 year ago

Things to consider:

evaachim commented 1 year ago

Worker options to consider:

EnableSessionWorker

DeadlockDetectionTimeout

evaachim commented 1 year ago

ActivityOptions not necessarily needed

ClientOptions may be needed

evaachim commented 1 year ago

To consider making async :

  1. Send notifications

To consider including in parallel exec logic:

  1. Staying Logged in
  2. Requests coming in
evaachim commented 1 year ago

Will only use for async situations

evaachim commented 1 year ago

For notification temporal, notification code is needed and may be divided into multiple parts.

evaachim commented 1 year ago

Use temporal with wrapper functions that contain the Zebra logic.

evaachim commented 1 year ago

ActivityOptions not necessarily needed

ClientOptions may be needed

Need a time parameter, to timeout

evaachim commented 1 year ago

Currently using StartToCloseTimeout for the time parameter

evaachim commented 1 year ago

May want to consider adding an additional verification step to distinguish between activities that get triggered, especially when an activity can be subdivided into multiple activities.

evaachim commented 1 year ago

Options for including API on top of temporal

evaachim commented 1 year ago

May consider including a lock/mutex to protect critical sections.

evaachim commented 1 year ago

There can be an interface for all temporal-related functions.

evaachim commented 1 year ago

Temporal should use abstraction

evaachim commented 1 year ago

Set up black-box style logic

evaachim commented 1 year ago

The abstraction can have an initial condition and an exit condition.

evaachim commented 1 year ago

Other things that should exist in the abstraction:

evaachim commented 1 year ago

The initial condition can be one / many. Currently, it is more granular.

evaachim commented 1 year ago

If there is ONE initial condition, it could possibly be the log in. If there are more, each can work as independent conditions.

evaachim commented 1 year ago

Think: How will the exit condition be determined ?

evaachim commented 1 year ago

Some ideas:

evaachim commented 1 year ago

Ideas to consider: