prototype testing

[mrentsch65]

Hello, I tried to test your prototypical frontend here, but I couldn't get a response from the servers:

https://mk28.github.io/TINF21C_Team2_AAS_digital_nameplate/#/list?server=https%3A%2F%2Fadmin-shell-io.com%2F5001

https://mk28.github.io/TINF21C_Team2_AAS_digital_nameplate/#/list?server=aas.murrelektronik.com

[MidFidelity]

Dear Customer, it seems that the servers you wanted to access are not AAS-Servers accessible via a REST-API. The adminshell-io server has a different address for their REST demo than their UI explorer.

Please use the address https://admin-shell-io.com/51411 for further testing. https://mk28.github.io/TINF21C_Team2_AAS_digital_nameplate/#/list?server=https://admin-shell-io.com/51411

I was not able to contact a REST-API on aas.murrelektronik.de as requests made seem to result in an error on their side.

[mrentsch65]

This is the Basyx-AAS-API: https://app.swaggerhub.com/apis/BaSyx/basyx_asset_administration_shell_http_rest_api/v1 This is the IDTA-AAS-API: https://app.swaggerhub.com/apis/Plattform_i40/Entire-API-Collection/V1.0RC02#/

I believe the problem is that you use a nonstandard endpoint "server/listaas":

For example, this works: https://aasrepo.digitaltwin-vdma.org/repo/shells https://admin-shell-io.com/5001/shells http://aas.murrelektronik.de:5001/shells

but not when called from your client like that: https://aasrepo.digitaltwin-vdma.org/repo/server/listaas https://admin-shell-io.com/5001/server/listaas http://aas.murrelektronik.de:5001/server/listaas

[mrentsch65]

Ich schaffe es nicht, diesen Server in Ihrer App zu zu connecten:

http://aas.murrelektronik.com:4000/registry

http://aas.murrelektronik.com:4000/registry/api/v1/registry

http://aas.murrelektronik.com:4001/aas/shells/

Hier tut er:

[MidFidelity]

Dear customer @mrentsch65 ,

all three mentioned server URLs do not expose a full API according to AAS-Spec found at https://v3.admin-shell-io.com/swagger/index.html. The only endpoint exposed seems to be the registry endpoint and the shells endpoint.

We use the /submodels endpoint that is described in the AAS-Spec. This does not seem to be exposed on any routes. We also use the /shells endpoint that is exposed in the third link. If the /submodels endpoint was available at http://aas.murrelektronik.com:4001/aas/submodels you would have to use http://aas.murrelektronik.com:4001/aas/ to access the server.

Another issue is that your server does not support https. Browsers block requests from a secure (https) context to an insecure (http) one. This is happening here, as GitHub Pages does not allow us to host an insecure site. The request is blocked by the browser.

Both issues together prevent any content from being shown. We cannot take any action in this case as both issues are out of our control and a problem with the server.

[mrentsch65]

Dear @mk28, the problem is that many of these v1-servers are around and need to be served. And I do not quite understand your problem, because both the /shells and the /submodels endpoint is obviously supported, although the url paths might be different to V3:

http://aas.murrelektronik.com:4001/aas/shells

http://aas.murrelektronik.com:4001/aas/shells/https%3A%2F%2Faas.murrelektronik.com%2FV000-PS024-0100001%2Faas%2F1%2F0/aas/submodels

What prevents you from probing for a V1 response via i.e. the /registry endpoint and use the alternative paths accordingly?

[mrentsch65]

To overcome the blocking of responses from http-servers, manipulate via "edge://flags/#unsafely-treat-insecure-origin-as-secure" this flag:

The browser will then deliver responses from the unsecure server, but this query "?level=Deep" is not supported:

[MidFidelity]

Dear Customer @mrentsch65 , we use the pure /submodels endpoint. Your API only exposes the /shells and all related endpoints. The submodels you see in your browser is actually /aas/shells/{assetId}/aas/submodels which the browser shortens to /submodels.

Our current implementation does not use the registry because we found it to be unrelieable. https://admin-shell-io.com/5001/registry/shell-descriptors should give a list of shell descriptors that we could use similar to https://v3.admin-shell-io.com/registry/shell-descriptors but for some reason for the V1 API it is just empty and not usable, at least on the IDTA servers.

Please provide a URL that can be used in the Murrelektronik AAS UI to open a Server as I currently have no luck opening a server with this UI. It does not produce any error messages and just does nothing if I enter URLs that should be working.

With this we can investigate further.

[mrentsch65]

Dear @mk28,

Why is this query "?level=Deep" required? To achieve a better generic API backward compatibility, it is highly recommendable to leave something like this out and let the server just respond with its default!

Please have look at this: https://admin-shell-io.com/5001/shells https://v3.admin-shell-io.com/shells http://aas.murrelektronik.com:4001/aas/shells

Would these not be the right endpoints to start with and build the AAS-listing? Instead of starting with endpoint "submodels" it is the recommended approach :

You may simply click on [Get all AAS](https://v3.admin-shell-io.com/shells) or you may do it by yourself by Swagger UI.
You will receive all AAS with their assetInformation and their submodel references.
Please notice the "type" in V3 references with GlobalReference or ModelReference.

Now you may just request a single AAS by GET /shells/{aasIdentifier}.

BTW, the returned content of the IDTA's V3-Server is not displayed:

[mrentsch65]

With the newest changes for Api-V1-support, some regressions have been introduced, i.e. selection of some servers is not longer working:

After returning to home screen or switching to server, the yellow message line should disappear or change content.

Server-URLs are not properly checked for correctness:

[MidFidelity]

Dear customer @mrentsch65 , regarding your last few issues:

• The ?level=deep is currently reqired beacause the /submodels would otherwise just retrun a shortened version of the submodel data. The V1 API retruns the full data by default. As it is a browser query, it is ignored, when a server cannot use the option. It should do no harm having it there for backwards compatibility.
• I could reproduce the bug with the warning label persisiting onto the home screen and created an Issue for it. #106
• I could not reproduce the error that some servers could not be loaded. I reqire more Information and / or detailed steps to reproduce it. The network tab is not always the best way to see, if the app is working correctly as some requests are rather slow.
• It is correct that there is no complex logic for validating server addresses in place. An issue for this task is created #107
• We still need the Information requested in an earlier comment about the Murrelektronik AAS server and GUI

  Please provide a URL that can be used in the Murrelektronik AAS UI to open a Server as I currently have no luck opening a server with this UI. It does not produce any error messages and just does nothing if I enter URLs that should be working. With this we can investigate further.

As this server does not support the full swagger API spec, we are forced to mostly rewrite our server connection code once again in order to support this server. This will take time as previous issues stated that we could use the full API spec documented at https://v3.admin-shell-io.com/swagger/index.html.