Skip to content

Latest commit

 

History

History
128 lines (94 loc) · 4.92 KB

File metadata and controls

128 lines (94 loc) · 4.92 KB

Implement a simple "Consumer Pull" Http transfer flow

The purpose of this sample is to show a data exchange between two connectors, one representing the data provider and the other, the consumer. It's based on a "consumer pull" use case that you can find more details on Transfer data plane documentation.

This sample consists of the following steps:

  • Perform a file transfer initiated by the consumer
  • The provider will send an EndpointDataReference to the consumer
  • The consumer will call the endpoint and fetch the data

Prerequisites

The following steps assume your provider and consumer connectors are still up and running and contract negotiation has taken place successfully. If not, re-visit the Prerequisites and Negotiation chapters.

Run the sample

Running this sample consists of multiple steps, that are executed one by one and following the same order.

1. Start the transfer

In the request body, we need to specify which asset we want transferred, the ID of the contract agreement, the address of the provider connector and where we want the file transferred. Before executing the request, insert the contractAgreementId from the previous chapter. Then run:

curl -X POST "http://localhost:29193/management/v3/transferprocesses" \
  -H "Content-Type: application/json" \
  -d @transfer/transfer-02-consumer-pull/resources/start-transfer.json \
  -s | jq

the "HttpData-PULL" transfer type is used for the consumer pull method, and it means that it will be up to the consumer to request the data to the provider and that the request will be a proxy for the datasource

Then, we will get a UUID in the response. This time, this is the ID of the TransferProcess ( process id) created on the consumer side, because like the contract negotiation, the data transfer is handled in a state machine and performed asynchronously.

Sample output:

{
  ...
  "@id": "591bb609-1edb-4a6b-babe-50f1eca3e1e9",
  "createdAt": 1674078357807,
  ...
}

2. Check the transfer status

Due to the nature of the transfer, it will be very fast and most likely already done by the time you read the UUID.

curl http://localhost:29193/management/v3/transferprocesses/<transfer process id>

You should see the Transfer Process in STARTED state:

{
  ...
  "@id": "591bb609-1edb-4a6b-babe-50f1eca3e1e9",
  "state": "STARTED",
  ...
}

Note that for the consumer pull scenario the TP will stay in STARTED state after the data has been transferred successfully. It might get eventually get shifted to TERMINATED or DEPROVISIONED by other resources, but this is not scope of this sample.

3. Check the data

At this step, an EndpointDataReference would have been generated by the provider and sent to the consumer. The latter stored it in a cache, so we can obtain it using the transfer process id:

curl http://localhost:29193/management/v3/edrs/<transfer process id>/dataaddress | jq
{
  "@type": "DataAddress",
  "type": "https://w3id.org/idsa/v4.1/HTTP",
  "endpoint": "http://localhost:19291/public",
  "authType": "bearer",
  "endpointType": "https://w3id.org/idsa/v4.1/HTTP",
  "authorization": "eyJraWQiOiJwdWJsaWMta2V5IiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJwcm92aWRlciIsImF1ZCI6ImNvbnN1bWVyIiwic3ViIjoicHJvdmlkZXIiLCJpYXQiOjE3MTc3NjkyMzEyOTYsImp0aSI6IjM2M2RhMGU4LWZmOGItNDY1My05YjQwLWY4MjdlMWMzOGMzYyJ9.WOVPz6m7XzIrbiMTfLqOXacGYz8Xk_-iQu7gmxoIgDFYsgo0da2Iv51EsugIpqbodPsmB0kK7zkyrmsFOfAASAq7fjsy4gQF-u5egYwoGpcxjYaJJdQa5lkwjC0fRxdVFVwZwrOaT5Mg-vGA9HssTEnlA64q-O0ae_aTH5ToflmPDM3FhAgL55I3odM5ysM2POEJY6pgOxIV9XjuhZFl_i_iTiUCZy__oQUZiYk58wKoqfK758Sy1WzpH-eyZCDUi_Z3n6cJB80_0ZThoPhtiFH7Tl9DfStnjsCoaeqMLFnTXp0s8h4ZGFmjfBc-72aAdRQqqLDT8WXNg3Csv5B56Q",
  "@context": {
    "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
    "edc": "https://w3id.org/edc/v0.0.1/ns/",
    "odrl": "http://www.w3.org/ns/odrl/2/"
  }
}

Once this json is read, use a tool like postman or curl to execute the following query, to read the data

curl --location --request GET 'http://localhost:19291/public/' --header 'Authorization: <edr authorization attribute>'

At the end, and to be sure that you correctly achieved the pull, you can check if the data you get is the same as the one you can get at https://jsonplaceholder.typicode.com/users

Since we configured the HttpData with proxyPath, we could also ask for a specific user with:

curl --location --request GET 'http://localhost:19291/public/1' --header 'Authorization: <auth code>'

And the data returned will be the same as in https://jsonplaceholder.typicode.com/users/1

Your first data transfer has been completed successfully. Continue with the next chapter to run through a "provider push" scenario.