WBM 與 Windchill+
使用 Windchill+ 進行 WBM 移轉
使用 Windchill Bulk Migrator (WBM) 模組進行移轉。本主題說明 Windchill Bulk Migrator (WBM) 各個活動。
先決條件
WBM 移轉情境有一些特殊性，但它是與本說明中心其他部份所開發的概念執行一致的建構。
• WBM 移轉情境是涉及移轉與 QA 環境的進階 Windchill+ 情境。環境架構如下所示：
• WBM 移轉利用專為 Windchill+ 建構的自動化架構。移轉環境中不需要且不會授與後端存取權。
• 每次移轉都具唯一性。本節描述 Windchill+ 中提供以支持大多數 WBM 移轉情境的服務。但是，客戶或合作廠商需要根據複雜度設計與計劃移轉專案，並將其調整為特定需求。例如，排練數、先決條件，以及要在內部部署執行的其他必要任務等。
• 對要移轉之中繼資料進行結構化需要使用資料庫。為了避免多次轉換，假設會使用內部部署暫置資料庫。您必須使用 Oracle 資料庫。根據 Windchill 版本需求，必須使用 Oracle 資料庫。資料庫結構必須符合 Windchill WBM 暫置資料庫需求。
• 建議針對 WBM 暫置資料庫在內部部署建立單獨的資料庫結構描述。
移轉環境
移轉環境是執行將程式碼、組態與資料合併在一起之指定流程的環境。除了提交要移轉的建構封裝以外，也可以使用 Windchill Bulk Migrator (WBM) 提交暫置資料。此資料會載入至移轉暫置資料庫，以進行評估。移動程式碼、組態和資料都是 Windchill+ 核心操作架構的一部份。例如，您從系統 A 產生資料並將其置於某個位置，Windchill+ 隨後會自動將所有項目移轉至系統 B。
移轉後，將建構封裝提交至 QA 環境，然後再提交至生產環境。
WBM 移轉活動
請考慮下列與 WBM 移轉活動相關的資訊：
上線之前階段
系統會使用整合環境來整合所有程式碼變更，並在達到建構的成熟度之後開始移轉載入測試。部署建構的流程與提交並推進您的封裝主題中所述的流程類似。
請執行下列步驟：
2. 完成整合與功能接受度測試 (FAT) 週期。在測試週期結束時，任務即會完成，且環境會恢復為其先前的狀態。
 | 如果未在七天內完成此步驟，則環境會恢復為其先前的狀態。 |
移轉環境步驟
移轉環境用於載入測試。請執行下列步驟：
1. 使用 AzCopy 將暫置資料庫轉儲上載至儲存區。
如需詳細資訊，請造訪下列連結：
2. 開啟服務請求以請求匯入暫置資料庫轉儲。如需詳細資訊，請參閱開啟服務請求。
3. 部署建構。部署建構的流程與提交並推進您的封裝主題中所述的流程類似。本主題適用於將建構部署至移轉環境。
| | 依預設，針對移轉環境，在此步驟期間建立的備份會保留 30 天。 |
5. 開啟服務請求以執行載入。
6. 進行內容移轉時，請從儲存帳戶擷取內容對應檔案，並準備內容複製指令集。之後，開啟附加指令集的服務請求以執行最終內容傳輸。如需詳細資訊，請參閱開啟服務請求。
7. 完成移轉測試週期。在測試週期結束時，透過服務請求所請求的下列其中一個動作 (以偏好順序)，將環境恢復為空白狀態：
◦ 從生產環境重新裝載
◦ 重新提供 (僅用於初始移轉，無法用於後續資料移轉)。
QA 環境步驟
QA 環境用於 UAT。執行下列步驟：
1. 對匯入至暫置資料庫之最新狀態的資料重複相同的流程。
◦ 使用 deploy_pipe : pipeline 提交建構與資訊清單檔案。
| | 依預設，針對 QA 環境，在此步驟期間進行的備份會保留 30 天。 |
2. 開啟服務請求以請求在 QA 環境中執行載入。如需詳細資訊，請參閱開啟服務請求。
3. 進行內容移轉時，請從儲存帳戶擷取內容對應檔案，並準備內容複製指令集。之後，開啟附加指令集的服務請求以執行最終內容傳輸。如需有關建立內容對應檔案的詳細資訊，請參閱 WBM 階段。
4. 完成 UAT 測試週期。您最多有 30 天時間做出下列其中一項決定：
◦ 如果測試週期成功 - 會核准任務，且只會將建構推進至生產環境。
◦ 如果測試週期不成功：
▪ 可以拒絕任務，且環境會恢復為先前的狀態。
▪ 可以核准任務，且會將建構推進至生產環境。可以提交後續建構以修正錯誤。
◦ 如果未在 30 天內完成測試週期，則環境會自動恢復為其先前的狀態。欲保留環境，您必須核准任務。
| | 如果需要完整載入其他 QA，透過使用服務請求所請求的下列其中一個動作 (以偏好順序)，將環境恢復為空白狀態： • 從生產環境重新裝載。 • 重新提供 (僅用於初始移轉，無法用於後續資料移轉)。 |
或者，如果針對上線計劃增量載入，則必須獨立完成載入才能生產。開啟服務請求以在生產環境中請求或重複載入執行。如需詳細資訊，請參閱開啟服務請求。
上線階段
• 在此階段，之前核准的建構已在 QA 與生產環境中。
• 此外，先前的資料載入可能可供在生產環境中使用。
• 如果在上線轉換期間不需要建構提交 (或如果您已預先提交上線所需的建構)，請執行下列步驟：
1. 將最新的暫置資料庫轉儲上載至儲存帳戶。
2. 開啟服務請求以請求匯入最新的暫置資料庫。
3. 開啟服務請求以在生產環境中執行載入。
4. 進行內容移轉時，在指令集建立之後，開啟服務請求以進行最終內容傳輸。
• 如果需要建構提交，請遵循「QA 環境步驟」部份所述的流程進行建構提交與推進。之後，執行生產活動與服務請求，如「QA 環境步驟」部份所述。
• 當您確認上線之後，必須將生產環境重新裝載至 QA 與整合 (如果計劃有後續移轉，還必須重新裝載至移轉)。必須針對重新裝載活動開啟服務請求。
執行階段
• 成功上線之後，由於所有環境都會從生產環境重新裝載，因此，PTC 強烈建議將變更傳播至您的開發環境。
◦ 資料模型是最低要求，且必須作為開發環境的起點使用。
◦ 您可以重新使用最新建構。
• 如果有後續移轉，必須重複「上線之前」部份所述的流程。
| | 為了避免任何現有資料遺失，您應該在專案設計與計劃階段仔細考慮環境重新整理活動。 |
最終考量
• 為了進行大規模移轉並降低上線轉換期間的影響，強烈建議將移轉活動設計為允許增量載入。
• 所有移轉專案都具唯一性。欲確保移轉專案成功，您必須執行諸如強計劃、範圍、風險與相依性管理等活動。這些活動可確保正確移轉設計及順利完成上線轉換。
• 移轉測試往往被低估。針對簡單移轉專案，PTC 建議從三個測試移轉週期開始。隨著複雜度的增加，您可以計劃實行更多週期。