2017-08-01 9 views
2

私はCordaで以下のユースケースを実装しようとしています。 FlowAはPartyAでstartFlowDynamic経由で呼び出されました。 FlowAは、部分的に署名されたトランザクションを作成し、sendAndReceiveを介してPartyBでFlowBを呼び出します。人間のユーザは、この取引を見直し、手動で承認しなければならない。理想的には、フローBはトランザクションを受信した後に中断する必要があります。私はRPCを介してFlowBの中断されたインスタンスを照会することができ、それらの(またはその中のトランザクションの表現)をUIにユーザに提示したいと考えています。その後、ユーザーの承認後、私はRPCを介してFlowBを再開したいと思います。そして、RPCはPartyA上のトランザクションに署名してFlowAに返します。RPCコールで再開できるようにフローを中断することはできますか?

私は、CordaRPCOps.stateMachineAndUpdatesを使用して中断されたフローをある程度調べることができ、進捗状況の追跡に関するチュートリアルを読みましたが、私の場合は十分ではありません。私はまた、流れから人々との相互作用が将来の機能として記載されていることを読んで、私はちょうどこれを達成するための方法がないのだろうかと思った?

答えて

1

EDIT:実際にどのように動作するかを示すサンプルCorDappがここにあります:https://github.com/joeldudleyr3/negotiation-cordapp

現在、Cordaでは、ユーザーの操作のためのフローの一時停止はサポートされていません。

ただし、このようなワークフローは次のようにサポートできます。あなたがローン申請用のCorDappを書いているとします。 2者の間でloanApplication状態の作成に同意する初期フローを持つことができます。そこから承認者が貸出申込書を調べ、loanApplicationapprovedLoan州に変換するトランザクションを作成するapproveフローを開始するか、approvedLoanステートを発行せずにloanApplication状態を消費するようにrejectフローをキックオフすることができます。

同じように、loanが承認されているかどうかを指定して、ステータスフィールドをloan状態に追加できます。当初、loan状態のフィールドはunapprovedに設定されていました。次に、承認者は、状態を更新するために2つのフローのうちの1つを開始し、approvedまたはrejectedのいずれかのステータスにすることができます。

+0

ありがとうございました。 PartyA(またはさまざまなパーティー)が作成できる多くのローン申請のうち、PartyB(ユーザー)が承認することができるのは、あなたの提案に基づくものです。これは、多くの取引/状態をPartyA/PartyB/Notaryのデータベースに永久に保存したままにします。 loanApplicationsの場合には、これは実際に望ましいかもしれません。私のユースケースでは監査目的ではないため、実際に承認されたloanApplicationsのトランザクション/状態のみを格納することが望ましいと感じます。これがコードに追加されるかどうかについての推測はありますか? –

+0

同様の使用例が必要です。これに関する更新はありますか? – bakriOnFire

+0

他のすべての 'LoanApplication'を受け入れた後は、それを受け入れるための追加フローはどうですか?これにより、トランザクションストレージに残しておくと、「LoanApplication」状態がボールトから削除されます。 – joel

0

これは「推奨されるアプローチ」であるかどうかはわかりませんが、他の誰かが説明したように、私のフローにQuasar互換のAsynchListenableFutureを実装しましたhere

フローを一時停止し、別のフローから状態を生成するまで待つ必要がありました(ユーザーの操作に応答して)。それはうまくいくようですが、それはむしろオフピースと見なすことができると思われます(?)。

アクティビティをUIのインタラクションによって直接呼び出すことはできますが、サブフローが次に開始するかどうかを判断する前に、外部(例:ユーザー)イベントを待つ一種の「監視」フローが必要でした。ユーザ相互作用に先立って既に呼び出されたフロー内から自動的に、かつ、発生することが可能である。フローロジックは、ユーザインタラクションまたは別のノードからの着信トランザクションから生じる状態変化を条件とする。私の場合、この高水準の監視フローは、ノード上の既知の状態の消費を検出し、それに応答してサブフローを呼び出します。ハイレベルのフローは、上記の答えで説明したAsynchListenableFutureで待機します。私は、契約状態タイプの状態(例えばカスタムフィールドX = Y)の属性に複合VaultQueryを作成し、返されたobservable(trackBy.futureから返された)をQuasarと互換性のあるAsynchListenableFutureに変換しました。状態が外部アクションによってトリガされたフローによって作成されたトランザクションによって消費されると、将来のリターンと自動イベント(私の場合、他のパーティとの他のトランザクションの作成)が実行されます。

私はCordaを実験/評価していますが、このアプローチが実際の生産現場でどの程度堅牢であるかはわかりませんが、うまくいくと思われます。

Cordaのいくつかの上位レベルのワークフローフローは、外部イベントを待つことができ、外部アクションに応じて条件付きで他のフローを呼び出すことができます。

関連する問題