AEM Forms as a Cloud service

Adobe hat bei der Implementierung von AEM Forms as a Cloud Service nicht bei Null angefangen. Ganz im Gegenteil: AEM as a Cloud Service für die Module „Sites“ (Web Content Management) und „DAM“ (Digital Asset Management) existiert bereits seit Anfang 2020, worüber auch unser Leiter Vertrieb und Marketing, Martin Brösamle, in diesem Blog berichtete.

Die zentralen Mehrwerte, die Adobe anpreist und die auch hier nicht unterschlagen werden sollen, sind:

-  Ständige Verfügbarkeit („always on“)

Ohne Ausfallzeiten können Inhalte von Autoren erstellt, bereitgestellt und weltweit verfügbar gemacht werden.

-  Skalierbarkeit („always at scale“)

Während des Betriebs werden bei Bedarf automatisch weitere Container-Instanzen hinzugenommen, um gestiegene Lasten auszugleichen und schnelle Antwortzeiten zu ermöglichen.

-  Aktualität („always current“)

Aufgrund der geschickten Trennung von durch Autoren erstellte Inhalte, durch Entwickler implementierten Code und Adobes Plattform-Code, ist es möglich, letzteren im laufenden Betrieb mit der stets neuesten Version zu aktualisieren. Sicherheitsupdates werden falls nötig tagesaktuell ausgerollt, regelmäßige Aktualisierungen im Monatszyklus.

-  Weiterentwicklung („always evolving“)

Durch ständige Analyse von bereitgestellten Inhalten und Code kann Adobe auf der einen Seite Best Practices befördern und auf der anderen Seite seine Prozesse so anpassen, dass der Umgang mit der Plattform für seine Kunden noch einfacher wird.

Weitere Details zum Cloud Service wie auch den anderen Betriebsmöglichkeit von AEM (Forms) auf der OSGi-Plattform finden sich in einem Beitrag unseres Geschäftsführers Michael Deiß aus dem Februar 2021.

Die oben angeführten Punkte sind gute Gründe, den Einsatz von AEM Forms in der Cloud zu erwägen. Für einen großen Teil der Anwendungsfälle ist das auch heute schon möglich. Es gibt jedoch einige Funktionalitäten, die (noch) „managed“ oder „on-premise“ Installationen vorbehalten sind; Adobe ist aber im Begriff, Forms in der Cloud mit weiteren Features zu ergänzen.

Die folgende Übersicht soll die Unterschiede darstellen. Die einzelnen Punkte sind mit Adobes (englischer, da aktuellster) Dokumentation verlinkt, sofern bereits verfügbar mit derjenigen aus dem Cloud-Bereich:

Erklärungen zu den grundlegenden Funktionen sind auch auf unserer Website verfügbar.

Warum einzelne Funktionen (noch) nicht verfügbar sind, können wir selbst als Adobe Partner nicht genau sagen. Wer sich aber wie wir schon lange Zeit mit AEM Forms und der AEM Cloud-Plattform beschäftigt, kann sich die Herausforderungen für Adobes Engineering-Team an dieser Stelle vorstellen:

-  Ähnlich wie beim Assets Compute Service für das cloud-basierte DAM Modul, ist zu erwarten, dass Adobe die Document Services, welche im Wesentlichen Operationen zur Erstellung, Modifikation und Auswertung von PDF-Dateien beinhalten, als Microservices in ein oder mehrere eigene Container verlagern wird. Für das Erzeugen des Document of Record aus Designer-Vorlagen ist dies bereits geschehen. Dieses Vorgehen ist nur konsequent: zum einen wird die Leistungsfähigkeit der Webvorgänge losgekoppelt von den zugleich stattfindenden PDF-Operationen, zum anderen lassen sich die notwendigen Instanzen falls nötig eigens skalieren. Dazu kommt, dass die Document Services seit jeher auf einem eigenen Rechenkern auf C++-Basis beruhen (demselben wie auch der Adobe Acrobat), welcher auf die OSGi-Plattform nicht angewiesen ist.

-  Die Ablage von nutzergenerierten Inhalten, wie z.B. zwischengespeicherte Formularstände oder Daten aus abgeschickten Formularen, direkt auf dem von außen angesprochenen Containern (Publish-Instanzen) ist nicht machbar, da der Adobes Replication Service nur in eine Richtung arbeitet. Unter Umständen wird Adobe hier einen eigenen Storage-Service bereitstellen, mittels dessen dies möglich wird.

Die wohl vielversprechendste Integration, nämlich die mit Adobe Sign, ist bereits vorhanden: Dadurch lassen sich Antragsstrecken komplett online mit rechtssicheren Unterschriften und optional nachfolgenden Entscheidungsschritten realisieren. Darüber hinaus ist zu erwarten, dass die Integration von Adobe Analytics und Adobe Target (die ja ihrerseits bereits Cloud Services sind) nicht lange auf sich warten lässt.

Viele unserer Kunden betreiben selbst AEM Forms Installationen auf OSGi- oder JEE-Plattformen. Für erstere stellt Adobe, wenn die obige Matrix die genutzten Funktionen abdeckt, eine Reihe von Werkzeugen zur Verfügung, mittels derer die Migration vereinfacht wird.

Wer sich den Weg in die Cloud noch nicht vorstellen kann, sei es, weil notwendige Features noch nicht bereitstehen oder aus betrieblichen oder gesetzlichen Gründen der Betrieb im eigenen Rechenzentrum erforderlich ist, kann trotzdem mit AEM Forms als Managed Service oder „on-premise“ loslegen und falls gewünscht zu einem späteren Zeitpunkt migrieren.

Diejenigen, die bereits AEM Sites in der Cloud im Einsatz haben, interessiert vielleicht, dass AEM Forms bei Bedarf auf bestehende Instanzen „zuschaltbar“ ist (aber auch getrennt von der Sites-Umgebung betrieben werden kann).

Interne oder externe Anwender werden als Website-Besucher den Wechsel in die Cloud kaum wahrnehmen (außer hoffentlich durch gesteigerte Verfügbarkeit und verbesserte Antwortzeiten).

Ebenso verhält es sich bei Autoren von Inhalten und Formularen wie auch bei Sachbearbeitern mit Aufgaben in Workflows: der Umzug bedeutet kaum eine Umstellung in der Nutzererfahrung bzw. Arbeitsweise. Allenfalls ein Versionswechsel von AEM 6.4 auf 6.5 macht sich durch die seitdem umgestalteten und optimierten Oberflächen bemerkbar.

Für Software-Entwickler, die AEM Forms anpassen oder erweitern, sind die Änderungen am ehesten spürbar: Adobe stellt ein Cloud Service SDK bereit, mittels dessen eine Umgebung auch auf lokalen Rechnern betrieben und getestet werden kann. Dennoch sollten Tests am Ende auch immer in der Cloud-Umgebung stattfinden; hierfür stehen separate Entwicklungsinstanzen mit eigener Build-Chain zur Verfügung, die unabhängig von den Produktivumgebungen laufen. Code und Inhalte müssen bei der Entwicklung getrennt und eine Reihe von Best Practices beachtet werden. Wer wie wir schon lange seine Projekte auf Grundlage von Adobes Maven-Archetype gestaltet, hat schon einen großen Schritt hierzu getan. Je nach Art und Umfang der Anpassungen und der Ausgangsversion von AEM Forms ist aber mit entsprechenden Aufwänden bei der Migration zu rechnen.

Ganz gleichgültig, für welche Variante von AEM Forms Sie sich interessieren oder entscheiden (oder vielleicht schon entschieden haben): Wir unterstützen Sie gerne bei der Analyse und Umsetzung Ihrer Anforderungen. Die Entwicklung von AEM Forms as a Cloud Service werden wir auch weiterhin eng begleiten und diesen Artikel entsprechend auf dem aktuellen Stand halten.