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