#HowTo: Mit K2 und PubNub in der Echtzeit

Nicht selten bin ich damit beschäftigt, K2 Interessenten zu erklären worum es sich bei einer LowCode App Plattform wie K2 eigentlich handelt. Gerade bei “echten” Entwicklern entsteht schnell der Eindruck dass man beim Arbeiten mit derartigen Plattformen irgendwann nicht mehr gebraucht wird oder alle Flexibilität eingebüsst werden muss, was wohl zu der Befürchtung führt, dass man als Entwickler nicht mehr mit den allerneuesten Frameworks und Services “spielen” darf.
Auf den ersten Blick ist diese Reaktion nachvollziehbar und natürlich, und ja, natürlich muss man sich an diverse Gegebenheiten anpassen – aber bedeutet das wirklich, dass man als Entwickler in der K2 Welt gefangen wäre? Setzt man diese (frühe) Wahrnehmung vor den Spiegel der Realität, lässt sich deutlich erkennen, dass K2 Kunden oftmals Anforderungen umsetzen, die ziemlich weit entfernt vom Standardverhalten einzuordnen sind. D.h. Kunden profitieren permanent von Standardfunktionen die mit der Plattform kommen (HTML5 UI Technologie, Mobile-Readiness, Workflowengine, Datenintegration, invididuelle Dashboards etc.), können aber aufgrund von APIs oder durch Komponenten wie den REST Broker auch Funktionen bzw. externe Services nutzen, ohne überhaupt die K2 Infrastruktur dafür anfassen zu müssen (Stichwort: Cloudkompatibilität).
Ein nettes Beispiel hierfür ist ein Cloudservice wie PubNub!

Was ist PubNub?

APIs for developers building secure realtime Mobile, Web, and IoT Apps.The PubNub Data Stream Network powers low-latency secure messaging at massive

Wie kann man mit K2 Nachrichten an einen PubNub Channel senden?
Ganz einfach und ohne Service-Side Code. PubNub bietet wie fast alle modernen Plattformen eine REST API, welche mit dem K2 REST Broker genutzt werden kann.
Für eine genaue Beschreibung bitte diese Doku lesen
https://www.pubnub.com/docs/pubnub-rest-api-documentation#publish-subscribe-publish-v1-via-post-post

Die URI sieht generisch wie folgt aus:
“https://pubsub.pubnub.com/publish/{pub}/{sub}/0/{channel}/0”

Was fehlt ist die einmalige Erstellung einer sog. SWAGGER Beschreibung für die Verbindung zu K2. Praktischerweise übersetzt der K2 REST Broker alle erwarteten Werte als Inputparameter für SmartObject-Methoden. Das Ergebnis ist ein wiederverwendbares, typisiertes Objekt im Repository, das man nun direkt von der UI aus oder in Workflows via Drag&Drop nutzen kann.

Eine mögliche Ausprägung der Swagger (JSON) Datei könnte so aussehen:

https://1drv.ms/u/s!Alwsd9IjhMleiqYt8I5fyRE_UV-xHw

(Hinweis: Natürlich wäre es auch möglich den Aufruf ohne den REST Broker via JS direkt auf einem K2 Formular zu machen. Dann würde die Nachricht sogar komplett am K2 Server vorbei an PubNub publiziert – allerdings hätte man dann nicht den Vorteil eines generischen und wiederverwendbaren Objekts und die Funktion wäre auch nicht in WFs nutzbar!)

Das SmartObject kann dann wie gehabt, in den K2 Designern typisiert genutzt werden.

K2 Smartforms Regeldefinition, nach einem Mausklick auf einen Button soll eine PubNub

Regelkonfiguration

Das funktioniert natürlich genau so in den K2 Workflow Designern, wo man nun on-demand an jeder passenden Stelle eine Nachricht an PubNub übermitteln kann:

SmartObject Event Methodenauswahl

In einer echten App kann das ganze dann so aussehen. Im rechten Fenster hinterlässt der Benutzer Bob eine Nachricht, die dann im Dashboard eines anderen Benutzers dargestellt wird:

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

K2 @ CeBIT 2017 – Halle 3, Stand H36

Auch in diesem Jahr ist unser Team wieder auf der CeBIT vertreten. Alle Kunden, Partner und Interessenten sind herzlich eingeladen, uns am Stand zu besuchen.

Es gibt neben der Möglichkeit jederzeit live am Stand eine K2 Demo mitzunehmen, auch den täglichen Vortrag in der BPM Area.

Jeden Tag um 12 Uhr:

LowCode Plattformen und BPM – Agile Umsetzung von Prozessen

K2 findet man in Halle 3 am Stand H36 in der sog. BPM Area.

Hallenplan 

Direktlink
http://ssp.deepmap.de/respmap/#/map/cebit17/de/exhibitor/T541709

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

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