管理佇列

交易式佇列是僅包含交易式訊息 (以及在交易內傳送的訊息) 的佇列。傳送和接收訊息的需求會根據所使用之佇列的類型 (交易式或非交易式) 及佇列位置 (本機或遠端) 而定。

子佇列允許應用程式將訊息分組。子佇列在下列狀況中會很有幫助：

• 處理工作順序。 如果應用程式處理包含來自不同工作順序之項目的訊息，則可以使用子佇列來將這些線性項目依工作順序分組，以便提升處理的效率。
  
  
• 處理受污染的訊息。 如果應用程式接收到在當時無法處理的訊息，則可以將該訊息移到錯誤的子訊息中，並於稍後再進行處理。
  
  

開啟子佇列時，會以隱含的方式加以建立。換句話說，將訊息移到子佇列時，如果沒有子佇列存在的話，這個動作基本上就會建立子佇列。子佇列內容為空時，便會遭到刪除，並且沒有任何開啟控制碼。應用程式無法直接將訊息傳送到子佇列。它們只能將訊息移到子佇列。他們可以接收來自子佇列的訊息、在主要佇列及其子佇列之間移動訊息，或是在同一個主要佇列的子佇列之間移動訊息。不過，它們無法將訊息從主要佇列的子佇列移到不同主要佇列的子佇列。

例如，在下圖中，可在子佇列1 (或子佇列2) 和佇列A 的佇列訊息資料夾之間來回移動訊息。也可以在子佇列1 或子佇列2 之間移動訊息。同樣地，也可以在佇列Z 及其子佇列、子佇列3 和子佇列4 之間來回移動訊息。

但是，不可以在佇列A 和佇列3 或子佇列4 之間，或是在佇列Z 和佇列1 或子佇列2 之間移動訊息。同樣地，也不可以在佇列A 的子佇列 (子佇列1 或子佇列2) 及佇列Z 的子佇列 (子佇列3 或子佇列4) 之間來回移動訊息。

子佇列沒有自己的內容或狀態。他們會共用主要佇列的內容。例如，子佇列沒有自己的：

• 配額
  
  
• 存取控制清單 (ACL)
  
  
• 交易類型
  
  

子佇列會共用主要佇列的配額，並且子佇列中的訊息會納入該配額中。

無法在日誌或其他系統佇列或其他子佇列下建立子佇列。

系統管理佇列是由應用程式產生的佇列。這些佇列可以用來儲存系統產生的正認可訊息，以及由訊息佇列或連接器應用程式所建立的負認可訊息。傳送應用程式會以程式設計的方式在原始訊息中指定那些系統管理佇列。任何可用的非交易式佇列都可以指定為系統管理佇列。系統管理佇列不包含儲存於內部私用佇列中的系統管理訊息。

傳回這些佇列的系統產生認可訊息會指出訊息是否到達其目的地佇列，及/或是否已從該目的地佇列擷取訊息。每個認可訊息都包含描述觸發認可者以及認可所代表之訊息的資訊。要求認可訊息時，傳送應用程式必須指定要做為系統管理佇列的佇列，以及訊息的認可等級。一般而言，系統管理佇列是本機佇列，因此傳送應用程式就可以在本機上讀取認可訊息。

與系統管理佇列一樣，回應佇列也是由應用程式產生的。其作用是儲存應用程式產生的回應訊息，這些訊息通常是由讀取佇列中之訊息的應用程式所傳回的。當傳送訊息時，傳送應用程式會以程式設計方式指定回應佇列。任何可用的佇列都可以指定為回應佇列。回應訊息與儲存於內部私用佇列中的系統管理回應訊息不同。

傳回這些回應訊息的應用程式和讀取回應訊息的應用程式，都必須能夠了解傳回這些佇列的回應訊息。訊息佇列無法控制回應訊息中所傳送的資訊。要求回應訊息時，傳送應用程式必須指定要做為回應佇列的佇列。一般而言，回應佇列是本機佇列，因此傳送應用程式就可以在本機上讀取回應訊息。

同時需要回應佇列和系統管理佇列時，可將兩者的功能合併到單一佇列。但是，因為所有系統管理佇列都必須是非交易式佇列，所以這個佇列只能接受非交易式訊息。

報告佇列是由應用程式產生的佇列，作用是儲存訊息佇列或連接器應用程式在傳送應用程式要求追蹤時所產生的報告訊息。報告訊息會指出訊息傳到遠端電腦上之目的地所走的路線，或是測試訊息傳到遠端電腦上之測試佇列所走的路線。每台電腦只能有一個報告佇列。

所有報告佇列都必須有下列標籤和佇列類型識別碼：

• 標籤：MQReport 佇列
  
  
• 佇列類型識別碼：
  
  

  {55EE8F32-CCE9-11CF-B108-0020AFD61CE9}

訊息佇列系統管理員通常會使用 [Active Directory 使用者和電腦] 建立報告佇列。但是，如果在建立佇列時指定了正確的標籤和佇列類型識別碼，應用程式也可以產生報告佇列。訊息佇列在傳送報告訊息時，會使用標籤和佇列類型識別碼來尋找和開啟適當的佇列。