Repository navigation
EDC-V contract negociation execution models (Polling-based/SQL) #5946
|
Hi EDC maintainers, We are currently preparing our migration from EDC to EDC-V using the Connector repository and noticed something regarding contract negotiation task processing. In the Virtual Connector, which is also the origin of the current NATS-based implementation, contract negotiation tasks can be processed using an SQL-backed approach through TaskPollExecutor.java, rather than through the NATS subscriber implementation (NatsContractNegotiationTaskSubscriber.java). Both approaches ultimately rely on ContractNegotiationTaskExecutor.java to execute the tasks, as described in the task-based architecture documentation. Our idea is to perform a progressive migration, first migrating to EDC-V while still relying on the database-backed task execution model, and introducing NATS at a later stage. Could you let us know whether the SQL flavour using TaskPollExecutor.java (or an equivalent database polling executor) is also planned to be migrated into the Connector repository? Thanks in advance for your help. |
Replies: 1 comment 1 reply
|
using databases for this, specifically Postgres, depends on a feature called CDC and at the time we looked into this, was not stable and caused more problems than it solved. That's why we moved to a message-based mechanism, i.e. NATS. Apparently the documentation still states "you can use NATS or Postgres", which is wrong - we don't endorse PG for this anymore. The documentation needs to be fixed. Of course you are free to implement your own Postgres-based state machine, but we do not recommend it. |
using databases for this, specifically Postgres, depends on a feature called CDC and at the time we looked into this, was not stable and caused more problems than it solved.
That's why we moved to a message-based mechanism, i.e. NATS.
Apparently the documentation still states "you can use NATS or Postgres", which is wrong - we don't endorse PG for this anymore. The documentation needs to be fixed.
Of course you are free to implement your own Postgres-based state machine, but we do not recommend it.