I have difficulty in re-using a sub-machine diagram.
I have a need to Re-Use one State machine that I have linked to a state as a sub-machine, in another state as a sub-machine. But when I give the reference to it I get a null pointer exception.
Refer image
I Have added a submachine reference to GeneralTopup, I want to add the same to Register. But it seems impossible. Is this so?
This would not work as you need to have unique states in a whole machine and this would add same state multiple times. Having said that, it is a story what has been in my mind for a long time but I don't yet know how to implement it.
Related
I'm trying to model a business process using the spring state machine. So far I've been very sucessful with it but I'm stuck on trying to model a dynamic bit, where
the user is in state A
in that state he can create a short (predefined) task for a different user (a small state machine)
those users have to basically execute a state machine flow til the end
it should be possible to spawn many tasks concurently.
the user returns to state A once all created by him tasks have completed.
Here is a graphical representation of what I'm trying to achieve.
I think I could do this if I represent each task as a state machine and so on but I would prefer to avoid going that route as it would complicate the application. Ideally I would have just one state machine configuration.
In the spring reference I found the fork pseudo state to be maybe what I'm looking for however the offical example repo only covers a static configuration (https://github.com/spring-projects/spring-statemachine/blob/master/docs/src/reference/asciidoc/sm-examples.adoc#statemachine-examples-tasks) where each tasks are already defined (T1, T2, T3). For my application needs however I would want to be able to (at runtime) add "T4".
In essence I would like to know whether my requirements could be fullfilled with a single state machine and if I could use fork() for my needs. If its not the case I will welcome any advice that would push me in the right direction.
As I commented over the weekend, if you need a "dynamic" configuration then easiest way to do it is using "dynamic builder interfaces" which is same as in all other examples. It was basically added to be able to use SSM outside of a spring application context. Tasks recipe uses this model as it supports running a DAG of tasks using hierarchical regions and submachines.
You don't necessarily need fork as if parallel regions are entered using initial states it is equivalent. You however need join to wait parallel regions to join their execution.
While that recipe provide some background how thins can be done, we have hopefully something better in our roadmap which is supposed to add a dsl language which should make these kind of custom implementations a much easier to make.
I'm trying to make a state machine in which I want to build a retry and max attemps feature. Let me explain, so far I have this:
From SAVED, I want to go to VALIDATED, although if there is an error, it has to go to AWAITING_VALIDATION state. After 3 minutes, try again to VALIDATED state.
Did I have correctly set up retry mechanism?
After 3 attemps, I want to go back to SAVED state (and pause state machine). Is it possible to do that in a fancy waty (e.g using spring state machine) or do I have to do this manually using some kind of a cache?
Thanks for your help
There are probably many ways to do these things with different machine configurations but having said that, this is such a clearly presented guestion that I wanted to spend some time on it.
You are close and you missed some things(I'd say tricks) to make this happen. Answer is to use extended state variables to add memory into a machine. These variables are usually used to limit number of needed stated to represent what machine needs to do. You need 3 loops and you could probably create more states to represent each loop and transition(with specific guards) to those as needed. However this will simply explode state configuration if you need more loops like 10 or 20 or 100+.
I created an example in ssm-sample3 which is showing how extended state variables and different guards and actions can be used to drive this specific flow.
Unfortunately there is a bug in a current 1.1.1.RELEASE which prevents you to directly transition from a AWAITING_VALIDATION into HAS_ERROR junction and loop until you pause into VALID using an anonymous transition having a guard(that's why sample has a dummy TMP state which is not needed with 1.2.x).
This is probably something I'd like to add as an example or faq to our ref docs.
Lemmy know if this helps.
I'm struggling to persist my state machine following the recipes and examples available. I'm working with the master branch and my state machine uses Hierarchical States, Regions and Orthogonal states. The first example I followed is spring-statemachine-samples/persist but it seems to deal only with basic FSM. The second one I tried is LocalStateMachineInterceptor but id does not seem to be working with Hierarchical States. Also, I can't find any way to persist an history state via a StateMachinePersist.
Is there an example of a complex FSM with persistence anywhere?
I have to be honest that persistence is one relatively unknown topic for samples and docs when things gets more complicated. It is something I'm currently working on to make it easier because as a user you should not care as there should be a relatively clean API's to do it. So stay tuned for those.
Having said that, before we get code more clear on this;
StateMachinePersist leads to StateMachineContext and there is some code in tests, namely StateMachineResetTests which shows some ways to do these things. There was also a question gh127 where I wrote something about internals of resetting a machine which is what a persistence does.
History state, yes that's my bad, for some reason it has slipped from my radar. Thanks for pointing it out! Created an issue for it gh182.
I am trying to use QSensor and friends in Qt5.5 for the first time, and a question has come up; who is responsible for managing instances of QSensorReading? I have tried to understand this by reading the documentation without getting any wiser.
Example:
QAccelerometer *accelerometer=new QAccelerometer(this);
if(accelerometer->connectToBackend()){
accelerometer->start();
}
//Some time later in handler for QSensorReading::readingChanged()signal:
QAccelerometerReading *myReading=accelerometer->reading();
What can I do with myReading here? Should I delete it? Will it be automaticaly delted? Can I pass it safely along as a parameter? Do I risk it being updated (mutable)? Can I copy it somehow?
It's owned by the QSensorBackend, so it'll be deleted with it. The pointer can be passed, but the object doesn't look like copyable. The value inside may be updated (but it's thread safe if it's used in the same thread where the backend lives). The pointer stays the same.
I need some suggestions. I am trying to implement an online order process through Spring state machine and am trying to construct a state diagram before I get to work. Now say my order can be canceled by three different admin users CanceledByAdmin1,CanceledByAdmin2 and CanceledByAdmin3. Should I make them substate of Cancel state or create three different states? Keeping in mind that all canceled states are the final states and independent of each other, I don't know if making substates does anything other than simplifying the paper diagram. Any help would be appreciated.
What comes for Spring Statemachine we can have only one terminate state and trying to make that as collection of substates is a bit awkward because once you enter it, state machine should stop all processing. Thought this area is something what I've probably overlooked and could try to enhance things.
While you could probably have a state S1 having three substates S11/S11E,S12/S12E andS13/S13E with triggerless transition from S11 to S11E and same with other substates, even this feels a bit weird because none of those would actually terminate root state machine.
I guess question is what you're trying to accomplish?
If you only want to keep that information around who/which cancelled the order, could you use a simple single terminate state and during a transition to that terminate state, add/modify extended state variables with this info.
Extended state variables are usually used to overcome these problems of suddenly having astronomical count of states to keep arbitrary information around. I know that in this example you only have three, but what about if you have 10, or 100? If you actually need to add even one more, you need to change state machine configuration and recompile. With extended state variables you would not need to do that.