Live Beispiel: K2 Contract Management mit Microsoft Teams Integration

Beim SharePoint Saturday in München haben wir eine umfassende K2 Demo zum Thema Vendor Contract Management gezeigt und dazu sehr gutes Feedback erhalten. Daher habe ich mich entschieden die Demo hier noch in einem Beitrag vorzustellen. Die Session hatte den Titel “Real-Life SharePoint: Vendor Contract Management” – der Hintergrund für die Erwähnung “real-life” war die Tatsache, dass in der Demo zahlreiche Anforderungen adressiert werden, die wir im Alltag von unseren Kunden hören:

  • die Vendor Daten liegen bereits in SAP und sollen in der Anwendung verwendet werden, ohne dass eine zusätzliche DB aufgebaut werden muss
  • Vertragsdokumente sollen im SharePoint abgelegt und dynamisch mit Inhalt gefüllt und letztlich als PDF konvertiert werden
  • neue Vertragsdokumente müssen einen mehrstufigen Freigabeworkflow durchlaufen, welcher mit mehreren Geschäftsregeln bestückt ist
    • die Rechtsabteilung soll nur bei Bedarf involviert werden
    • der CFO muss in den Prüfprozess involviert werden, wenn das Vertragsvolumen 500K übersteigt
  • geprüfte und genehmigte Veträge sollen mit DocuSign digital signiert und im SharePoint aktualisiert werden (Signatur erforderlich von internem Verantwortlichem und externem Vertreter des Lieferanten)
  • der Kunde hat sich strategisch für Microsoft Teams als Group-Chat Lösung entschieden – das Vertragsmanagement soll die Fortschritte der Vertragserstellung regelmäßig im Kanal “VendorNews” automatisch dokumentieren
  • die Lösung muss KPIs und Reports für maximale Sichtbarkeit und Transparenz bieten

Zunächst erfassen wir die Vertragsdaten und wählen u.a. auch den Lieferanten via Lookup gegen SAP aus. In diesem Beispiel wähle ich den Lieferanten “Vision Service Plan”.

Alle Daten auf einen Blick. Die Anwendung erfasst verschiedene Eigenschaften  – manche haben einen Einfluss auf den Prüfprozess (siehe oben) und involvieren dynamisch Verantwortliche oder führen zu Erinnerungsfunktionen wenn ein Vertrag ausläuft.

Nach dem Absenden werden die Daten gespeichert und ein Workflow übernimmt im Hintergrund das Routing des Vertrags.

1) Erfolgreich gespeichert und Referenznr. CTR00028 erhalten

2) Microsoft Teams automatisch aktualisiert

3) Anhand des Viewflow Controls kann man den Prozessfortschritt “live” verfolgen

Die Anwendungslogik sieht nun eine Freigabe des Abteilungsleiters vor.

Auf dem oberen Teil des Prüfformulars hat der Prüfer Einblick auf alle Vertragsdaten und zusätzliche visuelle Indikatoren. Es ist auch möglich andere K2 Apps zu referenzieren – in diesem Beispiel hinterlässt der Prüfer einen Kommentar via die App “Log Conversation”

Danach gibt er den Vertrag frei. Da der Vertrag keine Relevanz für die Rechtsabteilung hat und auch unter 500K liegt, wird sofort der Teilprozess für die Digitale Signatur gestartet.

Als erstes muss der interne Verantwortliche den Vertrag digital signieren. Über das K2 Aufgabenformular hat er Zugriff auf den Vertrag, der zwischenzeitlich als PDF Datei vorliegt und mit den korrespondieren Vertragsdaten gefüllt wurde!

Mit einen Klick kann die persönliche Sigantur gespeichert und die Aufgabe abgeschlossen werden.

Da die Anwendung automatisch den Microsoft Teams Channel befüllt, kann man dort direkt den Fortschritt nachverfolgen. Wie man sieht, wurde auch der Kommentar vom vorherigen Schritt in den Channel übertragen.

Nachdem dann der Verantwortliche des Lieferanten ebenfalls die Digitale Signatur gesetzt hat, ist der Prozess generell abgeschlossen und das Dokument wird als PDF doppelt-signiert im SharePoint abgespeichert.

Fertiger Vertrag:

Und ein letzter Blick in die Microsoft Teams App 🙂

Buffer this pageShare on LinkedInShare on FacebookTweet about this on TwitterEmail this to someone

#HowTo: Generische Swagger Datei für K2 REST Broker

In einem anderen Beitrag habe ich ausführlich erklärt, wie einfach man mit dem K2 REST Broker via IFTTT und den Maker Service praktisch jeden Dienst mit K2 ansteuern kann: LinkedIn, Facebook, Twitter, Philips Hue etc.

Grundvoraussetzung hierfür ist eine Swagger Datei, die den Service beschreibt und von dem K2 Broker genutzt wird um korrespondierende SmartObjects zu erstellen. In diesem Artikel geht es darum, wie diese Datei auszusehen hat und wie man sie letztlich den K2 Broker damit konfigurieren muss!

Zu erwähnen sei hier noch, dass ich diese Datei nun bewusst generisch aufgebaut habe, damit ich jedes Maker Ereignis auslösen kann. Natürlich könnte man auch eine Datei mit konkreten Werten aufbauen oder mit mehreren Dateien arbeiten! Der Inhalt meiner generischen Ausprägung ist am Ende des Artikels zu sehen.

Hat man die Datei erstellt muss man den REST Broker konfigurieren. Dies geht am einfachsten über die Management Site.

Wichtig ist hierbei der Speicherort der Datei. Der kann auf dem Server oder auf einer Onlineresource sein, siehe Descriptor Location.

Aber diesem Punkt ist man quasi wieder “back in business” und kann wie gehabt mit den SmartObjects arbeiten und sie direkt in der Oberfläche oder in Worklows nutzen.  Ein kurzer Test in der Management Site schadet allerdings nicht, denn vielleicht hat man ja die Swagger Datei nicht ordentlich aufgebaut.

Diese Parametrisierung entspricht allerdings exakt der Beschreibung und somit können wir wieder zurück zum eigentlichen Beitrag 🙂

Der Inhalt der generischen Swagger (.JSON) Datei ist wie folgt zu gestalten:

{
 "swagger": "2.0",
 "info": {
 "version": "1.0.0",
 "title": "IFTTTMaker",
 "description": "IFTTT Maker Test with K2 REST BROKER"
 },
 "schemes": [
 "https"
 ],
 "host": "maker.ifttt.com",
 "basePath": "/trigger",
 "paths": {
 "/{event}/with/key/{key}": {
 "post": {
 "responses": {
 "200": {
 "description": "IFTTT Response"
 }
 },
 "parameters": [
 {
 "name": "event",
 "in": "path",
 "description": "event name",
 "type": "string",
 "required": true
 },
 {
 "name": "key",
 "in": "path",
 "description": "maker key url part, keep this SECRET",
 "type": "string",
 "required": true
 },
 {
 "name": "value1",
 "in": "query",
 "description": "value1 parameter",
 "type": "string",
 "required": false
 },
 {
 "name": "value2",
 "in": "query",
 "description": "value2 parameter",
 "type": "string",
 "required": false
 },
 {
 "name": "value3",
 "in": "query",
 "description": "value3 parameter",
 "type": "string",
 "required": false
 }
 ]
 }
 } 
 }
}
Buffer this pageShare on LinkedInShare on FacebookTweet about this on TwitterEmail this to someone

K2 Everything! REST Broker mit IFTTT & Maker Service nutzen

Heutzutage kommt man in meinem Umfeld um bestimmte Themen ja nicht mehr herum – Mobile, LowCode, Cloud, IoT etc. Mit diesem Beitrag will ich kurz erklären, wie man heute bereits verschiedenste Schnittstellen als K2 SmartObject integrieren kann.

Dabei verwende ich bewusst keine alten “Klassiker” wie SharePoint, SQL oder CRM sondern habe mich für ein Beispiel entschieden, das momentan einem relativ starken Hype ausgesetzt ist und zudem representativ für IoT steht: IFTTT (If This Then That – www.ifttt.com).

Abstrahiert kann man IFTTT an dieser Stelle eigentlich gegen jeden beliebigen Dienst austauschen, der standardiesierte Schnittstellen im Internet bereitstellt – in diesem Fall via REST. Warum? REST ist der de facto Standard im Web und ermöglicht mir außerdem ohne Verwendung von Server-side Code zu integrieren. K2 setzt hierbei auf den Swagger Standard für die Dienstbeschreibung. Dementsprechend benötigt man für die Anbindung via REST Broker ein sog. Swagger-File. Diese Datei beschreibt die Servicestruktur, Objekte und Parameter für den Aufruf, diese Eigenschaften werden von dem Broker dann in K2 SmartObjects übersetzt. Aber was genau von IFTTT will ich eigentlich nutzen?

Auf IFTTT gibt es den Maker Service. Diesen Service kann man als generisches Event Hub betrachten, das von jedem Gerät oder von jeder App genutzt werden kann – vorausgesetzt es ist möglich Web Requests zu tätigen. Per Web Request kann man dann ein IFTTT Event auslösen (IF THIS) und danach praktisch jede beliebige Funktion ausführen (THEN THAT), z.B. Device Notifications senden, Dateien erstellen, Twittern, Facebook aktualisieren oder auch andere “smarte” Geräte steuern, wie z.B. Hue Lampen.

Ein Trigger für den Maker Service ist denkbar einfach aufgebaut:

  • Eventname (z.B. “Licht an”, “Twittern” etc.)
  • 3 Optionale Parameter die man in den IFTTT Rezepten dann nutzen kann

Wie man die Swagger Datei aufbauen und integrieren kann, beschreibe ich hier #HowTo: Generische Swagger Datei für K2 REST Broker

Da man mit K2 Smartforms jedes SmartObject direkt ansprechen kann, habe ich mir kurz ein kleines Dashboard erstellt:

Wie man sieht, habe ich für LinkedIn, Facebook, Twitter, Hue und den Device Notification Service ein paar Views erstellt. Diese sind alle mit einem Button zum Auslösen des IFTTT Events ausgestattet und identisch konfiguriert:

Der Parameter “event” muss entsprechend der IFTTT / Maker Konfiguration gesetzt werden. Den Key habe ich in eine Servervariable ausgelagert – falls er sich ändert, muss ich somit nur die Variable anpassen. Der Rest funktioniert automatisch!

Beispiel LinkedIn:

 

 

 

Beispiel Facebook:

Beispiel Twitter:

Das besonders praktische an der generischen Swagger Datei ist, dass ich nun IFTTT Dienste hinzufügen und integrieren kann, ohne auch nur irgendetwas an der K2 Seite konfigurieren oder ergänzen zu müssen! Ich muss nur auf IFTTT ein Maker Applet erstellen und den Namen des “event” plus 3 optionale Variablen übergeben!

 

Buffer this pageShare on LinkedInShare on FacebookTweet about this on TwitterEmail this to someone

Review: K2 Europe Customer Day 2016, Frankfurt

customerday2016

Wie schon im Jahr 2015 hatte das K2 Northern Europe Team wieder zum Kundentag nach Frankfurt geladen. Rund 50 Kundenvertreter aus Deutschland, der Schweiz, Österreich, der Ukraine und Skandinavien kamen am 5.Oktober im Hilton Hotel in Frankfurt zusammen, um sich im persönlichen Gespräch auszutauschen und natürlich auf den neuesten Stand rund um K2 zu bringen!

Neben zahlreichen Updates zu 4.7, Mobile und der neuen K2 Cloud Platform, gab es Referenzvorträge von Partnern und Kunden und eine Best Practice Session. Abgerundet wurde der Tag dann mit einer Ask The Experts Diskussionsrunde, bei der das K2NE Team von Andrew Murphy (Director Technical Sales EMEA) des K2 UK Teams unterstützt wurde.

Zum Abschluss gab es dann noch ein besonderes Gimmick. Die Gruppe von Drum Café Deutschland hat den Teilnehmern noch rhythmisch eingeheizt 😉 Wer die Gruppe nicht kennt, sollte sich dieses Video ansehen.

small_k2ne_customer_day_2016

 

Buffer this pageShare on LinkedInShare on FacebookTweet about this on TwitterEmail this to someone

K2 4.7 For SharePoint (2013 = 2016 = Online)

Mit K2 4.7 wird nun offiziell SharePoint 2016 unterstützt. Mit diesem Schritt bietet die K2 Plattform eine einheitliche und 100% kompatible Integration* über die aktuellen on-premise und cloudbasierten SharePoint-Ausprägungen!

Aber was bedeutet das eigentlich, wieso einheitlich?

Da es sich bei K2 nicht um ein (an eine bestimmte SP Version gebundenes) Add-On, sondern um eine standalone** Plattform handelt, ist es möglich mehrere / verschiedene / On-premise und/oder Cloud SharePoint Farmen mit einer einzigen K2 Infrastruktur zu betreiben. Verwendet wird hierfür eine Provider Hosted App, die letztlich als Container dient und K2 Inhalt mit zusätzlichen Funktionen im SharePoint darstellt. Daraus ergibt sich sowohl für Designer & Entwickler als auch für Anwender eine gleichgeschaltete User Experience, unabhängig von der SP Version.

Was kommt sonst noch mit?

– Globales Taskmanagement, d.h. 1 Taskliste sammelt Aufgaben aus X SharePoint Sites / WebApps / Farms
– Zentrale Verwaltung von K2 Anwendungen und Workflows über Farmgrenzen hinweg
– Unabhängige Skalierung von SharePoint, ohne Einfluss auf Technik und Lizenzkosten bei K2

Gibt es weitere Neuigkeiten?

Ja! Die App muss nun nicht mehr pro Site aktiviert, sondern kann zentral auf dem App Catalog konfiguriert werden. Es ist möglich die App automatisch auf neuen Sites zu aktivieren – was vor allem bei Site Provisioning Szenarien von Vorteil sein wird! Das automatische Aktivieren kann für bestimmte Pfade und Site Templates geschehen.

activation

*Integration
Diese Integration habe ich vor längerem im Detail mit Videobeitrag im SP Podcast von Michael Greth dargestellt, siehe Blogpost

**standalone
Mit der K2 Plattform können Anwendungen erstellt werden, die keine SharePoint-Daten nutzen und als reine Webanwendungen betrieben werden. Das Beispiel Mitarbeiter Onboarding habe ich hier dokumentiert

Buffer this pageShare on LinkedInShare on FacebookTweet about this on TwitterEmail this to someone