[EDC 0.7.1] Shell Lookup from EDC Data Plane

[tanweersalah]

EDC == 0.7.1

While requesting the Catalog from registry for a particular assetId, I am getting the empty list,

while requesting directly to DTR I am getting the response,

But when the same assetid is being lookup from the EDC Data Plane , I am getting empty result.

[wolf4ood]

Hi @tanweersalah

thanks for raising this, can you share which is the configuration for the asset?

Thanks

[tanweersalah]

@wolf4ood , here is the congfiguration for the assest :

{
    "description": [],
    "displayName": [],
    "id": "urn:uuid:6bb0929b-8f29-cc77-0975-ec30a0e2415e",
    "specificAssetIds": [
        {
            "supplementalSemanticIds": [],
            "name": "manufacturerPartId",
            "value": "XYZ78901",
            "externalSubjectId": {
                "type": "ExternalReference",
                "keys": [
                    {
                        "type": "GlobalReference",
                        "value": "PUBLIC_READABLE"
                    }
                ]
            }
        }
    ],
    "submodelDescriptors": [
        {
            "endpoints": [
                {
                    "interface": "SUBMODEL-3.0",
                    "protocolInformation": {
                        "href": "http://supplier-control-plane:9184/api/public/data/urn:uuid:79f4649a-ce85-bda6-fcb4-a172df0beba8",
                        "endpointProtocol": "HTTP",
                        "endpointProtocolVersion": [
                            "1.1"
                        ],
                        "subprotocol": "DSP",
                        "subprotocolBody": "id=urn:uuid:0c3d2db0-e5c6-27f9-5875-15a9a00e7a27;dspEndpoint=http://supplier-control-plane:9184",
                        "subprotocolBodyEncoding": "plain",
                        "securityAttributes": [
                            {
                                "type": "NONE",
                                "key": "NONE",
                                "value": "NONE"
                            }
                        ]
                    }
                }
            ],
            "idShort": "batteryPass",
            "id": "urn:uuid:79f4649a-ce85-bda6-fcb4-a172df0beba8",
            "semanticId": {
                "type": "ExternalReference",
                "keys": [
                    {
                        "type": "Submodel",
                        "value": "urn:bamm:io.catenax.battery.battery_pass:3.0.1#BatteryPass"
                    }
                ]
            },
            "supplementalSemanticId": [],
            "description": [
                {
                    "language": "en",
                    "text": "Battery Passport Submodel"
                }
            ],
            "displayName": []
        }
    ]
}

[wolf4ood]

Hi @tanweersalah

this is for the DTR registry right? do you have the asset payload on EDC side?

Thanks

[tanweersalah]

@wolf4ood , sorry I did not understand what you meant by having asset payload on edc side.

So let me rephrase the issue,

After EDR negotiation the first EDR receive is for the DTR Asset,

I am getting empty response when the assetid is being lookup from Dataplane of provider, while the same asset id I am able to fetch when using the DTR endpoints.

[tanweersalah]

Also i am able to fetch all shell descriptors from Dataplane , just when I look for specific Asset Id , I am getting empty result.

[wolf4ood]

@tanweersalah

is the provider in your control? did you configure the asset on the EDC provider side for the DTR registry?

[tanweersalah]

@wolf4ood yes I have the access of provider edc. And configured the asset on the provider side.

[wolf4ood]

Can you share the asset payload that you used for configuring the DTR registry asset on provider side?

Thanks

[tanweersalah]

{
    "@id": "registry-asset",
    "@type": "Asset",
    "properties": {
        "version": "3.0",
        "type": {
            "@id": "DigitalTwinRegistry"
        },
        "asset:prop:type": "data.core.digitalTwinRegistry",
        "id": "registry-asset"
    },
    "dataAddress": {
        "@type": "DataAddress",
        "proxyPath": "true",
        "type": "HttpData",
        "proxyMethod": "true",
        "proxyQueryParams": "true",
        "proxyBody": "true",
        "baseUrl": "http://dtr-supplier:4243/api/v3"
    },
    "@context": {
        "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
        "edc": "https://w3id.org/edc/v0.0.1/ns/",
        "tx": "https://w3id.org/tractusx/v0.0.1/ns/",
        "tx-auth": "https://w3id.org/tractusx/auth/",
        "cx-policy": "https://w3id.org/catenax/policy/",
        "odrl": "http://www.w3.org/ns/odrl/2/"
    }
}

[wolf4ood]

Can you also check on EDC provider side logs when you are fetching the data it should log the entire URL of the translated URL of the DTR registry.

[tanweersalah]

supplier-data-plane     | DEBUG 2024-06-03T09:47:53.911021264 Executing HTTP request: http://dtr-supplier:4243/api/v3/lookup/shells?assetIds=eyJuYW1lIjoicGFydEluc3RhbmNlSWQiLCJ2YWx1ZSI6IklNUjE4NjUwVjEifQ==

[wolf4ood]

Cool so from the EDC point of view all seems correct.

Is there some kind of filtering on DTR registry based on headers?

I remember that the registry filtered the requests based on Edc-Bpn header that the EDC will forward on the HTTP request. But i'm not expert there :)

[tanweersalah]

Yes For DTR request ,

Edc-Bpn : {{bpnNumberProvider}}

need to be added in header,

Does the edc adds it internally ??

[wolf4ood]

Yes it attaches to the request

[tanweersalah]

is there any way to check what bpn it is attaching ?

[wolf4ood]

It attaches the consumer BPN

[tanweersalah]

Ok I got the issue, i created the shel in registry with providerbpn ,

Now after updating it to consumer bpn I am getting the results.

So doest it mean for every consumer we have to create a shell descriptor in DTR ?

[wolf4ood]

I'm no expert on DTR and how the visibility restriction and configuration works there

[tanweersalah]

@wolf4ood No problem and Thanks for the prompt responses. Have a nice day.

[wolf4ood]

:+1:

thanks @tanweersalah , closing this then :)