このセクションでは、Enterprise Pack アプリケーションの実装に役立つベスト プラクティス、高度な使用のヒント、その他の情報について説明します。
カテゴリの使用
サービスを適したカテゴリにまとめることを推奨します。カテゴリは、サービスを探しやすくして管理しやすくするための手段ですが、 サービスをどのようにカテゴリ分けするかは最終的にユーザーの判断に任されます。デフォルトでは Extension Designer には 3 種類のビルトイン カテゴリがあります。
- Process Intelligence Engine
- DTP Workflows
- Compliance Practices
これらのカテゴリは削除できず、内部的に使用されます。一方、サービスは必要に応じて追加したり削除することができます。
デプロイ
サービスは、複数のユーザーが同時に参照したり編集することができます。そのため、他のユーザーのサービスをデプロイするのを避けるために、デプロイ設定を [Full Deploy] ではなく [Modified Flows] または [Modified Nodes] に変更することを推奨します。
フォーク型フローの回避
フォーク型フローは、フローの msg のサイズが大きい場合にパフォーマンスに悪影響を与えることがあります。フォーク型フローとは、「複数のワイヤーが出力ポイントにつながっているフロー」 あるいは 「 1 つのメッセージによって呼び出される複数の出力ポイントを持つノードがあるフロー」のことです。フォークに msg が渡された場合、msg がどのように変化するかは不明です。そのため、 msg は N-1 回 (N は msg オブジェクトが通過することを期待されるワイヤーまたは出力ポイントの数) 複製されます。msg を複製することは、フォーク型フローが引き起こすかもしれないレース条件を排除することで、スライスの作成を簡単にします。そのため、大量のデータを使用するスライスを扱う場合、可能な限りフォークを避けることを推奨します。
フローのデバッグ
debug ノードはフローのデバッグに非常に役立ちますが、パフォーマンスに影響する場合があります。デバッグするオブジェクトをシリアライズして Web ブラウザーに送る必要があるため、大きなオブジェクトのデバッグは可能な限り避けるべきです。デバッグ時には msg オブジェクトを小さく分割することを重視するべきです。
たとえば、msg オブジェクトの特定プロパティに配列があることを検証したい場合、何千個も要素がある配列全体をデバッグする代わりに、配列の長さ (たとえば msg.array.length) をデバッグします。debug ノードを追加すると、(そのノードがフローの最後のノードでない限り) 一般的にフローにフォークが作成されます。そのため、もう必要のない debug ノードはフローから削除することを推奨します。なお、debug ノードを無効化しても msg オブジェクトはフォークされて debug ノードに渡されます。debug ノードの無効化は、debug ノードが出力されて不要なオーバーヘッドになるのを防止するだけです。
サービスの分割: 何個のサービスが必要なのか ?
各サービスは、最大で 2GB の RAM と 1 つの CPU を消費します。Extension Designer の実行では、多くの場合、1 つのサービスに多くのフローをデプロイします。フローをビルトイン カテゴリにまとめること、ただし、1 つのカテゴリにつき 1 つのサービスから始めることを推奨します。パフォーマンスが低下した場合、カテゴリに別のサービスを追加できます。ノード処理に関連する CPU 使用率が高い場合は、複数のサービスにフローを分けるべきです。
サービスはそれぞれ専用のポートを使用します (「Enterprise Pack の概要」を参照)。OS のプロセス マネージャーを使って、どのサービスの負荷が高いかを把握できるはずです (約 1.5 GB の RAM を使用し、CPU の使用率が一定して 50% のものを「負荷が高いサービス」と定義します)。負荷が高いサービスがある場合、フローを複数のサービスに分けて負荷を分散するべきです。
エンドポイントの呼び出し時には HTTP(S) 準拠のパラメーターを使用
一部のアーティファクトは、ブラウザーでまたは cURL コマンドを使ってエンドポイントを呼び出すことを要求します。今日のブラウザーは、非準拠の URL 文字を解決しようとします。しかし、文字が適切にエンコードされているか人間が確認する場合ほど信頼はできません。パラメーターを追加する際は、文字列パラメーターにスペース、プラス (+)、スラッシュ (/)、その他 HTTP(S) プロトコルが許可しない文字を必ず適切にエンコードしてください。 たとえば、以下のパラメーターは許可されないため、アーティファクトが正しく動作しません: エンコーディング ツール (たとえば http://www.url-encode-decode.com) を使用すると、規格に準拠するよう適切にパラメーターをエンコードするのに役立ちます。buildId=c++test。このパラメーターをエンコードすると、次のようになります: buildId=C%2D%2Dtest
正しいエンドポイント パスの使用
Extension Designer は、Available Endpoints ページで 2 つのエンドポイント パスを使用可能にします。
Extension Designer のログの設定
Extension Designer は、複数のネットワークアクセス ログにネットワーク トラフィックを記録します。Extension Designer のネットワーク トラフィックは一般に extension-designer-access.log ファイルに記録され、Extension Designer サービスへのネットワーク トラフィックは <SERVICE_ID>-access.log という個別のログに記録されます (これらのログは同じ数だけ存在することになります)。 これらのログファイルは定期的にアーカイブされ、新しいログファイルが開始するときの日付が YYYY-MM-DD 形式でファイル名に付加されます。これらのログは <DTP_DATA_DIR>/logs ディレクトリにあります。
デフォルトでは、ログの種類ごとに 90 個のアーカイブ ログが保存されます。アーカイブ ログの最大数に達すると、最も古いログが自動的に削除され、必要に応じて最新のログのためのスペースが確保されます。アーカイブできるログの最大数は、DEP_ACCESS_LOG_BACKUPS 環境変数で変更できます。詳細については「環境変数の設定」を参照してください。
その他のリソース
Parasoft フォーラム (英語) にアクセスしてコミュニティに回答がないかをチェックできます。また、Parasoft 製品テクニカル サポート センターに問い合わせることもできます。
