﻿////
 *******************************************************************************
 * Copyright (c) 2019 Contributors to the Eclipse Foundation
 *
 * See the NOTICE file(s) distributed with this work for additional
 * information regarding copyright ownership.
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License v. 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0.
 *
 * SPDX-License-Identifier: EPL-2.0
 *******************************************************************************
////

openKonsequenz - Architecture of the module 'Contact Base Data'
===============================================================
:Author: Frank Dietrich
:Email: frank.dietrich@pta.de
:Date: 2018-03-19
:Revision: 1
:icons:
:source-highlighter: highlightjs
:highlightjs-theme: solarized_dark

This documentation is based on the ARC42-Template (v7.0):

== Introduction and Goals

=== Requirements Overview

The module 'Contact Base Data' supports the different openKonsesequence domain- and user-modules ...


=== Quality Goals
The module 'Contact Base Data' represents a user module that is based on the architecture platform of openKONSEQUENZ. The main quality
goals of the platform are:

* *Flexibility* The reference platform shall grant that different systems and modules from different vendors/developers can interact and interoperate, and may be exchanged or recombined.
* *Availability* All platform modules that are running on the platform can only be as available as the platform same for user modules that are based on platform modules.
* *Maintainability* (and testability as part of maintainability)  The platform and its platform modules shall be used longer than 15 years.
* *Integration performance* New implemented functionality of oK own modules and external modules shall be included fast / automatically.
* *Security* The platform and its modules need to underly security-by-design

The main quality goals of the user module Contact Base Data are:

* *Functionality* The user module must fulfil the functional requirements mentioned in the section before
* *Ergonomics* The web interface must be realized according to oK-GUI-Styleguide.
* *Good documentation* (i.e. code and architecture documentation) makes code changes easier and automatic
tests facilitate rigorous verification.
* *Modifiability* (and testability as part of modifiability)
* *Integration performance* The user module must be easy integratable in different production environments.

The following documents contain the quality goals in detail:

* Architecture Committee Handbook v1.3.1 from 05-09-2017
* Quality Committee Handbook v1.1.1 from 11-09-2017

The architecture is based on the AC-Handbook. The quality demands are described in the QC-Handbook.
Both specifications were fully complied with in the project, so that a high quality is given.

The code quality regarding static code analysis and unit test code coverage on the backend and fronend sides
are ensured by the use of sonarqube. The rule set and the qualtity gate are defined by the default, the
so called "sonar way".

The module 'Contact Base Data' is part of the Eclipse project 'Eclipse openK User Modules'.
This project bases on the Eclipse Public Licence 2.0.

=== Stakeholders

.Stakeholders
[options="header,footer"]
|=========================================================
|Role/Name|Contact|Expectations
|Product Owner (represents the Distribution System Operators)|Rainer Fuhrmann, Gordon Pickfort|The software must fulfil their functional and nonfunctional requirements.
|Module Developer|Michel Alessandrini, Jonas Tewolde, Frank Dietrich|All relevant business and technical information must be available for implementing the software.
|External Reviewer (represents the AC/QC)|n.n.|The software and the documentation is realized according to the Quality and Architecture Handbook of openKONSEQUENZ.
|External Reviewer (represents the Eclipse-Requirements)|n.n.|The software is  licensed under the EPL 2.0. It must be validated that all requirements are fulfilled.
|System Integrator|n.n.|A documentation for the integration of the module in the DSO specific environments must be available.
|=========================================================

== Architecture Constraints

The main architecture constraints are:

* *Public License* The module must be available under the “Eclipse Public License 2.0”.
* *Availability* The source code of the module must be accessible to any interested person/company.

Therefore the project is published under the following repositories:
•https://git.eclipse.org/r/openk-usermodules/org.eclipse.openk-usermodules.mics.centralService

* *Standardization* The module must use standardized data structures (CIM) [if available] and the reference platform.

=== Technical Constraints

TODO: Bibliotheken und Versionen aktualisieren

The following technical constraints are given:

.Technical Contraints
[options="header,footer"]
|========================================================
|Component|Constraints
|Base components of the reference platform
a|* Application Server Tomcat
* JPA EclipseLink
* Database PostgreSQL

|Enterprise service bus
a|* ESB Talend
* Communication via RESTful Webservices

|Programming language frontend
a|* Angular
* Bootstrap
* jQuery
* REST/JSON Interfaces

|GUI design
a|* According to oK-GUI-Styleguide

|Java QA environment
a| * Sonarqube 5.6.6

|Programming language
a|* Backend: Java 1.8
* Frontend: Angular 4.0.0 (Javascript, Typescript, HTML5, CSS3)

|IDE
a|* Not restricted (Eclipse, IntelliJ, Microsoft Developer Studio, Microsoft Visual Code ...)

|Build system
a|* Backend: Maven
* Frontend: NodeJS + Angular/cli

|Libraries, frameworks, components
a|* Used Libraries/Frameworks have to be compatible to the Eclipse Public License

|Architecture Documentation
a|* According ARC42-Template
|========================================================


=== Technical Dependencies

==== Modules
The following modules are required to use the 'Contact Base Data':

.Modules
[options="header,footer"]
|=========================================================
|Name of the module|Purpose|Status of the module
|'Auth&Auth'|Authentification and Authorization|available
|=========================================================


==== Libraries

The following libraries are used:

.Libraries
[options="header,footer"]
|=========================================================
|Name of the library|Version|Artefact-id|Usage|License|Tier


|org.springframework.boot.spring-boot-starter-parent|2.2.1.RELEASE
a|
[source,xml]
----

----
||Apache License 2.0|Backend
|=========================================================

== System Scope and Context

=== Business Context

The user module 'Contact Base Data' communicates via Restful Webservices with the follwowing modules
(see also figure 1):

* *Core Module 'Auth & Auth'* The 'Contact Base Data' can only be used by authorized users.
   Therefore, it is essential to invoke the module 'Auth & Auth' for authorization and authentication
   purposes.


=== Technical Context

The following aspects have to be taken into account for external communication of the module 'Contact Base Data':

* RESTful web services are used as interface-technology.
* Each external interface (interfaces between modules or external systems) has to be documented.
* Dependencies of modules to services realized by other modules have to be specified and documented explicitly.
* When CIM is not appropriate (like access management), other standards in their respective domain shall be taken into account first to avoid proprietary and inaccurate interfaces. The interface has to be documented in the overall openKONSEQUENZ interface profile and it should use REST & XML.

The interfaces of the module 'Contact Base Data' are described in the interface documentation.

=== Solution Strategy

The module 'Contact Base Data' bases on a three-tier architecture:

. *Frontend* - The GUI is implemented as a web-frontend with rich-client functionalities.
. *Backend* - The business functionalities are implemented in the backend tier. It provides the business functions via RESTful Webservices.
. *Database* - The database stores all module specific data.


== Building Block View

=== Whitebox Overall System

The module 'Contact Base Data' contains two components (see figure 2):

. *UI* - Represents the graphical user interface and consumes the services from the business logic component via RESTful webservices.
. *Business Logic* - Realizes the business functionality and the data storage of the module. The
module itself is split up in several components due to the requirement to use
microservices.

.Module components
[options="header,footer"]
[plantuml]
----
node Module {
    rectangle UI
    rectangle BusinessLogic

    interface REST

    UI -> REST
    REST -- BusinessLogic
}
----


The communication between WebBrowser and Apache Tomcat is established via HTTP/HTTPS.
ApacheTomcat is connected to the data source (PostgresDBMS) via TCP/IP.

==== contactBaseDataFE

This component implements the presentation logic for the *contact-base-data*-module using the *Angular*-TypeScript
framework. The Frontend is a so called *Single Page Application* (SPA) because
it behaves like a single HTML-page. 


==== contact-base-data.jar (backend tier)

This component implements the business functionality of the contact base data. And it provides services, that the
contactBaseDataFE can use the functions in the frontend.

The "spring boot/sprint cloud" framework is used to implement this application.

==== ContactBaseDataDev-DB (Database tier)

This component stores the data of the contact base data. It provides an interface to the contact-base-data.jar to create or
change data in the database.

The ContactBaseDataDev-DB runs on a Postgres DBMS.
(The decision to use the Postgres DBMS was made by the openKONSEQUENZ architecture committee)

=== Level 2

==== ContactBaseDataFE (frontend tier)

The frontend component implements the concept of a single-page application (SPA). The framework used is Angular5.

It divides the contactBaseDataFE into three layers:

. *Components* - The components (pages, lists, dialogs, common comp.) represent the presentation layer and the control layer. A component contains the control logic (.ts-file), an HTML-fragment as presentation description (.html-file) and a style definition (.css-file).
. *Services* - The service component communicates with the interfaces of the backend via HTTP requests by using the model component.
. *Model* - The model corresponds to the view-model of the backend tier.

.Frontend tier
[options="header,footer"]
[plantuml]
----

node contactBaseData_Frontend  {
    component Model


    node Components {
        component "Pages"
        component Lists
        component "Common Components"
    }

    component Services

    Components --> Services
    Components --> Model
    Services --> Model
}

node "Contact Base Data Backend (simplified)" {
    component RestService
    component ViewModel_API
}

Services .. RestService
Model .. ViewModel_API
RestService --> ViewModel_API
----


==== contact-base-data.jar (backend tier)

The backend tier contains five components which can be summarized in three layers:

. *Presentation layer* - Represented by
 .. REST-Srv
 .. View model
. *Controller layer* - Represented by
 ..	Controller
.	*Model layer* - Represented by
 ..	DAO
 ..	Model


.Backend tier
[options="header,footer"]
[plantuml]
----

node "Contact Base Data Backend"  {
    component Model


    component RestService

    component ViewModel_API

    component Controller

    component DAO

    RestService --> ViewModel_API
    RestService --> Controller
    DAO --> Model
    Controller --> DAO
 }

node DBMS {
    component ContactBaseDataDB
}

DAO --> ContactBaseDataDB
----

==== ContactBaseData-DB (database tier)

The ContactBaseData-DB is realized as a relational database system.

.Database tier
[options="header,footer"]
[plantuml]
----

node DBMS {
    component ContactBaseDataDB
}
----


==== Program Configuration

== Runtime view

=== Login / authentication


There is no login page, since the openK-Portal-Application is responsible for authentication and
the whole SSO (single sign on) process.
Therefore the application has to be started by providing a valid authentication token.
This token is a JWT (JSON Web Token).

.contactBaseData application is called by the *portal* application. The User is already logged in
[plantuml]
....
actor User
participant PortalFrontend
participant PortalBackend
participant ContactBaseDataFrontend
entity ContactBaseDataStorage
participant ContactBaseDataBackend


User->PortalFrontend: Start ContactBaseData(JWT)
PortalFrontend->ContactBaseDataFrontend: nav. to frontend-URL with JWT
ContactBaseDataFrontend->ContactBaseDataStorage: Extract JWT and store token in session
... some delay ...
ContactBaseDataFrontend->ContactBaseDataBackend: Call any secured service with JWT
group Call secured service

    ContactBaseDataBackend->PortalBackend: "/checkAut(JWT)"
    group Authorization succeeded
        ContactBaseDataBackend->ContactBaseDataBackend: run service
        ContactBaseDataBackend->ContactBaseDataFrontend: return service result
    end
    group Authorization failed
        ContactBaseDataBackend->ContactBaseDataFrontend: return HTTP Code 401
    end
end
....

=== Deployment of the application components

==== Deployment of the frontend

TODO:

==== Deployment of the backend
TODO:

==== Deployment of the database
The component "Flyway" is used to make to distribute structural
or content related changes to the database.

The database is built out of the scripts in the directory "db/migrations". Every sql
script contains the complete db script for the contact base data database (in different versions).
The highest version number indicates the currently valid script.

==== Configuration of the system

===== DB based configuration

TODO:


===== Configuration of the contact base data backend

When starting the microservice of the contact base data backend you have to provide a configuration "YML"
file.

TODO: Describe configuration possibilities.


=== CI- and CD-Components

==== GIT-Repository

TODO: Links to Repos

=== Continuous deployment

The continuous deployment is realized on two platforms:

 * the development platform (Dev-Environment)
 * the quality platform (Q-Environment)

The automatic deployment on both of the environments is
directly linked to the branches on the GIT-repositories:

. "SNAPSHOT" or "DEVELOP"
. "MASTER" or "TRUNC"

The running development is exclusively made on the Snapshot-Branch. Every time
a developer checks in (pushes) code to the repository, an automatic build
starts on the hudson ci-server. If the Snapshot-build is successful, then the result
of that build is directly deployed on the Dev-environment.

At the end of a scrum sprint or when a big user story is realized, all
the code changes are merged from the *Snapshot*-Branch to the *Trunc*.
This automatically triggers the build and the deployment on the
Q-environment.


== Design decisions

All architecture decisions are based on the Architecture Committee Handbook. There are no deviations.

== Risks and Technical Debts

(Currently there aren't any known issues)

<<<

== Glossary

.Abbreviations and glossary terms
[options="header,footer"]
|========================================================
|Short|Long|German|Description
|AC|Architecture Committee|Architektur-Komittee|Gives framework and constraints according to architecture for oK projects.
|CNCU|Central Network Control Unit||
|DAO|Data Access Objects||
|DSO|Distribution System Operator|Verteilnetz-betreiber (VNB)|Manages the distribution network for energy, gas or water.
|EPL|Eclipse Public License||Underlying license model for Eclipse projects like contact-base-data@openK
|ESB|Enterprise Service Bus||Central instance to exchange data to overcome point-to-point connections.
|GNM|Geplante Netzmaßnahme||German name of the module 'Contact Base Data'
|oK|openKONSEQUENZ|openKONSEQUENZ|Name of the consortium of DSOs
|QC|Quality Committee|Qualitätskomitee|Gives framework and constraints according to quality for oK projects.
|SCADA|Supervisory Control and Data Acquisition|Netzleitsystem|System, that allows DSOs view/control actual parameters of their power grid.
|========================================================