... | ... | @@ -22,8 +22,24 @@ Even without the prefix, the path is different. |
|
|
|
|
|
In conclusion, this registry probably could work as a substitute for the BaSyx registry but not without changing basically every route in the REST API.
|
|
|
|
|
|
### Manual testing
|
|
|
Testing this was another challenge.
|
|
|
That's because the documentation of this project's REST API honestly is a mess.
|
|
|
|
|
|
TODO: Test if the HTTP PUT body is even usable by taking and pushing it manually.
|
|
|
There are two different paths documented for the registry REST endpoint:
|
|
|
- `/registry/shellDescriptors/{aas-identifier}` in the [README on the project page](https://github.com/admin-shell-io/python-aas-registry#aas-registry-rest-api-services)
|
|
|
- `http://localhost:9021/api/v1/registry/{aas-identifier}` in the [provided example](https://github.com/admin-shell-io/python-aas-registry/blob/main/examples/restCLient.py#L11)
|
|
|
|
|
|
And the best part: None of those two work for the docker container that should be used according to the README.
|
|
|
Inspecting the docker container by attaching a command line to it and reading through the code was more successful:
|
|
|
[All these lines here](https://github.com/admin-shell-io/python-aas-registry/blob/main/src/main/aasendpointhandlers/restapi_endpointhandler.py#L69-L76) are different in the docker container and use "kebab-case" instead of "camelCase".
|
|
|
So the correct spelling for `shellDescriptors` in the path is `shell-descriptors`.
|
|
|
|
|
|
Before the test started I fetched a PUT request from our projects light component using [a simple server script](https://github.com/C0ntroller/simple-callback-server).
|
|
|
I now just needed to pipe this data into the correct path to the python-aas-registry and voila:
|
|
|
"HTTP/1.1 500 INTERNAL SERVER ERROR" and "The syntax of the passed Asset Administration Shell descriptor is not valid or malformed request".
|
|
|
|
|
|
This concludes the testing for this registry. The documentation is really bad and it won't work with any BaSyx components.
|
|
|
|
|
|
## [SAP/i40-aas](https://github.com/SAP/i40-aas)
|
|
|
SAP has a framework, too, which also is already talked about in the [initial considerations](/initial-considerations/Deciding-on-a-framework#deciding-with-which-frameworks-to-continue).
|
... | ... | @@ -44,4 +60,10 @@ How we can use the registry endpoints programmatically is described in the [endp |
|
|
And here we see: The routes are very different again.
|
|
|
They neither match the BaSyx registry nor the python-aas-registry.
|
|
|
|
|
|
TODO: Manual HTTP(S?) PUT and see if this works. |
|
|
\ No newline at end of file |
|
|
### Manual testing
|
|
|
This test took less time than the one above. In short: it fails too.
|
|
|
|
|
|
It took less time because the project provides [a test collection for Postman](https://github.com/SAP/i40-aas/blob/master/docs/markdown/test.md).
|
|
|
When trying to register our light asset, we just get another "HTTP/1.1 500 INTERNAL SERVER ERROR".
|
|
|
|
|
|
This registry won't work with BaSyx components either. |
|
|
\ No newline at end of file |