Templates画面テンプレートから作成した画面内のサンプルデータを置換します。WS-Addressing要素をSOAPリクエストに追加する。PDF例オプション1の使用オプション2の使用アプリケーションと密に統合されたプロセスを設計する場合には、プロセスとアプリケーションの両方が同じエンティティのレコードを同時に変更するという状況が生じることがあります。これによって誤動作が生じる主な理由は、以下のとおりです。プロセスインスタンスとアプリケーションが別々のトランザクションで実行されます。1つのトランザクションがエンティティレコードを変更しているときは、他のトランザクションが変更できないようにそのレコードをロックします。ロックしているトランザクションが終了して初めて、他のトランザクションはそのレコードを変更できるようになります。ロックしているトランザクションの終了を待っている間に、プロセスインスタンスのトランザクションがタイムアウトによって途中停止することがあります。Centerで不必要なロギングエラーを発生させてしまいます。このケースでは、以下の方法が推奨されます。アプリケーションを分析して、プロセスのライフサイクルがプロセス拡張アクションまたはシステムアクションを使用して制御されている状況を見つけます。手順1で見つけた状況に対して、アプリケーションロジックとプロセスロジックを分析し、同じレコードを変更するかどうかを調べます。両ロジックが同じレコードを変更している場合、ロックに関する問題が生じている可能性があります。以下の2つオプションから1つを選択します。アプリケーション、プロセス、またはそれらの両者が、どのアトリビュートを使用しているかを把握します。一部のアトリビュートはアプリケーションまたはプロセスのいずれかにより変更され、他のアトリビュートは両者により変更されることが一般的です。ここでの解決策は、エンティティを拡張して、プロセスからのみ変更されるアトリビュートを新しいエンティティに1対1の関係で移動することです。新しいエンティティ<EntityName>Processを呼び出します。アプリケーションフローで、プロセスライフサイクルに影響を及ぼすアクションを可能な限りフローの最後に移動します。その前にCommitTransactionを追加します。これにより、トランザクションが終了してレコードのロックが解除されます。後でトランザクションをロールバックすることはできないことにご注意ください。例として、採用応募者に対応するアプリケーションとプロセスを考えます。特定の時点で、応募者編集画面には、応募者を却下するためのボタンが表示されます。[Dismiss]ボタンを押すと、以下の状態になります。Candidateレコードが更新されます。そのため、Candidateレコードはロックされます。Closeコールバックアクションが実行されます。Closeコールバックアクションは、現時点でアプリケーションによりロックされているCandidateレコードを更新しようとします。オプション1の使用アプリケーションまたはプロセスのいずれかにより変更されたアトリビュートを特定します。StatusIdはプロセスによってのみ変更されます。それでは、CandidateProcessエンティティを作成し、分離させましょう。[Dismiss]ボタンを押すと、以下の状態になります。Candidateレコードが更新されます。そのため、Candidateレコードはロックされます。Closeコールバックアクションが実行されます。CloseコールバックアクションがProcessCandidateレコードを更新します。オプション2の使用CloseScheduleInterviewsはすでにフローの一番最後にあります。CommitTransactionをその前に追加して、データベースで変更をコミットし、ロックを解除しましょう。[Dismiss]ボタンを押すと、以下の状態になります。Candidateレコードが更新されます。そのため、Candidateレコードはロックされます。CommitTransactionアクションによりデータベースで変更がコミットされ、レコードのロックが解除されます。Closeコールバックアクションが実行されます。CloseコールバックアクションがProcessCandidateレコードを更新します。