邊緣傳遞服務的文件編寫 (DA) 簡介

有一項全新、極具吸引力的早期存取技術來管理邊緣傳遞服務網站，稱為「文件編寫」（以前稱為 Dark Alley 的專案）。對於 Edge Delivery 實作的編輯、翻譯、儲存和管理來說，這是一個新鮮的氣息，而作為第一個使用此技術的客戶專案的首席架構師，我希望向您介紹一下，並提供我的經驗和想法。如果您正在評估基於 AEM（或可能會遷移到 AEM）的網站的下一次移動，那麼您絕對應該了 解 DA。

什麼是邊緣傳遞服務的文件編寫 (或 DA)？

文件編寫或 DA（藝術家前稱為 " Project Dark Alley "）是一種極快的邊緣傳遞服務或 Helix 原生的整合解決方案，用於基於邊緣傳遞服務的管理、編輯和發佈網站。

DA 目前是 Adobe 提供 的早期存取技術， 這意味著 Adobe 目前正在與我們這樣的合作夥伴和選擇這種途徑的合作夥伴共同創新。如果您在本文的任何時候喜歡 " 我在註冊我加入 " 請滾動到底部以獲取 Slack/Discord & 聯繫信息。

對於任何想要了解 DA 在傳統的 AEM 基礎架構模式或基於近現代文檔的 Edge Delivery 架構中的哪些位置適合的人，讓我們首先解釋一些術語：

什麼是邊緣交付服務？

Adobe 的 Edge 傳遞服務是一種尖端的雲端網站傳遞系統，可以取得作者文檔 & 圖像（和一些視頻），並以最佳化的方式將它們發佈到 Web 上，以最佳化的方式為極高傳遞速度進行最佳化。邊緣傳遞服務在現代架構中基本上充滿了與傳統的 AEM「發布者」和「調度員」伺服器層級相同的角色， 並具有以下優勢：

• 非常快速的交付 速度-在傳統 AEM 與邊緣交付（以前我將稱為 EDS，以節省打字）的比較，EDS 頁面比現場 AEM 6.5 快 3 倍 -6 倍。
• 全球交 付內置於系統中。（注：中國仍然可能是一個挑戰）
• 幾乎無限的流量-沒有設定數量提供網站的服務器，因此該系統即使是超級碗廣告大小的突發，也可以毫無問題地處理。Edge Delivery 能夠捕捉到瘋狂大規模的流量激增的能力已經是傳奇的，請問任何擁有 EDS 網站的經營大型電視廣告活動的人。
• 內置預覽發佈，因此可以在上線之前預覽功能齊全的內容。不僅如此，由於內建的 CI/CD 功能集，每個代碼分支都有自己的即時佈建的預覽環境，在群組級 UAT 和功能分支方面提供了瘋狂的良好的靈活性。
• 基於「區塊」的簡單內容開發：Edge Delivery 服務提供由「區塊」組成的頁面，這些頁面是表格、標籤、手風琴或欄等內容元素。然後，它們會在簡單的 google doc 樣式界面中撰寫。

請記住：邊緣交付本身不是 CMS

Edge Delivery 是作為 AEM 解決方案的一部分提供的開發架構和交付管道，但它不決定您用於管理內容、控制修改的訪問權限，推出翻譯，整合數字資產管理系統等的解決方案。因此，有一些完全有效且完全支援的系統可用於在 Edge 傳遞服務上編寫 & 發佈，包括：

• 文件編寫
• 分享
• 谷歌文件
• Adobe 體驗管理員通用編輯器

在某些情況下，這些工具組中的每個工具都可以作為工作的工具有意義，並且瞭解每個工具的優缺點、功能和限制非常重要。請注意，並非每個網站都適用於邊緣交付服務，而某些網站可能在此時間最適合傳統 AEM。

作為邊緣交付術語法中的另一個清晰點：

• " 以文件為基礎的 " 編寫意味著文件是處理文件作為內容的主要單位。文件編寫使用 HTML 文件。SharePoint 使用 Word 文檔，谷歌顯然使用谷歌文檔。這與以 JCR 為基礎的編寫相反，其中個別文件及其中繼資料將作為節點儲存在 AEM Java 內容存放庫中。
• " Helix " = 邊緣交付服務：該技術已經經歷了許多名稱更改，從原始的代碼名稱 " Helix " 開始，後來被稱為 " 富蘭克林 " 以及 " 下一代可組合性 ".但是現在，如果您看到 " Helix " 的引用，則指以下圖 中的邊緣交付服務 塊。

文件編寫 & 邊緣傳遞架構圖

在深入探討文件編寫功能集之前，讓我們首先看一個架構圖，說明 DA 可以在 AEM/Edge 傳遞部署範例中的位置：

在上述架構中，DA 扮演 CMS 和編寫表面的角色，也是文件管理活動的整合點，例如分類、資產管理和翻譯。然而，它通 常 不是以傳統 AEM 作者的方式一樣，它不是後端或公共數據集成的中央集成點。

在上面的架構中，我們假設：

• 文件編寫是 Web 文件建立、管理、發佈和翻譯推出的表面
• Adobe Edge 傳遞服務 作為發佈層，可以採用文件編寫的文件，並以超快速、響應式、可供網頁使用的格式傳遞
• Adobe 受管 CDN 作 為 內容分發網路、網頁防火牆和可配置重新導向層。
• 用於 Web 資產管理的 Adobe Experience Manager 資產資產（由網站提供的影像、文件和其他檔案）
• 用於 Web 表單和確認/交易電子郵件的 Hubspot。(此角色也可以由 AEM 表單、Marketo 表單或許多其他表格管理提供商填寫)
• 用於視頻管理和傳遞的 Vidyard
• 用於翻譯的智能 手法

我可以（也會）花費大量時間來解釋這種設置的靈活性，以及如何解決產品數據、PIM 系統、舊系統等事物的資料存放和訪問需求，但這是另一天的帖子。

文件編寫 (DA) 功能集

DA 功能集包括：

文件樹管理

Edge Delivery 網站的內容管理是從 DA 介面內部 (與 Sharepoint 相反，或 AEM 內部) 完成，文件內部儲存並在雲端中進行版本化。DA 的文件管理和發佈界面允許正常的方式複製/粘貼/移動，並包含向 Edge Delivery 的內置呼叫來表示發佈/預覽狀態。

文件編輯器 & 工作表

DA 包括用於 Web 文檔以及結構化數據的文檔編輯器 & 工作表編輯器。編輯器非常簡單且速度極快，包括用於快速函數 & 格式化的斜線菜單，一個用於快速訪問塊的塊庫（即：" 您在項目中創建的舊 AEM 演講中的組件 "）。

編輯器插件框架，用於將其他自定義 UI 功能添加到您的項目中。我們使用的一些這樣的插件是用於瀏覽 & 的標籤瀏覽器，從 AEM 實例中選擇 AEM 標籤，或是日期選擇器，用於將預期格式輸入日期格式到事件管理 UI 中。

即時協作

DA 包括強大的即時協作，幾乎允許任意數量的使用者同時編輯文件。我們實際上最終在 AdaptTo () 會議上實時測試了這個問題，我在那裡進行了一個介紹文檔編寫的講座。作為演講的一部分，我最終邀請所有 200 多名觀眾同時登錄文檔，並開始編輯 & 預覽文件，而協作後端的效果非常完美-這對於有時候在 Office 中進行編輯的更多。

AEM 資產整合

DA 包括使用 AEM 資產微型前端 (MFE) 的內建 AEM 資產整合。這使組織能夠繼續使用 AEM Assets 作為數字資產管理的中央記錄系統，同時也讓作者可以自由地在基於文檔的快速邊緣交付系統中工作。

這個實現是 A+，真的是 DA 的絕佳功能之一。

內建文件版本控制

DA 具有內置文件版本控制和稽核歷史記錄。任何使用者對文件所做的每一次編輯都會以日期 & 時間戳記進行稽核，而且每次發佈頁面時，還原點版本控制都會自動執行，或在您想要切割還原點的任何點時進行臨時執行。

版本控制也可以批量使用，以及透過 API。

即時預覽

DA 在編輯視窗中提供即時預覽，並提供多種屏幕尺寸（手機，平板電腦，桌面）。

批量工具

這仍然是這種早期存取技術的早期實施，但 DA 已經包含了非常有用的批量工具，可用於批量預覽、大量發佈、大量重新索引和大量版本化。

這結合在整個內容樹上的速度快速搜尋 & 取代，& 可以在大量內容中進行安全、大量變更，然後推出這些變更非常快。

例如，在網站的一個子部分中包含大約 4000 頁面中，我不得不替換我們用於子導航的片段的名稱。而不需要讓開發人員編寫一個很棒的腳本（就像 AEM 世界中一樣），我們在 DA UI 中搜索了 & 替換，它在不到 8 秒內完成所有內容。

更好的是，我能夠首先批量版本網站的整個部分，所以如果搜索 & 替換出現問題，我有一個即時備份版本可以恢復到。再次... 呼吸新鮮空氣。

翻譯/推出以及邊緣交付的 " MSM " 替代

我們的推出客戶選擇 DA 進行 Edge Delivery 推出而不是 Sharepoint/通用編輯器的重大原因，是 DA 的強大的本地化架構和頁面推出 & 重新整合功能。使用 Google 文檔或 Sharepoint（甚至使用通用編輯器）實施本地化邊緣交付網站（甚至是帶有通用編輯器的跨越站點站點）來實現本地化邊緣交付網站的主要挑戰是缺少了固定的框架來取代 AEM 的多站點管理器（MSM）。

如果沒有翻譯管理系統 (TMS) 連接器和 MSM 功能可以利用，任何在 Edge Delivery 上實作本地化網站的任何人都必須設計並建立自己的定制工作流程和文件隨機處理災難，以收集文件進行翻譯，並將其運送到 TMS（例如Smartling 或 Translations.com 等），以檢索它們回來，處理本地更改並推出它們。僅僅有這種功能就可以代表開發工作的巨大部分，並消除了 EDS 開發速度的大部分。DA 通過提供強大且非常靈活的安排來解決此問題，以便將翻譯運送，然後在將這些翻譯返回時進行任何本地更改進行分析。

編寫 & 發佈存取控制

DA 確實包含用於發佈 & 編寫存取控制的強大 ACL 模型。在這方面，邊緣傳遞可能有點有趣，因為與 AEM 這樣的統一系統不同，其中編寫 & 發佈都是同一系統的一部分，Edge Delivery 是獨立的。參考上面的圖表，" Helix " 或 Edge Delivery 具有自己的預覽/發佈權限系統-並且不是細微細的。這意味著，您可以將內容推送到 " aem.page "或 " 艾姆 .直播 "水桶或你不能。精細的訪問控制（就像只有 " 部落客 " 組可以將內容寫入 /blog 內容樹，但他們不能僅發布它-等），這取決於編寫表面來實現。

因此，DA 同時支持授權表面層級訪問控制（細粒度），以及在 Helix 中配置受保護發佈的機制，以鎖定使用者可以預覽 & 將內容發佈到 Edge Delivery。

天啊，原始速度

我應該對 DA 發表的最後一個評論（這很可能是第一個）是 DA 毫無疑問是我使用過的最快的 CMS。如果您可以找到更快的 CMS，請告訴我。

文件加載時間、發佈時間和 UI 的整體快捷性是無與倫比的，當然是由於 DA 本身是一個 Edge Delivery 項目的事實。客戶端的入職作者，以 AEM 6.5 反對背使用 DA 的作者對它的速度一致感到震驚。當處理 AEM 中包含巢狀元件的複雜頁面，或多個對話框都需要時間從 JCR 載入的多個對話框時，這個差異尤其明顯。

如何取得文件編寫

重申請，DA 仍然是邊緣交付服務的早期訪問技術。

邊緣交付服務本身是 AEM 作為雲服務的一部分，截至此時，它是與 AEM 作為雲服務的統一產品。因此，如果您正在考慮將 AEM 作為雲服務轉移（或者您已經擁有它），DA 可能是您的一個選擇。

如果您已經使用 Adobe 實作 Slack，請詢問他們有關 DA，他們會幫助您開始。

您也可以透過 Adobe Discord 聯絡，這裡有專屬 DA 頻道。

最後，請在網站上與我們聯繫並與我們聯繫，或直接在 Linkedin 或 Twitter/X 上與我們聯繫。我很想告訴你我在這方面的經驗！

或者，來到 Adobe 高峰會見我 們，我們很樂意為您提供演示！

喜歡你聽到的嗎？對於適合您的選項有疑問嗎？我們很樂意談談！聯絡我們

播客劇集 & 博客文章