Adobe已採用Adobe Commerce的GraphQL API作為適用於所有商務相關資料的官方Commerce API。 因此,AEM會使用GraphQL透過I/O Runtime與Adobe Commerce及任何商務引擎交換商務資料。 此GraphQL API獨立於AEM GraphQL API,可存取內容片段。
沒有官方的AEM Assets — 提供Adobe Commerce整合。 上有可用的合作夥伴聯結器 marketplace
或者,作為因應措施,您可以在AEM Assets中儲存產品資產(影像),但您必須在Adobe Commerce中手動儲存資產URL。 Dynamic Media現在是AEM Assets的一部分,且運作方式相同。
不,您的商務解決方案部署在哪裡並不重要。 不論部署模式為何,CIF和AEM儲存庫都能運作。 不過,如果解決方案是使用建議的E2E參考架構進行部署,則E2E測試可以根據代表典型企業客戶設定檔的效能KPI執行。 此方法提供可當作基準的其他資訊。
目錄頁面和產品頁面是根據通用目錄和產品頁面範本,在AEM中動態建立及快取。 AEM中不會匯入及儲存任何產品或目錄資料。
搭配AEM Cloud Service使用的CIF附加元件可讓資料從商務解決方案依需求傳輸至AEM。 因此,當您的商務解決方案中有更新時,這不是即時推送或批次流程。
這取決於您必須考慮的其他幾個方面。 您的目錄資料和頁面的快取比率是多少? 您預期在高峰時段會有多少同時請求? 您的商務解決方案API的擴充性如何?
PIM資料會透過GraphQL要求向AEM和使用者端公開。 我們的建議是將PIM與商務引擎(Adobe Commerce或其他)整合,以便之後可以從商務引擎擷取PIM資料。
Dispatcher上不會快取價格或詳細目錄等動態資料。 直接透過GraphQL API,使用網頁元件在使用者端擷取動態資料。 Dispatcher上只會快取靜態資料(例如產品或類別資料)。 如果產品資料變更,則需要讓快取失效。
Adobe建議針對Dispatcher上快取的頁面設定TTL型快取失效。 若是價格或庫存等動態資訊,Adobe建議在使用者端轉譯資料。 如需有關TTL型快取失效的詳細資訊,請參閱 最佳化Dispatcher快取 和 AEM效能最佳化.
已提供產品搜尋參考實作,但未提供具有內容的整合式搜尋。 此功能因客戶而異,專案專屬層級也能提供更好的解決方案。
CIF提供搜尋列和搜尋結果元件。 搜尋列元件會將具有搜尋字詞的GraphQL要求傳送至商業解決方案,然後傳回包含產品名稱、價格、SLUG等的產品清單。 「搜尋結果」元件接著會在以AEM建立的搜尋結果頁面上的相簿檢視中顯示搜尋結果。 「搜尋」支援基本的全文檢索搜尋。 我們使用SLUG/url鍵來建置PDP的參考。
產品資料已在PIM或Adobe Commerce中轉譯。 AEM - Adobe Commerce整合支援連線至多個Adobe Commerce商店和商店檢視。 在MSM設定中,通常一個AEM網站會連結至一個Adobe Commerce商店檢視。
Adobe建議管理AEM中的行銷相關資料和內容。 使用內容片段的其他屬性裝飾您的商業解決方案的產品資料,或建立非結構化內容的體驗片段並將其與您的產品連結。
Adobe建議使用抽象的付款方法。 這樣一來,瀏覽器使用者端就會與支付閘道提供者直接通訊,因此Adobe或商業解決方案都不會保留或傳遞持卡人資料。 此方法只需要第3級PCI相容性。 不過,還有其他完全符合PCI規範的事項需要考慮,例如員工如何與系統和資料互動。 如需Adobe Commerce PCI法規遵循的詳細資訊,請參閱 PCI法規遵循需求.
可以,您可以依要求取得自我評估問卷D和合規證明。
您可以要求試用授權以使用I/O Runtime 此處.