SO Developement Guide
Setting up your development environment
SO (Service Orchestration) is built using maven and is mostly composed of java & groovy code along with camunda BPMN code flow. Please follow the instructions under the Setting your development environment page to prepare your machine for developing SO.
Cloning SO code
SO code is located in a single git repository named so
It is accessible via HTTPS : https://gerrit.onap.org/r/a/so.git
Or SSH : ssh://USERNAME@gerrit.onap.org:29418/so
Please make sure to review the ONAP Development Procedures and Policies to understand how to interact with the gerrit/git repositories.
Project structure
SO is composed of a main pom.xml is structured to build all submodules and also there is individual pom.xml for each sub-modules. It is composed of
Camunda BPM engine code flow for step by step order flow execution
Groovy script which invoked from camunda bpmn block for execution
Business logic written in java using Springboot framework
Mariadb for storing the metadata of the order flow execution
Unit test
The unit tests are composed of 2 different types:
The standard unit tests, testing obviously the class and methods
The Spring integration tests that really starts SO (using @SpringBootTest) and that can make use of everything in the code, like the database, the http connection, etc ...
Location details
Path | Content |
Docs |
|
/docs | The documentation in .rst files |
Logs |
|
/logger | The logging configuration of SO |
Docker |
|
/packages | The docker image preparation file |
Modules |
|
/mso-api-handlers | Exposed outside as rest service for entry point of incoming SO requests |
/bpmn | Contains all business logic of service order execution and interact with AAI, SDNC, requestdb, catalogdb etc, also accepts notification response from AAI via rest interface callback |
/adapters/mso-requests-db-adapter | Interacts with requestdb schema to update progress status |
/mso-catalog-db | Interacts with CatalogDB schema to query order details |
/so-monitoring | Monitoring UI portal of SO using AngularJS |
/adapters/mso-sdnc-adapter | Interacts with SDNC |
|
|
Code of Each Modules |
|
/src/main/java | The back-end and front-end code + resources |
/src/main/test | The unit tests and Spring integration tests to validate SO code |
/src/main/groovy | Groovy scripts used by maven build |
/src/main/resources | The default SO configuration files + the BPMN code flow files |
/src/main/frontend | The frontend code (HTML + javascript/typescript) using AngularJS framework |
Getting the containers
ONAP SO containers are stored on here for the releases, and here for the snapshots
The following Docker images are the actual deployment images used for running SO
Name | Tag | Description |
onap/so/api-handler-infra | 1.4.4 | MSO Api handler for SO REST service entry point |
onap/so/bpmn-infra | 1.4.4 | BPMN-Infra contains business logic of execution flow |
onap/so/catalog-db-adapter | 1.4.4 | CatalogDB to interact with mariaDB catalogdb schema |
onap/so/openstack-adapter | 1.4.4 | Adapter to interact with Openstack as a VIM |
onap/so/request-db-adapter | 1.4.4 | RequestDB to interact with mariaDB requestdb schema |
onap/so/sdc-controller | 1.4.4 | SDC-controller to interact with SDC module |
onap/so/sdnc-adapter | 1.4.4 | SDNC Adapter to interacts with SDNC module |
onap/so/so-monitoring | 1.4.4 | SO Monitoring for monitoring the SO workflows |
onap/so/vfc-adapter | 1.4.4 | Adapter to interact with VFC module |
onap/so/vnfm-adapter | 1.4.4 | Adapter to interact with external VNFMs through SOL003 interface |
library/mariadb | 10.1.11 | MariaDB image from Docker.io, this image hosts the database and is preloaded with SO schema and configuration at startup |
Building SO
To build SO you need to use maven with the goal "clean install". By default it executes the standard unit tests and the Spring integration tests but does not build the docker images.
Integration tests are started with the following profile “-P with-integration-tests”
You can disable the integration tests by executing: "mvn clean install -DskipTests=true -Dmaven.test.skip=true"
you can disable the javadoc or doclint creation by executing “mvn clean install -Dmaven.javadoc.skip=true -Dadditionalparam=-Xdoclint:none”
There are one profile to build the docker image named "docker", to build the docker image: "mvn clean install -P docker"
if you want to build docker images with out executing test and javadoc, then run the below command “mvn clean install -U -DskipTests=true -Dmaven.test.skip=true -Dmaven.javadoc.skip=true -Dadditionalparam=-Xdoclint:none -P docker”
Starting SO
You can use docker-compose to start SO. For running docker-compose, you need to checkout docker-config project.
docker-config code is located in a single git repository named so/docker-config
It is accessible via HTTPS : https://gerrit.onap.org/r/a/so/docker-config.git
Or SSH : ssh://USERNAME@gerrit.onap.org:29418/so/docker-config
To start SO, enter into the checked out docker-config folder and run command “docker-compose up -d”
You can also run / restart independent docker, like to run bpmn-infra docker, use command “docker-compose up -d bpmn-infra”
Testing SO
Starting SO dependencies using mock
SO service creation flow down the line interacts with AAI, OSS/BSS, SDNC. So user need to run mocking for these services if need to test the SO.
For running Mocking server we can use moco jar. Which can be downloaded from https://github.com/dreamhead/moco
AAI pointed to 8443 port, so start moco mocking stub on that port for AAI by running below command.
java -jar moco-runner-0.11.0-standalone.jar http -p 8441 -c config-onap.json
config-onap.json – this file should contains the request/response mapping as needed.
Similarly, create mock for SDNC ( map to port 8282) and OSS/BSS ( map to port 18008)
Verification
Most of the SO features within ONAP SO are triggered by using RESTful interfaces. SO supports both HTTP and HTTPS, but is configured on this release with HTTP only using Basic Authentication.
The SO APIs are configured to accept requests having a basic auth. header set with various username and password depending on which API is being triggered.
All API endpoints are exposed on port 8080
E.g. -1: send create a service request
Request:
POST /onap/so/infra/e2eServiceInstances/v3 HTTP/1.1
Host: localhost:8080
Authorization: Basic SW5mcmFQb3J0YWxDbGllbnQ6cGFzc3dvcmQxJA==,
X-FromAppId: onap-cli
Accept: application/json
Content-Type: application/json
X-TransactionId: req-ec1af3dc-3515-4e80-834b-999402728d02
Cache-Control: no-cache
User-Agent: PostmanRuntime/7.15.0
Host: localhost:8080
cookie: JSESSIONID=930E0055589BB32443E18F81928D84C5
accept-encoding: gzip, deflate
content-length: 1323
Connection: keep-alive
cache-control: no-cache
{
"service": {
"name": "SiteService",
"description": "SOTNVPNInfra",
"serviceInvariantUuid": "313abb16-d454-4a64-a39d-2ed4bb7713a3",
"serviceUuid": "3a76b1f5-fb0d-4b6b-82d5-0e8a4ebc3838",
"globalSubscriberId": "customer",
"serviceType": "service-subscription",
"parameters": {
"locationConstraints": [],
"resources": [
{
"resourceName": "simple_nf",
"resourceInvariantUuid": "1a140869-32f9-4e43-b618-9515f54c87cb",
"resourceUuid": "c4eb06cc-f0f5-4a8a-b986-c5daf8af3790",
"resourceCustomizationUuid": "08d3e5be-296c-478e-8d9a-f1825a6e74c8",
"parameters": {
"locationConstraints": [],
"resources": [],
"requestInputs": {
"name": "vpn1",
"description": "some_desc",
"vpnType": "ethernet"
}
}
}
],
"requestInputs": {
"siteName": "499hkg9933RRR",
"siteId": "499hkg9933RRR",
"ont_ont_serial_num": "sample-pnf"
}
}
}
}
Response:
{
"service": {
"serviceId": "bbfbe115-1e38-4038-8b14-5ce0bf11876b",
"operationId": "016f5b51-d40e-4fa3-b0b7-25c8f00a75aa"
}
}
This is testing SO standalone and thus cannot validate interactions with other components (SDC, OOF, Multi Cloud...).
Code Walk through of SO: