Übersicht über Workflow Engines

Mit diesen Tools modellieren Sie Workflows unter Windows

09.03.2018 von Holger Fleck
Wie gelingt es, die Arbeitsabläufe im Unternehmen zu vereinfachen und zu automatisieren? Der SharePoint Designer stößt schnell an seine Grenzen. Lösungen von Nintex, WebCon und K2 können helfen.
 
  • Zu unterscheiden sind in SharePoint integrierte und eigenständige Lösungen
  • Eigenständige Systeme stoßen nicht so schnell an Kapazitätsgrenzen wie die SharePoint Workflow Engine
  • SaaS-Lösungen und selbst-gehostete Systeme haben jeweils ihre Vor- und Nachteile

In den Arbeitsabläufen aller Unternehmen steckt das Potenzial, Prozesse zu vereinfachen und zu automatisieren. Für nachvollziehbare, effiziente und sichere Abläufe sorgen Workflow-Systeme, die zugleich Arbeitsschritte visualisieren. Dadurch wird auf einen Blick klar, was, wann, warum und wo passiert und was als nächstes geschehen muss. Workflow-Systeme helfen, die Arbeitsabläufe so zu entwickeln, dass Menschen besser und schneller zusammenarbeiten. Für den Einsatz im Windows-Umfeld werden nachfolgend die unterschiedlichen Lösungen und Ansätze verglichen sowie Vor- und Nachteile erläutert.

Sharepoint Designer Workflow
Foto: Axians

Als naheliegende Lösung lassen sich automatisierte Prozesse im Intranet des Unternehmens integrieren und sind somit für alle Stakeholder zugänglich. Wir werfen also zunächst einen Blick auf SharePoint, das nach wie vor die am häufigsten eingesetzte Plattform für Intranet-Lösungen ist.

SharePoint Designer Workflow

In allen SharePoint-Varianten und -Lizenzen sind out of the box Designer Workflows enthalten, also in Standard, Enterprise, On-Premises und Online. Für deren Nutzung fallen keine weiteren Kosten an. Auch das Tool mit dem die Workflows entwickelt werden können, der SharePoint Designer, kann kostenfrei heruntergeladen werden. Selbsterklärend bieten diese Workflows eine enge Integration in SharePoint an. Kleine Workflows lassen sich auch ohne Programmierkenntnisse von erfahrenen SharePoint-Anwendern mit ein bisschen Übung erstellen.

Allerdings ist der Funktionsumfang der Designer Workflows stark eingeschränkt. Bereits bei einfachen Schleifen bieten die Designer Workflows keine Unterstützung an. So können schon aus simplen Prozessen komplexe Workflows entstehen. Leider ist auch das Handling nicht optimal gelöst: Schnell liegen mehrere modale Dialoge übereinander, wodurch die Übersicht verloren gehen kann.

Einige fehlende Operationen können durch den Aufruf von Web Services ausgeglichen werden, was aber sogar für erfahrene SharePoint-Anwender oder solche mit Entwickler-Background eine echte Herausforderung darstellen kann. Zudem fehlen wichtige Verwaltungsfunktionen: Workflows können nicht kopiert, archiviert oder beispielsweise vom Test- in das Produktivsystem übertragen werden.

Trotzdem sollten Workflows mit SharePoint Designer nicht grundsätzlich ausgeschlossen werden. Sind jedoch mehrere nicht triviale Workflows geplant oder sollen systemkritische Prozesse umgesetzt werden, gibt es Sinn, mächtigere Systeme in Betracht zu ziehen. Das Gerücht, wonach SharePoint-Designer-Workflows mit SharePoint 2016 beziehungsweise SharePoint Online nicht betrieben werden könnten, ist falsch. Die Workflow Engine steht Online und On-Premises nach wie vor zur Verfügung und ist auch nicht abgekündigt. Allerdings hat Microsoft den SharePoint Designer für Version 2016 nicht weiterentwickelt - der SharePoint Designer 2013 kann jedoch für SharePoint 2016 und SharePoint Online unverändert genutzt werden.

Nintex für SharePoint (On-Premises)

Nintex für Office 365
Foto: Axians

Nintex für SharePoint ist seit SharePoint 2007 verfügbar und das am häufigsten genutzte Workflow-System für SharePoint. Da sich Nintex direkt in die Oberfläche von SharePoint integriert und die Funktionen für die Erstellung von Workflows optimiert sind, lassen sich Workflows einfacher und intuitiver erstellen als mit Designer Workflows.

Nintex setzt ebenfalls auf der Workflow Engine von SharePoint auf. Im Unterschied zu den Designer Workflows erweitert Nintex die Funktionalität jedoch durch eine Vielzahl von Aktionen. Dabei geht Nintex stringent den Weg, für möglichst alle Anforderungen Lösungen zur Verfügung zu stellen und gleichzeitig häufige Einsatzszenarien schnell und einfach anzubieten. Des Weiteren kann mit den Managementfunktionen ein echter Application Live Cycle abgebildet werden, und es steht zur Fehlerfindung ein Tracing zur Verfügung.

Um Nintex On-Premises zu erweitern, können eigene Aktionen in .NET entwickelt werden. Diese werden als Farm Solution auf dem SharePoint Server installiert. Dafür erhält man dabei dann aber auch die volle Flexibilität. Ein weiterer Vorteil von Nintex On-Premises ist der Formular Editor. Dieser kann die üblichen Anwendungsfälle direkt umsetzen. Bei erweiterten Anforderungen macht es sich bezahlt, dass die Nintex-Formulare komplett mit HTML/CSS und JavaScript angepasst werden können - auch wenn man dafür Programmierkenntnisse braucht.

Es soll aber auch nicht verschwiegen werden, dass die Funktionalität von Nintex On-Premises in den letzten Jahren nicht relevant erweitert wurde. Die Stagnation der Entwicklung geht vermutlich auf die Konzentration auf das Produkt "Nintex Cloud" zurück, das wir später betrachten.

Nintex für Office 365

Produktvergleich Sharepoint Designer Workflow, Nintex SharePoint und Nintex Office 365
Foto: Axians

Auch für SharePoint Online (Office 365) bietet Nintex eine Versionan. Diese scheint auf den ersten Blick identisch zur On-Premises-Version zu sein, denn auch sie integriert sich komplett in SharePoint. Allerdings basiert Nintex für Office 365 auf einer anderen Technologie. Office 365 lässt nur eine Integration als Hosted App zu, was einen Zugriff auf die Serverfunktionalität unterbindet. Das äußert sich dadurch, dass einige bei On-Premises gewohnte und auch häufig verwendete Aktionen in der Office-365-Variante fehlen oder weniger Funktionen mitbringen.

Zudem kann aus der Nintex Office 365 App heraus nicht so einfach auf eine andere Site Collection zugegriffen werden. Auch dadurch sind einzelne Aktionen komplexer zu benutzen oder in der Funktionalität eingeschränkt. Insbesondere muss häufig ein Account in der Aktion angegeben werden, ohne die Option diesen Account zentral verwalten zu können. All dies führt dazu, dass Nintex Lösungen in Office 365 aufwendiger umzusetzen sind und nicht so flexibel verwendet werden können, wie in der On-Premises-Welt. Die Formulare unterscheiden sich jedoch in der On-Premises- und der Cloud-Version nicht.

Es ist zu befürchten, dass die Weiterentwicklung der Office-365-Version aufgrund der Priorisierung auf die Nintex Cloud zurückstecken muss. Vergleicht man die Funktionalität der Nintex Cloud und die der Version für Office 365, so lassen sich bereits jetzt schon viele Szenarien einfacher mit der Nintex Cloud umsetzen.

Microsoft Flow / Azure-Logik-Apps

Microsoft Flow
Foto: Axians

Microsoft Flow und Azure-Logik-Apps sind technisch identisch: Während Microsoft Flow in Office 365 aufgehängt ist, sind die Logik-Apps Bestandteil von Azure. Der Hauptunterschied zwischen beiden besteht darin, dass die Logik-Apps neben einer grafischen Oberfläche zusätzlich auch über eine textuelle Eingabe (JSON-Notation) verfügen. Ausführlicher wird der Unterschied zwischen Flow und den Logik-Apps in dem Artikel "Komponenten in der Cloud schnell entwickeln" behandelt.

Im Unterschied zu den bislang vorgestellten Systemen stellt Flow eine eigene Engine zur Verfügung und ist damit unabhängig von SharePoint oder anderen Systemen. Diese Unabhängigkeit ist ein herausstechendes Merkmal, denn Flow bietet die Anbindung an über 160 unterschiedliche Cloud-Systeme. Allerdings fehlen Flow derzeit noch einige Funktionen, um umfangreiche Prozesse umzusetzen. Flow kann eher als ein System zur Weiterleitung von Ereignissen beschrieben werden. Berechnungen innerhalb von Flow sind nur umständlich zu realisieren. Beispielweise ist es schwierig, längere komplexere Texte aus mehreren Variablen zusammenzustellen.

Für diese und ähnliche Funktionen können eigene Webdienste über eine Swagger-Datei (Open API) eingebunden werden. Da die Azure Functions hierfür einen Automatismus anbieten, so dass die Verbindung über einen Button erfolgen kann, lassen sich Berechnungen jedoch unproblematisch auslagern.

Obwohl Flow ein Cloud-Produkt ist, kann über ein Daten-Gateway ein Zugriff auch auf eigene On-Premises-Daten (z.B. SharePoint On-Premises Server) erfolgen. Die Flexibilität von Flow, andere Systeme zu verbinden, kann vielseitig genutzt werden. So erläutert K2 (siehe unten), wie man K2 Workflows mit Hilfe von Flow durch andere Systeme ansteuern lassen kann.

Microsoft entwickelt das Produkt Flow in einem erstaunlichen Tempo weiter. Regelmäßig kommen neue Konnektoren für weitere Systeme aber auch Funktionen hinzu. Vor allem aber zeigt die direkte Integration von Flow in SharePoint Online (Office 365), welche Bedeutung Flow hat. Flows können wie SharePoint Workflows direkt aus SharePoint heraus gestartet werden, und bei einer Genehmigung kann beispielsweise gleich ein Kommentar angegeben werden - diese Option steht anderen Lösungen nicht zur Verfügung.

Auch die einfache Möglichkeit Flows von Smartphones direkt als native App zu starten, erlaubt es, Einsatzszenarien umzusetzen, die von den anderen Anbietern nicht unterstützt werden. Alles in allem können bereits jetzt einfache geschäftskritische Abläufe realisiert werden. In Zukunft werden die Einsatzmöglichkeiten sicherlich noch weiter anwachsen. Auch der vergleichsweise günstige Preis trägt zu dem Erfolg dieser noch sehr jungen Lösung bei.

Nintex Cloud

Produktvergleich Microsoft Flow und Nintex Cloud
Foto: Axians

Wie bereits erwähnt, hat Nintex vor einiger Zeit mit der Entwicklung der Nintex Cloud begonnen. Wie bei Flow handelt es sich auch hier um ein unabhängiges SaaS-Produkt, das nicht wie die bisherigen Lösungen auf SharePoint aufsetzt. Externe Systeme können als Auslöser und Aktionen direkt angesprochen werden - wenn auch bei weitem nicht so viele wie bei Flow/Logik-Apps. Interessanterweise gibt es keine Out-of-the-box-Konnektoren zu einem On-Premises SharePoint, wie es Flow mit dem Daten-Gateway bereitstellt.

Erweiterungen werden auch bei der Nintex Cloud in Form von Web Services, die wie bei Flow mit Hilfe einer Swagger-Datei eingebunden werden, realisiert. Derzeit können jedoch nur Aktionen und keine Auslöser realisiert werden. Dieser Nachteil soll jedoch nach Angaben von Nintex in den kommenden Monaten behoben werden. Je nach Sicherheitskonzept, kann es problematisch sein, dass die Nintex Cloud in Amerika gehostet ist. Somit werden auch alle Daten, die ein Workflow verarbeitet, über die USA geleitet. Nintex arbeitet an einer europäischen Version, ein Termin wurde aber noch nicht genannt.

Formulare für die Workflows werden über einen einfachen Editor erstellt. Hierbei besteht jedoch nur die Möglichkeit, die Steuerelemente anzuordnen und über wenige Eigenschaften zu definieren. Ein standardisiertes Verfahren zur Anpassung des Designs oder um eigene Regeln beziehungsweise ein einheitliches Layout umzusetzen - zum Beispiel über eine wiederverwendbare CSS-Datei - steht nicht zur Verfügung.

Nintex Cloud
Foto: Axians

Alles in allem geht Nintex hier einen harten Weg: Nintex Cloud ist nicht auf dem erfolgreichen Produkt Nintex für SharePoint aufgebaut. Es stellt eine komplett neue Lösung dar, die ohne die Abhängigkeit und Einschränkungen durch Abwärtskompatibilität auskommt. Die Möglichkeiten innerhalb des Workflow Editors sind vergleichbar mit Nintex On-Premises für SharePoint. Allerdings ist der Formular Editor sehr eingeschränkt und eine fehlende Anbindung an On-Premises Server (zum Beispiel SharePoint) sowie eine fehlende API zum automatisierten Management der Workflows (zum Beispiel per PowerShell oder per Web Service) schränken den professionellen Einsatz ein. So ist beispielsweise ein Export der Nintex Workflows außerhalb der Nintex Cloud nicht möglich.

WebCon und K2

Neben systemspezifischen Systemen wie SharePoint Designer Workflows oder Nintex On-Premises/Office365 und SaaS-Lösungen wie Flow und Nintex Cloud gibt es auch eigenständige Lösungen. WebCon oder auch K2 stellen solche Systeme bereit. Die Produkte WebCon BPS und K2 blackpearl sind vergleichbar, unterschieden sich technisch aber grundsätzlich adurch, dass WebCon auf einer relationalen Datenbank basiert. Somit ist es möglich, größere und aufwändige Berechnungen durch SQL-Eingaben effizient und performant umzusetzen.

K2 basiert dagegen auf .NET und integriert sich nativ in andere Lösungen, darunter SharePoint, Active Directory, Exchange, Dynamics CRM, SAP und Salesforce. Aber auch WebCon kann über Schnittstellen Daten mit anderen Produkten austauschen. Während WebCon jedoch vollständig auf Workflows fokussiert ist, bietet K2 eine Plattform mit weiteren Lösungen für Formulare, mobile Apps, Compliance etc.

Wie auch in allen anderen Workflow-Lösungen, werden die Workflows in K2 und WebCon mit Hilfe eines grafischen Editors erstellt. Im Gegensatz zu WebCon liefert K2 eine eigenständige Formularlösung, in der über Regeln und Aktionen komplette Formulare erstellt werden können. Allerdings bedarf es einiger Erfahrung um Logik in die Formulare zu integrieren.

Bei WebCon hingegen werden die Formulare automatisch generiert und bieten wichtige Funktionen wie Mehrsprachigkeit, Responsive Design, Apps für Smartphones & Tablets ohne weiteren Aufwand. Reichen die generierten Formulare nicht aus, ist der Anwender gezwungen, beispielsweise auf einem Web Server oder über SaaS eine eigene Oberfläche zu erstellen und die Workflows von dort aus zu starten.

Produktvergleich WebCon BPS und K2
Foto: Axians

WebCon zeichnet sich auch durch umfangreiche Funktionen aus: So ist effizientes Arbeiten mit den Workflows möglich, weil eine tiefe Integration in Office-Produkte, die elektronische Signatur des angemeldeten Nutzers und eine einfache Mehrsprachigkeit vorliegen. Stark ausgeprägt sind bei WebCon wie bei K2 die Management- und Maintenance-Funktionen der Workflows.

Fazit

Die Systeme unterscheiden sich zunächst einmal grundsätzlich darin, ob es sich um eine eigenständige oder eine in SharePoint integrierte Lösung handelt. Ferner muss zwischen einer SaaS (Cloud-Lösung) oder einem selbstgehosteten System differenziert werden.

SaaS-Lösungen bieten einen großen Umfang an einfach einzubindenden externen Systemen an. Dafür kann die Funktionsvielfalt nur über Webdienste erweitert werden. Selbstgehostete Systeme bringen von sich aus bereits viele Funktionen mit, zudem können sie einfach und unproblematisch durch eigenen Code erweitert werden. SaaS-Lösungen hingegen haben den Vorteil, dass sie ständig weiterentwickelt werden und sowohl der Funktionsumfang als auch die verfügbaren externen Systeme kontinuierlich erweitert werden.

SharePoint integrierte Lösungen können vor allem bei kleineren und mittleren Prozessen gewinnbringend eingesetzt werden. Allerdings hat die SharePoint Workflow Engine das bekannte Problem, bei einem hohen Durchsatz oder großen Datenmengen an Grenzen zu stoßen, so dass manchmal Workflows nicht korrekt oder gar nicht ausgeführt werden. Hier arbeiten eigenständige Systeme deutlich effektiver.

Oftmals hängt die Entscheidung für die eine oder andere Plattform auch an der geplanten Anzahl der Workflows und wie oft diese ausgeführt werden. Die angebotenen Lizenz-Modelle sind unterschiedlich. Daher ist es sinnvoll, je nach Anforderung individuell die geeignetste Plattform auszuwählen. Dabei gilt es, zwischen dem Aufwand für das Erstellen beziehungsweise Erweitern sowie dem Einbinden bereits vorhandener Dienste und den Kosten abzuwägen. Themen wie Sicherheit und Verwaltung sollten dabei nicht vernachlässigt werden.