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.

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.

Konfigurieren statt Programmieren

In ITRP werden für verschiedene wiederkehrende Geschäftsprozesse Vorlagen, auch Templates genannt, verwendet. Diese können bei der Erstellung von Automatisierungen dazu verwendet werden bestimmte Sachverhalte zu erkennen und entsprechend zu entscheiden.

Folgend Problemstellung: Ein Request wird dem Team „Intern“ zugewiesen. Wenn dieser Request auf einem bestimmten Template beruht soll ein neuer Change erzeugt werden, da sicher ist das es sich um einen komplexen Fall handelt. In allen anderen Fällen nicht.

Wie löst man diese Anforderung auf möglichst einfache Weise?

Dazu notwendig ist im Vorfeld die ID des Request Templates auf das reagiert werden soll wenn das Request Team geändert wird, und die ID des Change Templates mit dem der neue Change erstellt werden soll.

Diese Informationen werden im Automator am besten als „Environment Variablen“ hinterlegt. Diese können im Package verwendet werden, und eine Änderung der Werte wie zwischen Sandbox und Produktion Betrieb erfordert damit keine erneute Änderung des Packages.

DNDEX_001_Variable_request_template.png

 

DNDEX_001_Variable Change Template.png

Um durchgehend mit Variablen zu arbeiten wird der Team Name auch gleich als Variable angelegt. Alternativ könnte man auch hier mit der ID arbeiten. Variablen werden im Automator immer mit dem „$“ Zeichen eingeleitet – das ist aber in den meisten Fällen schon vorgegeben.

DNDEX_001_Variable Team.png

Dann wird ein neues Package eingerichtet, welches von dem Webhook Ereignis „request.team-changed“ ausgelöst wird. Der Webhook muss in ITRP wie auch im Automator eingerichtet werden. Im Automator geht das folgendermaßen.

 

Nach Eingabe des Namens wird der Auslöser (Trigger) festgelegt. Ein Webhook auf das Ereignis „request.team-changed“ wird im richtigen Account hinzugefügt:

DNDEX_001_Event_Config.png

Die Option für Audit Data ist standardmäßig aktiv – für unser Beispiel könnte sie deaktiviert werden. Die Option „Enable“ schaltet die Package Verarbeitung ein. Das sollte so lange abgeschaltet bleiben bis wir mit der Package Entwicklung fertig sind.

DNDEX_001 Package Settings edt.png

Sind die Einstellungen getätigt (ITRP Webhook einrichten nicht vergessen!) kann mit der Konfiguration des Package begonnen werden. Der erste Schritt ist die Entscheidung ob etwas getan werden muss oder nicht – eine „IF Condition“. Diese muss mit Drag and Drop in den Editor Bereich gezogen werden.

 

DNDEX_001_If_condition_name.png

Hier wird geprüft ob der Team Name des requests mit der Variable „$TEAM_NAME_INTERN“ übereinstimmt, UND ob die Request Template Id mit der Variable „$REQUEST_TEMPLATE_ID“ übereinstimmt (Vergleich auf Übereinstimmung „==“).

Wenn diese Bedingung erfüllt ist, so soll ein Change erzeugt werden.  Dazu wird ein ITRP-UPDATE / CREATE unter das IF hingezogen.

DNDEX_001_if and create.png

Dabei ist es wichtig darauf zu achten das sich das neue Element unter das IF einfügt und eingerückt dargestellt wird. Liegt es auf gleicher Ebene dann hätte das IF keine Wirkung darauf. Ein IF ohne Unterelemente zeigt daher zur Sicherheit eine entsprechende Warnmeldung am rechten Rand.

Im CREATE ist der Account optional. Wird dieser leer gelassen, so wird der Account des Auslösers in den Package Einstellungen verwendet.

Weiters ist die Angabe einer Variable für den Rückgabewert optional. Im Fall unseres CREATE würde der  neue Change zurückgegeben werden und könne mittels dessen ID sogleich weiter verwendet werden. Um unser Beispiel zu vervollständigen werden wir dies als LOG Eintrag ausgeben:

DNDEX_001_complete.png

Die CREATE Anweisung wurde noch um eine zusätzliche Variable „$new_change“ ergänzt und diese Variable dann in der darauf folgenden LOG Anweisung verwendet.

Fertig ist die Konfiguration. Nun kann mit dem Testen begonnen werden. Zum Testen dieses Packages folgt ein eigener Eintrag.

Je größer und komplexer ein Package wird, um so unübersichtlicher wird die Darstellung. Daher kann man einzelne Elemente und ganze Elementgruppen zusammenklappen in dem man einfach auf die Kopfzeile des Elements klickt. Alternativ gibt es rechts über der Toolbar zwei Anweisungen die das gesamte Package zusammenklappen (Collapse) oder erweitern (Expand).

DNDEX_001_collapsed.png

Diese Darstellung zeigt nur noch die wichtigsten Einstellungen, behält aber die komplette Struktur bei. Damit ist es möglich rasch zwischen verschiedenen Teilen eines komplexeren Packages zu wechseln, sowie seine Konzentration auf genau das zu legen was gerade in der Konfiguration wichtig ist und das andere weg zu klappen.

Soweit eine einfache Einführung in den neuesten Package Editor des Automator. Wer wie gewohnt programmieren will kann dies mit dem Script Kommando tun. Wenn dieses als einziges in den Arbeitsbereich gezogen wurde zoomt es auf die ganze bereitstehende Fläche und lässt so freies Programmieren zu.

Viel Spass beim Webhook konfigurieren!