概要
この「リーディング・プラクティス」シリーズは、Workiva PlatformのData Management Suite内の様々なアーティファクトについて、推奨される一般的なプラクティスを概説しています。これらは一般的なガイドラインであり、特定のユニークなユースケースに基づいて適応する必要があるかもしれないことに留意してください。これらの推奨事項は、ワークスペース内の整理整頓を改善することを目的としています。まずは、これらの命名規則を探ってみよう。
接続 、チェーン 、環境の名称規則
チェーンの接続
コネクション・イン・チェーンを作成する際には、エンバイロメント を明確に区別するために、最適な名称規則を確立することが不可欠である：
- コネクターの名称： コネクターの目的と機能をクリアに示す名称を記入してください。
- ワークスペースのタイプ： コネクターを使用するワークスペースまたはプロジェクトを指定します。
- コネクターの環境： コネクターが対応する環境（開発、生産など）をクリアに識別する。
例：
- SFTP接続｜SECレポート｜NON-PROD
- 説明: 開発、QA、サンドボックスなどの非プロダクト環境内のSECレポートワークスペースソリューション用のSFTPサーバーへの接続を確立します。
- SFTP接続｜SECレポート｜PROD
- 説明 本番環境内の SEC レポート・ワークスペース・ソリューションの SFTP サーバへの接続を確立します。
この名称規約は、異なる環境間での接続の識別と管理を容易にします。これにより、特定の環境にあるチェーンが適切なソースとのみ交流することが保証され、セキュリティと信頼性が向上する。Non-Prod 接続は、Non-Prod、Dev、Test の各環境で活用できる。
この名称慣習は、コアコネクターであるかプレミアムコネクターであるかにかかわらず、すべての接続に一貫して適用されるべきである。異なるエンバイロメント間で接続名称を統一することで、チェーン昇格プロセスを合理化し、ワークスペース間でシームレスなチェーンの実行を可能にします。
チェーンビルダー
Workivaプラットフォームでチェーンを構築する場合、きちんと整理された名称規則を維持することが重要です。明確で一貫性のある名称戦略は、特にワークフローの数が増えるにつれて、チェーンをより効率的にナビゲートするのに役立つ。本セクションでは、目的、ソースシステム、頻度、ワークフロー階層に基づくチェーンの名称に関する主要なプラクティスを概説する。
目的とソース・システム
チェーンの目的の決定
チェーンの目的を明確にするために、次の質問を考えてみよう：
- チェーン内ではどのようなデータが使われているのか？
- チェーンは複数のプロセスで利用できるか（すなわちユーティリティ・チェーンか）？
- どのソースシステムからデータを取得しているか？
頻度
チェーンの周波数を指定する
チェーンに名前をつけるときは、特に自動実行するようにスケジュールされている場合は、その頻度を示すことが重要である。以下のガイドラインを推奨する：
- チェーンがアドホックに実行されるかどうかをインジケーターで示します。
- チェーンが日単位、週単位、四半期単位、年単位で実行されるかどうかを指定する。
階層
複雑なチェーン構築の組織化
複数のワークフローからなるチェーンビルドでは、通常、トップレベルのチェーンと複数のサブチェーンが順番に実行される。これらのチェーンには接頭辞を付け、番号と名称を付けて組織化します。
番号付き名称の例：
1.0 トップ・レベル・チェーン1.1 データセットの実行1.2 Wdataテーブルにデータをロードする1.3 着信接続のリフレッシュ
このアプローチは、ユーザーがワークフロー内の操作の順序を素早く識別し、数値順序に基づいてワークスペース内のチェーンを自動的に整理するのに役立ちます。
チェーン名称の実例
ユーティリティチェーン
ユーティリティチェーンは、他の複数のワークフローによって実行される一般的なワークフローで、例えばWdataテーブルへのデータの読み込み 。ユーティリティ・チェーンがワークスペースの上部に目立つように表示されるようにするには、次の名称規則を考慮してください：
0.0 - [ユーティリティ・チェーン名] | [プロセス] | [ユーティリティ・チェーン0.1 - [ユーティリティ・チェーン名] | [プロセス] | [ユーティリティ・チェーン0.2 - [ユーティリティ・チェーン名] | [プロセス] | [ユーティリティ・チェーン
ソースシステム
ソースシステム」という用語はデータの出所を参照し、ERP（統合基幹業務システム）、EPM（統合業績管理）、HR（人事管理）、会計システムなど様々なシステムが含まれるほか、SFTP /FTPからのデータのようにファイルベースの場合もある。
以下の例では、3つのソース・システムの組織を例として示している：
- ワークデイ
- 1.0 - [チェーン名称/プロセス] | 勤務日 | [頻度].
- 1.1 - [チェーン名称／プロセス] | ワークデイ | [頻度].
- 1.2 - [チェーン名称／プロセス] | ワークデイ | [頻度].
- SAP
- 2.0 - [チェーン名称/プロセス] | SAP | [頻度]。
- 2.1 - [チェーン名称/プロセス] | SAP | [頻度]。
- 2.2 - [チェーン名称/プロセス] | SAP | [頻度]。
- Netsuite
- 3.0 - [チェーン名称/プロセス] | Netsuite | [頻度].
- 3.1 - [チェーン名称/プロセス] | Netsuite | [頻度].
- 3.2 - [チェーン名称/プロセス] | Netsuite | [頻度].
多数のチェーンがあるワークスペースでは、分かりやすく組織を整理するために、以下の名称規則の例を使用します：
この構造により、明確で一貫性のある名称規則と組織が確保され、ユーティリティ・チェーンとソース・システム・チェーンを、そのプロセスや実行頻度に基づいて識別し、管理することが容易になります。
環境名称規約
環境は、ワークフローの計画、テスト、デプロイを容易にします。これにより、ソフトウェア開発ライフサイクル（SDLC）のベストプラクティスの自動化プロセスへの適用が合理化されます。エンバイロメントを作成する際には、エンバイロメント の目的を明確にするために、以下の簡略化した命名規則を使用することをお勧めします。これは、ユーザーが各環境の使用目的を素早く理解するのに役立ちます。
環境タイプと名称規則
- DEV（開発）
- 目的：新規チェーンやプロセスの開発に使用。ビルダーは、開発（DEV）環境で安全に作成やエクスペリエンスを行うことができます。
- 例
DEV
- テスト（またはサンドボックス）
- 目的：テスト中およびQAプロセス専用。QAチームは、テスト（Test）環境でレビューとテストを行うことができる。
- 例
テスト
- PROD（プロダクション）
- 目的テストされ、改良され、本番環境に配備する準備が整ったプロセス。
-
例
PROD
メモ
複数のチェーンは同じ名前を持つことができるが、それぞれはGUID として知られる一意の識別子によって区別される。
- 各ワークスペースは一意のID（URLに記載）を持っているので、複数のワークスペースが同じ名前を持つことができます。しかし、ユーザーの混乱を招く可能性があるため、そのようなことはしないことをお勧めする。
- チェーン、ワークスペース、およびワークスペース環境の名前はすべて、スペースと Workiva 標準文字セットをサポートしています。
- 名前の長さ
- チェーン名の長さは最大100文字。
注意： チェーンをコピーする際、自動的に"-- Copy "の文字が追加される。この結果、名前が100文字より長くなった場合、そのチェーンはコピーされない。 - チェーンコマンド （ノード）名は最大255文字。
- ワークスペース 名の長さは最大 50 文字です。
- ワークスペース環境 名の長さは最大 25 文字です。
- チェーン名の長さは最大100文字。
概要
これらの簡略化された名称規則を使用することで、構造化され、ナビゲートしやすい環境セットアップを維持することができます。これにより、各環境の目的がクリアになり、開発、テスト、デプロイメントの各フェーズで混乱が減り、効率が向上します。