次の設定を想像してください
- タスク リスト内のn 個の独立したタスクのセットは、Siebel で完了する必要があります。
- タスクa、bなどは別々のスレッドで処理できます
- スレッドが開始すると、ワークフローはn 個のタスクすべての状態を記録します
- スレッドは引き続き完了し、最終的に JMS メッセージをキューに送信します。
次の問題があります。
- タスクaで動作するスレッド1は、その作業を完了し、タスクaをクローズ済みとしてマークします。
- 同時に、タスク b で動作するスレッド2もその作業を完了し、タスクbをクローズ済みとしてマークします。
- 2 つの JMS メッセージがキューに配置され、別のバックエンド システムに送信されます。
- 問題は次のとおりです。最初の JMS メッセージはタスク リストの状態を示し
a=closed b=open
、2 番目の JMS メッセージはa=open b=closed
- タスクは、Siebel のユーザーが合法的に再開できます (たとえば、不正チェックの目的で)。
- ミドルウェアは順序付けを保証しないため、バックエンド システムは任意の順序で 2 つの JMS メッセージを受信します。
- バックエンド システムは、1 つの JMS メッセージを受信
closed,open
し、その直後に別のJMS メッセージを受信しますopen,closed
。これは任意の順序で発生する可能性がありますが、結果は同じです。バックエンド システムには、タスク リスト全体が閉じられていないように見えますが、Siebel ではすべてのタスク (この例では a と b) が閉じられています。
Siebel では、ワークフロー スレッドで処理されているタスクの状態を変更するデータベースへのコミットが、ワークフローの最後でのみ発生する可能性はないとのことです。これは、JMS メッセージが誤解を招く状態で送信された後に決定的に意味します。これは明らかに、エラー時にワークフローをロールバックする必要があるためです。
質問: この問題は Siebel では決して解決できないという上記の説明は本当ですか? そうでない場合は、タスクの正しい状態で JMS メッセージが送信されるように、Siebel でこれを修正できるかどうか教えてください。これはセマフォを使用して解決できると単純に考えていますが、実際には、セマフォを扱う必要がなかったという意味で甘やかされており、その概念がSiebelに存在するかどうかもわかりません。何か助けはありますか?