Re: [basyx-dev] Various BaSyx questions

[<Frank.Schnicke@xxxxxxxxxxxxxxxxxx>]

Dear Nicolas,

> For my industry 4.0 prototype, I have Submodels that are shared between Administration Shells (e.g. Manufacturer and User connected to some shared submodels).
> I wonder, what is the canonical way of handling this use case with BaSyx?
> I thought it was possible to only deploy the shared Submodels once, and then retrieve them thanks to the endpoint being present in all concerned Administration Shell, however the 
> MultiSubmodelProvider seems to only be able to retrieve locally deployed submodels when looking for all its submodels.

This use case is supported by BaSyx. The MultiSubmodelProvider is just one supporting class for easy deployment. In your case,  you need to deploy the submodel separately. 
The following snippet shows the deployment of a separate submodel:

	SubModelProvider provider = new SubModelProvider(submodel);
	
	BaSyxContext context = new BaSyxContext("", "", "localhost", 5123);
	context.addServletMapping("/*", new VABHTTPInterface<IModelProvider>(provider));
	
	AASHTTPServer httpServer = new AASHTTPServer(context);
	httpServer.start();

You can of course also deploy this servlet on the same server as the other AAS/SMs. However, currently the registry does not support the registering of single submodels. We will implement this feature until the end of this week. 


> What I did here, was to create two separated servlets, one for all submodels, and one for all administration shells (meaning the submodels were only created on the submodel servlet, the AAS one only contained AAS high-level info + the submodel descriptors with submodels IDs and endpoints).
> Is it acceptable to use this type of infrastructure?
In the end, neither the AAS nor the SM care for where they are deployed since the Registry/ConnectionManager resolves this. Any working infrastructure is fine while of course different infrastructures will still have their own pros and cons.


> I wondered if in that case, the MultiSubmodelProvider could, when called, should look at all its linked resources (i.e. remote submodels) and then request them dynamically?
> Or perhaps each Administration Shell should have its own version of the remote submodels and update them when called?
> Or perhaps it is completely wrong, and submodels should be accessed manually in that case?
The MultiSubmodelProvider resolving this would be a possibility. I'll keep it in the back of my mind.


> On a different subject, I have remarks regarding the SQLDirectoryProvider:
> - Consulting the registry REST API, it only seems to implement the get all AAS call (not the call to get a specific AAS id, nor its submodels, etc.), are the other calls to be implemented on a later BaSyx version?
> - The call to get all AAS doesn't seem to work as intended, it returns a malformed json string (no ',' separators between AAS, no overall list structure "[]") instead of a List<AASDescriptor>, which makes the calls to AASRegistryProxy.lookUpAll not working
We are currently reworking the SQLDirectoryProvider exactly due to this. As an alternative until this rework is done, you can use the InMemory-Registry. For usage, see the test cases in org.eclipse.basyx.testsuite.regression.aas.registration.restapi. The empty constructor of DirectoryModelProvider uses an InMemory registry.

Best regards,
Frank Schnicke

----------------------------------------------------------------------------------
M.Sc. Frank Schnicke
Abteilung ESW
Fraunhofer IESE 
Fraunhofer-Platz 1 | 67663 Kaiserslautern 
Tel: +49 631 / 6800-2259 | Fax: +49 631 / 6800-9-2259
www.iese.fraunhofer.de 
Mail: frank.schnicke@xxxxxxxxxxxxxxxxxx


-----Ursprüngliche Nachricht-----
Von: basyx-dev-bounces@xxxxxxxxxxx <basyx-dev-bounces@xxxxxxxxxxx> Im Auftrag von Nicolas DUMINY
Gesendet: Dienstag, 3. Dezember 2019 17:18
An: basyx-dev <basyx-dev@xxxxxxxxxxx>
Betreff: [basyx-dev] Various BaSyx questions

Dear BaSyx development team,

I have multiple questions regarding features and best practices of BaSyx:

For my industry 4.0 prototype, I have Submodels that are shared between Administration Shells (e.g. Manufacturer and User connected to some shared submodels).
I wonder, what is the canonical way of handling this use case with BaSyx?
I thought it was possible to only deploy the shared Submodels once, and then retrieve them thanks to the endpoint being present in all concerned Administration Shell, however the MultiSubmodelProvider seems to only be able to retrieve locally deployed submodels when looking for all its submodels.

What I did here, was to create two separated servlets, one for all submodels, and one for all administration shells (meaning the submodels were only created on the submodel servlet, the AAS one only contained AAS high-level info + the submodel descriptors with submodels IDs and endpoints).
Is it acceptable to use this type of infrastructure?

I wondered if in that case, the MultiSubmodelProvider could, when called, should look at all its linked resources (i.e. remote submodels) and then request them dynamically?
Or perhaps each Administration Shell should have its own version of the remote submodels and update them when called?
Or perhaps it is completely wrong, and submodels should be accessed manually in that case?


On a different subject, I have remarks regarding the SQLDirectoryProvider:
- Consulting the registry REST API, it only seems to implement the get all AAS call (not the call to get a specific AAS id, nor its submodels, etc.), are the other calls to be implemented on a later BaSyx version?
- The call to get all AAS doesn't seem to work as intended, it returns a malformed json string (no ',' separators between AAS, no overall list structure "[]") instead of a List<AASDescriptor>, which makes the calls to AASRegistryProxy.lookUpAll not working


Best regards,


Nicolas Duminy
_______________________________________________
basyx-dev mailing list
basyx-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/basyx-dev