如果今天需要將近一個小時才能完成的工作流程，只需按一下即可在 Experience Cloud 中變成受控的可重複流程，那會怎麼樣？本指南說明 Adobe App Builder 如何將手動操作工作轉換為可擴充的自動化，並逐步說明從概念發展至已發佈企業應用程式的確切步驟。」

不久前，我正協助一家大型金融技術組織簡化其 Adobe Target 工作流程。他們的團隊花了將近 45 分鐘為每個活動設定曝光上限邏輯，也就是仔細地處理設定、客群、規則和驗證。看著這一切發生，我一直認為一定會有更好的方法。如果所有這一切都可以在幾分鐘內發生，甚至只需按一下，那會怎麼樣？

這讓我直接開始了解 Adobe App Builder。

在大型企業環境中，團隊通常仰賴工具、指令碼和部落知識的組合來完成日常工作。雖然沒有什麼真正「中斷」的地方，但感覺做什麼事都比應該的步驟要多。App Builder 提供不同的路徑：您不需要圍繞平台工作，而是在其中建立工作流程。

自訂介面。在 Adobe Experience Cloud 中。由您的邏輯、API 和自動化提供支援。

這正是我建立的——輕量型內部應用程式，可自動處理整個曝光次數上限設定。過去需要完成的數十種手動操作，現在變成直接內嵌於 Adobe UI 中的簡潔控制面板。

在本文中，我將分享 App Builder 的運作方式，以及它為何是企業團隊的寶貴工具，並逐步說明啟動和執行您自己的應用程式所需的命令和設定。無論您是要自動化利基工作流程，還是要建立完整的內部產品，本指南都應為您提供堅實的起點。

什麼是 Adobe App Builder？

Adobe App Builder 是完整的應用程式和執行階段框架，可建立在 Adobe 基礎結構上執行的自訂雲端原生應用程式。它可讓開發人員擴充 Adobe Experience Cloud、Adobe Experience Platform 和其他 Adobe 產品的功能。透過 App Builder，團隊可以在 Adobe 和第三方系統之間建立自訂整合，以簡化營運並提高工作流程效率。

App Builder 提供數個範本，可作為不同類型整合的起點。在本文中，我會著重介紹 excshell 擴充功能，此擴充功能可讓您的應用程式直接在 Adobe Experience Cloud 命令介面中執行。

每個應用程式：

• 已使用 Adobe IMS 進行驗證

• 已使用 Adobe I/O Runtime 以無伺服器方式部署

• 已與您組織的 Adobe Experience Cloud 環境整合

• 已使用統一的 Developer Console 和專案工作區模型進行管理

簡而言之：這是您的 Adobe Experience Cloud 自訂擴充功能框架。

諮詢觀點

身為顧問，我經常遇到企業團隊想要：

• 簡化內部行銷或內容檢閱工作流程

• 提供複雜的 Target 或 AEM 設定的受控可見度

• 自動化重複式 API 工作，例如行銷活動同步或客群建立

App Builder 優雅地解決了這個問題。它結合了安全執行階段動作、頻譜式 UI 元件和控管的存取控制，實現了快速開發，而不需要管理基礎結構或認證。

現實範例概觀

我的一位客戶面臨 Adobe Target 中複雜的活動設定，涉及多個技術性步驟且非常耗時。我提出要建立一個應用程式，只要按一下按鈕即可處理複雜的 45 分鐘設定。此應用程式將與 Adobe Target Admin API 整合，以管理活動、產品建議和客群。主要功能：

• 可搜尋、可排序的 Target 活動清單

• 工作區篩選器，用於儲存使用者選擇

• 包含每個體驗動作的詳細資料模型

• 按一下產品建議更新 (插入後設資料)

• 選擇性客群建立與可設定值

• 適用於原生 Adobe 外觀的頻譜式 UI (Spectrum CSS)

快速入門 (新環境)

1) 先決條件

• Adobe Developer Console 存取 (使用 App Builder 的專案)

• Node.js 18+ 和 npm

• Adobe I/O CLI：npm install -g @adobe/aio-cli

• 登入 Adobe：aio login

2) 初始化

如果從頭開始：

3) 設定 app.config.yaml

app.config.yaml 檔案會定義應用程式與 Adobe Experience Cloud 整合的方式。它會告訴 App Builder 您正在建立哪種擴充功能、前端檔案所在位置，以及應該在 Adobe I/O Runtime 中執行哪些後端動作。

概言之，您可以指定：

• 擴充功能類型 — 在此案例中為 Experience Cloud 命令介面擴充功能 (dx/excshell/1)，可讓應用程式直接顯示在 Adobe Experience Cloud 介面中。

• 前端實作 — 指向主要 HTML 進入點 (例如 index.html) 以及應用程式名稱、說明和圖示等後設資料。

• 網頁資產資料夾 — 通常是 Web-src 目錄，包含頻譜式前端。

• 執行階段動作 — 部署至 Adobe 無伺服器基礎結構的一組 Node.js 函式 (例如「getTargetActivities」、「updateOffer」等)。每個動作都包含如下詳細資訊：

  • JavaScript 函式檔案路徑

  • 是否可供網頁存取

  • Node.js 執行階段版本

  • 任何註解 (例如需要 Adobe 驗證)

簡而言之，此設定會將您的使用者介面連線到後端邏輯，並讓 Experience Cloud 在部署後可偵測到應用程式。

4) 本機開發

應用程式在 http://localhost:9080 提供即時重新載入和 IMS 驗證 (在 Experience Cloud 命令介面中啟動時)。

5) 部署至工作區

視需要切換工作區 (例如預備、生產)：

6) 發佈至目錄 (生產)

Exchange 核准後，應用程式會出現在您組織的 App Builder 目錄中。

動作 (無伺服器 API)

此應用程式中使用的範例 (Node.js, @adobe/aio-sdk + node-fetch)：

• getTargetActivities — 列出組織/租用戶的 Target 活動

• getActivity — 擷取特定活動的詳細資料 (/target/activities/{type}/{id})

• getOffer — 讀取 JSON 產品建議 (/target/offers/json/{offerId})

• updateOffer — 更新產品建議 (PUT /target/offers/content/{offerId})

• createAudience — 使用規則邏輯建立目標客群

每個動作會從快取的 State 存放區 (由 getAccessToken 動作填入) 擷取 IMS 存取權杖，並以 Authorization: Bearer <token> 和 X-Api-Key: <clientId> 標頭呼叫 Adobe Target API。

前端 (頻譜 UI)

UI 是使用 Spectrum CSS 的普通 HTML/JS：

• 使用清除按鈕搜尋輸入

• 工作區選擇器 (安靜選擇器)

• 具有狀態晶片和格式化時間戳記的表格

• 包含 更新產品建議 和選擇性 建立客群 控制項的模組化對話方塊

UI 會將選取的工作區儲存在 localStorage 中，讓您的篩選器跨工作階段持續存在。

命令參考

最佳做法和備註

• 在 Experience Cloud 命令介面內執行時，使用 runtime.done() (透過 @adobe/exc-app Runtime)，以避免命令介面逾時 UI (針對 SPA 設定)。

• 避免長時間執行的動作；如有需要，可快速返回並串流或輪詢。

• 偏好使用安靜頻譜元件，以實現一致的命令介面。

• 在動作中保留驗證邏輯；前端會呼叫您的動作，而非直接呼叫 Adobe API。

• 在 localStorage 中儲存使用者篩選器 (例如工作區)，以獲得更好的 UX。

• 針對 Exchange 發佈，請確定適當的後設資料 (名稱、圖示)，並在 app.config.yaml 中包含擴充功能區塊。

文件

• Adobe App Builder — 快速入門

• Developer Console