How to handle Human Tasks in Zeebe workflow execution?

shashi_chavan · May 5, 2019, 4:43pm

Hi,

How do we need to handle Human tasks in zeebe workflow ?
In camunda bom we have Human Task | docs.camunda.org
Is there anything like this in zeebe or do we have to handle this via service task using pub/sub mechanism.

Thanks
Shashi Chavan

Philipp_Ossler · May 6, 2019, 5:11am

Hi @shashi,

currently, Zeebe doesn’t support user tasks - only service task. However, there is community project which might be useful: https://github.com/zeebe-io/zeebe-simple-tasklist

Best regards,
Philipp

asaf · March 16, 2020, 6:07pm

@philipp.ossler I wonder if creating a long timeout is a mis conception / not recommended.

if a client doesn’t flags the job as completed / failed it seems like every 5 minutes the job gets free for a new polling, so a client gets the job over and over again,

This code sets 365 days for a timeout:

github.com

zeebe-io/zeebe-simple-tasklist/blob/a3e4575beda4407828f007d577f075d2821c70b1/src/main/java/io/zeebe/tasklist/ZeebeClientService.java#L40


  public void connect(String connectionString) {


    client =
        ZeebeClient.newClientBuilder().brokerContactPoint(connectionString).usePlaintext().build();


    getClient()
        .newWorker()
        .jobType("user")
        .handler(jobHandler)
        .name("zeebe-simple-tasklist")
        .timeout(Duration.ofDays(365))
        .open();
  }


  public ZeebeClient getClient() {
    return client;
  }
}

Is it a recommended / fair behaviour ?

Thanks,

Asaf

Philipp_Ossler · March 16, 2020, 7:39pm

Exactly. If the timeout is not set then the job would be fetched after the default timeout of 5 minutes. The tasklist worker sets the high timeout to avoid that the job is fetched again. It assumes that it is the only worker that processes this job.

Why do you think that this is a misconception or not recommended?

asaf · March 16, 2020, 8:25pm

It’s more a question than a saying

It depends on implementation details, I was wondering whether Zeebe is designed to have clients set very long term timeouts such as years or timeouts suites more for very small durations. (usually “timeout” implies short term durations)

The other alternative would be to use event + message correlation, not sure what’s best or recommended,

Thanks.

jwulf · March 18, 2020, 5:44am

You would not want to set years timeouts, because then you couldn’t upgrade, and currently there is a release per quarter at least.

asaf · March 18, 2020, 7:07am

there is no way to upgrade broker if flow instances are opened ? or this constraint is specifically with tasks having long timeouts ? I mean – if I replace tasks with “wait for approval” message catch event / receive task, will it better or the same regarding upgrades?

Thanks

system · January 31, 2024, 10:11am