© 2019 synetics GmbH

© 2019 synetics GmbH

Devday auf der i-doit AWK 2019

Begrüßung

© 2019 synetics GmbH

© 2019 synetics GmbH

Moderation

Moderator

● Jens Dörnenburg

● Teil des i-doit Teams seit 2011

● Tätig in Support/Care

© 2019 synetics GmbH

Das Entwickler-Team

Pavel Abduramanov Leonard Fischer

Kevin Mauel Van Quyen Hoang

Architektur

Frontend

Frontend

Architektur

API

Kategorien

Beziehungen

© 2019 synetics GmbH

Devday → Agenda

Agenda

● i-doit 2.0 Systemvoraussetzungen

● i-doit 2.0 Technisches Leitbild & Architektur

● i-doit 2.0 Verwendete Technologien

● i-doit 2.0 API

● Im Anschluss: Fragerunde

© 2019 synetics GmbH

i-doit 2.0Systemvoraussetzungen

Referent: Kevin Mauel

© 2019 synetics GmbH

i-doit 2.0 → Mindestsystemvoraussetzungen

● CPU: 2 CPU Kerne

● RAM: 2 GB

● Storage: 10 GB

● DBMS:

○ MySQL: 5.7.8, 8.x

○ MariaDB: 10.2+

○ PostgreSQL: 9.5+

● PHP >= 7.2

● Browser: letzte stabile Version und ESR/LTS von

Firefox, Chrome, Safari, Edge

© 2019 synetics GmbH

i-doit 2.0Technisches Leitbild & Architektur

Referent: Pavel Abduramanov

© 2019 synetics GmbH

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Agenda

Agenda

● Ziele

● Architektur von i-doit 2.0

● Wie funktioniert i-doit 2.0 von Login bis Objektlisten

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Ziele

● Verbesserung der Datenstruktur

● Übernahme von Business Logik

● Zukunftsfähiges i-doit Framework

● Erweiterbare und modulare Struktur

● Standardisierte API

● Trennung Frontend und Backend

● Migration von i-doit 1.x Daten

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Architektur

Backend

Auth API

Frontend Routes

DataLayer

Objekt Modell

Param Converter

Search Search Sources

DataAPI

Preset

...

Module

Dashboard

Finder

...

Preset Sources

Suggestion

Object Table

...

Text Control

Select Control

...

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Common Service Struktur

● Interfaces zur Beschreibung von Logik

● Austauschbar durch Interfaces

● Facade Service

● Erweiterbarkeit durch tagged Services

Facade

Interface

Class1Collection Class1

public service.id

tag service.id

Result Interface

Result Class1

Result Class2

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Login in i-doit

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Aufbau von i-doit Core

Konfiguration

Vorbereitung

Add-ons

Lizenzen

KonfigurationProvider

Add-onsProvider

LizenzenProvider

Aufbau

Registrieren Core

Registrieren Add-ons

i-doit

Services

Endpunkte

Übersetzung

usw

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Add-ons

Add-on

Endpunkte

Übersetzungen

Frontend Komponenten

Eigene Services

Erweiterungen für Kern

Erweiterungen für Data Modell

Add-on● hat eine vordefinierte Struktur● hat Zugriff zu public Services von i-doit● erweitert i-doit an bestimmten Punkten● registriert eigene Services● registriert eigene Frontend Komponenten:

Seiten, Module, Controls

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Login in i-doit

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Authentication

Authentification ChainLogin/Authentifizierung● ist mit standard Symfony Authentifizierung

Service (UserProviderInterface) gebaut● Findet einen entsprechenden i-doit User während

Matching Prozess● erweiterbar● Standard Implementierung mit eigener User

Tabelle

AuthenticationMethod

UserProvider

User

Matcher

i-doit User

AuthenticationMethod

...

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Authentication mit Ldap

Ldap Verbindung Einstellungen

AuthenticationMethod

LdapUserProvider

LdapUser

LdapUserMatcher

IdoitUser

Ldap Matcher Einstellungen

Ldap Server

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Dashboard

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Suche

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Search Service

Finder

FinderSource

RecentObjects Source

FulltextSearch Source

Search

Engine Interface

DoctrineSearch Engine

FinderItem[] SearchIndex Item[]

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Finder Page

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. Überblick

DataLayer

Category Info

Property Info

DataLayer Request

DataLayer Request

Event

DataLayer Response

DataLayer Handler

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. Info Klassen

Info

Class CollectionInfo

Classification Info Category Info Property Info

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. InfoFactory

InfoFactory

InfoProducer

Category InfoProducer

CustomCategory InfoProducer

...

InfoCollector

Properties InfoCollector

UiConfiguration InfoCollector

...

CategoryInfo CategoryInfo

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. Request Flow

Verarbeitung

Daten in DB aktualisieren

Nachbearbeitung

Daten von DB abholen

...

Vorverarbeitung

Vorbereitung Daten in Request

Rechte prüfen

Werte konvertieren

...

Durchführungdes Requests

Überprüfung und Modifikation von

Request

Vorbereitung des Responses

Relations erneuern

Logbuch aktualisieren

...

Triggern von Subprozessen

Aufrufen Subprozesse mit Information von

Request und Response

© 2019 synetics GmbH

i-doit 2.0 → Technisches Leitbild & Architektur → Zusammenfassung

Backend

Auth API

Frontend Routes

DataLayer

Objekt Modell

Param Converter

Search Search Sources

DataAPI

Preset

...

Module

Dashboard

Finder

...

Preset Sources

Suggestion

Object Table

...

Text Control

Select Control

...

© 2019 synetics GmbH

i-doit 2.0Verwendete Technologien

Referent: Kevin Mauel Leonard Fischer

© 2019 synetics GmbH

i-doit 2.0 → Verwendete Technologien → Agenda

Agenda

● Backend

○ PHP 7.2

○ Symfony

○ Doctrine

● Frontend

○ React

○ Redux

○ Sagas

○ SCSS

Verwendete TechnologienBackend

i-doit 2.0 → Verwendete Technologien → Backend → PHP 7.2

● Performance Optimierungen

● Scalar Type declarations

function sum(int ...$ints) {}

● Return type declarations

function sum(int ...$ints): int {}

i-doit 2.0 → Verwendete Technologien → Backend → Symfony

● Lange Historie (2.0 released im Juli 2011)

● Große und erfahrene Community

● Viele sinnvolle Erweiterungen

● Effiziente Entwicklung

● Bereits Erfahrung gesammelt durch i-doit 1.x

● Semantic Versioning

i-doit 2.0 → Verwendete Technologien → Backend → Symfony - Dependency Injection

● Bessere Strukturierung von Code

● DI Container Caching

● Ermöglicht u.a. tagged services

● Lazy Loading von Services

i-doit 2.0 → Verwendete Technologien → Backend → Symfony - Security

● Genutzt in Rechtesystem

○ Verwendet für User, Rechte, API

● Verschiedene Firewalls konfigurierbar

● Erweiterbar via Voter Interface

○ genutzt für Rechtesystem

● Password Encryption: Argon2i

i-doit 2.0 → Verwendete Technologien → Backend → Symfony - Messenger

● Library für Message Queues, auch synchron nutzbar

● Leicht erweiterbar für andere Queues

● Genutzt für indexierung von Suchergebnissen

i-doit 2.0 → Verwendete Technologien → Backend → Doctrine

● Nahtlose Integration in Symfony Ökosystem

● Erweiterbarer ORM für diverse Plattformen

● Migrationen für Updates

● i-doit 2.0 unterstützt:

○ MySQL: 5.7.8, 8.x

○ MariaDB: 10.2+

○ PostgreSQL: 9.5+

Verwendete TechnologienFrontend

● Wir nutzen 16.8.6 (16.0 wurde im September 2017 veröffentlicht)

● Semantic Versioning

● Große und erfahrene Community

● Effiziente Entwicklung durch Komponentenbasierte Entwicklung

● Saubere trennung von Frontend und Backend

React Angular Vue

i-doit 2.0 → Verwendete Technologien → Frontend → React

i-doit 2.0 → Verwendete Technologien → Frontend → Redux

● Umfangreicher Stand-Alone Store (oder “State Container”)

● Zentrale Stelle für Daten (State) - “one-way-binding”

● Sinnvolle Erweiterung zu React

● Entkoppelt Komponenten vom globalen State

● Konsistentes Verhalten durch strikt definierten Output

● Hervorragend Debug- und Testbar

i-doit 2.0 → Verwendete Technologien → Frontend → Sagas

● Middleware Bibliothek für Redux

● Sorgt (unter anderem) für asynchrone Anfragen an das Backend

● Vereinfacht Business Logik und Abhängigkeiten untereinander

○ (Redux) Reducers bleiben simpel

i-doit 2.0 → Verwendete Technologien → Frontend → SCSS

● CSS Compiler

● Durch Variablen eine einheitliche Definition

○ Schneller und einfacher anzupassen

● Übersichtliche Struktur: je Komponente, Container und Seite eine SCSS Datei

● Vererbung und Sinnvolle Funktionen, z.B. transparentize() , lighten() , darken() , …

● Durch Bootstrap v4.3 eine solide Grundlage (so viel wie nötig, so wenig wie möglich)

i-doit 2.0 → Verwendete Technologien → Frontend → Storybook

● Storybook ist “Styleguide 2.0”

● Interaktive Dokumentation / Spielwiese für React Komponenten

● Hilfreich für Designer und Entwickler

○ Lifecycle Events und Actions werden im Log dargestellt

© 2019 synetics GmbH

i-doit 2.0API

Referent: Kevin Mauel

© 2019 synetics GmbH

i-doit 2.0 → API → Agenda

Agenda

● Zielsetzung

● Unterschiede zu i-doit 1.x API

● Open API v3

● REST vs. JSON-RPC

i-doit 2.0 → API → Zielsetzung

● Vollständige und standardisierte API Spezifikation

● Einheitliches Verhalten bei Frontend und API

● Klare Strukturen bei API Design

i-doit 2.0 → API → Unterschiede zu i-doit 1.x API

● Teil von i-doit Kern

● Versionierung

● i-doit Frontend nutzt aktuellste Version von API

● Anstatt JSON-RPC nun REST

● Design folgt Spezifikation OpenAPI v3

● Dokumentation mittels OpenAPI v3

i-doit 2.0 → API → Open API v3

● Open API ist eine Spezifikation für API Beschreibungen

● Von OpenAPI Initiative

● Angaben von:

○ Server

○ Authentifizierung

○ Operationen

○ Request Parameter, Responses, Schemas

○ Media Typen JSON, XML

● Formate: YAML, JSON

i-doit 2.0 → API → i-doit 2.0 und Open API v3

● Command generiert Open API v3 Spezifikation (json, yaml)

● Alternativ: /api/openapi.json

● Spezifikation kann z.B. genutzt werden für:

○ Generierung von

■ API Dokumentation

■ User Interface

■ API Client (z.B. für PHP, Python, Java)

○ Prototyping z.B. mit Postman

i-doit 2.0 → API → Open API v3 → Spezifikation

49

i-doit 2.0 → API → Open API v3 → User Interface

50

i-doit 2.0 → API → Open API v3 → Client

51

i-doit 2.0 → API → Open API v3 → Postman

52

i-doit 2.0 → API → REST vs. JSON-RPC

REST

● CRUD api/v1/object/{id}

● Ergebnis entspricht Resource

z.B. api/v1/object = i-doit Objekt

● Z.b. 404 Response mit Response Body:

code: HTTP Status Code

message: z.B. Object not found.

● Subresources zur Strukturierung

z.B. api/v1/category/model/entry

JSON-RPC

● POST src/jsonrpc.php mit Request Body

● Ergebnis besteht aus:

JSON-RPC Version, beliebiges Result, id

● HTTP 200 mit error im Response Body

● POST src/jsonrpc.php

Vielen Dank!

Vielen Dank für eure Aufmerksamkeit!