問題タブ [spring-statemachine]

新しい Spring Statemachine プロジェクトでは、JavaConfig および Spring @Configuration クラスで使用可能なアダプター クラスを使用せずに、プログラムでステート マシンを作成できますか?

次の将来には、非常に単純なワークフロー、3 ～ 4 の状態、ルール ベースの遷移、および最大アクターを備えた Spring SM を使用したいと考えています。WF はかなり固定されているため、その定義を Java 構成に保存することはまったく問題ありません。機械ごと付いてくるWFエンジンよりもSMの方がいいのですが、Actorという概念があるかどうかわかりませんでした。つまり、(ログイン文字列によって決定される) 1 人の特定のユーザーのみが、状態間の遷移をトリガーできます。

また、同じステート マシン定義を並行して実行できますか。WF 用語のプロセス インスタンスのようなインスタンスの概念はありますか?

ありがとう、ミラン

ビジネスロジックを統合して明確にすることを期待して、Spring Statemachine を既存のプロジェクトに導入しています。相互接続された状態を持つさまざまな JPA エンティティがあり、既存の状態マシンの現在の状態として永続化された状態を設定するのに問題があります。

StateMachineFactory を使用して、エンティティ インスタンスごとに新しい StateMachine インスタンスを作成しています。StateMachine の現在の状態を別のフィールドに保存して、Hibernate を永続化します。理想的には、永続化されたフィールドの値を StateMachine と同期する必要があります。私の質問は、これが通常 Spring Statemachine でどのように達成されるべきかについてです。

1. 1 つの方法として、ローカル遷移を定義して初期状態を永続状態に移行する方法があります。その後、条件付きチェックを実行して、ソース状態をターゲット状態に移動させるローカル遷移に関連付けられたイベントを見つけることができます。これは少し厄介に思えます。ステート マシンの構成をできるだけクリーンに保ちたいと考えています。

2. StateMachine の現在の状態を、トランジションを経由せずにパブリック API を介して設定する方法がわかりません。そのため、私が検討した別のアプローチは、StateMachine インスタンスをラップして次のメソッドを公開することです (便利なデフォルトスコープであるため)。

次に、次のコードをMyEntityListener.postLoadにスローします。

上記のアプローチはうまく機能しているように見えますが、これがどのように機能すると想定されていたかは想像できません。確かにこれを達成するためのよりクリーンな方法がありますか、それともプロジェクトが十分に成熟しておらず、この機能がまだ含まれていないのでしょうか?

ご意見やご感想をお寄せいただきありがとうございます。

スプリング ステート マシンおめでとうございます。私は昨日それを見つけて、特に STS で実行されている改札口の例を試してみました。FSM の構築は非常に簡単で直感的であることがわかりました。

Spring Shell は STS でうまく動作しないため、リファレンス ドキュメントのコマンド ラインから例を実行する手順を追跡しました。

"java -jar spring-statemachine-samples-turnstile-1.0.0.BUILD-SNAPSHOT.jar"

、しかし実行するとエラーが発生しました

「spring-statemachine-samples-turnstile-1.0.0.BUILD-SNAPSHOT.jar にメインのマニフェスト属性はありません」。

gradleの使用に初心者でもありませんが、jarセクションのbuild.gradleにこの行を追加して、これを修正しようとしました

「manifest.attributes['Main-Class'] = 'demo.turnstile.Application'」(私が知っているさまざまなサブプロジェクトを処理しません) ですが、このエラー「NoClassDefFoundError: org/springframework/shell/Bootstrap」が発生しました。

サンプルを gradle から実行できる場合は、参考資料に含めていただけますか? を使用してサンプルを実行してみました

gradle を実行しましたが、シェル スクリプトとのやり取りはありませんでした。

選択疑似状態に追加されたアクションは黙って無視されるようです。これを行う：

CHOICE_STATE が入力されたときに someAction が実行されないという結果になります。

CHOICE_STATE からの遷移 (たとえば、上記の S1 または S2 への遷移) にアクションを追加することは、フレームワークによって許可されていません。

これを回避するために、CHOICE_STATE の前に状態を実装しました。その後、通常どおり、この状態に自由にアクションを追加できます。この制限の理由は何なのか、または見逃した可能性のある疑似状態にアクションを設定する方法があるのだろうかと思っていました。

私は大規模な e コマース アプリケーションを開発していますが、このプロジェクトはチェックアウト プロセスに最適だと思います。ドキュメントを読んだばかりですが、まだいくつか質問があります...

1- StateMachine を作成してセッション スコープに挿入できますか? 理論的にはこれは可能だと思いますが、セッションごとに stateMachine インスタンスを持っても大丈夫ですか、それともやり過ぎですか?

2-状態をセッションに永続化できますか? StateMachine は SpringSession でどのように機能しますか? 状態を永続化または Redis にシリアル化できますか?

この場合、スプリングステートマシンを効果的に使用するためのベストプラクティスは何ですか?

ありがとう