Eine Einführung in die Dokumenterstellung (Document Authoring, DA) für Edge-Bereitstellungsdienste
Es gibt eine neue, äußerst überzeugende Early-Access-Technologie zur Verwaltung von Edge Delivery Services-Websites namens Document Authoring (ein Projekt, das früher als Dark Alley bekannt war). Es ist ein Hauch frischer Luft für die Bearbeitung, Übersetzung, Speicherung und Verwaltung von Edge Delivery-Implementierungen, und als leitender Architekt des ersten Kundenprojekts, das diese Technologie einsetzt, würde ich Sie gerne ein wenig durch das Projekt führen und meine Erfahrungen und Gedanken teilen. Wenn Sie Ihren nächsten Schritt für eine Site evaluieren, die auf AEM basiert (oder zu AEM migriert werden könnte), sollten Sie auf jeden Fall über DA Bescheid wissen .
Was ist Document Authoring (oder DA) für Edge Delivery Services?
Document Authoring oder DA
(der Künstler war früher als "Project Dark Alley" bekannt) ist eine blitzschnelle, Edge-Delivery-Services- oder Helix-native, integrierte Lösung für die Verwaltung, Bearbeitung und Veröffentlichung von Websites, die auf Edge Delivery Services basieren.
DA ist derzeit eine Early-Access-Technologie von Adobe, was bedeutet, dass Adobe derzeit gemeinsam mit Partnern wie uns und Partnern, die sich für diesen Weg entschieden haben, innovativ ist. Wenn du zu irgendeinem Zeitpunkt in diesem Artikel denkst: "ICH BIN DABEI, MELDE MICH AN", scrolle bitte nach unten, um die Slack/Discord- und Kontaktinformationen zu erhalten.
Für alle, die versuchen zu verstehen, wo DA in ein traditionelles AEM-Infrastrukturparadigma oder eine quasi-moderne dokumentenbasierte Edge-Delivery-Architektur passt, lassen Sie uns zunächst einige Begriffe aus dem Weg räumen:
Was sind Edge Delivery Services?
Die Edge Delivery Services von Adobe sind ein hochmodernes, Cloud-basiertes System für die Bereitstellung von Websites, das verfasste Dokumente und Bilder (und einige Videos) aufnimmt und sie auf eine für extreme Bereitstellungsgeschwindigkeit optimierte Weise im Web veröffentlicht. Edge Delivery Services erfüllt in einer modernen Architektur im Wesentlichen die gleiche Rolle wie die herkömmlichen AEM-Serverebenen "Publisher" und "Dispatcher" und bietet Vorteile wie:
- SEHR schnelle Bereitstellungsgeschwindigkeit - Im direkten Vergleich von herkömmlichem AEM und Edge Delivery (das ich bisher als EDS bezeichnen werde, um das Tippen zu sparen) waren die EDS-Seiten 3x bis 6x schneller als mit dem lokalen AEM 6.5.
- Die globale Bereitstellung ist in das System integriert. (Hinweis: China kann immer noch eine Herausforderung sein)
- Praktisch unbegrenzte Traffic-Kapazität - es gibt keine festgelegte Anzahl von Servern, die die Website bereitstellen, sodass das System in der Lage ist, selbst eine Super-Bowl-Werbespitze ohne Probleme zu bewältigen. Die Fähigkeit von Edge Delivery, lächerliche Traffic-Spitzen zu schlucken, ist bereits legendär, fragen Sie jeden, der eine EDS-Website hat und eine große TV-Werbekampagne durchgeführt hat.
- Integrierte Vorschau-Veröffentlichung, so dass man voll funktionsfähige Inhalte in der Vorschau anzeigen kann, bevor sie live gehen. Nicht nur das, sondern aufgrund des integrierten CI/CD-Feature-Sets verfügt jeder BRANCH des Codes über eine eigene, sofort bereitgestellte Vorschauumgebung, die eine wahnsinnig gute Flexibilität bietet, wenn es um UAT und Feature-Branching auf Squad-Ebene geht.
- Einfache "Block"-basierte Inhaltsentwicklung: Edge Delivery Services stellt Seiten bereit, die aus "Blöcken" bestehen, bei denen es sich um Inhaltselemente wie Tabellen, Registerkarten, Akkordeons oder Spalten handelt. Diese werden dann in einer einfachen Benutzeroberfläche im Google-Doc-Stil erstellt.
Denken Sie daran: Edge Delivery selbst ist KEIN CMS
Edge Delivery ist ein Entwicklungs-Framework und eine Bereitstellungspipeline, die als Teil der AEM-Lösung angeboten werden, aber NICHT die Lösung vorschreiben, die Sie verwenden, um Ihre Inhalte zu verwalten, den Zugriff auf Änderungen zu steuern, Übersetzungen einzuführen, Digital Asset Management-Systeme zu integrieren usw. Als Ergebnis gibt es eine REIHE von voll gültigen, vollständig unterstützten Systemen für die Erstellung und Veröffentlichung auf Edge Delivery Services, darunter:
- Dokumenterstellung
- Sharepoint (Englisch)
- Google Docs
- Adobe Experience Manager Universal-Editor
Es gibt Fälle, in denen jedes dieser Toolsets als Werkzeug für die jeweilige Aufgabe sinnvoll sein könnte, und es ist wichtig, die Vor- und Nachteile, Funktionen und Einschränkungen der einzelnen Toolsets zu verstehen. Beachten Sie auch, dass nicht JEDE Site gut für Edge Delivery Services geeignet ist, und einige eignen sich zu diesem Zeitpunkt möglicherweise am besten für herkömmliches AEM.
Ein weiterer Punkt der Klarheit in der Nomenklatur von Edge Delivery:
- "Dokumentbasiertes" Authoring impliziert, dass man es mit Dokumenten als primärer Inhaltseinheit zu tun hat. Bei der Dokumenterstellung werden HTML-Dokumente verwendet. Sharepoint verwendet Word-Dokumente, Google verwendet offensichtlich Google Docs. Dies steht im Gegensatz zum JCR-basierten Authoring, bei dem die einzelnen Dokumente und ihre Metadaten als Knoten im AEM Java Content Repository gespeichert werden.
- "Helix" = Edge Delivery Services: Diese Technologie hat eine Reihe von Namensänderungen durchlaufen, beginnend mit ihrem ursprünglichen Codenamen "Helix" und später unter der Bezeichnung "Franklin" sowie "Next-Generation Composability". Wenn Sie jedoch im Moment einen Verweis auf "Helix" sehen, bezieht er sich auf den Edge Delivery Services-Block im folgenden Diagramm.
Architekturdiagramm für Dokumenterstellung und Edge-Bereitstellung
Bevor wir uns mit dem Funktionsumfang der Dokumenterstellung befassen, schauen wir uns zunächst ein Architekturdiagramm an, das zeigt, wo DA in einer AEM/Edge Delivery-Beispielbereitstellung sitzen könnte:
In der oben genannten Architektur spielt DA die Rolle des CMS und der Authoring-Oberfläche und ist der Integrationspunkt für Dokumentverwaltungsaktivitäten wie Taxonomie, Asset-Management und Übersetzungen. Es ist jedoch im Allgemeinen NICHT der zentrale Integrationspunkt für die Integration von Backend- oder öffentlichen Daten, wie es bei einem herkömmlichen AEM-Autor der Fall sein könnte.
In der obigen Architektur gehen wir von Folgendem aus:
- Document Authoring ist die Oberfläche für die Erstellung, Verwaltung, Veröffentlichung und Einführung von Webdokumenten
- Adobe Edge Delivery Services als Publishing-Stufe, bei der Dokumente, die in Document Authoring erstellt wurden, in einem ultraschnellen, reaktionsschnellen und webfähigen Format bereitgestellt werden
- Adobe Managed CDN als Content Distribution Network, Web-Firewall und konfigurierbare Umleitungsschicht.
- Adobe Experience Manager Assets für Web Asset Management (Bilder, Dokumente und andere Dateien, die von der Website bereitgestellt werden)
- Hubspot für Webformulare und Bestätigungs-/Transaktions-E-Mails. (Diese Rolle kann auch von AEM Forms, Marketo Forms oder einer Vielzahl anderer Formularverwaltungsanbieter ausgefüllt werden.)
- Vidyard für Videoverwaltung und -bereitstellung
- Smartling für Übersetzungen
Ich könnte (und werde) viel Zeit darauf verwenden, die Flexibilität dieses Setups zu erläutern und zu erläutern, wie man sich mit den Anforderungen an die Datenresidenz und den Zugriff auf Dinge wie Produktdaten, PIM-Systeme, Altsysteme und dergleichen auseinandersetzen kann, aber das ist ein Beitrag für einen anderen Tag.
Der Funktionsumfang der Dokumenterstellung (DA)
Der DA-Funktionsumfang umfasst:
Verwaltung von Dokumentenbäumen
Die Inhaltsverwaltung für Ihre Edge Delivery-Site erfolgt über die DA-Schnittstelle (im Gegensatz zu Sharepoint oder AEM), wobei Dokumente intern in der Cloud gespeichert und versioniert werden. Die Dateiverwaltungs- und Veröffentlichungsschnittstelle von DA ermöglicht das normale Kopieren/Einfügen/Verschieben, wie Sie es erwarten würden, und enthält integrierte Aufrufe an Edge Delivery, um den Veröffentlichungs-/Vorschaustatus anzugeben.
Editor für Dokumente & Tabellen
DA enthält einen Dokumenteneditor und einen Blatteditor für Webdokumente sowie strukturierte Daten. Der Editor ist schnörkellos und blitzschnell, inklusive einem Schrägstrich-Menü für schnelle Funktionen und Formatierungen, einer Blockbibliothek für den schnellen Zugriff auf Blöcke (z. "Komponenten" in der alten AEM-Sprache), die Sie in Ihrem Projekt erstellt haben.
Das Editor-Plugin-Framework zum Hinzufügen anderer benutzerdefinierter UI-Funktionen für Ihr Projekt. Einige dieser Plug-ins, die wir verwendet haben, sind ein Tag-Browser zum Durchsuchen und Auswählen von AEM-Tags aus einer AEM-Instanz oder ein Datumswähler zum Eingeben von Datumsformaten in einem erwarteten Format in eine Ereignisverwaltungs-Benutzeroberfläche.
Zusammenarbeit in Echtzeit
DA umfasst eine robuste Zusammenarbeit in Echtzeit, die es praktisch beliebig vielen Benutzern ermöglicht, ein Dokument gleichzeitig zu bearbeiten. Wir haben dies tatsächlich in Echtzeit auf der AdaptTo()-Konferenz getestet, wo ich einen Vortrag zur Einführung in Document Authoring gehalten habe. Als Teil des Vortrags lud ich schließlich alle 200+ Mitglieder des Publikums ein, sich gleichzeitig in ein Dokument einzuloggen und mit der Bearbeitung und Vorschau zu beginnen, und das Collaboration-Backend hielt einfach perfekt - was mehr ist, als man manchmal von der Bearbeitung in Office sagen kann.
Integration von AEM Assets
DA umfasst eine integrierte AEM Assets-Integration über das AEM Assets Micro Frontend (MFE). Auf diese Weise kann das Unternehmen AEM Assets weiterhin als zentrales Aufzeichnungssystem für das Digital Asset Management verwenden, während Autoren gleichzeitig die Freiheit haben, in einem schnellen, dokumentenbasierten Edge-Bereitstellungssystem zu arbeiten.
Integrierte Versionierung von Dokumenten
DA verfügt über eine integrierte Dokumentversionierung und einen Überwachungsverlauf. Jede Bearbeitung, die ein Benutzer an einem Dokument vornimmt, wird mit einem Datums- und Zeitstempel versehen, und die Versionierung des Wiederherstellungspunkts erfolgt automatisch jedes Mal, wenn eine Seite veröffentlicht wird, oder ad-hoc an jeder Stelle, an der Sie einen Wiederherstellungspunkt streichen möchten.
Die Versionierung ist auch in großen Mengen und über die API verfügbar.
Live-Vorschau
DA bietet eine Live-Vorschau im Bearbeitungsfenster, wobei mehrere Bildschirmgrößen (Handy, Tablet, Desktop) verfügbar sind.
Bulk-Werkzeuge
Es handelt sich noch um eine frühe Implementierung dieser Early-Access-Technologie, aber DA enthält bereits ÄUSSERST nützliche Massentools für die Massenvorschau, die Massenveröffentlichung, die Massenneuindizierung und die Massenversionierung.
Dies, kombiniert mit einem berserkerschnellen Suchen und Ersetzen über ganze Inhaltsbäume hinweg, ist sehr schnell und praktikabel, um sichere, massenhafte Änderungen an großen Teilen von Inhalten vorzunehmen und sie dann auszurollen.
Zum Beispiel musste ich in einem Unterabschnitt der Website, der etwa 4000 Seiten umfasste, den Namen eines Fragments ersetzen, das wir für die Unternavigation verwendeten. Anstatt einen Entwickler mit dem Schreiben eines groovigen Skripts beauftragen zu müssen (wie man es in der AEM-Welt tun würde), haben wir Search & Replace in der DA-Benutzeroberfläche durchgeführt, was alles in weniger als 8 Sekunden erledigt hat.
Noch besser war, dass ich in der Lage war, den gesamten Abschnitt der Website zuerst in großen Mengen zu versionieren, so dass ich eine sofortige Backup-Version hatte, auf die ich zurückgreifen konnte, falls bei der Suche und dem Ersetzen etwas schief ging. Wieder.... HAUCH FRISCHER LUFT.
Übersetzung/Rollout und ein "MSM"-Ersatz für Edge Delivery
Ein wichtiger Grund, warum sich unser Launch-Kunde für DA anstelle von Sharepoint/Universal Editor für die Edge-Delivery-Einführung entschieden hat, ist das robuste Lokalisierungs-Framework und die Funktionalität von DA für die Einführung und Reintegration von Seiten. Eine große Herausforderung bei der Implementierung lokalisierter Edge-Delivery-Sites mit Google Docs oder Sharepoint (oder sogar Crosswalk-Sites mit Universal Editor) ist das Fehlen eines etablierten Frameworks, das den Multi-Site-Manager (MSM) von AEM ersetzt.
Ohne einen Konnektor für ein Translation-Management-System (TMS) und MSM-Funktionen, auf die zugegriffen werden kann, ist jeder, der eine lokalisierte Website auf Edge Delivery implementiert, gezwungen, seinen EIGENEN maßgeschneiderten Workflow zu entwerfen und zu erstellen, um Dokumente für die Übersetzung zu sammeln und sie an das TMS zu senden (z. Smartling oder Translations.com etc.), um sie wieder abzurufen, lokale Änderungen zu verarbeiten und auszurollen. Allein diese Funktionalität könnte einen großen Teil der Entwicklungsarbeit ausmachen, um auf Edge Delivery umzusteigen, und einen Großteil des Vorteils der Schnelligkeit der Entwicklung von EDS zunichte machen. DA löst dieses Problem, indem es ein robustes und SEHR flexibles Arrangement für den Versand von Übersetzungen bereitstellt und dann alle lokalen Änderungen unterscheidet, wenn diese Übersetzungen zurückgebracht werden.
Zugriffskontrolle für Authoring und Publishing
DA enthält ein robustes ACL-Modell für die Zugriffssteuerung für Veröffentlichung und Erstellung. Edge Delivery kann in dieser Hinsicht etwas interessant sein, da Edge Delivery im Gegensatz zu einem einheitlichen System wie AEM, bei dem das Authoring und die Veröffentlichung alle Teil desselben Systems sind, separat ist. In Bezug auf das obige Diagramm verfügt "Helix" oder Edge Delivery über ein eigenes Vorschau-/Veröffentlichungsberechtigungssystem - und ist NICHT feinkörnig. Das heißt, Sie können Inhalte entweder in den "aem.page" schieben oder "aem.live" Eimer oder Sie können es nicht. Eine fein abgestufte Zugriffskontrolle (z. B. kann nur die Gruppe "Blogger" Inhalte in den /blog-Inhaltsbaum schreiben, aber sie können sie nicht nur veröffentlichen - usw.), die von der Authoring-Oberfläche implementiert werden muss.
Daher unterstützt DA sowohl die Zugriffssteuerung auf Oberflächenebene (fein abgestuft) als auch einen Mechanismus zum Konfigurieren der geschützten Veröffentlichung in Helix, um festzulegen, welche Benutzer Inhalte in der Vorschau anzeigen und in Edge Delivery veröffentlichen können.
OMG die rohe Geschwindigkeit
Die letzte Bemerkung, die ich zu DA machen sollte (die sehr gut die erste sein könnte), ist, dass DA ohne Zweifel das schnellste CMS ist, das ich je verwendet habe. Wenn Sie ein schnelleres CMS finden können, lassen Sie es mich bitte wissen.
Die Ladezeit von Dokumenten, die Veröffentlichungszeit und die allgemeine Schnelligkeit der Benutzeroberfläche sind unübertroffen, was natürlich darauf zurückzuführen ist, dass DA SELBST ein Edge-Delivery-Projekt ist. Onboarding-Autoren auf der Client-Seite, die DA hintereinander mit AEM 6.5 verwenden, sind einhellig schockiert darüber, wie schnell es ist. Der Unterschied ist besonders deutlich, wenn es sich um komplexe Seiten handelt, die in AEM verschachtelte Komponenten oder mehrere Dialogfelder enthalten, die alle Zeit benötigen, um aus dem JCR geladen zu werden.
So erhalten Sie die Dokumenterstellung
Um es noch einmal zu wiederholen: DA ist nach wie vor eine Early-Access-Technologie für Edge Delivery Services.
Edge Delivery Services selbst ist Teil von AEM as a Cloud Service und ab diesem Zeitpunkt ein einheitliches Angebot mit AEM as a Cloud Service. Wenn Sie also einen Wechsel zu AEM as a Cloud Service in Betracht ziehen (oder wenn Sie es bereits haben), ist DA möglicherweise eine Option für Sie.
Wenn Sie bereits eine Implementierungs-Slack mit Adobe haben, fragen Sie sie nach DA und sie werden Ihnen helfen, loszulegen.
Sie können sich auch über den Adobe Discord an uns wenden, wo es einen eigenen DA-Kanal gibt.
Zu guter Letzt kontaktieren Sie uns bitte entweder auf der Website oder direkt auf Linkedin oder Twitter/X. Ich würde Ihnen gerne von meinen Erfahrungen damit erzählen!
Oder besuchen Sie uns auf dem Adobe Summit und wir würden Ihnen gerne eine Demo geben!

Tad Reeves
Leitender Architekt bei Arbory Digital
AEM Architect & DevOps mit 14+ Jahren Erfahrung mit AEM/CQ und 25+ Jahren in der Systeminfrastruktur. Er fährt schon länger Mountainbike, als er sich um die Systemadministration kümmert, und obwohl er ursprünglich aus Maine stammt, lebt er in den Bergen im Nordwesten von Georgia.
Gefällt Ihnen, was Sie gehört haben? Haben Sie Fragen dazu, was für Sie das Richtige ist? Wir würden uns freuen, mit Ihnen zu sprechen! Kontaktieren Sie uns
Podcast-Episoden & Blogbeiträge

Was ist AEM? Wofür wird Adobe Experience Manager verwendet? Wir haben versucht, in 30 Minuten oder weniger zu erklären, was AEM ist und tut - und irgendwie haben wir es geschafft, obwohl die Feuerwehr zufällig etwa 19 Minuten nach der Podcast-Aufnahme auftauchte!

Wie viel wissen Sie über die Tools, die Ihnen zur Verfügung stehen, um die Leistung Ihrer Website auf dem chinesischen Festland zu optimieren? Und selbst wenn Sie keine chinesischsprachige Website haben, müssen Sie sich um die Leistung in China kümmern? SIE TUN!

Im heutigen Krieg zwischen Cloud-Rückführung und blitzschnellen neuen Edge-Delivery-Services wollen wir uns noch einmal die Frage stellen: Ist selbst gehostetes AEM immer noch ein Thema?