Hi, I have another question on Spryker’s state machine. I just found this in the documentation: Tri

UPDV9V3ST

Hi, I have another question on Spryker’s state machine. I just found this in the documentation:

Triggering an event follows the transition that has the current state as a source state and the triggered event type attached to it. The event triggers the transaction and the related command is executed. The condition(s) is/are checked afterwards. If no condition is evaluated to true, the item stays on the source state (and the timeout is reseted because it moved away for a moment).

So if I have several transitions with different conditions from state A to B then all commands will be executed although only one (or even none) condition is true?

Andriy Netseplyayev

Hi Matthias! Can you please explain, what do you mean by “different conditions”, “several transitions” and “all commands” between A and B? Does it mean, that you have multiple states between A and B? If you have already a state machine visualization to show here - that would be helpful!

UPDV9V3ST

My point is that the documentation states that the condition is checked after the command is executed. I would expect that a condition is checked first.
Imagine a state with several transitions from this state to other states. Each transition can have an event which can have a command and a condition. To decide which transition is executed you have to check the conditions. If the command is executed BEFORE the condition then all commands would be executed.

Andriy Netseplyayev

@UPDV9V3ST I see your point! I also had a situations in the past where executing condition before the command would be beneficial, however I also had situations where you first want to execute a command, and then check it’s result execution with the condition and proceed further.

If you need to execute a command after the condition check, then you have to introduce a state right after condition, and then from that state do a trasition to the next one which will include the event.

Andriy Netseplyayev

That’s an example of what I mean:

Andriy Netseplyayev

you do a command (export), then you check if it was successful in a condition, and if yes - you notify buyer with another command

Andriy Netseplyayev

if it wasn’t successful - you fix the issue and then retry manually

UPDV9V3ST

Ok, thanks for the clarification. Actually I have a pretty similar use case. What I don't like about that solution is that I need an additional method/interface in my middleware to check whether the last command was successful. It would be much better to use the outcome of the export itself to transition to different states.

UPDV9V3ST

In my use case I would use a HTTP response code to decide if I can proceed, retry or go to an error state.

Andriy Netseplyayev

@UPDV9V3ST yes, that’s a pretty common use case.

additional method/interface in my middleware

So just do it in Zed!

how I’ve done that In my project:
1. Command executes the HTTP call and persists the results into the separate table. Can be “pyz_order_export_log” or similar.
2. Condition checks, is there an entry for order_id (or order_item_id) with the status “success”? Yes - go there; No - go elsewhere.

As a bonus, the “log” table was turned out to be extremely useful during further checks like “what did we send and why did the request fail?”

UPDV9V3ST

Hi Andriy, can you give me a hint how you persist the result into an separate table? Do I have to create a new Transfer object?