Versionen

Wenn eine Änderung an Automatisierungen durchgeführt werden muss birgt das immer auch die Gefahr das plötzlich etwas nicht mehr wie gewünscht funktioniert. Natürlich testet man vorher alle Möglichkeiten durch – dennoch bleibt vor allem bei größeren Änderungen immer ein Unbehagen ob nicht etwas übersehen wurde oder ob nicht bestimmte Daten und mögliche Zustände aus der Produktivumgebung nicht vollständig durch Tests abgedeckt wurden.

Wenn nun etwas nicht wie gewünscht funktioniert wäre es gut wenn ein Knopfdruck reicht um wieder zur vorherigen Version der Automatisierung zurück zu gehen.

Dies ist beim Automator von Anfang an inkludiert!

Mit dem Menüpunkt „New Environment Version“ kann eine neue Version des aktuellen Environments (sandbox oder production) erzeugt werden – über Dialog der durch den Menüpunkt „Select Environment Version“ angezeigt wird kann jederzeit die vorige oder eine beliebige andere Version wieder aktiviert werden.

Versionen Dialog neu G.png

Dabei wird angezeigt wann die Version angelegt wurde, sowie wann diese zuletzt gespeichert wurde.

Versioniert werden Environments als ganzes – daher ist bei einer Aktivierung einer anderen Version alles genau so wie in dieser konfiguriert.
Keine Überlappungen, keine gegenseitige Beeinflussung.

Empfohlenes Vorgehen: Bei größeren Änderungen immer eine neue Version anlegen, damit zurück geschalten werden kann bzw. ein manueller Vergleich zwischen bestimmten Konfigurationsbestandteilen möglich ist.
Sobald die Änderung funktioniert sollte nur mit der neuen Version gearbeitet werden. Auch wenn es technisch möglich ist macht es keinen Sinn mehrere verschiedene Versionen gleichzeitig zu editieren – dies führt auf lange Sicht zu Verwirrung welche Version die korrekte ist. Dabei sollte insbesondere nicht nur auf das Versionsdatum sondern auch auf das ebenfalls angezeigte letzte Änderungsdatum geachtet werden.

Fazit: Seit Anbeginn wurde die Art und Weise wie die Konfigurationen und Scripts im Automator gespeichert werden auf eine sichere Versionierung getrimmt. Dies dient massiv der Sicherheit bei Änderungen – es ist jederzeit möglich auf eine vorherige Version zurück zu gehen und diese wieder zu aktivieren, oder aber manuell zu prüfen in welchen Punkten sich die vorherige Version von der aktuellen unterscheidet.

 

Advertisements

Neue Templates

Schon vor einigen Wochen wurde hier die neue Execution Engine beschrieben und damit auch auf die neuen ASP-Style Templates hingewiesen. Letztere sind zwar unglaublich mächtig, aber es braucht auch eine einfache, rein Ersetzungsbasierte Template Engine. Diese liegt nun in der neuesten Version vor, und ist derzeit in der Demo Umgebung zu testen.

Die neuen Templates zeichnen sich durch eine vereinfachte Markup Syntax aus, die an die AngularJS Syntax angelehnt wurde:

{{request.id}}

Wird ein Ausdruck wie dieser gefunden, so wird versucht die Variable aufzulösen und an dieser Stelle einzusetzen. Wird die Variable nicht gefunden, so wird ein Leerwert eingesetzt.

Natürlich sind auch Formatierungen möglich:

{{formatDateTime(request.created,'DD/MM/YYYY HH:MM z','Vienna')}}

Die erlaubten Funktionen beschränken sich logischerweise auf die Essentiellen Formatierungsfunktionen. Alles was darüber hinaus geht sollte sinnvollerweise im Package oder im ASP Style Code abgebildet werden.

Als weitere Möglichkeiten der neuen Templates gibt es Bedingungen:

{{?request.service_instance.id==1500}}
  Die Service Instanz ID ist 1500
{{?}}

Und natürlich Wiederholungen:

{{@request.notes}}
    Kopfzeile
        {{*item,item.internal==false}}
            {{item.id}} - {{item.note}}
        {{*}}
    Fußzeile
{{@}}

Neu ist das eine einzelne Iteration durch eine Bedingung geprüft werden kann – im Beispiel werden nur Elemente gerendert die nicht internal sind. Sollen alle Elemente gerendert werden, so kann man die Bedingung einfach weglassen.

Wie bisher gilt das Wiederholungen und Bedingungen nicht ineinander verschachtelt sein dürfen, da es sich um eine einfache Ersetzungsfunktionalität handelt die ansonsten zu komplex für die Benutzung wird – dafür sind die mächtigen Features der ASP-Style Templates geeignet.

Klarerweise sind alle bisherigen Templates kompatibel mit der neuen Template Engine und auch mit der Execution Engine.

Fazit: Mit der erweiterten Template Engine wird das Erstellen von Vorlagen nochmals einfacher! Insbesondere weil für komplexere Situationen auf die ASP-Style Schreibweise zurückgegriffen werden kann, welche die Klammern-Schreibweise implizit erweitert.

Cluster und Failover

Nach gut einem Jahr der Entwicklung ist es nun soweit – das was jedes Server Produkt als Grundvoraussetzung mitbringen sollte ist nun auch im automator realisiert:

Die Fähigkeit in einem Cluster zu laufen sowie die Integration eines Failover Systems.

Man sollte meinen das ist nicht besonders schwierig. Einfach einen Load Balancer vorschalten der die Webhook Aufrufe verteilt, und schon kann man dahinter mehrere Server laufen lassen, bei denen die jeweiligen Aufrufe abgearbeitet werden.

Jeder der sich mit dem Thema auseinandersetzt weiß natürlich das dies nur die eine Seite der Medaille ist.

Zwar funktioniert dieser Ansatz wenn man sauber programmiert für die eingehenden Webhooks, die ja ohnehin asynchron eintreffen und daher auch ebenso auf unterschiedlichen Systemen verarbeitet werden können. Hier ist nur darauf zu achten das Änderungen in der Konfiguration immer auf allen Servern Zeitnah mitgezogen werden. Weiters muss der Load Balancer über die Auslastung der einzelnen Server Bescheid wissen um die eingehenden Webhooks sauber verteilen zu können.

Ganz anders sieht es bei der Verarbeitung von Mails oder Zeitlichen Ereignissen aus – da sie nicht von Webhooks unabhängig sind nennen wir sie Independent Events. Ein eingehendes Mail darf nur von einem Server angenommen und verarbeitet werden, und nicht von allen Servern im Cluster. Genauso darf ein zeitliches Ereignis nur jeweils von einem Server abgearbeitet werden. Wäre ja seltsam wenn jeden Tag ein Package mit einem Kontrollpunkt Mail laufen würde, und dieses Mail entsprechend der Anzahl der Server im Cluster ankommt…

Für den automator haben wir dieses komplexe Thema verbunden mit einem Failover System. Beim Start eines Servers prüft dieser ob er für die Independent Events zuständig ist und übernimmt gegebenenfalls die Verantwortung dafür. Muss dieser Server für Wartungszwecke heruntergefahren werden, übernimmt ein anderer seinen Part und damit auch die Verantwortung über die Independent Events. Dabei ist sichergestellt das auch während der Übergabe immer nur ein Server wirklich verantwortlich ist, und keine Aktionen mehrfach ausgelöst werden können, bzw. kein Ereignis verloren gehen kann.

Von Seiten der UI oder der Packages wird davon niemals jemand etwas mitbekommen – und dennoch ist dieses Thema immens wichtig, denn:

Jeder der mit dem automator arbeitet sollte die Gewissheit haben das im Hintergrund eine starke Maschine ihre Aufgaben verrichtet. Eine Maschine auf die man sich verlassen kann.

 

Slack Integration

Stark vereinfacht gesagt ist Slack ein Firmen Internes WhatsApp – es regelt die Unternehmensinterne Kommunikation auf recht einfache Art und Weise.

Slack in den automator zu integrieren funktioniert über den generischen REST Account:

SLACK_integration.png

Die URL findet sich auf der eigenen Slack Page unter „Add an app or integration“.

In diesem Fall habe ich den eingehenden Webhook genau so genannt – entsprechend sieht das Ergebnis aus:

slack_incoming_message.png

 

Wie kommt dieses zustande?

Erstmal die automator Konfiguration Version:

slack_dnd.png

Aber es geht natürlich auch als Script:

slack_rest_code.png

Das Script wie ab jetzt immer mit der engine V2.

 

 

Templates – ASP-Style Syntax

Mit der neuen Version der execution Engine ist im automator auch eine neue Syntax im ASP-Style für Templates realisiert worden.

Innerhalb der ASP-Style Klammern ist es nun möglich normale automator Script Anweisungen zu schreiben und mit der echo Funktion template Elemente auszugeben.

Das sieht an einem Beispiel wie folgt aus:

<html>
<head><title>Templates V2</title></head>
<body>
	<h1>Header in Template</h1>
	<p>Variable from Package : <%=$MaxAnzahl%>
	<% 
	for(let i=0;i<$MaxAnzahl;i++) {
		echo("<p>Line from code :"+i+"</p>");
	}
	%>
</body>
</html>

Die neuen Möglichkeiten der Templates sind damit wesentlich weitreichender als bisher! Wichtig ist das ein V2 Template nur in V2 Packages bzw. V2 Services genutzt werden kann. In einem UI-Service können Templates jetzt sogar ohne Package genutzt werden, in dem der gesamte Package Code auch im Template stecken kann.

Hier gehts zum techwork automator

ASP ist ein eingetragenes Markenzeichen von Microsoft

Javascript V2016 – EC6

Die Scriptsprache des automator basiert auf Javascript. Zur Vereinfachung des Gesamtsystems haben wir einige  Erweiterungen eingeführt die nun mit der Version 2 der Execution Engine wegfallen.

Damit ist ein wichtiger Meilenstein erreicht:
Die automator Script Sprache ist nun vollständig kompatibel mit der aktuellen Javascript Version EC6. Um genau  zu sein ist die automator Script Sprache eine Teilmenge von EC6. Es gibt keine Klassen und erweiterte Funktionen – aber wer weiß ob das nicht in zukünftigen Versionen Sinn machen würde – wenn ja dann werden wir es sicher rasch einbauen!

Was ist alles enthalten:

  • Variablendeklaration mit var, let und const
  • if, else, Blockmanagement
  • for, for in, for of, break
  • while, do…while
  • switch
  • regex
  • Basisfunktionen wie
    • isFinite
    • isNaN
    • parseFloat
    • parseInt
    • decodeURI
    • decodeURIComponent
    • encodeURI
    • encodeURIComponent
  • Basisobjekte wie
    • JSON
    • Math
    • Number
    • Date
    • Infinity
    • NaN
    • undefined
    • true, false
  • Standardoperatoren wie
    • Logische Operatoren (==, !==, <, >, <=, >=, ===, !==, ||, &&, in)
    • Mathematische Operatoren (+, -, *, /, %)
    • Ternärer Operator (? 🙂

und darüber hinaus natürlich die erweiterbare Funktionsbibliothek für den Zugriff auf ITRP, REST (z.b. JIRA) oder GRAPH (Office 356, SharePoint) Systeme, sowie Logging, Templates und external Proxy Aufrufe für Firmen interne Systeme.

Natürlich bleiben alle vorhandenen Scripts vollständig lauffähig. In den Package Settings findet sich ein Schalter zum Umstellen auf die neue Version sobald der Code angepasst wurde. Aber warum etwas ändern wenn es gut läuft – Neue Packages können jedoch nun mit noch mehr Sprachfeatures entwickelt werden als bisher.

Fazit
Das bedeutet das jede/r JS Developer auch automator Script schreiben kann ohne zusätzliche Lernhürden. Systemautomatisierung wird damit nochmals um vieles einfacher.

Hier gehts zum techwork automator

Hinweise zu angesprochenen Marken:
JIRA ist eine geschützte Marke von Atlassian
Office 365 und SharePoint sind geschützte Marken von Microsoft

automator Vorgehensmodell

Eines der wichtigsten Ziele beim Design des automator war das es möglichst einfach und effizient sein muss die gewünschten Automatisierungen zu erstellen, zu testen, in Produktion zu bringen und dort zu warten. Dazu wurde ein Vorgehensmodell erstellt das im folgenden erläutert wird.

Environments und Profile:

Es wird davon ausgegangen das für Produktivsysteme immer Testsysteme – so genannte Sandboxes – im Unternehmen oder in der Cloud zur Verfügung stehen bzw. relativ leicht eingerichtet werden können. In diesen Sandboxen können Konfigurationsanpassungen, Scripts oder eben Automatisierungen auf sichere Art und Weise aufgebaut und getestet werden ohne das Produktivsystem zu gefährden.

Eine solche Umgebung nennt sich im automator ein „Environment“.
Normalerweise stehen in einem Unternehmen ein „sandbox“ Enviroment und ein „production“ Environment zur Verfügung. Bei größeren Unternehmen steht oftmals zusätzlich noch ein „development“ Environment bereit.
Mehrere zusammengehörende Environments ergeben ein automator Profil.

Accounts:

In einem Environment werden Zugangsinformationen für die Systeme abgelegt auf die zugegriffen werden soll. So genannte Accounts. Im sandbox Environment die Accounts für die Sandbox Systeme – im production Environment die Accounts für eben diese.
Dabei wird darauf geachtet das die Alias Bezeichnungen für die Accounts in den jeweiligen Environments identisch sind.

Beispielsweise soll es in beiden Environments einen JIRA REST Account mit der Alias Bezeichnung „JIRA-REST“ geben.
Der „JIRA-REST“ Account im Sandbox Environment verweist auf die JIRA Sandbox. Der „JIRA-REST“ Account im Production Environment verweist auf die Production.

In der jeweiligen Automatisierung wird nur und ausschließlich mit dem Alias Namen gearbeitet – das ermöglich einen einfachen Transfer von sandbox zu production, ohne das an der Automatisierung selbst noch etwas geändert werden muss.

Anmerkung zur Sicherheit: Alle Account Informationen werden im automator verschlüsselt abgelegt und liegen weder in der Konfigurations Datenbank noch im Speicher im Original vor. Erst wenn ein Zugriff durch eine Automatisierung angefordert wird kommt es zur Entschlüsselung um das Zugriffskonto freizugeben.

Packages:

Eine Automatisierung im techwork automator definiert sich durch

  • Auslösendes Ereignis z.B. Webhook, Scheduler, Mail In oder Service
  • auszuführende Aktionen z.B. Script, Drag and Drop Konfiguration oder UI Service Template
  • Account unter dem die Automatisierung ausgeführt werden soll.

Eine eindeutige Kombination aus diesen Bestandteilen nennt sich Package.

Im Package wird auf die Accounts ausschließlich über deren Alias Bezeichnung zugegriffen (im Beispiel oben „JIRA-REST“). Daher muss ein Package beim verschieben von sandbox Environment zu production Environment nicht mehr gesondert angepasst werden.

Ist also sichergestellt das ein Automatisierungs Package in der Sandbox funktioniert, kann es über einen einfachen Menübefehl in die Production verschoben werden.

Für Packages stehen Logging, Test und Debugging Mechanismen zur Verfügung.

Defaults, Mail In und Mail Out

Damit das verschieben ohne weitere Änderung von sandbox zu production vollständig und durchgängig gewährleistet werden kann, stehen im Environment nicht nur Accounts zur Verfügung, sondern auch Mail In und Mail Out Konten mit frei definierbaren Alias Namen, sowie die Möglichkeit Default Einstellungen mit Environment spezifischen Werten zu hinterlegen. Diese können in den Packages genutzt und abhängig von den Werten unterschiedlich agiert werden.

Bei der Erstellung der Automatisierungs Packages muss so vorgegangen werden das keine Environement spezifischen Information im Package liegen, sondern immer nur mit den Account Alias Bezeichnungen und den Environment Einstellungen – den Defaults – gearbeitet wird.

automator Vorgehensmodell:

Eine Automatisierung wird in der Sandbox entwickelt und getestet.
Ist sichergestellt das die Automatisierung korrekt funktioniert und sich auch mit anderen Automatisierungen gut integriert, wird die Automatisierung in die produktion verschoben und ist ab diesem Zeitpunkt dort aktiv. Schnell, einfach und effektiv!

Versionen:

Wenn eine Automatisierung in die Production verschoben wird, wird auch eine neue Version der production angelegt. Sollte also irgend etwas nicht so funktionieren wie gewünscht, kann mit nur einem Mausklick auf die Vorversion zurück gegangen werden.

Fazit:

Effiziente, rasche und einfache Entwicklung von Automatisierungen sind Teil des Grunddesigns des automator. Im Gegensatz zu herkömmlicher Webhook Entwicklung auf eigenen Servern ergibt sich ein Produktivitätsvorteil von bis zu 80 %

Hier gehts zum techwork automator

(Atlassian JIRA, ITRP, Microsoft SharePoint, Microsoft OneDrive und Microsoft Office 365 sind Marken der jeweiligen Inhaber und als solche rechtlich geschützt).

UI-Services

Die Idee hinter UI Services ist das für bestimmte Zwecke spezielle angepasste User Interfaces notwendig sind, oder auch nicht allen Usern ein Zugang zu ITRP zur Verfügung gestellt werden soll bzw. kann.

Mit UI-Services kann ein HTML UI in Form eines Templates zur Verfügung gestellt werden. Die Informationen auf diesem HTML UI können durch ein eigenes Package abgerufen werden. Das GET Ereignis für die Anforderung der HTML UI dient dann als Auslöser des Package. Das Package wird vor der Anzeige des Template ausgeführt. Das Template hat Zugriff auf die Daten aus dem Package und kann diese an den Client schicken.

UI Service Form.png

Ist auf der HTML UI ein Formular enthalten, kann durch den User ein POST Ereignis ausgelöst werden. Auch dazu kann wiederum ein Package ausgeführt werden. Dieses Package hat Zugriff auf sämtliche Daten aus dem Formular.

Das Beispiel auf den Screenshots zeigt für eine anzugebende Serien Nummer an wem diese zugeordnet ist.

Ein UI Service definert sich also wie folgt:

  • URL für den Abruf des Service im Browser
  • GET Ereigniss für die Datenzusammenstellung
  • HTML UI Template für die Darstellung der Daten bzw. des Formulars
  • POST Ereigniss für die HTML Form Datenverarbeitung

 

UI Service Settings.png

Die Service Form URL die am Ende der Service Definition abrufbar ist, kann via Email oder Social Networks verteilt werden. Eine andere Möglichkeit ist die Generierung eines QR Codes für die URL damit dieser per Smartphone eingelesen werden kann und die User direkt auf das Formular kommen.

Die beiden Ergeignisse GET und POST können wie auch bei webhooks mehrere unabhängige Packages auslösen.

UI Service POST Code.png

Die dazu gehörige Package Definition sieht folgendermaßen aus:

UI Service Package Settings.png

Natürlich können UI Services auch über ITRP hinaus bei allen REST basierten Zielsystemen für Erweiterungen Verwendung finden. Hat ein User z.B. keinen Zugriff auf Atlassian Jira, soll sich aber dennoch über Release Termine informieren können, so kann dies auf einfache Art und Weise mit dem Automator und UI Services realisiert werden.

Die für UI Services notwendigen HTML Templates sind mit einfachen HTML Kenntnissen zu erstellen bzw. leicht aus den umfassend vorhandenen Beispielen anzupassen.

UI Service Template.png

Fazit: Der automator vereinfacht die Entwicklung von Erweiterungen sowie die Integrationen beliebiger REST basierter Systeme untereinander. Die Möglichkeiten sind dabei mit UI Services wieder vielfältiger geworden:

  • webhooks
  • mail-in
  • scheduler
  • UI-Services

Mit wenig HTML Kenntnissen ist es mit dem automator zusätzlich möglich neben webhook und mail In Automatisierungen auch User Interface Add-Ons zu vorhandenen Systemen zu erstellen wenn dies notwendig sein sollte.

 

REST

Seit einiger Zeit unterstützt der automator auch andere REST basierte Systeme ausserhalb von ITRP. Als eines der bekannteren sei hier Atlassian JIRA als Beispiel angeführt.

Damit ist es auf sehr einfache Weise möglich Automatisierungen zu realisieren die über JIRA hinausgehen. Diese Automatisierungen können auf Basis der Standard Webhooks im automator realisiert werden, oder von jedem beliebigen Workflow Wechsel der in JIRA modelliert wird.
Dazu ist in Jira der Webhook Link einzutragen (Jira System Administration – Webhooks – ab Version 5.2) der vom automator vorgeschlagen wird.

Da Jira bei der aktuellen Version keine Basic Authentication anbietet, muss das automator Feature für Token Authentifizierung verwendet werden, bei dem der Token als letzter Url Bestandteil mitgegeben wird:

REST_Token_Auth.png

Andere Tools in der Cloud verwenden die Variante der Basic Authentifizierung mit Username und Passwort im Header des Webhook REST Request.

Für den Datenabruf steht die Anweisung rest_get zur Verfügung – dabei muss den jeweiligen REST API’s der angesprochenen Tools gefolgt werden. Im folgenden Beispiel werden alle JIRA Issues einer bestimmten Version abgefragt.

rest_read_data.png

Das Ändern von Daten erfolgt mittels der Anweisungen rest_put bzw. rest_post für das Erzeugen neuer Elemente.

rest_put_data.png

Durch diese sehr einfach gehaltene Integration beliebiger REST basierter Systeme in den automator ist es möglich übergreifende Automatisierungen zu realisieren. Beispiele dafür sind die Integration von JIRA mit ITRP, weil der Service Desk mit dem Service zentrierten ITRP arbeitet und die Developer Teams mit JIRA. Aber auch Integrationen zwischen JIRA und GIT sind denkbar – oder noch weit darüber hinaus.

Dabei ermöglicht es der automator die Prozesse auf einfache Weise per Drag and Drop abzubilden. Das folgende Beispiel zeigt die Suche nach Issues einer bestimmten Version, sowie das Update aller gefundenen.

rest_JIRA_GetVersionIssues_and_Updat.png

Alternativ kann alles natürlich auch als Script Code geschrieben werden:

$version_search_result = rest_get("rest", "/search?fixVersions=1.2.1.0");
foreach($issue in $version_search_result.issues) { 
  $fields = {};
  $fields.customfield_10600 = "Link to other system";

  $response = rest_put("rest", '/issue/'+$issue.key, {
      fields : $fields
    });

}

 

JIRA (r) ist ein Produkt und eingetragenes Warenzeichen von atlassian.com

 

 

 

Mail Attachments im automator

Eingehende Mails beinhalten unter Umständen Attachments, welche zu Notes im ITRP hinzugefügt werden müssen.
Im folgenden Beispiel wird der Text einer eingegangenen Mail und seine Attachments als Note an den Change mit der Nummer 1234 angehängt:

update(
  "changes",
  1234,
  {
    note:$mail.body,
    attachments:$mail.attachments
  });

Selbstverständlich registriert der automator ob es sich um ein Cloud oder ein onPremise System handelt, und geht entsprechend unterschiedlich vor.