Как создать собственные определения рабочего процесса?

временной Рабочие процессы — это код, непосредственно реализующий вашу бизнес-логику.

Для случаев использования, когда жесткое кодирование бизнес-логики в коде невозможно, следует написать интерпретатор внешнего языка определения рабочего процесса. Такой язык часто называют DSL, поскольку они действительно полезны при реализации для конкретной области. DSL часто основаны на YAML/Json/XML. Иногда это просто данные в таблицах БД.

Вот как я бы структурировал код рабочего процесса для поддержки пользовательского DSL:

1. Действие, которое получает идентификатор и состояние текущего определения рабочего процесса и возвращает список операций для выполнения. Это действие применяет текущее состояние (которое включает результаты самых последних выполненных операций) к соответствующему экземпляру DSL. Результатом является набор следующих операций для выполнения. Операции специфичны для DSL, но наиболее распространенными являются выполнение действия, ожидание определенного сигнала, сон в течение некоторого времени, завершение или сбой рабочего процесса.
2. Рабочий процесс, который реализует цикл, вызывающий указанное выше действие и выполняющий запрошенные операции до тех пор, пока не будет запрошена операция завершения рабочего процесса.

Вот пример кода для тривиального DSL, который определяет последовательность выполняемых действий:

@ActivityInterface
public interface Interpreter {
  String getNextStep(String workflowType, String lastActivity);
}

public class SequenceInterpreter implements Interpreter {

  // dslWorkflowType->(activityType->nextActivity)
  private final Map<String, Map<String, String>> definitions;

  public SequenceInterpreter(Map<String, Map<String, String>> definitions) {
    this.definitions = definitions;
  }

  @Override
  public String getNextStep(String workflowType, String lastActivity) {
    Map<String, String> stateTransitions = definitions.get(workflowType);
    return stateTransitions.get(lastActivity);
  }
}

@WorkflowInterface    
public interface InterpreterWorkflow {
  @WorkflowMethod
  String execute(String type, String input);
  @QueryMethod
  String getCurrentActivity();
}

public class InterpreterWorkflowImpl implements InterpreterWorkflow {

  private final Interpreter interpreter = Workflow.newActivityStub(Interpreter.class);

  private final ActivityStub activities =
      Workflow.newUntypedActivityStub(
          new ActivityOptions.Builder().setScheduleToCloseTimeout(Duration.ofMinutes(10)).build());

  private String currentActivity = "init";
  private String lastActivityResult;

  @Override
  public String execute(String workflowType, String input) {
    do {
      currentActivity = interpreter.getNextStep(workflowType, currentActivity);
      lastActivityResult = activities.execute(currentActivity, String.class, lastActivityResult);
    } while (currentActivity != null);
    return lastActivityResult;
  }

  @Override
  public String getCurrentActivity() {
    return currentActivity;
  }
}

Очевидно, что в реальной жизни интерпретатор будет получать более сложный объект состояния в качестве параметра и возвращать структуру, которая потенциально может содержать список нескольких типов команд.