ジョブ、ルート、データサービスをデザイン
コンセプト |
ベストプラクティスの例 |
---|---|
命名基準 |
Talend Studioの場合は、ジョブ、ルート、データサービス、フォルダーの命名規則を定義し、それに従います。 このドキュメントでの命名規則は次のとおりですが、ユーザー要件に適用させることもできます。job_|route_ |service_といプレフィックスはそれぞれジョブ名、ルート名、データサービス名に、test_というプレフィックスはテストケース名に、pub_というプレフィックスは公開タスク名に、task_というプレフィックスは実行タスク名に使用します。 たとえば、フォルダーにxxxという名前を付けます。フォルダーは、類似するタイプのジョブをグルーピングするために使用します。次に、job_xxx_descriptionという名前のジョブと、test_xxx_descriptionという名前のそのテストケースを作成します。 より細かいレベルでは、コンポーネントに意味のある名前を付ける必要もあります。 プロジェクトレベルではプロジェクトに大文字で名前を付けます。大文字にしないとビルドエラーが発生する場合があります。 情報メモ警告: Git管理プロジェクトで作業している場合は、次の予約キーワードをジョブやジョブフォルダーに使用しないでください。
|
バージョン管理 |
アーティファクトのバージョンの処理には、Talend StudioおよびGITブランチとタグを使用します。 アーティファクトのバージョンを一元的に一度に変更して指定のバージョンで公開する方法の詳細は、各アーティファクトのデプロイメントバージョンを一括変更をご覧ください。 |
[Project identifier] (プロジェクト識別子) |
Talend Studioで最初にプロジェクトに接続する時に、パラメーターを編集し、デプロイメント時に使用されるプロジェクトID (グループID)を設定します。 このプロジェクト識別子を設定する方法の詳細は、プロジェクトのデプロイメント識別子を一括変更をご覧ください。 |
メタデータ |
自分のジョブ、ルート、またはデータサービスでスキーマメタデータを使用して複数のアーティファクト間でデータベース接続を共有したり、ソース/ターゲットコンポーネントをデザインできます。 |
コンテキスト |
コンテキストを使用して、データベース接続、ホスト名、ポートといった変数を(アーティファクトではローカルにコンテキストパラメーターを、プロジェクトではグローバルにグループコンテキストを)再利用します。変更の必要がある値や複数の場所で使用されている値は、ハードコードせず、コンテキストを使用することをお勧めします。 これらのコンテキストは、段階ごと(開発環境コンテキスト、その後にテスト環境コンテキスト、その後に本番環境コンテキスト)に切り替える場合にも便利です。 |
標準ジョブのレイアウト |
標準ジョブのレイアウトを使用して読みやすくします。特に共同作業で便利です。 一部の例の場合: 左から右に、上から下にというレイアウトをデータフローに設定し、サブジョブ間や右側のターゲット コンポーネント間といったプロセスフローが表示されるようにします。 |
複雑性 |
必要であれば、ジョブは論理に従ってサブジョブというステップに分割されます。また、プロセスフローを作成できるよう親ジョブを使用して子ジョブを実行すること、そして制限がなくても1つのジョブで20個を超えるコンポーネントを使用しないことをお勧めします。 |
Talend Studioからのリモートプロジェクトでデザインされたアーティファクトは、Talend Cloudで公開、デプロイ、実行できます。アーティファクトとしてエクスポートすると、開発環境で作成されたものとまったく同じジョブにクオリティ保証テストを実行する際にも役立ちます。
詳細は、QA環境および本番環境にデプロイをご覧ください。