Die Vorfreude auf die Veröffentlichung von ProcessMaker v3.2, die nur noch ein paar Wochen entfernt ist, steigt. Es gibt viele Gründe für diese Vorfreude. V3.2 ist aus drei Gründen ein wichtiges Release für ProcessMaker: Qualität, Konnektivität und Reporting.
Lassen Sie uns zunächst über den ersten Grund sprechen - Qualität. V3.2 von ProcessMaker ist das erste Release, das wir unter der Leitung unseres neuen CTO, Taylor Dondich, erstellen. Taylor ist ein erstklassiger Ingenieur und eine großartige IT-Führungskraft. Ich habe auch gelernt, dass er in Bezug auf die Qualitätskontrolle ein echter Schmerz im *!@!" sein kann. V3.2 ist die am meisten getestete Software, die wir je veröffentlicht haben. Im vergangenen Jahr haben wir sehr hart daran gearbeitet, eine neue Schicht von DevOps-Tools und -Prozessen für unser QA-Team einzuführen. Wir haben unseren gesamten Veröffentlichungsprozess sehr formalisiert. Für einige unserer Kunden bedeutete dies eine scheinbar endlose Wartezeit auf diese Version 3.2. Wir sind jedoch davon überzeugt, dass wir drastische Verbesserungen erzielt haben und dass dies der richtige Weg ist, um die Qualität und Zuverlässigkeit unserer Veröffentlichungen zu verbessern.
Und nun zu den coolen Sachen. In unserer letzten Version haben Sie wahrscheinlich bemerkt, dass wir eine neue Möglichkeit zum Aufrufen einer REST-API hinzugefügt haben. Wir nannten sie unsere ProcessMaker Connectors. Sie können hier darüber lesen. Nun, das war nur der erste Schritt. Sie konnten schon immer einen REST-Endpunkt aus einem ProcessMaker-Trigger heraus aufrufen. Der Konnektor machte es einfach viel einfacher, einen neuen REST-Endpunkt in einer Standardbibliothek, d.h. unserer Konnektor-Bibliothek, hinzuzufügen. In Version 3.2 gehen wir mit dem Konzept von ProcessMaker als "Platform as a Service" (iPaaS) jedoch noch einen Schritt weiter. Jetzt haben wir die Service-Aufgabe hinzugefügt. Die Service Task ist ein BPMN 2.0 Aktivitätstyp, der in Kombination mit der ProcessMaker Connector Library etwas ganz Besonderes ist. Mit der Service-Aufgabe können unsere Prozessdesigner nun auf visuell eindeutige Weise einen Connector aufrufen, der eine Verbindung zu einem Fremdsystem herstellt. Früher musste man sich einen Schritt in einer Aufgabe und den Code eines Triggers ansehen, um zu sehen, was passierte. Jetzt können Sie einfach eine Serviceaufgabe verwenden, um in einer ProcessMaker-Prozesslandkarte visuell darzustellen, wann und wie Sie eine Verbindung zu einem Drittsystem herstellen wollen. Wir glauben, dass dies die Abbildung von Prozessen und die Integration von Drittsystemen VIEL einfacher machen wird.
Nehmen wir an, Sie haben einen Prozess, bei dem wir zunächst eine Verbindung zu unserem SAP-ERP herstellen und dann ein Formular mit SAP-Daten vorbefüllen wollen. Wir benötigen die SAP-Daten für den ECO Request, damit unser Benutzer das Teil oder die Unterbaugruppe auswählen kann, die wir ändern möchten. Der Benutzer soll die Teile und die abhängigen Unterbaugruppen in einer Dropdown-Liste auf dem Formular sehen.
In diesem Bild ist die erste Aufgabe eine Service-Aufgabe, die einen SAP-Konnektor aufruft. Der SAP-Konnektor würde aus der öffentlichen ProcessMaker-Konnektor-Bibliotheksdatei ausgewählt werden. Das Schöne daran ist, wie oben erwähnt, dass dies nun visuell eindeutig ist. Ich kann in meinem Prozess sehen, welche Systeme aufgerufen werden, warum und wann. Für diejenigen, die dies gerne innerhalb von Triggern und Schritten tun... "Ja," Sie können dies auch weiterhin tun. Aber für die technisch weniger versierten Unternehmensanalysten da draußen macht es die Serviceaufgabe viel einfacher zu verstehen, wie und wann ein Prozess Informationen von einem anderen System erhält oder in ein anderes System einspeist.
Wie Sie in der Abbildung oben sehen können, ist es jetzt sehr visuell und sehr einfach. Ich gehe einfach zum Service Task, klicke auf Eigenschaften und erhalte Zugriff auf meine Connector Library. In der Connector-Bibliothek finde ich Endpunkte für beliebte Dienste wie Google Drive, S3 und Box für die Speicherung, Google Calendar für die Kalenderverwaltung, Adobe Sign und Docusign und Right Signature für digitale Signaturen, Konnektoren zu SalesForce, SAP und anderen für Unternehmens-CRM, ERP usw.
Aber warten Sie, es kommt noch besser. Was ist mit all den internen Systemen, die Ihr IT-Team aufbaut? Für diese Systeme haben wir das Konzept einer privaten Konnektorenbibliothek. Ihre internen Entwickler können ihre Konnektoren (APIs) in einer privaten Konnektorbibliothek veröffentlichen, die eine Verbindung zu Ihren internen API-gesteuerten Systemen auf genau die gleiche Weise ermöglicht. Auf diese Weise "aktivieren" wir Ihr Ökosystem von Anwendungen, so dass sie von ProcessMaker Workflow genutzt werden können.
Ziemlich cool, oder?
Lassen Sie uns zum Schluss noch über die Data Reporting Tools sprechen. Wir haben diese neuen Tools im Laufe der letzten paar Versionen langsam eingeführt. In v3.2 erhalten Sie jetzt visuelle Gadgets als Berichtsoption in Ihrem Berichtsdesigner. Lassen Sie mich zur Auffrischung erklären, was die Data Reporting Tools bieten. Erstens können Sie einen Geltungsbereich für Ihre Berichte erstellen. Damit können Sie festlegen, wer einen Bericht erstellen darf und auf welche Daten er zugreifen kann. Sie können den Zugriff auf Tabellen- und/oder Feldebene einschränken.
Jetzt können Sie Ihr Sicherheitsmodell direkt in ProcessMaker erstellen. Dann können Sie entscheiden, welche Daten in Ihrem Bericht angezeigt werden sollen und wie Sie diese Daten filtern. Und jetzt können Sie entscheiden, ob Sie einen tabellarischen Bericht oder ein grafisches Gadget verwenden möchten. Natürlich kann alles in die Formate .xls, .pdf oder .doc exportiert werden.
Es wird noch mehr zum Thema Berichte geben, z. B. werden Sie bald in der Lage sein, jeden Bericht in ein benutzerdefiniertes Dashboard zu verwandeln. Aber das hebe ich mir für einen anderen Beitrag auf. Werfen Sie in der Zwischenzeit einen Blick auf diese Beispielberichte:
