LiveCycle プロセス作成のベストプラクティス

Adobe LiveCycle Workbench を使用した Workbench プロセスを設計した経験があることが望ましい。

すべて

この記事では、Adobe LiveCycle Workbench を使用して LiveCycle プロセスを作成するためのベストプラクティスのいくつかを説明します。Workbench の一部のバージョンには適用されないため、LiveCycle プロセスを作成するための詳しい手順ガイドとして扱うべきではありませんが、慣習を改善および標準化するための一般的な慣行を表しています。これらのベストプラクティスを実装する前に、LiveCycle プロセスを設計する際の戦略全体および、組織のニーズに合っていることを確認してください。

ベストプラクティスを定義し、通常の手順に従って作成することは、個人やチームが LiveCycle プロセスの作成経験を得られる、継続的なアクティビティとなります。

LiveCycle プロセスの重要な側面は、そのデザインとレイアウトです。プロセスは、整理され、論理的にレイアウトされ、実装と理解が容易であることが理想的です。

• デザインはシンプルにします。プロセス管理図は、プロセスを視覚的に表します。多数の手順を使用した、煩雑な図は避けてください。明確なプロセスダイアグラムを設計するには、スイムレーン、サブプロセス、および適切なドキュメントを使用します。
• 各プロセス、操作およびルートに対して適切な説明を提供します。プロセス「プロパティ」パネルで説明を設定できます。
• 各変数にタイトルと説明を入力する。  「タイトル」は、変数が操作の入力や出力に使用される場合に常に使用され、単に変数の名前だけでなく、その目的についての詳細を提供します。「説明」には、プロセス開発者に有効なヘルプ情報を提供します。この情報は特に、サブプロセスとその入力および出力変数に関連します。
• LiveCycle では、新しいデータベーステーブルの作成やデータソースの操作に対する広範なサポートは提供されていません。データベースオブジェクトの作成には、サードパーティのデータソースを使用する。
• 労力を最小限に抑えつつ LiveCycle プロセスの作成を高速化するには、サブプロセスの作成を検討する必要があります。サブプロセスを使用すると、アプリケーション内のプロセスを再利用および単純化できます。複数の場所や複数のアプリケーションで使用される、類似した機能に対するサブプロセスを作成します。

LiveCycle プロセスを作成する際、プロセスを標準化する際の重要な側面は、命名規則に従うことです。命名規則は通常、組織に固有のものなので、LiveCycle プロセスの開発を始める前に要件とポリシーを考慮して定義する必要があります。

• オブジェクトの機能や使用方法を定義するには、デフォルト名ではなく、オブジェクトにわかりやすい名前を付けます。変数名にはキャメルケースを使用します。
• すべてのプロセス、サブプロセスおよびアプリケーションで同じ言語を使用します。複数の言語を混在させないでください。
• アプリケーションおよびプロセスのフォルダー構造を作成するための標準規格を作成します。
• 名前の競合を回避するため、変数、オブジェクト、プロセス、アプリケーションごとに異なる名前を使用します。        
• カスタムコンポーネントの標準規格を定義し、これらの規格を適用および使用します。
• ログの実装に関する標準規格を定義し、使用するログの標準規格を適用します。

プロセス、サブプロセス、アプリケーションのパフォーマンスを最適化することで、リソースの使用率および計算時間が減少し、アプリケーションが停止状態になるのを防ぎます。

LiveCycle プロセスのパフォーマンスを向上させるためのベストプラクティスをいくつか示します。

• すべてのサブプロセスに例外処理を実装します。これにより、再開できない、停止したプロセスの数が減少します。  
• 標準搭載のコンポーネントを使用すると、エラールートを定義できます。  可能な値をチェックする場合は、常にすべてのサブプロセスにデフォルトのルートまたはエラールートを実装します。
• executeScript を使用すると、LiveCycle プロセスの速度が遅くなる場合があります。executeScript に大きく依存する代わりに、カスタムコンポーネントを作成するか、サブプロセスの組み合わせを使用します。
• 可能な値のチェックを実行する場合は、大文字または小文字の式を使用して、フェールセーフメカニズムを実装します。例えば、@nextStep = ‘PROC.001’ をチェックする場合は、「proc.001」と「Proc.001」もチェックします。
• コードに警告が含まれていないことを確認します。コードに修正を適用して、警告の数を減らします。
• コメントセクションにコードを配置しないでください。コードが読めなくなり、新しい開発者がコードを理解するのが困難になります。
• 開発者は、一部の機能をテストするためだけのクラスやメソッドをほとんど書き込まず、後で使用することはありません。  コードを読みやすく理解しやすくするため、未使用のコードを削除します。
• 場合によっては、複数のコンポーネントが似たようなコードを使用することがあります。他のコンポーネントからコードをコピーする代わりに、再利用可能なコードの jar ファイルを作成します。
• アドホックのデータベーステーブルは作成しないでください。承認済みおよび正規化スキームについては、データベースチームに問い合わせてください。
• 例外の場合は、特定の状況を前提とする代わりに、条件を適切に確認します。状況を推測してしまうと、あいまいな結果や停止したプロセスが生じる可能性があります。
• すべてのノードは実行時間に追加され、長期間有効なプロセスの場合はデータベースストレージに追加されます。無関係なノードや使用していないノードおよび操作は避けてください。
• 個々のマッピング式の長いリストを定義する代わりに XSLT を使用して、XML データ内または XML データ間で複数の要素を移動またはコピーすることを検討してください。
• プロセス、サブプロセス、およびアプリケーションに未使用の変数がないか確認します。Workbench アドオンを使用して、未使用の変数を特定します。未使用の変数を削除します。特に、長期間有効なプロセスは、変数にデータベース領域を割り当てるので、これらの変数を削除します。

コーディングのベストプラクティスをいくつか示します。

• 変数名にはキャメルケースを使用します。
• 変数の型（整数／文字列／ドキュメント）は必ず定義してください。
• アクティビティには、明確でわかりやすい名前を付け、「setSearchVariables」ではなく「検索変数の設定」のような名前を使用します。これらの名前は LiveCycle Administration Console で使用されます。
• プロセスには常にデフォルトルートが必要です。
• 比較をおこなう際は、必ず明示的に説明します。計算の場合、計算に使用するプロセス変数を数値に変換します。

Eエラーが発生しやすい：
/process_data/dataXML/CandidateDataCaptureForm/dataCapture/pmiData/pmiForSelf = “1” または /process_data/dataXML/CandidateDataCaptureForm/dataCapture/pmiData/pmiForSelf = 1

ベストプラクティス：
number(/process_data/dataXML/CandidateDataCaptureForm/dataCapture/pmiData/pmiForSelf) = 1

• executeScript オブジェクトにコードを代入する代わりに、カスタムコンポーネントを作成することを常に検討してください。これにより、ユニットテストを向上し、他のカスタムコンポーネントの機能を再利用することができます。
• サブプロセスに対しては常に戻り値を実装します。サブプロセス（特に同期的で、短時間のみ有効なプロセス）を呼び出すと、値が返されます。この値は、メインプロセスで確認できます。これにより、メインプロセスでサブプロセスのステータスを把握できます。メインプロセスでは、戻り値を適切に処理する必要があります。
• リテラル値をハードコーディングしないでください。このような値を使用するには、LiveCycle 環境を変更する際に、アプリケーションの再構築、再パッケージ化および再デプロイをおこなう必要があります。可能な場合は、設定値を使用して、プロセス定義の外部でサービスを設定できます。 
• すべてのチェックポイントでデフォルトルートを実装します。プロセスルートは、有効な値のほとんどすべてに対して定義されます。有効な値と変数が一致しない場合に呼び出されるデフォルトルートです。デフォルトのルートでは、停止したプロセスを作成できません。
• ログでは、電源がオフになっていても、多くのシステムリソーが使用されます。システムリソースの利用を最適化するために、過剰なログを実行しないでください。

すべてのプロセス間で一貫性と完全性を確保することにより、プロセスがわかりやすくなり、パフォーマンスが向上し、コードが煩雑になるのを防ぎます。

LiveCycle プロセス間の一貫性と完全性を確保するためのチェックリストを次に示します。

• 例外を処理しました。
• サブプロセスの呼び出しとその戻り値を正しく処理しました。
• 未使用の変数を削除しました。
• 無関係な操作を削除しました。
• プロセスに適切な注釈を付けました。
• 操作からの発信ルートの一貫性を確認しました。
• リテラルを、関連する場所で設定変数に置き換えました。
• 計算と比較で、適切なデータ型の使用および完全性を確認しました。
• 各変数のサイズを確認しました。

ここでは、Workbench のプロセスを作成するためのベストプラクティスを簡単に説明しました。

詳しくは、LiveCycle AEM Forms デベロッパーセンターを参照してください。LiveCycle Workbench のドキュメントは、LiveCycle ES3 のドキュメントページで入手できます。

ドキュメントには、ほとんどの質問に対する回答が記載されていますが、ご自由にディスカッションを開始および参加してください。