2016-07-25 3 views
1

私は会社のプロセスをモデリングしています。この処理には、クライアントにメッセージを送信することが含まれます。今、このクライアントは、応答として受け入れるか、拒否するか、または異なる命題を作ることができます。これをキャッチするエラーイベントからループバックできますか? - BPMN

私はそうのようなプロセスをモデル化しています

Loop on error

私は、これはモデリングの正しい方法であるかはわかりません。しかし、モデリングが私の学士論文の一部であるので、私はこれを正しいものにしなければなりません。

あなたの回答/考えをお寄せいただきありがとうございます。

編集:

パーDruxのフィードバック、私はそうのようなモデルを変更した:

Remodeled process

をこのモデルでは、不正のエラーイベントで離れて行い、それぞれの結果は、それが自身の道だ持つようになります。これは理解しやすいはずです。

+0

私はあなたのモデルの弱点を指摘したいと思います。クライアントがプロセスのインスタンスに応答しない場合、インスタンスは永久に停止します。この可能性を扱うことを考えるべきです。 – elnin0

答えて

1

あなたのモデルは正しく見えますが、BPMの観点からは元の質問だったようです。 「何が起こっているのか理解している」という視点からは、私にとってはちょっと離れているようです。

まず、このメッセージを読むと、クライアントにメッセージを送信した直後に「予約を確認する」という人間活動があるようです。クライアントがまだ応答していないことを考えると、それは間違っていると感じます。第2に、私はエラーとして考えていない何かのためにエラーイベントを使用しています。あなたが言うように、ユーザーは3つの方法で対応できるので、期待される応答に対してエラーを投げるのは間違っています。

上記の説明に基づいて、クライアントに通知を送信した直後にメッセージイベントを待ってモデル化します。これは「クライアント応答」であり、この中間メッセージイベントは、顧客がどのように応答したかに基づいて、正しい次のステップ、すなわち「確認」、「拒否」、「カウンタ提案」に進む意思決定ゲートウェイに移動します。このようにしてクライアントからの応答を待っている間に、「Aletha」スイムレーンで行動すべきでない活​​動はありません。

+0

あなたの責任に感謝します!私がBPMNをかなり新しく使っていることを考えると、このように見ていなかったことを考えると、あなたの洞察にもっと感謝します。しかし、今ではそれが複数のオプションであることが明らかになったようです。意思決定ゲートウェイが明らかに必要です...私はそれを改造し、私の質問を更新します。 –

+0

あなたのフィードバックごとにモデルを変更し、それを質問に追加しました。再度、感謝します! –

+1

これはずっと簡単に理解できます。あまりにも多くの文脈を必要とせずに流れに従うことができると思う。 – Drux

関連する問題