Wrong port and protocol for accessing a file from the AAS Server

[CMor1184]

I am running the BaSyx docker containers (registry, server, gui) in a docker compose environment and traefik as a reverse proxy with SSL termination.

Everything is working fine except the download of a File from the element details view, because the wrong domain is pre-filled here. In the input field, instead of "https://aas-server.example.com/aasServer/files/aasx/Document/operating-manual-xp-xpc-xpk-en.pdf" - "http://aas-server.example.com:4001/aasServer/files/aasx/Document/operating-manual-xp-xpc-xpk-en.pdf" is pre-filled. If I change the domain manually the download and pdf preview is working. I think the initial pre-filled info comes from the context.properties file from the AAS server, right? But thats actually the internal docker port and non TLS.

[aaronzi]

The issue seems to me to be more related to the AAS server. I'm adding @FrankSchnicke to the conversation for this. He knows best about the implementation and intricacies of the AAS server.

[FrankSchnicke]

For changing the external URL/Port to be used in the registry, there's the registry.host entry in the aas.properties.

[CMor1184]

yes that is configured, but the only issue I have is the pre-filled "File path", see screenshot above.

[FrankSchnicke]

Thanks for pointing this out. After investigating, it seems like the file path handling does not use the registry.host entry correctly. We will provide a bugfix soon.

[FischerRene]

As I can't replicate the issue, a few more questions:

1. What versions of the docker containers did/do you use?
2. How did you configure the containers?

My guess would be that you either have not added the aas.properties file correctly to the aas server container (maybe a typo?) or you used docker environment variables that have overwritten the properties from the file.

As a reference, here is a simple compose file with environment variables. To use the aas.properties for example you would need to mount it into the container using a volume just like the AASX-files in the example.

[adankert70]

I use the latest container available at any given time. We use a CosmosDB as backend for both registry and server, and we run the containers in our Kubernetes-based platform. I upload the aasx files using the API and POST method. After I do that I see the files both in the server and the registry (thanks to the new version!) But the binary files included in the aasx are nowhere to be found, and not found errors are shown in the Web UI.

If I use this sample aasx file: https://admin-shell-io.com/samples/aasx/17_ABB.aasx It uploads fine to the server and the server registers it to the registry. I connect the UI to the registry and I can see the ABB asset admin shell. I can browse the submodels and see the various properties. If I open the Nameplate submodel and try to look at the "File" property I can see that there is a URL specified on the "Download" button: https://our-server/shells/aas/submodels/Nameplate/submodel/submodelElements/Marking_CE/File/File

The server seems to be correct, however the path returns a 404. (I would expect it to be a image filename there)

Same for the "Document" submodel. The download link for property "File" is: https://ourserver/shells/aas/submodels/Document/submodel/submodelElements/ManualEN/File/File and it returns a 404.

I have tried using the UI to upload files but that fails: Error uploading File-SubmodelElement "File"!

Are binary files/attachment supported with the MongoDB backend?

I have tried other sample AASX files, but with the same result. Everything works as expected, apart from the binary files/attachments.

[adankert70]

[adankert70]

As you can see the initial port and protocol issue has been ironed out. Now the issue is the issue seems to be file url/path and/or availability of the files on the server side.

[FischerRene]

I use the latest container available at any given time. We use a CosmosDB as backend for both registry and server, and we run the containers in our Kubernetes-based platform. I upload the aasx files using the API and POST method. After I do that I see the files both in the server and the registry (thanks to the new version!) But the binary files included in the aasx are nowhere to be found, and not found errors are shown in the Web UI.

If I use this sample aasx file: https://admin-shell-io.com/samples/aasx/17_ABB.aasx It uploads fine to the server and the server registers it to the registry. I connect the UI to the registry and I can see the ABB asset admin shell. I can browse the submodels and see the various properties. If I open the Nameplate submodel and try to look at the "File" property I can see that there is a URL specified on the "Download" button: https://our-server/shells/aas/submodels/Nameplate/submodel/submodelElements/Marking_CE/File/File

The server seems to be correct, however the path returns a 404. (I would expect it to be a image filename there)

Same for the "Document" submodel. The download link for property "File" is: https://ourserver/shells/aas/submodels/Document/submodel/submodelElements/ManualEN/File/File and it returns a 404.

I have tried using the UI to upload files but that fails: Error uploading File-SubmodelElement "File"!

Are binary files/attachment supported with the MongoDB backend?

I have tried other sample AASX files, but with the same result. Everything works as expected, apart from the binary files/attachments.

From my perspective this seems to be a mismatch between the CosmosDB and MongoDB design, but I'm not an expert on CosmosDB, so I might be wrong here. According to the MongoDB comparison (might have a slight bias as it's the company website) documents might be handled differently as the maximum size is only 2MB instead of the 16MB supported by MongoDB. My guess is it is simply not supported by the library we use to communicate with MongoDB. See the implementation here with the filehandling on the SubmodelAPI level.

If you this is not a solution to the issue, please feel free to create a new issue in the BaSyx Java Components Repository and we can go on from there. This way we avoid mixing up the issues for different purposes. 😄

If this is a feature you like to see in the future, please feel free to either contribute to the open source project or come to one of our BaSyx Open Hours or shoot us a mail and we can see how it fits in the roadmap.

[FrankSchnicke]

@adankert70 , @CMor1184 is this issue still relevant? If no, I will close this ticket in the coming days