標準單一租用戶邏輯應用程式與使用量多租用戶邏輯應用程式之間的差異
Azure Logic Apps 是雲端式平台，可建立和執行自動化「邏輯應用程式工作流程」，以整合應用程式、資料、服務和系統。 使用這個平台，您可以為企業和企業對企業 (B2B) 案例快速開發高可擴縮性的整合解決方案。 建立邏輯應用程式資源時，您可以選取 [使用量] 或 [標準] 裝載類型。 使用量邏輯應用程式只能有一個在多租用戶 Azure Logic Apps 中執行的工作流程。 標準邏輯應用程式可以有在單一租用戶 Azure Logic Apps 或 App Service 環境v3 (ASE v3) 中執行的一或多個工作流程。
在您選擇要建立的邏輯應用程式資源之前，請先檢閱下列指南，以了解邏輯應用程式工作流程類型間的比較。 接著，您可以針對哪一個邏輯應用程式工作流程和環境做出更適合您的案例、解決方案需求，以及您想要部署和執行工作流程的目的地的更好選擇。
如果您不熟悉 Azure Logic Apps，請檢閱什麼是 Azure Logic Apps？，以及什麼是邏輯應用程式工作流程？。
邏輯應用程式工作流程類型和環境
下表摘要說明使用量邏輯應用程式工作流程與標準邏輯應用程式工作流程之間的差異。 您也會了解在部署、裝載和執行工作流程方面，單一租用戶環境與多租用戶環境的不同之處。
| 主控選項 | 福利 | 資源共用和使用方式 | 價格和計費模型 | 限制管理 |
|---|---|---|---|---|
| 耗用 主機環境：多租用戶 Azure Logic Apps |
- 最容易上手 - 按使用量付費 - 完全受控 |
單一邏輯應用程式資源只能有「一個」工作流程。 跨 Microsoft Entra 租用戶的所有邏輯應用程式會共用相同的處理 (計算)、儲存體、網路等等。 為了備援目的，資料會在配對區域中複寫。 針對高可用性，已啟用異地備援儲存體 (GRS)。 |
消費方案 (依執行次數付費) | Azure Logic Apps 會管理這些限制的預設值，但您可以變更這其中一些值 (如果針對特定限制存在該選項)。 |
| 標準 (工作流程服務方案) 主機環境： 單一租用戶 Azure Logic Apps 注意：如果您的情節需要容器，請使用已啟用 Azure Arc 的 Logic Apps 建立以單一租用戶為基礎的邏輯應用程式。 如需詳細資訊，請檢閱什麼是已啟用 Azure Arc 的 Logic Apps？ |
- 裝載在單一租用戶執行階段上的更多內建連接器，以達到更高的輸送量，並大規模降低成本 - 在執行階段和效能設定方面，提供更多控制和微調功能 - 虛擬網路和私人端點的整合式支援。 - 建立您自己的內建連接器。 |
單一邏輯應用程式資源可以有多個「具狀態」和「無狀態」工作流程。 「位於單一邏輯應用程式和租用戶中」的工作流程會共用相同的處理 (計算)、儲存體、網路等。 資料會保留在您部署邏輯應用程式的相同區域中。 |
標準方案，以主控方案搭配選取的定價層為基礎。 如果您執行的「具狀態」工作流程使用外部儲存體，Azure Logic Apps 執行階段就會根據 Azure 儲存體定價進行儲存體交易。 |
您可以根據案例需要，變更許多限制的預設值。 重要：某些限制有固定上限。 在 Visual Studio Code 中，對邏輯應用程式專案設定檔中的預設限制值所做的變更將不會出現在設計工具體驗中。 如需詳細資訊，請參閱在單一租用戶 Azure Logic Apps 中編輯邏輯應用程式的應用程式和環境設定。 |
| 標準 (App Service 環境 v3) 主機環境： App Service 環境 v3 (ASEv3) - 僅限 Windows 方案 |
與單一租用戶的功能相同，再「加上」下列優點： - 完全隔離邏輯應用程式。 - 建立和執行比單一租用戶 Azure Logic Apps 更多的邏輯應用程式。 - 不論您建立和執行的邏輯應用程式數目有多少，都只需支付 ASE App Service 方案的費用。 - 可以自動或手動調整為更多虛擬機器執行個體或不同的 App Service 方案。 - 從選取的 ASEv3 繼承網路設定。 例如，當您部署至內部 ASE 時，工作流程可以存取與 ASE 相關聯並具有內部存取點之虛擬網路中的資源。 注意：如果從內部 ASE 外面存取，則該 ASE 中的工作流程執行歷程記錄，就無法存取動作輸入和輸出。 |
單一邏輯應用程式可以有多個「具狀態」和「無狀態」工作流程。 「位於單一邏輯應用程式和租用戶中」的工作流程會共用相同的處理 (計算)、儲存體、網路等。 資料會保留在您部署邏輯應用程式的相同區域中。 |
App Service 計劃 | 您可以根據案例需要，變更許多限制的預設值。 重要：某些限制有固定上限。 在 Visual Studio Code 中，對邏輯應用程式專案設定檔中的預設限制值所做的變更將不會出現在設計工具體驗中。 如需詳細資訊，請參閱在單一租用戶 Azure Logic Apps 中編輯邏輯應用程式的應用程式和環境設定。 |
標準邏輯應用程式和工作流程
標準邏輯應用程式和工作流程由重新設計的單一租用戶 Azure Logic Apps 執行階段所提供。 此執行階段會使用 Azure Functions 擴充性模型，並在 Azure Functions 執行階段裝載為延伸模組。 此設計為您的邏輯應用程式工作流程提供可攜性、彈性和更高效能，還繼承 Azure Functions 平台和 Azure App Service 生態系統的其他功能和優點。 例如，您可以在 Azure App Service 環境 v3 (僅限 Windows 方案) 中，建立、部署及執行以單一租用戶為基礎的邏輯應用程式及其工作流程。
標準邏輯應用程式引進的資源結構可裝載多個工作流程，類似於 Azure 函式應用程式裝載多個函式的方式。 使用一對多的對應時，相同邏輯應用程式和租用戶中的工作流程會共用計算和處理資源，由於其鄰近性而提供更好的效能。 此結構不同於使用量邏輯應用程式資源，其中邏輯應用程式資源和工作流程之間為一對一的對應。
若要深入了解可攜性、彈性和效能改善，請繼續檢閱下列各節。 如需單一租用戶 Azure Logic Apps 執行階段和 Azure Functions 擴充性的詳細資訊，請檢閱下列文件：
可攜性和彈性
當您建立標準邏輯應用程式和工作流程時，您可以在其他環境中部署和執行工作流程，例如 Azure App Service 環境 v3 (僅限 Windows 方案)。 如果使用 Visual Studio Code 搭配 Azure Logic Apps (標準) 延伸模組，則可在開發環境中本機開發、建置及執行工作流程，而不需部署至 Azure。 如果您的案例需要容器，您可以使用已啟用 Azure Arc 的 Logic Apps 建立單一租用戶邏輯應用程式。 如需詳細資訊，請參閱什麼是已啟用 Azure Arc 的 Logic Apps？
相較於多租用戶模型，這些功能提供重大改善和顯著優點，其要求您根據 Azure 中目前正在執行的資源進行開發。 此外，將使用量邏輯應用程式資源部署自動化的多租用戶模型，是以 Azure Resource Manager 範本 (ARM 範本) 為基礎，可合併並處理應用程式與基礎結構的資源佈建。
標準邏輯應用程式資源讓您將應用程式部署和基礎結構部署分開，使得部署變得更輕鬆。 您可以將單一租用戶 Azure Logic Apps 執行階段和工作流程一起封裝在邏輯應用程式資源或專案中。 您可以使用一般步驟或工作，建置及組合邏輯應用程式資源，並壓縮為可立即部署的成品。 若要部署基礎結構，您仍然可以使用 ARM 範本，個別佈建那些資源以及適用於那些用途的其他程序和管線。
若要部署應用程式，將成品複製到主機環境，然後啟動應用程式來執行工作流程。 或者，利用您已知道並使用的工具和程序，將成品整合到部署管線中。 如此一來，不論您使用何種技術堆疊來開發，都可以使用自己選擇的工具來部署。
使用標準建置和部署選項，可讓您專注於應用程式開發，基礎結構部署則另外處理。 因此，您會獲得一個更通用的專案模型，讓您可在其中套用許多針對一般應用程式使用的類似或相同部署選項。 當您為應用程式組建部署管線，以及在發佈至生產環境之前執行必要的測試和驗證時，一致的體驗也會對您更有幫助。
效能
使用標準邏輯應用程式，您可以在相同的單一邏輯應用程式資源與租用戶中建立和執行多個工作流程。 透過此一對多的對應，這些工作流程會共用計算、處理、儲存體和網路等資源，並基於此鄰近性而提供更好的效能。
標準邏輯應用程式資源和單一租用戶 Azure Logic Apps 執行階段提供另一項顯著改善，就是將較常用的受控連接器變成內建連接器作業。 例如，內建連接器作業可用於 Azure 服務匯流排、Azure 事件中樞、SQL Server 等。 同時，受控連接器版本仍可使用且持續運作。
使用新的內建連接器作業時需要建立連線，稱為內建連線或服務提供者連線。 其對應的受控連線稱為「API 連線」，需個別當成 Azure 資源來建立和執行，之後還必須使用 ARM 範本來部署。 內建作業及其連線會在執行您工作流程的相同程序中本機執行。 這兩者都裝載於單一租用戶 Azure Logic Apps 執行階段。 因此，由於鄰近您的工作流程，而使得內建作業及其連線能夠提供更佳的效能。 因為服務提供者連線會封裝為相同的組建成品，所以，此設計也適用於部署管線。
資料落地
標準邏輯應用程式資源會裝載於單一租用戶 Azure Logic Apps 上，其不會在您部署這些邏輯應用程式資源的區域之外儲存、處理或複寫資料，這表示工作流程中的資料會保留在您建立和部署其父資源的相同區域中。
直接存取 Azure 虛擬網路中的資源
在單一租用戶 Azure Logic Apps 中執行的工作流程可以直接存取受保護的資源，例如虛擬機器 (VM)、其他服務和存在於 Azure 虛擬網路中的系統。
單一租用戶 Azure Logic Apps 是 Azure Logic Apps 服務的專用執行個體，會使用專用資源，並且會從多租用戶 Azure Logic Apps 個別執行。 在您的專用執行個體中執行工作流程，有助於減少其他 Azure 租用戶對您應用程式效能可能造成的影響，也就是 "noisy neighbors" effect (相鄰干擾效應)。
單一租用戶 Azure Logic Apps 也提供下列優點：
您自己的靜態 IP 位址，這與 Azure Logic Apps 在多租用戶服務中所共用的靜態 IP 位址不同。 您也可以設定公用、靜態且可預測的單一輸出 IP 位址，以便與目的地系統進行通訊。 如此一來，您就不必在目的地系統上設定額外的開放式防火牆。
增加執行期間、儲存體保留期、輸送量、HTTP 要求和回應逾時、訊息大小及自訂連接器要求的限制。 如需詳細資訊，請檢閱 Azure Logic Apps 的限制和設定。
建立、建置及部署選項
若要根據您所需的環境建立邏輯應用程式資源，您有多個選項，例如：
單一租用戶環境
| 選項 | 資源與工具 | 其他相關資訊 |
|---|---|---|
| Azure 入口網站 | 標準邏輯應用程式 | 在單一租用戶 Azure Logic Apps 中建立範例標準邏輯應用程式工作流程 - Azure 入口網站 |
| Visual Studio Code | Azure Logic Apps (標準) 延伸模組 | 在單一租用戶 Azure Logic Apps 中建立範例標準邏輯應用程式工作流程 - Visual Studio Code |
| Azure CLI | Logic Apps Azure CLI 延伸模組 | az logicapp |
| Azure Resource Manager | - 本機 - DevOps |
單一租用戶 Azure Logic Apps |
| 支援 Azure Arc 的 Logic Apps | 已啟用 Azure Arc 的 Logic Apps 範例 | - 什麼是已啟用 Azure Arc 的 Logic Apps？ - 使用已啟用 Azure Arc 的 Logic Apps 建立及部署以單一租用戶為基礎的邏輯應用程式工作流程 |
| Azure REST API | Azure App Service REST API* 注意：標準邏輯應用程式 REST API 隨附於 Azure App Service REST API。 |
開始使用 Azure REST API 參考 |
多租用戶環境
| 選項 | 資源與工具 | 其他相關資訊 |
|---|---|---|
| Azure 入口網站 | 使用量邏輯應用程式 | 快速入門：在多租用戶 Azure Logic Apps 中建立範例使用量邏輯應用程式工作流程 - Azure 入口網站 |
| Visual Studio Code | Azure Logic Apps (使用量) 延伸模組 | 快速入門：在多租用戶 Azure Logic Apps 中建立範例使用量邏輯應用程式工作流程 - Visual Studio Code |
| Azure CLI | Apps Azure CLI 延伸模組 | - 快速入門：在多租用戶 Azure Logic Apps 中建立和管理使用量邏輯應用程式工作流程 - Azure CLI - az logic |
| Azure Resource Manager | 建立邏輯應用程式 ARM 範本 | 快速入門：在多租用戶 Azure Logic Apps 中建立和部署使用量邏輯應用程式工作流程 - ARM 範本 |
| Azure PowerShell | Az.LogicApp 模組 | 開始使用 Azure PowerShell |
| Azure REST API | Azure Logic Apps REST API | 開始使用 Azure REST API 參考 |
雖然開發體驗會隨著您建立使用量或標準邏輯應用程式資源而有所不同，但您可以在 Azure 訂用帳戶下方找到並存取所有已部署的邏輯應用程式。
例如，在 Azure 入口網站中，[邏輯應用程式] 頁面會顯示 [使用量] 和 [標準] 邏輯應用程式資源。 在 Visual Studio Code 中，已部署的邏輯應用程式會出現在您的 Azure 訂用帳戶底下，但使用量邏輯應用程式會出現在 [Azure] 視窗的 [Azure Logic Apps (使用量)] 延伸模組底下，而標準邏輯應用程式會出現在 [資源] 區段底下。
具狀態和無狀態工作流程
在標準邏輯應用程式中，您可以建立下列工作流程類型：
「具狀態」
當您需要保留、檢閱或參考先前事件的資料時，請建立具狀態工作流程。 這些工作流程會將所有作業的輸入、輸出和狀態儲存至外部儲存體。 這項資訊可讓您在每次執行完成後，檢閱工作流程執行詳細資料和歷程記錄。 具狀態工作流程會在發生中斷時提供強大的復原能力。 還原服務和系統之後，您可以從儲存的狀態重新建構中斷的執行，並重新執行工作流程直到完成。 具狀態工作流程持續執行的時間遠長於無狀態工作流程。
在多租用戶和單一租用戶 Azure Logic Apps 中，具狀態工作流程都預設為非同步執行。 所有 HTTP 型的動作預設會遵循標準非同步作業模式。 在 HTTP 動作呼叫或將要求傳送至端點、服務、系統或 API 之後，要求接收者會立即傳回 "202 ACCEPTED" 回應。 此代碼確認接收者已接受要求，但尚未完成處理。 回應可能包括
location標頭來指定 URI，還包括重新整理識別碼，可供呼叫者輪詢或檢查非同步要求的狀態，直到接收者停止處理並傳回「200 確定」(英文) 成功回應或其他非 202 回應為止。 不過，呼叫者不需要等候要求完成處理，即可繼續執行下一個動作。 如需詳細資訊，請參閱非同步微服務整合強制微服務自主性。「無狀態」
如果每次執行完成後，不需要在外部儲存體中保留、檢閱或參考先前事件的資料以供稍後檢閱，請建立無狀態工作流程。 這些工作流程「只會在記憶體中」儲存每個動作的所有輸入和輸出及其狀態，而不會儲存於外部儲存體。 因此，由於外部儲存體不會儲存執行工作流程詳細資料和歷程記錄，所以無狀態工作流程的執行時間較短 (通常在 5 分鐘內結束)、效能較高 (回應時間較快)、輸送量較高且執行成本較低。 不過，如果發生中斷，則不會自動還原中斷的執行，呼叫者必須手動重新提交中斷的執行。
在處理大小「總計」不超過 64 KB 的資料或內容 (例如檔案) 時，無狀態工作流程可提供最佳效能。 較大的內容大小 (例如多個大型附件) 可能會讓工作流程的效能明顯變慢，甚至因為記憶體不足的例外狀況而導致工作流程損毀。 如果您的工作流程可能必須處理較大的內容大小，請改為使用具狀態工作流程。
注意
在無狀態工作流程中，您只能使用推送觸發程序，其中您未指定工作流程執行的排程。 這些以 Webhook 為基礎的觸發程序會等候事件發生或資料變成可用。 例如，定期觸發程序僅適用於具狀態工作流程。 若要啟動工作流程，請選取推送觸發程序，例如要求、事件中樞或服務匯流排觸發程序。 如需受限、無法使用或不支援的觸發程序、動作及連接器詳細資訊，請參閱已變更、受限、無法使用或不支援的功能。
無狀態工作流程只會同步執行，因此，其不像具狀態工作流程一樣使用標準非同步作業模式。 相反地，所有以 HTTP 為基礎並傳回 "202 ACCEPTED" 回應的動作，會繼續工作流程執行的下一個步驟。 如果回應包括
location標頭，無狀態工作流程將不會輪詢指定的 URI 來檢查狀態。 若要遵循標準非同步作業模式，請改為使用具狀態工作流程。為了更輕鬆偵錯，您可以針對無狀態工作流程啟用執行歷程記錄，這對效能產生些微影響，然後在您完成時停用執行歷程記錄。 如需詳細資訊，請參閱在 Visual Studio Code 中建立單一租用戶型的工作流程，或在 Azure 入口網站中建立單一租用戶型的工作流程。
重要
您必須決定工作流程類型，也就是具狀態或無狀態，才能在建立時實作。 建立之後對工作流程類型的變更會導致執行階段錯誤。
具狀態和無狀態工作流程之間的差異摘要
| 可設定狀態 | 無狀態 |
|---|---|
| 儲存執行歷程記錄、輸入和輸出 | 預設不會儲存執行歷程記錄、輸入或輸出 |
| 可使用且允許受控連接器觸發程序 | 無法使用或不允許受控連接器觸發程序 |
| 支援區塊化 | 不支援區塊化 |
| 支援非同步作業 | 不支援非同步作業 |
| 在主機設定中編輯預設的執行持續時間上限 | 最適合持續時間上限小於 5 分鐘的工作流程 |
| 處理大型訊息 | 最適合處理小型訊息 (小於 64KB) |
具狀態和無狀態工作流程之間的巢狀行為差異
您可以使用要求觸發程序、HTTP Webhook 觸發程序，或具有 ApiConnectionWebhook 類型且可接收 HTTPS 要求的受控連接器觸發程序，將工作流程變成可呼叫，供存在於相同標準邏輯應用程式中的其他工作流程呼叫。
下列清單說明父工作流程呼叫子工作流程之後，巢狀工作流程可以遵循的行為模式：
非同步輪詢模式
父工作流程不會等候子工作流程回應其初始呼叫。 不過，父代會持續檢查子系的執行歷程記錄，直到子系完成執行為止。 具狀態工作流程預設會遵循此模式，這對於可能超過要求逾時限制的長時間執行子工作流程來說很理想。
同步模式 (「射後不理」)
子系工作流程會立即傳回
202 ACCEPTED回應，以認可父工作流程的呼叫。 不過，父代不會等待子系傳回結果。 相反地，父代會繼續執行工作流程中的下一個動作，並在子系完成執行時接收結果。 不包含回應動作的子系具狀態工作流程一律會遵循同步模式，並提供可供您檢閱的執行歷程記錄。若要啟用此行為，請在工作流程的 JSON 定義中，將
operationOptions屬性設定為DisableAsyncPattern。 如需詳細資訊，請參閱觸發程序和動作類型 - 作業選項。觸發並等候
無狀態工作流程會在記憶體中執行。 因此當父代工作流程呼叫子系無狀態工作流程時，父代會等候子系傳回結果的回應。 此模式的運作方式類似於使用內建 HTTP 觸發程序或動作來呼叫子系工作流程。 不含回應動作的無狀態子工作流程會立即傳回
202 ACCEPTED回應，但父代會等候子系完成，才繼續下一個動作。 這些行為僅適用於無狀態子工作流程。
下表根據父代和子系是具狀態、無狀態或混合的工作流程類型，識別子工作流程的行為： 資料表之後的清單
| 父工作流程 | 子工作流程 | 子系行為 |
|---|---|---|
| 可設定狀態 | 可設定狀態 | 非同步或同步取決於 "operationOptions": "DisableAsyncPattern" 設定 |
| 可設定狀態 | 無狀態 | 觸發並等候 |
| 無狀態 | 可設定狀態 | 同步 |
| 無狀態 | 無狀態 | 觸發並等候 |
單一租用戶模型的其他功能
單一租用戶模型和標準邏輯應用程式類型包括許多現有和新的功能，例如：
針對軟體即服務 （SaaS） 和平臺即服務 （PaaS） 應用程式和服務，以及內部部署系統的連接器，從 1,400 個以上的受控連接器 建立邏輯應用程式和其工作流程。
現在有更多的受控連接器可在標準工作流程中，以內建連接器的形式供使用。 內建版本會以原生方式在單一租用戶 Azure Logic Apps 執行階段中執行。 某些內建連接器也稱為「服務提供者」連接器。 如需清單，請檢閱使用量與標準中的內建連接器。
您可以使用單一租用戶 Azure Logic Apps 擴充性架構，針對您需要的任何服務，建立自己的自訂內建連接器。 類似於內建連接器，例如 Azure 服務匯流排和 SQL Server，自訂連接器提供較高的輸送量、低延遲和本機連線能力，並可在與單一租用戶執行階段相同的程序中執行。 不過，自訂內建連接器與自訂受控連接器 (目前不支援) 並不類似。 如需詳細資訊，請檢閱自訂連接器概觀和在單一租用戶 Azure Logic Apps 中建立適用於標準邏輯應用程式的自訂內建連接器。
您不需要整合帳戶，就可以對 Liquid 作業和 XML 作業使用下列動作。 這些作業包括下列動作：
XML： 轉換 XML、 XML 驗證、 使用架構撰寫的 XML，以及 使用架構剖析 XML
Liquid：將 JSON 轉換為 JSON、將 JSON 轉換為文字、將 XML 轉換為 JSON 和將 XML 轉換為文字
注意
若要在標準工作流程中使用這些動作，您需要有 Liquid 對應、XML 對應或 XML 結構描述。 在 Azure 入口網站中，您可以從邏輯應用程式的資源功能表，在 [成品] 下方 (包括 [結構描述] 和 [對應] 區段) 上傳這些成品。 或者，您可以使用個別的 [對應] 和 [結構描述] 資料夾，將這些成品新增至 Visual Studio Code 專案的 [成品] 資料夾。 然後，您可以在相同邏輯應用程式內跨多個工作流程使用這些成品。
標準邏輯應用程式工作流程可以從任何地方觸發，因為 Azure Logic Apps 會產生共用存取簽章（SAS）連接字串 這些邏輯應用程式可用來將要求傳送至雲端連線運行時間端點。 Azure Logic Apps 會將這些連接字串與其他應用程式設定一起儲存，讓您在 Azure 中部署時，輕鬆將這些值儲存在 Azure Key Vault。
標準邏輯應用程式工作流程支援同時啟用系統指派的受控識別和多個使用者指派的受控識別，不過您一次只能選取一個要使用的身分識別。 雖然內建的服務提供者型連接器支援使用系統指派的身分識別，但除了 SQL Server 和 HTTP 連接器之外，大部分目前都不支援選取使用者指派的受控識別進行驗證。
注意
預設已啟用系統指派的身分識別在執行階段驗證連線。 此身分識別與您建立連線時所使用的驗證認證或連接字串不同。 如果停用此身分識別，則連線在執行階段沒有作用。 若要檢視此設定，請在邏輯應用程式的功能表上，於 [設定] 下方選取 [身分識別]。
您可以在 Visual Studio Code 開發環境中，於本機執行、測試和偵錯邏輯應用程式及其工作流程。
在執行和測試邏輯應用程式之前，您可以在工作流程的 workflow.json 檔案內新增和使用中斷點，更輕鬆地進行偵錯。 不過，目前只有動作支援中斷點，觸發程序不支援中斷點。 如需詳細資訊，請參閱在 Visual Studio Code 中建立單一租用戶型的工作流程。
將邏輯應用程式及其工作流程從 Visual Studio Code 直接發佈或部署至各種主控環境，例如 Azure 和已啟用 Azure Arc 的 Logic Apps。
如果您的 Azure 訂用帳戶和邏輯應用程式設定支援 Application Insights，使用此功能對邏輯應用程式啟用診斷記錄和追蹤功能。
存取網路功能 (例如，與 Azure 虛擬網路私下連線和整合) 類似於使用 Azure Functions 進階方案來建立和部署邏輯應用程式時的 Azure Functions。 如需詳細資訊，請參閱下列文件：
針對標準邏輯應用程式中個別工作流程使用的受控連線，重新產生存取金鑰。 針對此工作，請遵循使用量邏輯應用程式的相同步驟，但是在工作流程層級，而不是邏輯應用程式資源層級。
適用於標準版的內建連接器
標準工作流程可以使用許多與使用量工作流程相同的內建連接器，但並非全部。 反之亦然，標準工作流程有許多內建連接器無法在使用量工作流程中使用。
例如，標準工作流程同時具有 Azure Blob、Azure Cosmos DB、Azure 事件中樞、Azure 服務匯流排、DB2、FTP、MQ、SFTP 和 SQL Server 等的受控連接器和內建連接器。 雖然使用量工作流程不具有這些相同的內建連接器版本，但提供其他如 Azure API 管理和 Azure App Service 等內建連接器。
在單一租用戶 Azure Logic Apps 中，具有特定屬性的內建連接器會稱為「服務提供者」(非正式名稱)。 某些內建連接器僅支援透過單一方法驗證與基礎服務的連線。 其他內建連接器可供選擇，例如使用連接字串、Microsoft Entra ID 或受控識別。 所有內建連接器皆在與重新設計的 Azure Logic Apps 執行階段的同一個處理程序中執行。 如需詳細資訊，請檢閱標準邏輯應用程式工作流程的內建連接器清單。
重要
請務必正確地設定及測試任何服務提供者型觸發程序，以確認作業成功。 失敗的服務提供者型觸發程序可能會建立不必要的調整，這可能會大幅增加您的計費成本。 例如，常見的錯誤是設定觸發程序，而不授與邏輯應用程式權限或目的地的存取權，例如服務匯流排佇列、Azure 儲存體 Blob 容器等等。 此外，請確保您隨時監視這類觸發程序，以便立即偵測並修正任何問題。
已變更、受限、無法使用或不支援的功能
針對標準邏輯應用程式工作流程，下列功能不同，目前有限、無法使用或不受支援：
觸發程序和動作：內建觸發程序和動作會以原生方式在 Azure Logic Apps 中執行，而受控連接器會於 Azure 使用共用資源裝載並執行。 針對標準工作流程，目前無法使用某些內建觸發程式和動作，例如滑動視窗和 Azure App 服務 作業。 若要啟動具狀態或無狀態工作流程，請使用內建觸發程序，例如要求、事件中樞或服務匯流排觸發程序。 定期觸發程序適用於具狀態工作流程，但不適用於無狀態工作流程。 在設計工具中，內建的觸發程式和動作會隨應用程式內標籤顯示，而受控連接器觸發程式和動作則以共用標籤顯示。
無狀態工作流程只能使用推送觸發程序，其中您未指定工作流程執行的排程。 這些以 Webhook 為基礎的觸發程序會等候事件發生或資料變成可用。 例如，定期觸發程序僅適用於具狀態工作流程。 若要啟動工作流程，請選取推送觸發程序，例如要求、事件中樞或服務匯流排觸發程序。 雖然您可以針對無狀態工作流程啟用受控連接器，但連接器資源庫不會顯示任何可供您新增的受控連接器輪詢觸發程序。
注意
若要在 Visual Studio Code 中於本機執行，Webhook 型觸發程序和動作需要額外的設定。 如需詳細資訊，請參閱在 Visual Studio Code 中建立單一租用戶型的工作流程。
以下觸發程序和動作已變更，或者目前受限、不支援或無法使用：
內建動作 [Azure Functions - 選擇 Azure 函式] 現在是 [Azure Functions 作業 - 呼叫 Azure 函式]。 此動作目前僅適用於從 HTTP 觸發程序範本建立的函式。
在 Azure 入口網站中，您可以選取 HTTP 觸發程序函式，然後透過使用者體驗建立連線來存取。 如果您使用 Visual Studio Code 在程式碼檢視或 workflow.json 檔案中檢查函式動作的 JSON 定義，該動作會使用
connectionName參考來參考函式。 此版本將函式的資訊抽象化為連線，您可以在邏輯應用程式專案的 connections.json 檔案中找到此連線，而此檔案則會在您 Visual Studio Code 中建立連線之後提供。注意
在單一租用戶模型中，函式動作僅支援查詢字串驗證。 Azure Logic Apps 會在建立連線時從函式取得預設金鑰、將該金鑰儲存在應用程式的設定中，然後在呼叫函式時使用該金鑰進行驗證。
例如，如同在多租用戶模型中，如果您在入口網站中透過 Azure Functions 體驗更新此金鑰，函式動作就會因為金鑰失效而不再運作。 為了修正此問題，必須對您要呼叫的函式重新建立連線，或使用新金鑰來更新應用程式設定。
內建動作 Azure Logic Apps - 選擇邏輯應用程式工作流程現在是工作流程作業 - 在此工作流程應用程式中叫用工作流程。
目前不支援自訂受控連接器。 不過，使用 Visual Studio Code 時，您可以建立「自訂內建作業」。 如需詳細資訊，請檢閱使用 Visual Studio Code 建立單一租用戶型的工作流程。
標準工作流程只能有一個觸發程式，而且不支援多個觸發程式。
驗證
某些處理輸入呼叫的要求型觸發程式，例如要求觸發程式，目前不支援Microsoft Entra ID Open Authentication （Microsoft Entra ID OAuth），而其他像是 HTTP Webhook 觸發程式的觸發程式則支援這項支援。
某些 內建服務提供者型連接器 目前不支持選取使用者指派的受控識別進行驗證。 不過，系統指派和使用者指派的受控識別支援一般都可供使用。 預設會自動啟用系統指派的受控識別。
Visual Studio Code 中的中斷點偵錯：雖然您可以在工作流程的 workflow.json 檔案內新增和使用中斷點，但目前只有動作支援中斷點，觸發程序不支援中斷點。 如需詳細資訊，請參閱在 Visual Studio Code 中建立單一租用戶型的工作流程。
觸發程式歷程記錄和執行歷程記錄：針對標準邏輯應用程式工作流程，Azure 入口網站 中的觸發歷程記錄和執行歷程記錄會出現在工作流程層級，而不是邏輯應用程式資源層級。 如需詳細資訊，請檢閱使用 Azure 入口網站建立單一租用戶型的工作流程。
Terraform 範本：您無法將這些範本與標準邏輯應用程式資源搭配使用來完成基礎結構部署。 如需詳細資訊，請參閱什麼是 Azure 上的 Terraform？
嚴格的網路和防火牆流量權限
如果您的環境具有嚴格的網路需求或防火牆有限制流量，您必須允許存取工作流程中的任何觸發程序或動作連線。 您可以選擇允許來自服務標籤的流量，並使用與 Azure App Service 相同的限制或原則層級。 您也需要找出並使用連線的完整網域名稱 (FQDN)。 如需詳細資訊，請參閱下列文件中對應的章節：
下一步
我們也想知道您使用單一租用戶 Azure Logic Apps 的體驗！
- 關於錯誤 (Bug) 或問題，請在 GitHub 中提出問題 (英文)。
- 如有疑問、要求、留言和其他意見反應，請使用此意見反應表單。