initial

.deployment

@@ -0,0 +1,2 @@
+[config]
+command = bash deploy.sh

.gitignore

@@ -0,0 +1,12 @@
+node_modules
+.idea
+typings
+npm-debug.log
+dist-core
+dist
+src-contract-app/lvm
+src-job-search-app/lvm
+src-wizard-app/lvm
+src-schufa-app/lvm
+.DS_Store
+!**/systemjs/dist

.nvmrc

@@ -0,0 +1 @@
+v5

AzureDeployment.md

@@ -0,0 +1,37 @@
+# Azure Auto Deployment
+
+The prototype supports azure auto deployment. Azure Websites will automatically detect our Node.js app and install required packages listed in `dependencies`, `devDependencies` will not be installed on Azure machines.
+
+By default Azure will always render the `LAS-Root` application. This behaviour can be changed by using the `LVM_APP` environment variable.
+
+## Idea
+
+There should be two websites for each branch you want to host on Azure.
+
+ * WebApp1 for `LAS-Root`
+ * WebApp2 for `LVM-Contract-App`
+
+## Configuration
+
+Configure continuous deployment using Azure's GitHub integration feature and select the same branch for both **WebApp1** and **WebApp2**.
+
+**Currently all code is only hosted in the** `develop` **branch**
+
+### Protection
+
+You can overwrite the default password for web access by setting a `LVM_PASSWD` environment variable.
+
+
+## WebApp1 (LAS-Root)
+
+Keep Azure default configuration as is. After all deployment jobs were finished for WebApp1, you should be able to access `LAS-Root` by browsing WebApp1's public URL.
+
+## WebApp2 (LVM-Contract-App)
+
+Provide the following environment variable utilising Azure's Configuration Interface for WebApp2
+
+|Variable Name|Variable Value|
+|-------------|--------------|
+|LVM_APP|src-contract-app|
+
+After you've specified the environment variable and all deployment tasks were finished, restart the Web Application to ensure a clean state. When browsing to WebApp2's public URL, you should now see `LVM-Contract-App`

README.md

@@ -0,0 +1,11 @@
+# LVM Prototyp
+
+## Prototyp starten
+
+Nach dem Klonen des Repositories müssen die Abhängigkeiten mit `npm install` installiert werden.
+
+Die Anwendung kann durch `npm run start` gestartet werden. Der Browser öffnet hierbei automatisch die App
+
+## PoC Dokumentation
+
+Die Dokumentation des PoC ist [hier zu finden](docs/readme.md)

cacheServers.js

@@ -0,0 +1,16 @@
+var startServer = require('./startCacheServer');
+
+// Root
+startServer(8000, 'dist');
+
+// Contract
+startServer(9999, 'src-contract-app');
+
+// Schufa
+startServer(9888, 'src-schufa-app');
+
+// Job Search
+startServer(9898, 'src-job-search-app');
+
+// Wizard
+startServer(9899, 'src-wizard-app');

deploy.sh

@@ -0,0 +1,130 @@
+#!/bin/bash
+
+# ----------------------
+# KUDU Deployment Script
+# Version: 1.0.6
+# ----------------------
+
+# Helpers
+# -------
+
+exitWithMessageOnError () {
+  if [ ! $? -eq 0 ]; then
+    echo "An error has occurred during web site deployment."
+    echo $1
+    exit 1
+  fi
+}
+
+# Prerequisites
+# -------------
+
+# Verify node.js installed
+hash node 2>/dev/null
+exitWithMessageOnError "Missing node.js executable, please install node.js, if already installed make sure it can be reached from current environment."
+
+# Setup
+# -----
+
+SCRIPT_DIR="${BASH_SOURCE[0]%\\*}"
+SCRIPT_DIR="${SCRIPT_DIR%/*}"
+ARTIFACTS=$SCRIPT_DIR/../artifacts
+KUDU_SYNC_CMD=${KUDU_SYNC_CMD//\"}
+
+if [[ ! -n "$DEPLOYMENT_SOURCE" ]]; then
+  DEPLOYMENT_SOURCE=$SCRIPT_DIR
+fi
+
+if [[ ! -n "$NEXT_MANIFEST_PATH" ]]; then
+  NEXT_MANIFEST_PATH=$ARTIFACTS/manifest
+
+  if [[ ! -n "$PREVIOUS_MANIFEST_PATH" ]]; then
+    PREVIOUS_MANIFEST_PATH=$NEXT_MANIFEST_PATH
+  fi
+fi
+
+if [[ ! -n "$DEPLOYMENT_TARGET" ]]; then
+  DEPLOYMENT_TARGET=$ARTIFACTS/wwwroot
+else
+  KUDU_SERVICE=true
+fi
+
+if [[ ! -n "$KUDU_SYNC_CMD" ]]; then
+  # Install kudu sync
+  echo Installing Kudu Sync
+  npm install kudusync -g --silent
+  exitWithMessageOnError "npm failed"
+
+  if [[ ! -n "$KUDU_SERVICE" ]]; then
+    # In case we are running locally this is the correct location of kuduSync
+    KUDU_SYNC_CMD=kuduSync
+  else
+    # In case we are running on kudu service this is the correct location of kuduSync
+    KUDU_SYNC_CMD=$APPDATA/npm/node_modules/kuduSync/bin/kuduSync
+  fi
+fi
+
+# Node Helpers
+# ------------
+
+selectNodeVersion () {
+  if [[ -n "$KUDU_SELECT_NODE_VERSION_CMD" ]]; then
+    SELECT_NODE_VERSION="$KUDU_SELECT_NODE_VERSION_CMD \"$DEPLOYMENT_SOURCE\" \"$DEPLOYMENT_TARGET\" \"$DEPLOYMENT_TEMP\""
+    eval $SELECT_NODE_VERSION
+    exitWithMessageOnError "select node version failed"
+
+    if [[ -e "$DEPLOYMENT_TEMP/__nodeVersion.tmp" ]]; then
+      NODE_EXE=`cat "$DEPLOYMENT_TEMP/__nodeVersion.tmp"`
+      exitWithMessageOnError "getting node version failed"
+    fi
+
+    if [[ -e "$DEPLOYMENT_TEMP/__npmVersion.tmp" ]]; then
+      NPM_JS_PATH=`cat "$DEPLOYMENT_TEMP/__npmVersion.tmp"`
+      exitWithMessageOnError "getting npm version failed"
+    fi
+
+    if [[ ! -n "$NODE_EXE" ]]; then
+      NODE_EXE=node
+    fi
+
+    NPM_CMD="\"$NODE_EXE\" \"$NPM_JS_PATH\""
+  else
+    NPM_CMD=npm
+    NODE_EXE=node
+  fi
+}
+
+##################################################################################################################################
+# Deployment
+# ----------
+
+echo Handling node.js deployment.
+
+# 1. KuduSync
+if [[ "$IN_PLACE_DEPLOYMENT" -ne "1" ]]; then
+  "$KUDU_SYNC_CMD" -v 50 -f "$DEPLOYMENT_SOURCE" -t "$DEPLOYMENT_TARGET" -n "$NEXT_MANIFEST_PATH" -p "$PREVIOUS_MANIFEST_PATH" -i ".git;.hg;.deployment;deploy.sh"
+  exitWithMessageOnError "Kudu Sync failed"
+fi
+
+# 2. Select node version
+selectNodeVersion
+
+# 3. Install npm packages
+if [ -e "$DEPLOYMENT_TARGET/package.json" ]; then
+  cd "$DEPLOYMENT_TARGET"
+  eval $NPM_CMD install --production
+  exitWithMessageOnError "npm failed"
+  cd - > /dev/null
+fi
+
+##################################################################################################################################
+
+# Post deployment stub
+if [[ -n "$POST_DEPLOYMENT_ACTION" ]]; then
+  POST_DEPLOYMENT_ACTION=${POST_DEPLOYMENT_ACTION//\"}
+  cd "${POST_DEPLOYMENT_ACTION_DIR%\\*}"
+  "$POST_DEPLOYMENT_ACTION"
+  exitWithMessageOnError "post deployment action failed"
+fi
+
+echo "Finished successfully."

docs/app-quick-access.md

@@ -0,0 +1,9 @@
+# Schnelleinstieg in zentrale Apps
+
+Wichtige Bestandteile der Gesamtanwendung müssen für den Anwender schnell zugreifbar sein um den täglichen Arbeitsablauf zu optimieren.
+
+Hierzu werden in der SPA unterschiedliche Routen definiert die aus jedem beliebigen Programmbereich angesprochen werden können. Somit kann (ähnlich wie in der aktuellen Anwendung) ein App Menu realisiert werden welches sowohl Apps im Kundenkontext als auch allgemeine Apps für den Benutzer schnell zugreifbar macht.
+
+Sobald sich der Sachbearbeiter im Kontext eines Kunden befinden ist dessen `PartnerId` innerhalb der Anwendung verfügbar und kann an die jeweiligen Routen angehangen werden. Durch das Verwenden von Routen im Schema `/apps/customer-related-app/:partnerId` kann die `PartnerId` dann an jeden Anwendungsbestandteil weitergegeben werden.
+
+Sollte die Anwendung als gesonderte App realisiert worden sein, so kann die `PartnerId` natürlich auch an die gesonderte App weitergegeben werden. Durch die Integration des `lvm-core` können bei Bedarf auch weitere kontextabhängige Informationen bei der `LAS-Root` App angefragt werden.

docs/complex-wizards.md

@@ -0,0 +1,50 @@
+#Zwischenspeichern in Wizards
+
+Im Rahmen des PoC wurde der Assistent **Brief erstellen** implementiert. Hierbei handelt es sich allerdings um einen *einfachen* Assistent, der keinerlei Zwischenspeichern des aktuellen Standes unterstützt. Im Rahmen des Gesamtprojektes werden allerdings komplexere Assistenten erstellt werden bei denen auch die Möglichkeit des Zwischenspeicherns gegeben sein soll.
+
+Der Mechanismus des Zwischenspeicherns kann auf unterschiedliche Arten realisiert werden. Der aktuelle Stand kann entweder auf dem Client oder auf dem Server gespeichert werden.
+
+Die Entscheidung ob auf dem Client oder auf dem Server gespeichert wird muss durch die fachliche Anforderung beantwortet werden.
+
+Aus technischer Sicht kann auf dem Client zwischen unterschiedlichen Speicherorten gewählt werden
+
+ * Local Storage
+ * Session Storage
+ * IndexedDB
+
+## Local Storage
+
+Der Local Storage stellt einen einfachen Schlüssel-Wert Speicher zur Verfügung der pro Anwendungsdomain angesprochen werden kann. Hier kann der Anwendungsentwickler auch strukturierte Daten in Form einer JSON Repräsentation ablegen. Hier gespeicherte Daten sind über die Browser Session hinweg persistiert, können allerdings vom Benutzer eingesehen und auch gelöscht werden.
+
+## Session Storage
+
+Der Session Storage verhält sich analog zum Local Storage allerdings wird dieser Speicher automatisch vom Browser gelöscht, sobald der Prozess beendet wird (Benutzer schließt das Tab oder den Browser).
+
+## IndexedDB
+
+Die IndexedDB erlaubt es dem Anwendungsentwickler Daten in einer NoSQL Datenbank lokal abzulegen. Bei Bedarf kann der in Anspruch genommene Plattenplatz einer Anwendung nach Bestätigung des Anwenders vergrößert werden, so dass hier enorme Datenmengen abgelegt werden können.
+
+Durch die Developer Tools kann auch dieser Speicher durch den Benutzer eingesehen und manipuliert werden.
+
+## Lokales Daten speichern
+
+Grundsätzlich sollte beim Speichern von wichtigen Daten auf dem Client immer eine Prüfziffer erstellt werden. Beim Laden der Daten aus dem gewünschten Speicher kann anhand der Prüfziffer ermittelt werden ob die Daten durch einen Dritten manipuliert wurden oder noch im Originalzustand sind.
+
+Generell muss die Anwendung auch mit dem Fall umgehen können, dass gespeicherte Daten durch den Browser (Funktion: lokale Daten löschen) oder den Anwender entfernt wurden.
+
+## entferntes Speichern (Serverseitig)
+
+Das Serverseitige Speichern hätte in diesem Fall den größten Mehrwert. Die Daten können intern gehalten werden und sind somit nicht vom Anwender manipulierbar oder gar löschbar.
+
+Darüber hinaus kann der Anwender den Assistenten an einem beliebigen Endgerät erneut aufrufen und exakt an der gleichen Stelle weitermachen, an der er zuvor den Assistenten verlassen hat.
+
+Zur Implementierung eines solchen Features wird lediglich ein `Service` benötigt. Hierbei spielt das verwendete SPA Framework keine Rolle.
+
+Bevor der Assistent dem Endanwender präsentiert wird, muss durch  einen ausgehenden `HTTP GET` Aufruf sichergestellt werden ob zwischengespeicherte Daten vorhanden sind. Sind keine Daten vorhanden, so kann der Anwender mit der Verwendung des Assistenten beginnen.
+
+Sind jedoch zuvor gespeicherte Daten vorhanden wir der Anwender darüber informiert und sollte selbst entscheiden ob er die Daten vom Server verwenden möchte oder den Assistenten **normal** (ohne die zwischengespeicherten Daten) starten möchte. Möchte der Anwender die Daten verwenden, so wird er automatisch auf die zuletzt geöffnete Seite des Assistenten umgeleitet. Jedes SPA Framework stellt Möglichkeiten zur Datenbindung bereit, daher muss nach dem Laden der Daten keinerlei **neuer Code** geschrieben werden damit sämtliche Daten wieder in der Oberfläche für den Benutzer ersichtlich sind.
+
+Eine Möglichkeit des Zwischenspeicherns wäre die implizite Speicherung, hierbei wird bei jedem Seitenwechsel im Assistent der aktuelle Zustand (Das `model`) durch eine `HTTP POST` Anfrage an den Server gesendet. Der Server ist ab diesem Zeitpunkt dafür verantwortlich die empfangenen Daten benutzerspezifisch abzulegen. Darüber hinaus wird die gleiche Logik nochmals ausgeführt wenn der Benutzer den Dialog im normalen Verlauf schließt, um sicherzustellen, dass sämtliche Daten auf dem Server vorhanden sind.
+
+Zur Ablage der Daten auf dem Server muss eine Kombination aus `Id des Assistenten`, `Id des Kunden/Interessenten` und `Id des Benutzers` verwendet werden, damit ein Sachbearbeiter möglichst viele Kombinationen an Zwischenständen auf dem Server halten kann ohne zuvor eingegebene Daten zu überschreiben.
+

docs/contract-component.md

@@ -0,0 +1,7 @@
+# Vertragsanbindung
+
+Die LAS Anwendung muss dem Sachbearbeiter einen direkten Überblick für einen Kunden geben können so dass der Sachbearbeiter direkt sehen kann ob ein Kunde weitere Verträge in anderen Sparten hat oder nicht.
+
+Im Rahmen des SPA PoC wurde hierzu die `LasFooterComponent` implementiert. Die Komponente empfängt die von der REST API bereitgestellten Metadaten zu den Verträgen des Kunden und zeigt dem Sachbearbeiter basierend darauf an, in welchen Sparten der aktuell geöffnete Kunde Verträge bei der LVM abgeschlossen hat.
+
+![LasFooterComponent](images/customer-contracts.png)

docs/customer-metadata.md

@@ -0,0 +1,13 @@
+# Wichtige Kundenmerkmale
+
+Wichtige Kundenmerkmale (oder Kopfdaten) müssen immer direkt im Zugriff sein. Der Sachbearbeiter muss in der Lage sein schnell benötigte Informationen zu finden um somit auf individuelle Ereignisse (zum Beispiel im Rahmen eines Telefonates) reagieren zu können.
+
+Im Rahmen des PoC wurde hierzu eine `CustomerMetadataComponent` entwickelt, welche wichtige Informationen zum aktuellen Kunden darstellt und dem Sachbearbeiter darüber hinaus die Möglichkeit bietet diese Daten schnell zu bearbeiten.
+
+Sollte der Anwender sich allerdings auf die Erfassung eines Angebotes, Auftrages oder sonstiger Daten konzentrieren, kann die Komponente durch einen einfache Klick minimiert werden. Im minimierten Zustand werden nur die wichtigsten Daten (zur Identifizierung des Kunden) angezeigt.
+
+Die Komponente selbst kann beliebig in Anwendungsteile integriert werden. Zur korrekten Darstellung bedarf es lediglich einer Instanz des Types `Customer`, so dass alle Werte korrekt dargestellt werden können.
+
+Die Komponente lädt die Daten bewusst nicht eigenständig um die Gesamtanzahl der `HTTP` Anfragen gegen das Backend zu minimieren.
+
+Am Beispiel der Job-Auswahl wurde auch eine gesondert implementierte AngularJS App durch das `lvm-core` Framework integriert. Somit musste an dieser Stelle der Code zur Darstellung und Abbildung der Job-Auswahl nicht mehrfach implementiert werden.

docs/customer-related-apps.md

@@ -0,0 +1,39 @@
+# Kundenbasierte Apps
+
+Viele alltägliche Aufgaben der Sachbearbeiter sind im Umfeld des Kunden angesiedelt. Deshalb wird ein Konzept zur Abbildung von **kundenbasierten Apps** zwingend benötigt, so dass zukünftige Apps einen homogenen Aufbau haben und Funktionalitäten wiederverwenden können.
+
+
+## Integration in LAS-ROOT
+
+`LAS-Root` stellt einige Funktionalitäten bereit die von jeder App wiederverwendet werden können. Durch die Verwendung der `Widget` API des `lvm-core` Frameworks können diese Funktionalitäten über die Grenze der eigentlichen Anwendung hinweg angefordert werden.
+
+Die `Widget` API ist hierbei Use Case basiert implementiert, so dass der Einstieg und die Verwendung der API für den Anwendungsentwickler sehr einfach sind.
+
+Die nachfolgenden Codezeilen sind dem PoC der Thinktecture AG entnommen und zeigen wie einfach ein modaler Dialog angefragt und das Ergebnis der Benutzerauswahl verarbeitet werden kann.
+
+```javascript
+$scope.showPopup = function () {
+  if (widget) {
+    widget.openPopup('http://localhost:9898/', { title: 'LAS Berufsuche' })
+    .then(function (result) {
+       $scope.$apply(function () {
+         $scope.selectedJob = result;
+       });
+     });
+  }
+};
+```
+
+Hierbei ist der Aufruf in einer AngularJS Anwendung (konkret die Vertragsanwendung zu finden im Repository unter `src-contract-app`).
+
+## Den Kunden-Kontext wahren
+
+Sobald die Anwendung im Kontext eines Kunden ist, steht die `PartnerId` des Kunden zur Verfügung und kann für den Aufruf von internen oder externen kundenbasierten Apps verwendet werden.
+
+Bei internen Apps handelt es sich um einfache Angular2 Komponenten, die entweder via `@Input` Property die `PartnerId` oder gar die komplette Instanz des aktuell geladenen `Customers` in Empfang nehmen. Sofern die Komponente selbstständig betrieben werden kann und die Ansicht direkt zugreifbar sein muss, besteht auch die Möglichkeit eine dedizierte `Route` für die Ansicht zu generieren. Hierzu muss die `PartnerId` dann als dynamischer Teil der Route konfiguriert werden.
+
+Die Vertragsübersicht des Kunden könnte daher über die folgende Route abgebildet werden `/customer/:partnerId/contracts`. Innerhalb der dazugehörigen `CustomerContractsComponent` wird unter Verwendung des existierenden `CustomerService` der Kunde anhand der `partnerId` geladen.
+
+Externe Apps werden mittels `iFrame` in `LAS-Root` integriert. Hierbei kann entweder die `PartnerId` an die URL der externen Anwendung übergeben werden, oder die externe Anwendung kann unter Verwendung des `lvm-core` Frameworks die aktuelle Id des Kunden bei `LAS-Root` anfragen.
+
+Dadurch ist für beide Szenarien eine einfache Integration von kundenbasierten Anwendungen in die Gesamtanwendung vorhanden.

docs/dossiers.md

@@ -0,0 +1,14 @@
+# Vorgänge
+
+Innerhalb der LAS Anwendung müssen Sachbearbeiter flexibel parallel arbeiten können um auf alltägliche Situationen reagieren zu können.
+
+In der SPA Implementierung wird automatisch ein neuer Vorgang erstellt wenn
+
+ * ein Kunde geöffnet wird
+ * der Briefkasten aufgerufen wird
+
+Über das Vorgangsmenü kann der Anwender zwischen offenen Vorgängen wechseln ohne dass hierbei Daten verloren gehen.
+
+Jeder Vorgang selbst merkt sich die zuletzt eingegeben Daten und die zuletzt dargestellte Ansicht.
+
+Sofern **mindestens zwei Vorgänge** existieren, kann der aktuelle Vorgang über den Button **Kunde schließen** entfernt werden. Der davor besuchte Vorgang wird nach dem Schließen wieder aktiviert und der Anwender kann die App wie gewohnt weiter verwenden.

docs/field-audit.md

@@ -0,0 +1,21 @@
+#Freischalten gesperrter Felder
+
+Einige Felder der Anwendung sollen lediglich nach expliziter Freigabeanforderung vom Bearbeiter anpassbar sein. Hierbei kann eine beliebige Logik vom Server angesprochen werden um festzustellen ob der aktuelle Anwender das Feld bearbeiten darf oder nicht.
+
+Im Rahmen des PoC wurde ein solches 'gesperrtes' Feld exemplarisch im UseCase **Neues Angebot erstellen** implementiert.
+
+Es wurde eine wiederverwendbare Komponente `LvmLockedControl` erstellt, welche es dem Anwendungsentwickler ermöglicht beliebige Felder nur nach expliziter Freischaltungsanfrage des Benutzers in den Editiermodus zu versetzen.
+
+Die API des `LvmLockedControl`'s bedarf keiner weiteren Programmierung, es muss lediglich das benötigte Markup für das Eingabefeld erstellt werden
+
+```
+<lvm-locked-control [caption]="'Schäden'">
+
+    <input type="text" class="form-control" />
+
+</lvm-locked-control>
+```
+
+Die Komponente selbst kümmert sich um die Freigabe des Feldes. Die API des PoC stellt keine Schnittstelle zur Prüfung der Freigabe bereit, daher wird das Feld direkt nach Anfrage des Benutzers für die Bearbeitung freigegeben. Eine eventuelle Integration einer auf dem Server bereitgestellten Schnittstelle kann in der Methode `unlockControl` vorgenommen werden. Exemplarisch wird im aktuellen Stand des PoC hier eine einfache Ausgabe in der Browser Console vorgenommen. Für den Anwender wird ein **gesperrtes Feld** wie folgt dargestellt
+
+![Feld entsperren](images/unlock-control.gif)