Architektur

AEM forms ist eine Anwendung, die in AEM in Form mehrerer Pakete bereitgestellt wird. Sie wird durch ein JEE-basiertes Forms Workflows Add-On unterstützt, das für einen erweiterten Funktionsumfang wie Korrespondenznachbearbeitung und Prozessverwaltung sorgt. AEM-Pakete enthalten Dienste (API-Anbieter), die im AEM OSGI-Container bereitgestellt werden, und Servlets oder JSPs (Frontend- und REST-API-Funktion), die über das AEM Sling-Framework verwaltet werden. Das folgende Diagramm zeigt diese Einrichtung.

Klicken Sie zum Öffnen einer vergrößerten Ansicht in einer neuen Registerkarte

Die Architektur für AEM forms beinhaltet die folgenden Komponenten:

  • Kern-AEM-Dienste: Grundlegende Dienste, die von AEM für eine bereitgestellte Anwendung verfügbar gemacht werden. Diese enthalten ein JCR-kompatibles Inhalts-Repository, einen OSGi-Dienstcontainer, eine Workflow-Engine usw. Diese Dienste sind für die AEM forms-Anwendung verfügbar, werden aber nicht von AEM forms-Paketen bereitgestellt. Die Dienste sind ein wesentlicher Bestandteil des Gesamtstapels, da sie von verschiedenen AEM forms-Komponenten verwendet werden.
  • Gemeinsame Formulardienste: Stellt allgemeine Funktionen für verschiedene AEM forms-Komponenten bereit. Mit Ausnahme von Document Manager und Unterstützung für überwachte Ordner sind diese Dienste zur internen Verwendung von Adobe und nicht für die Verwendung oder Anpassung vorgesehen.
  • Formulardienste: Stellen formularspezifische Funktionen bereit, wie die Formularwiedergabe, die Kombination von aus Formularen generierten PDF-Dokumenten usw. Viele dieser Dienste sind öffentlich für den Gebrauch durch benutzerdefinierten Code verfügbar, der in AEM bereitgestellt wird.
  • Weblayer: JSPs oder Servlets, die auf allgemeine Dienste oder Formulardienste aufgesetzt wurden und folgende Funktionalität bieten:
    • Authoring-Frontend: Eine Benutzeroberfläche zum Erstellen und Verwalten von Formularen.
    • Formularwiedergabe und -übermittlungs-Frontend: Eine Benutzeroberfläche für Endbenutzer von AEM forms (z. B. Bürger, die auf einen Behördenseite zugreifen). Hier werden die Formularwiedergabe- und Sendefunktionen bereitgestellt.
    • REST APIs: JSPs und Servlets exportieren einen Teil der Formulardienste zur Nutzung durch HTTP-basierte Clients wie das SDK für mobile Formulare.

Zusätzlich zu den AEM-basierten Komponenten enthält AEM forms ein (JEE-basiertes) Forms Workflows Add-On, das bestimmte unterstützende Dienste für die AEM-Komponenten bereitstellt:

  • Integrierte Benutzerverwaltung: Ermöglicht die Erkennung von Benutzern des Forms Workflows Add-On auch als AEM-Benutzer. Dies ist in Fällen erforderlich, in denen eine einmalige Anmeldung für AEM und Add-On erforderlich ist (z. B. HTML Workspace).
  • Asset Hosting: Das Forms Workflows Add-On kann für Elemente eingesetzt werden (z. B. HTML5-Formulare), die auf AEM wiedergegeben werden.
  • Korrespondenznachbearbeitung: Bei Kunden, die Correspondence Management verwenden, kann das Forms Workflows Add-On optional gesendete Briefe über Workflows nachbearbeiten, die auf seiner Workflow-Engine gehostet werden.

Zusätzlich kann das Forms Workflows Add-On von den AEM forms-Kunden für anspruchsvolle Anwendungsfälle wie komplexe formularbezogene Arbeitsabläufe, Arbeitsbereiche und Aufgabenverwaltung, Dokumentsicherheit usw. verwendet werden.

Nicht alle Formulare können über die Benutzeroberfläche von AEM forms erstellt werden. Solche Formulare sind mit dem eigenständigen Dienstprogramm Forms Designer zu erstellen, auf der lokalen Festplatte zu speichern und einzeln oder als ZIP-Datei auf AEM forms Manager hochzuladen. Alternativ können Formulare in Szenarios, in denen AEM und das Forms Workflows Add-On als benachbarte Anwendungen gemeinsam auf demselben JEE-Server installiert sind, als Anwendungselement erstellt und im Add-On bereitgestellt werden. Sie lassen sich dann automatisch mit AEM forms Manager synchronisieren.

Topologie

Die Bereitstellungstopologie für AEM forms umfasst Elemente, die Formularentwickler bei der Gestaltung der Formulare, Endbenutzer beim Anzeigen und Versenden der Formulare und die Verarbeitung und Speicherung der gesendeten Formulardaten unterstützen. Das folgende Diagramm zeigt diese logischen Elemente.

Klicken Sie zum Öffnen einer vergrößerten Ansicht in einer neuen Registerkarte

Autor: Instanz(en) von AEM forms, die im Standard-Autorenmodus ausgeführt wird (werden). Dieser Modus ist nur für interne Benutzer vorgesehen (Formular- und Briefentwickler). Ermöglicht werden folgende Funktionen:

  • Formularerstellung und -verwaltung: Formularentwickler können adaptive Formulare erstellen, andere extern erstellte Formulartypen hochladen (z. B. in Adobe LiveCycle Designer erstellte Formulare) und Formulare über die Forms Manager-Konsole verwalten.
  • Formularveröffentlichung: Formulare, die auf der Authoring-Instanz gehostet werden, können in anderen Elementen in der Topologie veröffentlicht werden (Verarbeitung und Veröffentlichen), um Laufzeitvorgänge durchzuführen. Bei der Formularveröffentlichung werden von AEM bereitgestellte Replizierungsfunktionen verwendet. Es wird empfohlen, einen Replizierungsagenten beim Authoring für das manuelle Übertragen von veröffentlichten Formularen zur Verarbeitung zu konfigurieren und einen anderen Replizierungsagenten für die Verarbeitung, während der Auslöser On Receive aktiviert ist, um die empfangenen Formulare automatisch zur Veröffentlichung zu replizieren.
  • Erstellen/Veröffentlichen von Briefen (für Kunden, die Correspondence Management verwenden): Ähnlich wie das Erstellen/Veröffentlichen von Formularen.

Veröffentlichen: Instanz(en) von AEM forms , die im Standard-Veröffentlichungsmodus ausgeführt wird (werden). Dieser Modus richtet sich an Endbenutzer von formularbasierten Anwendungen (z. B. Benutzer beim Anmelden und Versenden von Formularen auf Websites). Ermöglicht werden folgende Funktionen:

  • Formularwiedergabe und -übermittlung für Endbenutzer
  • Transport unbearbeiteter gesendeter Formulardaten zur Verarbeitung für die weitere Verarbeitung und Speicherung im endgültigen Aufzeichnungssystem. Die Standardimplementierung in AEM forms erreicht dies mit den von AEM bereitgestellten Funktionen zur umgekehrten Replizierung. Eine alternative Implementierung ist auch das direkte Weiterleiten der Formulardaten zur Verarbeitung, anstatt sie zuerst lokal zu speichern (letzteres ist eine Voraussetzung für die Aktivierung der umkehrten Replizierung). Kunden, die Bedenken bei der Speicherung potenziell vertraulicher Daten bei Veröffentlichung haben, können diese alternative Implementierung wählen, da die Verarbeitung üblicherweise in einer sichereren Zone erfolgt.
  • Wiedergeben und Versenden von Briefen (für Kunden, die Correspondence Management verwenden): Durch Veröffentlichen werden Briefe für Endbenutzer wiedergegeben und die Daten in gesendeten Briefen zur zukünftigen Speicherung und Nachbearbeitung verwaltet. Für den Speicherteil können die Daten entweder lokal gespeichert und zur Verarbeitung umgekehrt repliziert werden (die Standardeinstellung), oder direkt zur Verarbeitung gesendet werden (diese Implementierung ist nützlich für sicherheitsbewusste Kunden). Die Daten können optional auch von einem AEM-Workflow oder einem Workflow nachbearbeitet werden, der durch das Forms Workflows Add-On gehostet wird. Bei AEM-Workflows wird der Workflow immer bei der Verarbeitung ausgelöst, unabhängig vom Mechanismus, mit dem die Daten dort ankommen (umkehrte Replizierung oder direktes Senden).

Verarbeitung: Instanz(en) von AEM forms , die im Standard-Autorenmodus ausgeführt wird (werden), wobei kein Benutzer der Formularmanagergruppe zugewiesen ist. Dadurch wird sichergestellt, dass Authoring- und Verwaltungsaktivitäten bei Formularen nicht bei der Verarbeitung, sondern nur beim Authoring ausgeführt werden. Die Verarbeitung ermöglicht die folgenden Funktionen:

  • Die Verarbeitung von Formularrohdaten aus der Veröffentlichung: Dies wird hauptsächlich über AEM-Workflows erreicht, die ausgelöst werden, wenn die Daten eingehen. Sie verarbeiten die Daten und speichern sie in einem passenden Datenspeicher.
  • Sicheres Speichern der Formulardaten: Die Verarbeitung bietet ein hinter der Firewall befindliches Repository für Formularrohdaten, auf das die Benutzer keinen Zugriff haben. Weder Formularentwickler noch Autoren noch Endbenutzer bei der Veröffentlichung können auf dieses Repository zugreifen. Es dient auch als sicheres Repository für die endgültigen verarbeiteten Daten, wenn der Kunde keinen Datenspeicher Drittanbieters verwendet.
  • Speichern und optionales Nachbearbeiten von Korrespondenzdaten aus der Veröffentlichung Das optionale Nachbearbeitung wird von AEM-Workflows durchgeführt, die für die entsprechenden Briefdefinitionen konfiguriert sind. Diese Workflows können die fertig verarbeiteten Daten in einen geeigneten externen Datenspeicher speichern.
  • HTML Workspace Hosting (für Kunden, die HTML Workspace verwenden): Bei der Verarbeitung wird das Frontend für den Workspace für interne Benutzer bereitgestellt und die Formulare der zugehörigen Benutzeraufgaben werden gerendert.

Für die Verarbeitung ist aus folgenden Gründen der Autorenmodus konfiguriert:

  • Dies ermöglicht die umgekehrte Replizierung von Formularrohdaten aus der Veröffentlichung, eine vom Standarddatenspeicher-Handler erforderliche Funktion.
  • Es wird empfohlen, dass AEM-Workflows (die Hauptmethode zur Verarbeitung von Formularrohdaten aus der Veröffentlichung) auf einem Authoring-System für TarMK-basierte Bereitstellungen ausgeführt werden.

AEM forms Workflows Add-On: Ein JEE-basiertes Add-On, das von bestimmten Komponenten von AEM forms benötigt wird. Kunden können es zudem für eine anspruchsvollere Verarbeitung von Formulardaten verwenden:

  • Erweiterte zusätzliche Verarbeitung der Formular-/Briefdaten: Das Add-On kann bei anspruchsvollen Anwendungsfällen, die eine erweiterte Prozessverwaltung erfordern, zur zusätzlichen Verarbeitung von Formular-/Briefdaten (und zum Speichern der Ergebnisse in einem geeigneten Datenspeicher) verwendet werden.
  • HTML Workspace-Unterstützung (für Kunden, die HTML Workspace verwenden): Das Add-On ermöglicht einmalige Anmeldung unter „Verarbeitung“, unterstützt bestimmte unter „Verarbeitung“ wiedergegebene Elemente und besorgt das Versenden von Formularen, die in HTML Workspace wiedergegeben werden.

Form Data Store: Datenspeicher eines Drittanbieters, der zum Speichern des fertig verarbeiteten Formular-/Briefdaten verwendet wird. Dies ist außerdem ein optionales Element der Topologie. Der Speicher unter „Verarbeitung“ kann endgültiges Aufzeichnungssystem verwendet werden.

Als Nächstes werden einige Empfehlungen zum Zuordnen von logischen Topologieelementen zu physischen Computern vorgestellt.

Empfohlene physische Topologie für neue Kunden ohne Workspace

Klicken Sie zum Öffnen einer vergrößerten Ansicht in einer neuen Registerkarte

Bei neuen AEM-Kunden, die keine Verwendung von AEM forms Workspace oder der AEM forms Workspace-App planen, wird die Ausführung von „Autor“ und „Verarbeitung“ im eigenständigen Modus außerhalb des JEE-Servers empfohlen, auf dem das Forms Workflows Add-On gehostet wird. Die stärkere Entkopplung von AEM und Forms Workflows Add-On bringt außerdem einige weitere Vorteile wie die Möglichkeit zur einfacheren Wartung/Aktualisierung eigenständiger Instanzen und die Möglichkeit, ohne JEE-Server auszukommen, sofern für die Kunden keine Anwendungsfälle bestehen, die den Rückgriff auf das Forms Workflows Add-On erfordern, usw.

Beachten Sie, dass adaptive Formulare meist bei internetbasierten Endbenutzern zur Anwendung kommen, während Correspondence Management von Intrane-basierten internen Benutzern verwendet wird. Daher werden für jedes Szenario zwei verschiedene Einrichtungen für „Veröffentlichung“ dargestellt: eines innerhalb des Extranets (für adaptive Formulare) und eines innerhalb des Intranets (für Correspondence Management).

Es sollte beachtet werden, dass in diesem Szenario das Forms Workflows Add-On ausschließlich optional ist und die Verwendung von den Anforderungen des Kunden abhängt.

Empfohlene physische Topologie für Kunden mit einfachen Formularen

Kunden mit einfachen Formularen, die nicht Workspace oder Correspondence Management verwenden und die benutzerdefinierte Formulardatensendung und Nachbearbeitung nutzen, können eine vereinfachte Topologie verwenden, die mehr mit einer standardmäßigen AEM-Bereitstellung im Einklang ist. Dies wird im folgenden Diagramm dargestellt:

Klicken Sie zum Öffnen einer vergrößerten Ansicht in einer neuen Registerkarte

Beachten Sie, dass die oben genannte Bereitstellung eher eine Autoren-Veröffentlichungs-AEM-Bereitstellung ist. Der Verarbeitungsserver wird hier nicht benötigt, da der Kunde nicht Workspace oder Correspondence Management verwendet. Die Formulardaten werden auch direkt an den eigenen Datenspeicher des Kunden mit einem Sende-Handler für benutzerdefinierte Formulare gesendet.

Empfohlene physische Topologie für Kunden, die von LiveCycle aktualisieren, oder für neue Kunden, die Workspace verwenden

Klicken Sie zum Öffnen einer vergrößerten Ansicht in einer neuen Registerkarte

Es wird empfohlen, die Autorenfunktion zusammen mit der Entwicklerversion des Forms Workflows Add-Ons auf demselben JEE-Server/-Cluster bereitzustellen. Nutzen Sie die gleiche Bereitstellung für Versionen des Forms Workflows-Add-Ons zur Verwaltung und Produktion. Bei Aktualisierung von Livecycle-Kunden ähnelt diese der bereits bekannten. Für neue Kunden, die HTML/Mobile Workspace verwenden, ist die parallele Bereitstellung von AEM und des Forms Workflows Add-Ons eine Voraussetzung.

Beachten Sie, dass die Kunden bei Bedarf möglicherweise auch „Veröffentlichen“ im eigenständigen Modus anstatt von einem JEE-Server aus ausführen können.

Stapelverarbeitung

Die aktuelle AEM forms-Version bietet einige neue Funktionen, die die Verarbeitung großer Dateistapel erleichtert. Das folgende Diagramm zeigt, wie Kunden PDF-Berichte aus einem großen Stapel von Eingangsdatendateien generieren und sie zum Senden an Endbenutzer drucken können:

Klicken Sie zum Öffnen einer vergrößerten Ansicht in einer neuen Registerkarte

Im Folgenden wird der Ablauf bei der Verarbeitung detaillierter beschrieben, wie im Diagramm oben dargestellt:

  • Der Stapel von Eingangsdatendateien wird in einen physischen Eingabeordner kopiert.
  • Ein geplanter Auftrag, der im Topologiefüllzeichen im Verarbeitungs-Cluster ausgeführt wird, wählt die Eingabedateien zur Verarbeitung aus. Dieser Auftrag wird aktiviert und konfiguriert, um den Eingabeordner über die neue Funktion für überwachte Ordner zu überprüfen.
  • Der Scan-Auftrag stellt die Dateistapel für die weitere Verarbeitung den verfügbaren Servern bereit. Die Dateiverarbeitung erfolgt über ein Skript, einen Dienst oder einen Workflow, den der Kunde für diesen überwachten Ordner festgelegt.
  • In diesem bestimmten Szenario verwendet der Dateiverarbeitungscode die neuen Stapelverarbeitungs-APIs (und das zugrunde liegende PDFG) zum Erstellen von PDF-Dateien aus den Eingabedatendateien und sendet die generierten PDF-Dateien an den Drucker.
  • Die Leistungsmetriken und Fehlerinformationen, die durch die Stapelverarbeitungs-APIs ausgegeben werden, werden wieder an das Framework des überwachten Ordners übertragen. Dadurch werden sie in den Ergebnis-/Fehlerordnern der physischen überwachten Ordner zur weiteren manuellen Analyse gespeichert.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie