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:

  1. The standard unit tests, testing obviously the class and methods

  2. 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: