Is your feature request related to a problem? Please describe.

I am currently using the Zeebe.Client.Accelerator package for my C# project,. The package automatically deserializes the TInput object into an array of fetch variables. However, I've encountered an issue with variable naming conventions. While the official camunda documentation allows the usage of camelCase, PascalCase, and snake_case for variable names, the Zeebe.Client.Accelerator package only supports camelCase. This limitation is causing problems in our integration with camunda, as we need the flexibility to use custom variable names that may not follow the camelCase convention.

Describe the solution you'd like

To address this limitation and enhance the package's functionality, I propose the implementation of a new custom attribute in C#. The custom attribute should be used to decorate C# properties and provide the necessary metadata for mapping these properties to the desired Zeebe variable names. With this attribute, users can specify the exact variable names they want to use, regardless of the variable naming convention.

Expected Behavior:

The package should support custom attribute mapping for properties to allow users to define custom variable names when deserializing TInput into the array of fetch variables. This custom attribute should enable us to map C# property names to custom Zeebe variable names in a straightforward manner.

Example Usage:

public class MyWorkflowInput
{
    [ZeebeVariableName("OrderId")] // Using the custom attribute to map to Zeebe variable "OrderId"		
    public string OrderId { get; set; }

    [ZeebeVariableName("ItemList")] // Using the custom attribute to map to Zeebe variable "ItemList"
    public List<string> ItemList { get; set; }

    // Additional properties and their mappings as needed...
}

Addional context

existing mapping to fetchVariables: JobHandlerInfoProvider.GetFetchVariablesFromJobState(Type jobType) - Line: 171

Hi everyone,

I'm trying to use abstract class on top on all my IAsyncZeebeWorkers classes (derivative classes). I faced that BootstrapZeebe scan in assemblies and try to register using DeclaringType instead of ReflectedType.

If ReflectedType is used in AddZeebeJobHandlers method (ServiceCollectionExtensions) and in HandleJob (ZeebeJobHandler.cs) all goes fine.

Thanks.

Hi @arjangeertsema. I'm developing a POC with camunda platform and found your fork very useful for simplifying the overall experience configuring the Zeebe client, thanks for that. I'm trying to replicate the first implementation of my POC using your library but I noticed the lack of the .HandlerThreads() implementation when creating the JobWorker, which handles how many threads could be used by the worker, any particular reason for not including it? Thanks.

Problem

Right now the zb-client-sharp AccessTokenSupplier is quite simple http client that fetches tokens and caches it to file. With high load and multithreaded usage its not performing well and is causing file locks and due to that errors in logs.

Solution

With zb-client-sharp there is possibility to provide custom token supplier in the client builder. The builder has to implement IAccessTokenSupplier interface which is included in the zb-client-sharp.

Idea is in the accelerator setup to check if there is a service implementing IAccessTokenSupplier registered in DI and if its there, it will be provided to the zb-client builder.
Possible fix is done in the PR: #31

Describe alternatives you've considered

Alternate solution would be to update zb-client-sharp token supplier code - it would need more advanced token provider. But as there are already decent libraries that have those so no reason to build it in there. (ie Duende.AccessTokenManagement

Additional context

Explanation how to use custom provider is also under the zb-client-sharp discussions: camunda-community-hub/zeebe-client-csharp#666

Since ZbClient 2.2 now is multiple targeted, maybe we should upgrade to 2.2, so this can also support net6 and net7.

Describe the bug

The Zeebe Resource Deployer does not use the same logger as the rest of the code as observed here:

I believe this is because its using its own create logger instead of inputting the default one through the constructor

To Reproduce

Steps to reproduce the behavior:

1. Replace the default logger with a different logger like Serilog
2. Run a deployment of resources with other logs
3. Observe different formatting of logs

Expected behavior

The logs for resource deployer follow the same format as the rest of the logging

Enviroment (please complete the following information):

• OS: Windows
• Version 1.0.2

Additional context

Add any other context about the problem here.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update actions/setup-dotnet action to v4.0.1

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dotnet monorepo to v8 (major) (Microsoft.Extensions.Configuration.Abstractions, Microsoft.Extensions.Hosting, Microsoft.Extensions.Options.ConfigurationExtensions)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Problem : I want to subscribe to usertasks to push them through websockets to the front-end without waiting for tasklist to be populated. I'd like a worker without autocomplete

Solution : A worker that is Void and not completing the job.

Alternative : sending an exception... but that's ugly :)

Thanks in advance for any feedback (perhaps I missed something)

When creating a abstract class for Zeebe worker class, so that the abstract class inherits from IAsyncZeebeWorker<TInput> or IAsyncZeebeWorker<TInput, TResponse> interfaces then dependency injection exception is thrown because abstract class is detected as Zeebe worker and instance instantiation fails.

Exception

System.ArgumentException: Cannot instantiate implementation type '...BaseAsyncWorker`1[TInput]' for service type '...BaseAsyncWorker`1[TInput]'.
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.Populate()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(ICollection`1 serviceDescriptors, ServiceProviderOptions options)
   at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(IServiceCollection services, ServiceProviderOptions options)
   at Microsoft.Extensions.Hosting.HostApplicationBuilder.Build()
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
  at Program.<Main>$(String[] args) in Program.cs:line NN

Example of the abstract class

public abstract class BaseAsyncWorker<TInput>, IAsyncZeebeWorker<TInput>
    where TInput : BaseVariables, new()
{
    protected abstract Task HandleJob(TInput variables, CancellationToken cancellationToken);

    public async Task HandleJob(ZeebeJob<TInput> job, CancellationToken cancellationToken)
    {
        var variables = job.getVariables();

        Exception? exception = null;
        try
        {
            await HandleJob(variables, cancellationToken);
            OnSuccess(variables);
        }
        catch (Exception e)
        {
            exception = e;
            OnError(variables, e);
            throw;
        }
        finally
        {
            await StoreStateForJob(job, exception, cancellationToken);
        }
    }
    // Base class methods omitted for brevity
}

Example of the worker class inheriting from the abstract class BaseAsyncWorker

public class StartSomethingAsyncWorker : BaseAsyncWorker<MyJobVariables>
{
    protected override Task HandleJob(MyJobVariables variables, CancellationToken cancellationToken)
    {
        return apiClient.DoSomethingAsync(variables.MyUniqueId, cancellationToken);
    }
}

Solution

Solution would be to detect if the type is abstract class JobHandlerInfoProvider and not to register the class as worker in ZeebeHostedService method Task StartAsync(CancellationToken cancellationToken).

Proposed change in JobHandlerInfoProvider

private static bool IsZeebeWorker(Type t)
{
    if (t.IsAbstract) return false;
    
    var interfaces = t.GetInterfaces();
    return
        interfaces.Contains(typeof(IZeebeWorker)) ||
        interfaces.Contains(typeof(IAsyncZeebeWorker))
        || interfaces.Any(i => i.IsGenericType && GENERIC_HANDLER_TYPES.Contains(i.GetGenericTypeDefinition()));
}

See the bool IsZeebeWorker(Type t) method

Also

Describe the bug

The command NewCreateProcessInstanceCommand() only gets sent to the local Zeebe docker via ZeebeClient successfully for once after the example web application is up and running and then it goes down for the subsequent requests without any errors.

To Reproduce

Steps to reproduce the behavior:

1. Spin up the example web application
2. Go to the Swagger UI provided by the example
3. Submit an application
4. Check the process instance in Operator. A new instance is created.
5. Go to Swagger UI and submit another application
6. Check the process instance in Operator. The number of the instance remains the same.

Expected behavior

A new process instance should be created whenever a new application is submitted via ZeebeClient.

Enviroment (please complete the following information):

• OS: Windows
• Version: 11
• Zeebe: 8.2.11 (running in Docker Desktop)