Conceptual struggle around activities

Community Support
,
1

So, I’m currently experimenting with a Temporal use case that involves creating lots of different workflows (potentially thousands) and assigning each workflow a UUID. Let’s say that the workflow is called MyWorkflow and that workflow has an activity called MyActivity. Something like this boilerplate-y example:

func MyActivity(ctx context.Context) (string, error) {
        return "ok", nil
}

func MyWorkflow(ctx workflow.Context) string {
        // preparatory stuff

        var value string
        if err := workflow.ExecuteActivity(myActivityCtx, MyActivity).Get(ctx, &value); err != nil {
                // do something with the result
        }
}

I create a new instance of MyWorkflow and give it a UUID of a1b2c3. All of MyWorkflows share the same my-queue task queue. How can I trigger MyActivity on workflow a1b2c3?

I do realize that this is a very basic question! I just feel like I’m missing something conceptually here.

Is it possible that what I really need here is signals? Is that the preferred way of “reaching” specific workflows?

2

Activities are always invoked in the context of a workflow execution. You just invoke the activity using ExecuteActivity api within your workflow implementation and pass activity type (MyActivity) and input parameters. Caller passes in the WorkflowID when starting the workflow execution and then all activity invocations happens within the scope of particular execution. I highly recommend to go over core concepts sections of our documentation.

3

You can verify that an activity was invoked by a given workflow by printing out the workflowId:

func MyActivity(ctx context.Context) (string, error) {
	logger := activity.GetLogger(ctx)
	workflowId := activity.GetInfo(ctx).WorkflowExecution.ID
	logger.Info("MyActivity", "WorkflowId", workflowId)
        return "ok", nil
}
4

@samar Basically I want to have workflows tied to the internal state of a struct (this is in the Go SDK) and I want to make calls to that workflow to update that state. So in reading the docs more, it seems like maybe signals are the appropriate way to accomplish that.

5

Yes signals are good mechanism when workflows need to react to external events.