-
Notifications
You must be signed in to change notification settings - Fork 1
7.6 Starting SLA Manager
The requirements to install a working copy of the sla core are:
- Oracle JDK >=1.7
- Database to install the database schema for the service: Mysql>=5.0
- Maven >= 3.0
- RabbitMQ
- SymbIoTe Monitoring component
All commands shown here are ready to be executed from the root directory of the project (i.e., the one with the configuration.properties file)
Download the project using a git client: git clone <url>
From mysql command tool, create a database (with a user with sufficient privileges, as root):
$ mysql -p -u root
mysql> CREATE DATABASE symbiote;
Create a user:
mysql> CREATE USER symbiote@localhost IDENTIFIED BY '_symbiote_';
mysql> GRANT ALL PRIVILEGES ON symbiote.* TO symbiote@localhost; -- * optional WITH GRANT OPTION;
Create the database schema executing the following script (this runs the sql file in sla-repository/src/main/resources/atossla.sql):
$ bin/restoreDatabase.sh
The names used here are the default values of the sla core. See configuration to know how to change the values.
Most modern IDE such as Eclipse, Netbeans or IntelliJ open Maven projects directly or through an import wizard. Please, see your IDE documentation to see how it works.
The parameters on the SLA Framework can be classified into:
- compile-time values: these specify static behaviour of the SLA core (e.g. the class of the Monitoring adapter)
- runtime values: these specify runtime configuration and its value should be set with an env var (e.g. the address of a MySQL or RabbitMQ instance)
All compile-time configuration is done through the Spring context files, which build all the configurable objects. Several of these objects declared in the context files takes their parameters from the file configuration.properties.
Several parameters (of both types) can be configured through this file.
- db.* allows to configure the database username, password and name in case it has been changed from the proposed one in the section Creating the mysql database. It can be selected if queries from hibernate must be shown or not. These parameters can be overriden at runtime time through the use of environment variables (see section Running),
- rabbit.* allows to configure the RabbitMQ host, username and password.
- enforcement.* several parameters from the enforcement can be customized,
- service.basicsecurity.* basic security is enabled These parameters can be used to set the user name and password to access to the rest services.
- converter.* values specify how WSAG documents are parsed and extended.
The file configuration.properties initially contains default values for the project. For runtime parameters, the values in the file are intended to be used ONLY in development, and they should be overriden at deployment time using env vars.
Additional implementations may require the modification of the context files. In that case, it is
recommended to modify sla-personalization/src/main/resources/personalization-context.xml
.
$ mvn install
If you want to skip tests (do not skip tests the first time):
$ mvn install -Dmaven.test.skip=true
The result of the command is a war in sla-service/target.
runserver.sh script runs the sla-core server using jetty runner on port 8080 and / as context path.
$ bin/runserver.sh
Some configuration parameters can be overriden using environment variables or jdk variables. The list of overridable parameters is:
Mysql parameters
-
DB_DRIVER
: JDBC driver to use. Default value iscom.mysql.jdbc.Driver
-
DB_URL
: URL to a SQL database (MySQL preferred). Default value isjdbc:mysql://${db.host}:${db.port}/${db.name}
-
DB_USERNAME
: Username for the aforementioned database. Default value is${db.username}
-
DB_PASSWORD
: Password for the username above. Default value is${db.password}
-
DB_SHOWSQL
: Log the SQL queries executed by the SLA manager. For debug purposes only. Default value is${db.showSQL}
RabbitMQ parameters
-
RABBIT_HOST
: Hostame of an accessible RabbitMQ instance. Default value is${rabbit.host}
-
RABBIT_USERNAME
: User to use in this host. Default value is${rabbit.username}
-
RABBIT_PASSWORD
: Password for the user. Default value is${rabbit.password}
SymbIoTe specific parameters
-
PLATFORM_ID
: ID of the current platform. Default value is${platform.id}
-
SYMBIOTE_MONTORING_URL
: URL to the SymbIoTe monitoring component. Default value is${symbiote.monitoring.url}
For default values, ${exp}
means exp
value in the configuration.properties
file at compilation time.
F.e., to use a different database configuration:
$ export DB_URL=jdbc:mysql://localhost:3306/sla
$ export DB_USERNAME=sla
$ export DB_PASSWORD=<secret>
$ bin/runserver.sh
By default, sla-core uses slf4j for logging, using log4j as backend.
The default log4.properties
file logs to stdout, and is stored in sla-service in
sla-service/src/main/resources
.
If you want to use another log4j configuration, you can pass a different properties file to the JRE using
-Dlog4j.configuration=file:{file path}
.
Check that everything is working:
$ curl http://127.0.0.1:8200/api/providers
Time to check the User Guide and the Developer Guide!
Getting Started
Migration to 3.0.0
Migration to Docker
-
Preparation steps
1.1. Register user and configure platform in symbIoTe Core
1.2. Installation of required tools for symbIoTe platform components
1.3. Downloading jars
1.4. Downloading sources -
Configuring and starting components
2.1. Configuration of NGINX
2.2. Starting third party tools that are prerequisite for symbIoTe
2.3. Starting (generic) symbIoTe Cloud components
2.4. Configuration of cloud components
2.4.1. Starting symbIoTe Cloud components
2.5. Setting up the Platform Authentication and Authorization Manager (PAAM)
2.6. Starting Registration Handler and resource management
2.7. Set up of Resource Access Proxy
2.8. Manage resources
2.9. Set up of the Monitoring component
2.10. Other configuration topics -
Test integrated resource
3.1. Security
3.2. Search for resources
3.3. Obtaining resource access URL
3.4. Accessing the resource and actuating and invoking service for default (dummy) resources -
Creating RAP plugin
4.1. Customizing internal RAP plugin
4.2. Using RAP plugin starter
4.3. Creating RAP plugin in other languages -
Resource Description Examples
5.1. JSON Description Examples
5.2. RDF Description Examples - Preparation for L2 compliance
-
Configuring and starting components for L2
7.1. Starting Federation Manager
7.2. Starting Subscription Manager
7.3. Starting Platform Registry
7.4. Starting Trust Manager
7.5. Starting Bartering And Trading
7.6. Starting SLA Manager
7.7. Create a federation
7.8. Manage resources in L2
7.9. Register Subscription - Test Integrated L2 Resources
- Developing symbIoTe enabled apps