Studio のベスト・プラクティス

Studio の能力を完全に引き出して使用するための手引きを示します。

組織での命名規則を設定する
すべての Studio プロジェクトと、ファイル、フォルダー、プロジェクト、オーケストレーション、エンドポイントなどの関連するコンポーネントに対して、(解決すべきビジネス問題というコンテキストで) 意味のある固有の名前を指定します。名前は次のようにする必要があります。
  • 固有の名前 - Studio は大/小文字の区別があり、filename1、FILENAME1、および FileName1 は 3 つの異なるファイルになります。ただし、Studio プロジェクトを区別するために大文字化に依存しないでください。大文字化に依存すると混乱を招くことがあります。
  • 記述的な名前 - 例えば、供給業者と在庫システムを統合するプロジェクトは「SupplyChainIntegration」などと呼ぶことができます。
プロジェクトを頻繁にバックアップする
特にマルチユーザー環境ではプロジェクトを頻繁にバックアップするようにしてください。内容の圧縮ファイルをプロジェクトの特定ディレクトリーに作成するだけで、すべての Studio プロジェクト・コンポーネントを素早くバックアップできます。圧縮ファイルは他の安全な場所に保管しておいてください。プロジェクトの変更内容を追跡できるバージョン管理システム内が理想的です。
プロジェクトを中央の場所に保管する
すべてのプロジェクト・ファイルを中央の場所に配置する (できればバージョン管理ソフトウェアを使用する) と、プロジェクトの検索が簡単になり、以前の反復を容易に回復することができます (これは、同じプロジェクトで多数の開発者が作業中の場合に特に重要です)。
最適なパフォーマンスを実現するためのオーケストレーションを設計する
可能な場合、ソース・システムのネイティブ機能を使用して、できるだけ多くの入力データを統合前に前処理します。ソース・システム外部でデータを変換すると、処理オーバーヘッドが追加されます。パフォーマンスが問題になる場合、統合プロジェクトのオーケストレーションにおいて「アクティビティーのマップ」の使用を最小化する方法を検討します。
例えば、複数の異なるデータベース・システムからのデータを統合する場合、異なるデータ型の間におけるすべての差異をオーケストレーション内で解決しようとする代わりに、データを前処理する抽出表を作成することを検討します。
エンドポイント定義の構成プロパティーを使用する
プロジェクト・エンドポイントの詳細をハードコーディングする代わりに、詳細の一部についてプロパティーを使用することができます。これらの構成プロパティーを Studio で定義した後、管理コンソールを使用して様々なランタイム値を指定します。プロジェクトをデプロイする前に、実稼働環境の実際のエンドポイントに合わせてプロパティーを構成する必要があります。 詳しくは、オンライン・ヘルプを参照してください。
設計時にアクティビティーとすべての定義を Studio 内でテストする
Studio を使用してオーケストレーションのすべてのエレメントを設計するとき、適切である場合は必ずテスト・データを使用して、マッピングが期待通りに動作することを確認するようにします。プロジェクトを公開する前に、Studio を使用してすべてのマッピングおよびフラット・ファイル・スキーマをテストします。
開発環境およびテスト環境をセットアップする
実稼働環境をミラーリングした開発環境およびテスト環境をセットアップすることが理想的です (テスト環境でのデータ・ソースおよびターゲットの複製を含む)。
  • 開発環境とテスト環境に実動データを抽出 (または複製) します。

プロジェクトをデプロイする前に、構成プロパティーを変更して、実稼働環境の実際のエンドポイントに合わせてプロパティーを構成する必要があります。 詳しくは、管理コンソールのオンライン・ヘルプを参照してください。