Error 400 when posting validated JSON to AAS Repository about basyx-java-server-sdk

[s-heppner]

The feature branch v3.0.2 of the BaSyx Python SDK does not fully implement the meta model of version 3.0.2., which is probably the reason for the inconsistencies that you're noticing.
We are working hard on a release for version 3.0 of the meta model, which will come soon.

[mhrimaz]

@SebBehrendt Try this payload. Probably the issue is with your parser/serializer. How did you got that payload?

Anyway, you can look for valid/invalid examples in aas-specs repo.

{
    "embeddedDataSpecifications": [
        {
            "dataSpecification": {
                "type": "ExternalReference",
                "keys": [
                    {
                        "type": "GlobalReference",
                        "value": "example_value"
                    }
                ]
            },
            "dataSpecificationContent": {
                "modelType": "DataSpecificationIec61360",
                "preferredName": [
                    {
                        "language": "en",
                        "text": "example_name"
                    }
                ],
                "valueFormat": "xs:string",
                "value": "example_value_content"
            }
        }
    ],
    "idShort": "example_id_short",
    "modelType": "AssetAdministrationShell",
    "id": "example_id",
    "assetInformation": {
        "assetKind": "INSTANCE"
    }
}

@FrankSchnicke However I am not quite sure if basyx really check always if your input is valid or not. For example you can create concept description or aas without id or empty string as id, which violates the specificaiton (it is mandatory field and the length should be more than 1). It also makes the database table messy.

[SebBehrendt]

@mhrimaz thank you for your help. The request is now working by the small changes on "DataSpecificationIec61360", "ExternalReference" and "GlobalReference". The string that I posted here was created with the a generated python client using the openAPI-specification generated by the AASRepository (generator: https://github.com/openapi-generators/openapi-python-client).
When instantiating the AAS, I created it at first with the basyx-python-sdk, serialized it then to JSON and used this JSON in the generated python client. The wrong serialization occured, in my opinion, due to three reasons:

• The basyx-python-sdk seems to have some inconsistencies when compared to the AASrepository server, as a data specification requires to be a of kind "GlobalReference" whereas in the AASRepository it can only be of kind "ModelReference" or "ExternalReference". The whole concept of ExternalReference is missing in the basyx-python-sdk. I reworked this by changing the serialized JSON afterwards and changing the data specfication type to ExternalReference from GlobalReference.
• The data specification content is differntly written in the basyx-python-sdk (DataSpecificationIEC61360) and AASrepository (DataSpecificationIec61360).
• The Enums in the openAPI specification all use only capital letters, e.g. "GLOBAL_REFERENCE", which is transformed to "GlobalReference" when posting a value. This, however, throws errors when using a generated client since they have validation of the JSON data when parsing it to models in case of requested data. Since the client expects, according to openAPI specification, that the key is "GLOBAL_REFERENCE".

In my opinion, the defintions in basyx-python-sdk and AASrepository should be aligned to the AAS meta model specification to ensure integration. However, I don't know which one has the wrong implementation. Seccondly, the generated openAPI-file of the AAsrepository sould have keys that align with the keys used in the server.

Thank you again.

[FrankSchnicke]

@mhrimaz thank you very much for providing your input! You're right, in future we will validate the meta model more thoroughly to avoid issues like empty ids.

@SebBehrendt Unfortunately, there's an issue with the OpenAPI specification that the AAS Repository is providing right now. We're looking into it on how to fix it. Until then, please use the official OpenAPI spec for code generation: https://app.swaggerhub.com/search?type=API&owner=Plattform_i40

In regard to the basyx-python-sdk, I think it isn't implementing the latest spec but a previous release candidate of it at the moment. @s-heppner can you point out the current status of the python-sdk?

[SebBehrendt]

@FrankSchnicke Thank you for this hint, I will try it with the official OpenAPI specs. I used the feature branch that implements the V3RC02 specification (https://github.com/eclipse-basyx/basyx-python-sdk/tree/improve/V30RC02), which should align with the AASrepository.

[FrankSchnicke]

V3RC02 is a release candidate that was superseded in the meantime with the official Version 3 of IDTA. BaSyx Java supports the official version 3 release, thus the mismatch between the payloads

[SebBehrendt]

Thank you all for the help! I will hold on until the new relase is published. For now, I just do some transformations of the KeyType and ReferenceTypes to ensure API conformance of the python-sdk and AASrepository.

[mhrimaz]

@mhrimaz thank you very much for providing your input! You're right, in future we will validate the meta model more thoroughly to avoid issues like empty ids.

@FrankSchnicke I am not that deep in the code and everything, but I can guess that the issue seems to be on aas4j side.

In this case INSTANCE handled correctly and converted to Instance.

#POST INPUT
{
   
    "idShort": "example_id_short",
    "modelType": "AssetAdministrationShell",
    "id": "example_id",
    "assetInformation": {
        "assetKind": "INSTANCE"
    }
}
#OUTPUT
{
    "modelType": "AssetAdministrationShell",
    "assetInformation": {
        "assetKind": "Instance"
    },
    "id": "example_id",
    "idShort": "example_id_short"
 }

In this case, also GLOBAL_REFERENCE and EXTERNAL_REFERENCE handled correctly.

#POST INPUT
{
   
    "idShort": "example_id_short",
    "modelType": "AssetAdministrationShell",
    "id": "example_id2",
    "assetInformation": {
        "assetKind": "INSTANCE"
    },
     "embeddedDataSpecifications": [
        {
            "dataSpecification": {
                "type": "EXTERNAL_REFERENCE",
                "keys": [
                    {
                        "type": "GLOBAL_REFERENCE",
                        "value": "example_value"
                    }
                ]
            },
            "dataSpecificationContent": {
                "modelType": "DataSpecificationIec61360",
                "preferredName": [
                    {
                        "language": "en",
                        "text": "example_name"
                    }
                ],
                "valueFormat": "xs:string",
                "value": "example_value_content"
            }
        }
    ]
}
#OUTPUT
{
    "modelType": "AssetAdministrationShell",
    "assetInformation": {
        "assetKind": "Instance"
    },
    "id": "example_id2",
    "idShort": "example_id_short",
    "embeddedDataSpecifications": [
        {
            "dataSpecification": {
                "keys": [
                    {
                        "type": "GlobalReference",
                        "value": "example_value"
                    }
                ],
                "type": "ExternalReference"
            },
            "dataSpecificationContent": {
                "modelType": "DataSpecificationIec61360",
                "value": "example_value_content",
                "valueFormat": "xs:string",
                "preferredName": [
                    {
                        "language": "en",
                        "text": "example_name"
                    }
                ]
            }
        }
    ]
}

However, if we change the DataSpecificationIec61360 to DataSpecificationIEC61360, we would have parsing issue.

2023-07-03 09:39:52.178 DEBUG 13224 --- [nio-8081-exec-1] .m.m.a.ExceptionHandlerExceptionResolver : Resolved [org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Could not resolve type id 'DataSpecificationIEC61360' as a subtype of `org.eclipse.digitaltwin.aas4j.v3.model.DataSpecificationContent`: known type ids = [] (for POJO property 'dataSpecificationContent'); nested exception is com.fasterxml.jackson.databind.exc.InvalidTypeIdException: Could not resolve type id 'DataSpecificationIEC61360' as a subtype of `org.eclipse.digitaltwin.aas4j.v3.model.DataSpecificationContent`: known type ids = [] (for POJO property 'dataSpecificationContent')<EOL> at [Source: (org.springframework.util.StreamUtils$NonClosingInputStream); line: 21, column: 30] (through reference chain: org.eclipse.digitaltwin.aas4j.v3.model.impl.DefaultAssetAdministrationShell["embeddedDataSpecifications"]->java.util.ArrayList[0]->org.eclipse.digitaltwin.aas4j.v3.model.impl.DefaultEmbeddedDataSpecification["dataSpecificationContent"])]

[FrankSchnicke]

Thanks for pointing out this behavior of AAS4J. It seems like enums are parsed correctly for both notations. "modelType", however, is no enum - thus the different behavior.