Slack et al. - Lernen von den Digitalen (4)

Von Matthias Geisler 09.06.2016
Slack et al. - Lernen von den Digitalen (4)

“Seamless Process Integrations” (Custom Integrations)

In diesem Blog Beitrag wird es nun (endlich?) technisch(-er), soll es doch um die Integration von Slack in die (Geschäfts-) Prozesse des eigenen Unternehmens, der Abteilung oder Teams gehen.

Slack bietet hierzu eine Handvoll von Möglichkeiten an. Diese im Einzelnen vertieft zu beleuchten würde zwar den Rahmen dieses Blogbeitrages sprengen — aber ohne eine einführende Übersicht gleich in ein Beispiel abzutauchen, möchte ich dann auch nicht.

Apps vs. Custom Integrations

Die Dokumentations-Webseite von Slack (api.slack.com) bietet eine gute Übersicht und Einstieg in den Betreff.

Die erste Unterscheidung ist dann gleich die Folgende:

  1. Slack Apps

    Darunter sind Integrationen unter Nutzung der Slack API zu verstehen, die (auch) anderen Slack Kunden (Teams) z.B. über Slack’s App Directory (slack.com/apps) zur Nutzung angeboten werden können — eben Apps.

  2. Slack Custom Integrations

    Hierbei handelt es sich um alle konfigurierten Integrationen eines bestimmten (=des eigenen) Slack Teams mit bestehenden internen und externen Services des Unternehmens — ebenfalls unter Nutzung der Slack API.

In diesem Blog Beitrag soll es uns um letzteres, also die Custom Integrations gehen, sind diese doch das Mittel der Wahl im Kontext der eigenen Slack Nutzung.

Hier stehen uns folgende 4 Komponenten zur Auswahl:

  1. Incoming Webhooks — um Daten in Echtzeit an Slack zu senden, z.B. aus eigenen Enterprise oder SaaS Anwendungen.
    —› api.slack.com/incoming-webhooks
  2. Outgoing Webhooks — um Daten aus Slack an Slack-externe, eigene Services zu senden, ebenfalls in Echtzeit.

    —› api.slack.com/outgoing-webhooks
  3. Bot Users — eine Möglichkeit im Dialog-/ Konversationsstil mit Slack-externen Services zu kommunizieren oder eigenen Code aufzurufen/ auszuführen.

    —› api.slack.com/bot-users
  4. Slash Commands — Ergänzung der eingebauten sog. Slash Commands zur Ausführung von Aktionen, durch eigene.

    —› api.slack.com/slash-commands

Ich habe jeweils den direkten Link zur wirklich empfehlenswerten Online Dokumentation für die jeweilige Komponente ergänzt.

Der Einstieg ist wirklich denkbar einfach — ein Beispiel:

Anwendungsfall Benachrichtigung über Produktdatenimport

Im Rahmen der (Continuous) Deployment Pipeline für eine Webanwendung wird ein Delta-Produktdatenimport durchgeführt — automatisiert, einmal täglich, zu nachtschlafender Stunde.

User Story:

Als Slack DevOps Teammitglied möchte ich über das Ergebnis des Produktimport informiert werden damit ich ggf. steuernd eingreifen kann.

Akzeptanzkriterien:

  • Im Erfolgsfall Nachricht mit der Anzahl neuer, geänderter, gelöschter Produkte in dem Slack Channel devops.
  • Im Fehlerfall Nachricht mit Fehlermeldung (Log-Statement(s)) in dem Channel devops-tower.

Für die Umsetzung der skizzierten Anforderung bietet sich die Komponente Incoming Webhook an.

Im einfachsten Fall senden wir die JSON-Payload mit der Slack-Nachricht über ein Shell-Skript.

Dieses setzt einige Shell-Variablen (SLACK_WEBHOOK_USERNAME=transporter, PRODUCT_INDEX_NAME=products, …) entsprechend dem Umgebungs-spezifischen Kontext (z.B. Staging vs. Production Umgebung) und ruft schliesslich dass in der API-Entwicklung nahezu omnipräsente Hilfsprogramm curl auf, um den HTTP POST Request mit der formatierten Slack-Nachricht als JSON-Payload zu senden.

Nachfolgend der curl Befehl — zur besseren Lesbarkeit ergänzt um zusätzliche Zeilenumbrüche:

curl -X POST --data-urlencode \
  "payload={
      \"channel\": \"${SLACK_WEBHOOK_CHANNEL}\",
    \"username\": \"${SLACK_WEBHOOK_USERNAME}\",
    \"text\": \"Changelog to Index \`${PRODUCT_INDEX_NAME}\`:\n
            - ${PRODUCTS_COUNT_ADDED} added\n
            - ${PRODUCTS_COUNT_CHANGED} changed\n
            - ${PRODUCTS_COUNT_REMOVED} removed\",
    \"icon_emoji\": \":truck:\"
    }" \
    ${SLACK_WEBHOOK_URL}

Im Ergebnis sieht die formatierte Slack-Nachricht dann so aus:

Dieser Anwendungsfall ist zugeben ein sehr einfaches aber gerade deswegen auch sehr mächtiges Beispiel für die Integration mit Slack, kann doch von da nahezu jedweder Technik ein Incoming Webhook Request erstellt werden und die dafür nötige administrative Konfiguration mit wenigen Klicks erstellt ist.

Anwendungsfall Anwendungsintegration

Spannender wird es schon wenn es um tiefergreifende Integrationen geht — z.B. von zwei Anwendungen.

Die folgende Integration von Slack mit IBM Connections (On-premises) wurde im Rahmen der BeaS Labs umgesetzt.

User Story:

Als ein Slack Teammitglied, möchte ich eine Nachricht in Kopie an einen IBM Connections Anwender oder eine Community schicken können um Informationen zu teilen.

Akzeptanzkriterien:

  • Die mit einem IBM Connections Anwender geteilte Nachricht soll in IBM Connections kommentier- und suchbar sein (—› Microblog).
  • Die an eine IBM Connections Community adressierte Nachricht soll inkl. Slack-spezifischer Formatierung (Links, Emoji) in dem Activity Stream der Community publiziert werden (—› Embedded Experience).
  • Die Nachricht soll nur über Angabe von Vor- und/ oder Nachname bzw. Community-Titel adressiert werden.
  • Die Benutzerdatenbanken von Slack und IBM Connections sind nicht synchronisiert, es besteht kein Single-Sign On und keine OAuth Integration.

Für die Umsetzung dieses Anwendungsfalls eignet sich besonders die Bot User Komponente.

Dabei dient ein Bot sowohl als “Mittelsmann” (Actor) für die technische Integration und Kommunikation mit den unterschiedlichen REST APIs von Slack und IBM Connections (z.B. Slack/ JSON vs. IBM Connections/ Atom XML) als auch als Kommunikationspartner für den Anwender in Slack (z.B. Ansprache des Bot Users nach Einladung in einen Slack Channel oder als Direktnachricht).

Für die Anwendung wurde ein (Chat) Slack Bot in Node.js umgesetzt welcher einen korrespondierendes IBM Connections Benutzerkonto besitzt. Dabei dient die identische Benennung (“harambot” — hüben wie drüben) einzig einer konsistenten Benutzererfahrung (UX) und ist nicht technisch-bedingt.

Screenshot einer Direktnachricht an den Slack Bot “harambot”, geteilt in Kopie mit dem Autor selbst (… cc me):

Screenshot der obigen Nachricht von “harambot” als Microblog Post aus dem Profil des Autors in IBM Connections

Screenshot einer Direktnachricht, geteilt in Kopie (… cc community…) mit einer IBM Connections Community über den Slack Bot “harambot”

Screenshot der Nachricht und der Slack Embedded Experience aus dem Activity Stream der IBM Connections Community

Fazit

Ich denke doch, dass die beiden beschriebenen und jeweils in einer konkreten Umsetzung gezeigten Anwendungsfälle das Potential der Nutzung von Slack’s “Custom Integrations” für die Integration mit bestehenden (Enterprise) Anwendungen und Services zeigen — und zwar in seinem kompletten Spektrum: von einfach/ schnell bis hin zur effektiven Verbindung von unterschiedlichen “Collaboration Galaxien” (Slack/ IBM Connections).

Nach meiner/ unserer Erfahrung in der Umsetzung verschiedener Integrationen gibt es hinsichtlich der funktionalen Tiefe einer Integration bzw. der Tauglichkeit dieser für den Produktiveinsatz — im Vergleich zu anderen API-basierten Integrationen — wenig, bis nichts besonderes zu beachten. Wir konnten zumindest bis dato immer eine Lösung finden (Wenig Emojis? IBM Connections, looking at you!).

… und der Autor möchte noch ergänzen: Spaß macht es (speziell die Bot Programmierung) obendrein! :-)

So long… <3

Über den Autor

Matthias Geisler Technical Architect
"I want the web to win as a platform."

Follow me