ジョブ、ルート、データサービスをデザイン

命名基準

Studioでジョブ、ルート、データサービス、フォルダーの命名規則を定義し、それに従います。

このドキュメントでの命名規則は次のとおりですが、ユーザー要件に適用させることもできます。job_|route_ |service_といプレフィックスはそれぞれジョブ名、ルート名、データサービス名に、test_というプレフィックスはテストケース名に、pub_というプレフィックスは公開タスク名に、task_というプレフィックスは実行タスク名に使用します。

たとえば、フォルダーにxxxという名前を付けます。フォルダーは、類似するタイプのジョブをグルーピングするために使用します。次に、job_xxx_descriptionという名前のジョブと、test_xxx_descriptionという名前のそのテストケースを作成します。

より細かいレベルでは、コンポーネントに意味のある名前を付ける必要もあります。

プロジェクトレベルではプロジェクトに大文字で名前を付けます。大文字にしないとビルドエラーが発生する場合があります。

バージョン管理

アーティファクトのバージョンの処理には、StudioおよびGITブランチとタグを使用します。

アーティファクトのバージョンを一元的に一度に変更して指定のバージョンで公開する方法の詳細は、各アーティファクトのデプロイメントバージョンを一括変更 (英語のみ)をご覧ください。

プロジェクト識別子

Studioで最初にプロジェクトに接続する時に、Studioのパラメーターを編集して、デプロイメント時に使用されるプロジェクトID (グループID)を設定します。

このプロジェクトIDの設定方法は、プロジェクトのデプロイメント識別子を一括変更 (英語のみ)をご覧ください。

メタデータ

自分のジョブ、ルート、またはデータサービスでスキーマメタデータを使用して複数のアーティファクト間でデータベース接続を共有したり、ソース/ターゲットコンポーネントをデザインできます。

コンテキスト

コンテキストを使用して、データベース接続、ホスト名、ポートといった変数を(アーティファクトではローカルにコンテキストパラメーターを、プロジェクトではグローバルにグループコンテキストを)再利用します。変更の必要がある値や複数の場所で使用されている値は、ハードコードせず、コンテキストを使用することをお勧めします。

これらのコンテキストは、段階ごと(開発環境コンテキスト、その後にテスト環境コンテキスト、その後に本番環境コンテキスト)に切り替える場合にも便利です。

標準ジョブのレイアウト

標準ジョブのレイアウトを使用して読みやすくします。特に共同作業で便利です。

一部の例の場合: 左から右に、上から下にというレイアウトをデータフローに設定し、サブジョブ間や右側のターゲット コンポーネント間といったプロセスフローが表示されるようにします。

複雑性

必要であれば、ジョブは論理に従ってサブジョブというステップに分割されます。また、プロセスフローを作成できるよう親ジョブを使用して子ジョブを実行すること、そして制限がなくても1つのジョブで20個を超えるコンポーネントを使用しないことをお勧めします。