このセクションでは、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 つのエンドポイント パスを使用可能にします
その他のリソース
Parasoft フォーラム (英語) にアクセスしてコミュニティに回答がないかをチェックできます。また、Parasoft 製品テクニカル サポート センターに問い合わせることもできます。
