如何處理 Service Broker原則

原則會根據原則定義進行處理。特別是當您有多個原則可套用到單一部署時，範圍和強制執行層級決定了哪些原則有效。

本文提供有關原則處理的一般資訊，但同時包括有關不同原則類型的更多詳細資料。

根據組織層級和強制執行類型對原則進行排名的方式

當屬於專案成員的使用者建立藍圖時，可能有多個原則會套用至該部署。

	若要評估原則，系統會先確定原則並對其進行排序。 在組織層級或專案層級是否有任何硬性原則。如果同時有硬性原則和軟性原則，則只會考慮硬性原則，並對其進行排序。如果只有軟性原則，則會對軟性原則進行排序。 所有硬性原則或軟性原則均按範圍排序，且組織原則比專案原則的排名高。 最終區分特性，即為建立日期，且較早日期比較晚日期的排名高。

根據組織層級和強制執行類型處理原則的方式

系統會對原則進行評估和排列順序，然後合併適用的原則，以產生有效原則。有效原則會產生預期結果，但不一定是特定的具名原則。

此區段包括下列範例：

• 租用原則
• 第 2 天動作原則

檢閱下列租用原則範例。

	確定要考慮的原則，並對其進行排名後，會評估這些原則以決定合併順序。 排名最高的原則將成為基準。接著套用第二層級的原則，依此類推。 如果某個原則與先前的原則不相容，則該原則不考慮在內。例如，值高於之前的原則。 將忽略任何捨棄的原則。若要查看套用的原則，請選取內容和原則 > 原則 > 強制執行，找到部署，然後檢閱決定附註。
	系統會合併原則並且可能包含來自多個個別原則的值，而非套用一個原則並排除其上所有其他原則。 在此範例中，合併程序排除原則 2，因為值高於原則 1。 然後，根據原則 1 評估原則 3。原則 3 中的「租用」和「租用總計」值低於原則 1，因此這兩個值和「寬限期」一起成為有效原則的一部分。

檢閱以下第 2 天動作原則範例。

	確定要考慮的原則，並對其進行排名後，會評估這些原則以決定合併順序。 排名最高的原則將成為基準。接著套用第二層級的原則，依此類推。 如果某個原則由前面的原則強制執行 (例如，原則 3)，則會根據考量事項將其捨棄。 將忽略任何捨棄的原則。若要查看套用的原則，請選取內容和原則 > 原則 > 強制執行，找到部署，然後檢閱決定附註。

租用原則管理目標考量事項

您已瞭解如何處理租用原則，現在可以確定原則管理目標。透過瞭解如何處理原則，您可以實現自己的管理目標，而無需建立過多無法管理的原則。

決定如何實作原則時，請考慮下列案例。

• 租用原則目標和強制執行範例
• 第 2 天原則目標和強制執行範例

表 1. 租用原則目標和強制執行範例

管理目標	組態範例	行為
有意義的組織層級預設原則仍允許專案層級原則值影響套用的值。	組織原則 = 軟 寬限期：10 租用：100 租用總計：100 專案 1 原則 1 = 軟 租用：20 租用總計：50 專案 2 原則 1 = 軟 租用：10 租用總計：30	專案 1 的成員申請目錄項目。 專案 2 不考慮在內，因為其不適用於專案 1 部署。 合併的有效原則為： 寬限期：10 租用：20 租用總計：50
一律預設為組織層級原則。	組織原則 = 硬 寬限期：10 租用：100 租用總計：100 專案 1 原則 1 = 軟 租用：20 租用總計：50	專案 1 的成員申請目錄項目。 專案 1 原則 1 不考慮在內，因為硬性組織層級原則具有較高的排名，並且軟性原則不考慮在內。 有效原則為： 寬限期：10 租用：100 租用總計：100
所有原則均在專案層級定義，並且沒有任何組織層級預設原則。	專案 1 原則 1 = 軟 寬限期：10 租用：100 租用總計：100 專案 1 原則 2 = 軟 租用：20	專案 1 的成員申請目錄項目。 它們都是軟性原則，並且都適用於專案 1。值已合併。 有效原則為： 寬限期：10 租用：20 租用總計：100

在這些範例中，將使用第 2 天動作原則。

表 2. 第 2 天原則目標和強制執行範例

管理目標	組態範例	行為
有意義的組織層級預設原則仍允許專案層級原則值影響套用的值。	組織原則 = 軟 動作：Deployment.* 專案 1 原則 1 = 軟 動作：Cloud.vSphere.Machine.* 專案 2 原則 1 = 軟 動作：Cloud.Azure.Machine.*	專案 1 的成員申請目錄項目。 專案 2 不考慮在內，因為其不適用於專案 1 部署。 合併的有效原則為： 動作：{Deployment.* ,Cloud.vSphere.Machine.*}
一律預設為組織層級原則。	組織原則 = 硬 動作：Deployment.* 專案 1 原則 1 = 軟 動作：Cloud.vSphere.Machine.*	專案 1 的成員申請目錄項目。 專案 1 原則 1 不考慮在內，因為硬性組織層級原則具有較高的排名，並且軟性原則不考慮在內。 有效原則為： 動作：{Deployment.* }
所有原則均在專案層級定義，並且沒有任何組織層級預設原則。	專案 1 原則 1 = 軟 動作：Deployment.ChangeLease 專案 1 原則 2 = 軟 動作：Deployment.Delete	專案 1 的成員申請目錄項目。 它們都是軟性原則，並且都適用於專案 1。值已合併。 有效原則為： 動作：{Deployment.ChangeLease , Deployment.Delete}

核准原則目標和強制執行範例

核准原則評估將遵循此程序。

1. 已提交執行部署或第 2 天動作的請求。
2. 核准服務會查詢適用於請求目錄項目或變更已部署項目之專案的原則。
3. 將傳回所有適用的專案和組織層級範圍原則。
4. 根據部署準則篩選核准原則。部署準則適用於部署和第 2 天動作。
5. 如果找不到相符原則，則無需核准，並且部署程序將會繼續進行。
6. 如果有相符原則，例如 AP1、AP2、APn，則會建立一個核准項目，如下所示：
   • 強制執行的原則 = AP1、AP2、APn。
   • 核准者 = 所有強制執行原則中的所有核准者的聯集。
   • 自動到期 = 拒絕 (如果有任何原則具有拒絕值)；否則，請核准。
   • 到期時間 = 任何強制執行原則的天數下限。

下表提供了多個原則的範例。在資料表下方說明了這些原則的處理方式。

原則	組態範例
AP1	範圍 = 組織 自動到期 = 核准 到期時間 = 7 天
AP2	範圍 = 專案 1 自動到期 - 核准 到期時間 = 3 天
AP3	範圍 = 專案 1 自動到期 = 拒絕 到期時間 = 4 天
AP4	範圍 = 專案 2 自動到期 = 核准 到期時間 = 5 天

根據上述原則和組態範例，下列資訊說明了如何處理專案 1 請求。

1. 範圍評估傳回了 AP1、AP2 和 AP3。AP4 不包含在內，因為它是專案 2 原則。
2. 假設 AP1、AP2 和 AP3 滿足部署和動作準則，則核准項目會包含下列值：
   • 核准者 = AP1、AP2 和 AP3 中的任何或所有核准者都將新增為核准者。
   • 自動到期 = 拒絕。AP3 提供了限制更多的行為。
   • 到期時間 = 3 天。AP2 提供了最低值。