Closed zambrovski closed 3 months ago
So I envision the following configuration to be possible:
dev:
bpm-crafters:
process-api:
adapter:
c7:
embedded:
external-service-tasks:
delivery-strategy: embedded_job
worker-id: embedded-worker
lock-time-in-seconds: 10
execute-initial-pull-on-startup: true
user-tasks:
delivery-strategy: embedded_job
execute-initial-pull-on-startup: true
remote:
c7-remote-one:
external-service-tasks:
delivery-strategy: remote_scheduled
fixed-rate-schedule-rate: 10
worker-id: embedded-worker
lock-time-in-seconds: 10
user-tasks:
fixed-rate-schedule-rate: 10
delivery-strategy: remote_scheduled
c7-remote-two:
external-service-tasks:
delivery-strategy: remote_scheduled
fixed-rate-schedule-rate: 10
worker-id: embedded-worker
lock-time-in-seconds: 10
user-tasks:
fixed-rate-schedule-rate: 10
delivery-strategy: remote_scheduled
c8:
c8-one:
user-tasks:
delivery-strategy: subscription_refreshing
fixed-rate-schedule-rate: 2000 # every 2 seconds
tasklist-url: http://localhost:8082
fixed-rate-refresh-rate: 2000 # every 2 seconds
completion-strategy: job
service-tasks:
delivery-strategy: subscription
worker-id: worker
c8-other:
user-tasks:
delivery-strategy: subscription_refreshing
fixed-rate-schedule-rate: 2000 # every 2 seconds
tasklist-url: http://localhost:8082
fixed-rate-refresh-rate: 2000 # every 2 seconds
completion-strategy: job
service-tasks:
delivery-strategy: subscription
worker-id: worker
So the type
should part of the properties and there should be a named element.
Scenario
process-engine-api
adapters in runtime at the same time, in order to allow for migrations between different engines.Current Behaviour
Wanted Behaviour
Possible Workarounds