Skip to content

Transaction and Workflows

This section explains how to manage transactions and workflows using the EuroDaT APIs. All the following actions can be started via the EuroDaT Swagger UI or with the provided curl commands.

1. Start Transaction

To start a transaction, you need to provide an app ID of the app for which you want to start a transaction. You can specify a list of partaking data consumers and a list of partaking data providers. This restriction is optional. If not specified all registered clients can participate in the transaction.

The start of a transaction provides you with the corresponding transaction ID and creates a PostgreSQL database for this transaction. For information on how this is created see Configuration of a database. The name of the database contains the transaction ID. To start a transaction use the transactions POST endpoint.

2. Start Workflow

You need to provide the transaction ID as well as the workflow definition ID of the workflow you want to start. Only participants which are specified as consumers for this transaction are permitted to start workflows. The start of the workflow triggers the start of the Argo template which is stored under the app ID. The start of a workflow provides you with the corresponding workflowRun ID. To start a workflow for a transaction use the transactions/{transactionId}/workflows POST endpoint.

3. View status of a started Workflow

To view the status of your workflow, use the transactions/{transactionId} /workflows/{workflowRunId} GET endpoint where transactionId is the ID of your transaction that you obtain from the transactions POST endpoint and the workflowRunId is the ID that you obtain from the transactions/ {transactionId}/workflows POST endpoint.

4. End Transaction

To end a transaction and delete its associated transaction specific database created in the start transaction step, use the transactions/{transactionId} DELETE endpoint.

5. Safe Deposit Database

With the safedeposit POST endpoint a database is created which can be used as a safe deposit box for data storage. This database can be deleted with the safedeposit/{appId} DELETE endpoint.

Authorization

Access to the endpoints is restricted. In addition to being an authenticated client, specific scopes and JWT claims are required depending on the domain:

Transactions (/transactions/...)

  • Scopes: - All POST, GET, and DELETE endpoints require the transaction:write scope.
  • Participant Claim Rules:
    • POST (Start): The participant specified in the JWT claim will become the transaction owner.
    • GET (Status): The participant in the claim must be a partaking consumer, provider, or the transaction owner itself.
    • DELETE (End): Only the participant who is the transaction owner is permitted to delete it.

Safe Deposit Database (/safe-deposit-database/...)

  • Scopes:
    • Both POST and DELETE endpoints require the safedeposit:write scope.
  • Participant Claim Rules:
    • The Access Token must contain a valid participant claim.
    • Ownership: A Safe Deposit Database is exclusively tied to the participant who created it. Because the database name is internally derived from the participant's ID, participants can only create and delete their own safe deposit databases for a given App ID.