Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "BaSyx / Documentation / Components / AAS Server"

m (Changes order of description for clarity)
m (Fixes spelling)
Line 114: Line 114:
 
== Operation Delegation ==
 
== Operation Delegation ==
 
'''Disclaimer: in development branch:'''
 
'''Disclaimer: in development branch:'''
An operation is a specific type of submodel element that is capable of performing server-side functions. However, in certain environments this is not possible. Therefor, the operation can be delegated to an independent destination url to be executed.
+
An operation is a specific type of submodel element that is capable of performing server-side functions. However, in certain environments this is not possible. Therefore, the operation can be delegated to an independent destination URL to be executed.
The operation invocation request is defined on [https://app.swaggerhub.com/apis/BaSyx/basyx_submodel_http_rest_api/v1#/Submodel/InvokeOperationByIdShort swaggerhub]. The type and the number of the in and output variables is definded within the operation itself. An example request body is given below. The strong and italic formatted attribute(s) <code>value</code> is/are the value(s) to be processed by the operation.  
+
The operation invocation request is defined on [https://app.swaggerhub.com/apis/BaSyx/basyx_submodel_http_rest_api/v1#/Submodel/InvokeOperationByIdShort swaggerhub]. The type and the number of the in and output variables is defined within the operation itself. An example request body is given below. The strong and italic formatted attribute(s) <code>value</code> is/are the value(s) to be processed by the operation.  
 
  {
 
  {
 
     "requestId": "1",
 
     "requestId": "1",

Revision as of 07:34, 19 January 2022

Overview | Interface | Implementation | Component

AAS Server Component

The AAS server component provides an empty AAS server that can be used to host several AAS and Submodels. For its API usage see Aggregator API. Additionally, there's a video illustrating the configuration and usage in 5 minutes: YouTube.

For a complete deployment of the AAS infrastructure, additionally to this server a registry is needed. For this registry, the Registry Component can be used.

For illustration on how to create an AAS on the server provided by the component and how to retrieve it see the snippet in the repository.

Download

The AAS Server image is made available via Docker Hub and can be pulled by:

docker pull eclipsebasyx/aas-server:1.0.1

Alternatively, the command described in Startup section will download the image.

Startup

To easily start the AAS server component, you can use the following command:

docker run --name=aas -p 8081:4001 eclipsebasyx/aas-server:1.0.1

Now the endpoint for accessing the server with its AAS is

http://localhost:8081/aasServer/shells/

And the container can be stopped, started and removed using its name (see --name):

docker stop aas
docker start aas
docker rm aas

Context Configuration

As with the other components, the server's context can be customized using the context configuration.

AAS Configuration

For the AAS server component, three main options can be configured:

  • The backend
  • The AAS source file
  • The registry url

Additionally the usage of MQTT events and the option to upload *.aasx files can be set.

By default, an empty InMemory server is started. The backend can be changed with the option

aas.backend=InMemory

Currently, the other valid option for the backend is MongoDB that persists the whole AAS together with its submodels in a MongoDB. Additionally, it is possible to give an input file for the server using an absolute file path:

aas.source=/usr/share/config/myAAS.aasx

This loads the file myAAS.aasx into the server as soon as it is started. For input files, the .xml file ending is supported as well:

aas.source=/usr/share/config/myAAS.xml

Furthermore, when loading a default AAS, it can be registered in an external registry by specifying the registry url. The registry path depends on the deployment location. Thus, when starting a local docker registry for testing purposes, it needs to be in the same docker network as the AAS to be reachable. So for a non-docker deployment, the registry address could be:

registry.path=http://localhost:4000/registry/

Whereas it could be different for a deployment with docker containers:

registry.path=http://registry:4000/registry/

See also the official Docker documentation for more information on that topic.

By default, this configuration file is assumed to be located at "/usr/share/config/aas.properties" within the container. Thus, another configuration file can be set by mounting a local configuration file into the container during startup. As an example, a local folder containing the configuration files can be mounted using:

docker run --name=aas -p 8081:4001 -v C:/tmp:/usr/share/config eclipsebasyx/aas-server:1.0.1

In this example, the aas.properties file is located in C:/tmp/. Similarly, the AAS source file also needs to be mounted into the docker container.


Disclaimer: in development branch: Eventing via MQTT can be enabled in the property file as well. This will publish events for every action to a separately specified server:

aas.events=MQTT

By default, this function is disabled:

aas.events=None

Disclaimer: in development branch: Finally, the option to upload *.aasx files via multipart form upload can be configured:

aas.aasxUpload=Enabled

this function is enabled by default. to disable it, the value has to be set to

aas.aasxUpload=Disabled

MongoDB Backend

Uses a MongoDB backend that can be configured using the .properties files in src/main/resources of the components. Similar to the SQL backend, for the MongoDB backend, another configuration file can be specified.

InMemory Backend

Stores the Registry entries in RAM. !!Please be aware that this is not persistent and therefore only for testing! After component restart, all entries are lost. Use this only for testing!!

Eventing with MQTT

Additionally, to the aas.properties file, you need to edit the mqtt.properties file in order to connect to the right MQTT broker. The MQTT configuration file can be found in the same folder as the AAS configuration. It allows you to add credentials and a Quality of Service level (default: 1) besides the mandatory server address. By default the configuration adds a whitelist for filtering specific submodel/submodelelement events to avoid unnecessary messages.

Information about what events will be published can be found in the eventing extension.

Operation Delegation

Disclaimer: in development branch: An operation is a specific type of submodel element that is capable of performing server-side functions. However, in certain environments this is not possible. Therefore, the operation can be delegated to an independent destination URL to be executed. The operation invocation request is defined on swaggerhub. The type and the number of the in and output variables is defined within the operation itself. An example request body is given below. The strong and italic formatted attribute(s) value is/are the value(s) to be processed by the operation.

{
   "requestId": "1",
   "timeout": 60,
   "inputArguments": [{
      "value": {
         "idShort": "in",
         "valueType": "integer",
         "value": 1,
         "modelType": {
            "name": "Property"
         }
      }
   }]
}

Alternatively to the full request body above, the raw data can simply be passed as an array of values to be processed by the operation. In this case, the response would also consist of raw data instead of a structured body.

  1. To create an operation delegation, an AAS with a Submodel that has a Operation(-SubmodelElement) must be present.
    1. The Operation has neither input, output nor inout variables
    2. To achieve the Delegation functionality, a Qualifier of type "invocationDelegation" is added to the operation.
      • As value, the url to the desired operation must be given.
      • The url follows the pattern
http://{server}:{port}/{contextPath}/{idShortPathToOperation}/invoke
resp. it is the url for direct operation invocation.
  • Knowledge about the operation to be delegated to, with regard to the number and type of input and output parameters is assumed.

This achieves that operations can be delegated to endpoints of the same server as well as to external servers. For the frontend it remains completely transparent whether an operation was called directly or delegated.

Java Implementation

Within the project, the component can be found in the Java repository at Java. In this project, the executable can take the parameter BASYX_AAS to configure the path of the aas configuration file. For example, you can specify the path of the aas configuration file via

java -jar -DBASYX_AAS="C:/tmp/aas.properties" aas.jar

Back to the top