Workiva 支援中心

概觀

此「領先做法」系列概述了適用於 Workiva 平台中的資料管理套件中各種工件的建議一般做法。請記住，這些只是一般指引，可能需要根據特定、獨特的使用個案進行調整。這些建議旨在協助您改善工作區的條理。這就開始探索這些命名慣例。

連線的命名慣例,Chains 和環境

連線中的連線

在建立連線時，必須建立最佳的命名慣例，以確保環境 ：

• Connector 的名稱： 提供連接器的描述性名稱，清楚說明其目的和功能。
• 工作區類型： 指定使用 Connector 的工作區或專案。
• Connector 的環境： 清楚辨識 Connector 對應的環境 (例如：開發、生產)。

範例：

• SFTP 連線 | SEC Reporting | NON-PROD
  • 說明： 為 SEC Reporting 工作區解決方案在非生產環境（如開發、QA、Sandbox 等）中建立與 SFTP 伺服器的連線。
• SFTP 連線 | SEC 報告 | PROD
  • 說明： 建立連線至生產環境中 SEC 報告工作區解決方案的 SFTP 伺服器。

此命名慣例有助於在不同環境中輕鬆識別和管理連線。它可確保特定環境中的 Chain 僅與適當的來源互動，以加強安全性與可靠性。 非生產 連線可在非生產、開發和測試環境中使用。

此命名慣例應一致地應用於所有連線，不論它們是核心或高級連線。透過在不同的環境中維持 Connection 命名的一致性，您可以簡化 Chain 的推廣流程，並讓 Chain 可以在不同的工作空間中無縫執行。

鏈結產生器

在 Workiva 平台中建立 Chains 時，維持一個組織良好的命名慣例至關重要。明確一致的命名策略有助於更有效率地導航鏈，尤其是當工作流程的數量增加時。本節概述了根據目的、源系統、頻率和工作流程層級來命名 Chain 的主要實踐。

目的和來源系統

確定連鎖的目的

考慮以下問題來定義鏈的目的：

• 鏈中使用的是什麼類型的資料？
• 該鏈是否可在多個流程中使用（例如，它是否是公用鏈）？
• 從哪些來源系統取得資料？

頻率

指定鏈的頻率

命名鏈結時，請務必註明頻率，尤其是排程為自動執行時。我們建議遵循以下準則：

• 說明 Chain 是否以臨時方式執行。
• 指定 Chain 是否以每日、每週、每季或每年為基礎運行。

階層圖

組織複雜的 Chain 建立

在由多個工作流程組成的連鎖建立中，通常會有一個頂層連鎖與多個子連鎖依序執行。以編號命名慣例作為前綴來組織這些 Chain。

編號命名慣例範例：

• 1.0 頂層鏈結
• 1.1 執行資料集
• 1.2 將資料載入 Wdata 表格
• 1.3 重新整理傳入連線

此方法可幫助用戶快速識別工作流程中的操作順序，並根據數字順序自動組織工作區中的鏈。

鏈命名慣例實例

公用程序鏈

Utility Chains 是由多個其他工作流程執行的共同工作流程，例如Loading data into a Wdata Table 。為確保 Utility Chain 顯示在工作區頂端的顯眼位置，請考慮下列命名慣例：：

• 0.0 - [公用程式鏈結名稱] | [進程] |公用事業鏈結
• 0.1 - [公用程式鏈結名稱] | [進程] |公用事業鏈結
• 0.2 - [公用程式鏈結名稱] | [進程] |公用事業鏈結

來源系統

來源系統」一詞是指資料的來源，可包括各種系統，例如 ERP (企業資源規劃)、EPM (企業績效管 理)、HR (人力資源) 和會計系統，也可以是檔案型，例如來自 SFTP /FTP 的資料。

以下範例以三個來源系統為例，說明組織架構：

1. Workday
   • 1.0 - [鏈名/流程] | Workday | [頻率］
   • 1.1 - [鏈名/流程] | 工作天 | [頻率］
   • 1.2 - [鏈名/流程] | Workday | [頻率] 1.0
2. SAP
   • 2.0 - [鏈名稱/流程] | SAP | [頻次］
   • 2.1 - [鏈名稱/流程] | SAP | [頻次］
   • 2.2 - [鏈名稱/流程] | SAP | [頻次］
3. NetSuite®
   • 3.0 - [鏈名/流程] | Netsuite | [頻次］
   • 3.1 - [鏈名/流程] | Netsuite | [頻次］
   • 3.2 - [鏈名/流程] | Netsuite | [頻率］

對於具有大量 Chain 的工作區，請使用下列命名慣例範例，以確保清晰性和組織性：

此結構可確保明確、一致的命名慣例和組織，讓您更容易根據程序和執行頻率來識別和管理公用程式鏈和源系統鏈。

環境命名慣例

環境可讓您輕鬆規劃、測試和部署工作流程。這簡化了軟體開發生命週期 (SDLC) 最佳做法在自動化流程中的應用。建立環境時，我們建議使用以下簡化的命名慣例，以清楚地識別每個 Environment的用途。這有助於使用者快速瞭解每個環境的預期用途。

環境類型與命名慣例

1. DEV (開發)
   • 目的：用於開發新的鏈和流程。建立者可以在開發 (DEV) 環境中安全地建立和實驗。
   • 範例：開發
2. 測試（或沙箱）
   • 目的：專用於測試和 QA 流程。QA 團隊可以在測試 (Test) 環境中進行審閱和測試。
   • 範例: TEST
3. PROD（生產）
   • 目的：用於已經過測試、優化並準備在生產環境中部署的流程。 

   • 範例： PRODPROD

     

附註

• 多個鏈結可以有相同的名稱，但每個鏈結都由稱為 GUID的唯一識別碼區分。

• 每個工作區都有唯一的 ID（請參閱 URL），因此多個工作區可以使用相同的名稱。我們不建議這麼做，因為這可能會使使用者產生混淆。
• 鏈結、工作區和工作區環境名稱均支援空間和 Workiva 標準字元集。
• 名稱長度:
  • 鏈結 名稱的最大長度為 100 個字元。
    注意： 複製鏈結時，會自動新增字元「-- Copy」。如果這導致名稱超過 100 個字元，則不會復制鏈結。
  • 鏈結命令 （節點）名稱最多為 255 個字元。 
  • 工作區 名稱的最大長度為 50 個字元。
  • 工作區環境 名稱的最大長度為 25 個字元。

總結

使用這些簡化的命名慣例有助於維持結構化、易於導覽的環境設定。它可確保每個環境的目的都很清楚，以減少混亂，並提高開發、測試和部署階段的效率。