Hi, does someone know why the OMS doesn't execute transitions with `onEnter="true"` events automati

U01SE4SRCU9

Hi,
does someone know why the OMS doesn't execute transitions with onEnter="true" events automatically? I have this event:

<event name="auto cancel" onEnter="true" command="CrefoPay/Cancel" />

and such a transition:

<transition>
    <source>cancel call successful</source>
    <target>cancellation pending</target>
    <event>auto cancel</event>
</transition>

I can trigger the transition manually from Zed; then it works and does what it should. But the oms:check-condition never touches it. Why is this? What can be done about this?

martin

Hi Gabriel!

I was facing a similar issue. Go check your database table spy_oms_transition_log for more details. There is one column error_message which gives you more details about the error.

U01SE4SRCU9

Hi Martin - thanks, checked it just now, but there don't seem to be any errors logged. The error-related columns all have null as value.

martin

Okay, can you at least see that the command CrefoPay/Cancel is executed?

U01LKKBK97T

Are you sure that your scheduler is running?

U01SE4SRCU9

@U01LKKBK97T Yep. Same result (nothing) if I run the check-condition command manually.

U01SE4SRCU9

@U01F1RQDKCY When triggered manually, yes. Otherwise no.

U01LKKBK97T

I'd suggest to debug manually. Stop the scheduler, and run the oms commands manually with debugging. Set your breakpoints inside your conditions and commands to see if they're getting called at all.
Assuming that you're using Docker, this should work:

docker/sdk console scheduler:suspend
docker/sdk console -x oms:check-condition
docker/sdk console -x check-oms-timeouts

U01SE4SRCU9

I'm using vagrant. Did that already. At first it seemed like the check-condition doesn't even consider transitions with events but now I see that further down in its code, onEnters are - theoretically - called separately. I'll check that in more detail and see what I find.

U01SE4SRCU9

Buuut yeah, that doesn't help either, as its starting point is the same eventless-only stack of transitions.

U01SE4SRCU9

If you check \Spryker\Zed\Oms\Business\OrderStateMachine\OrderStateMachine::checkConditionsForProcess, you can see that it already starts out, right on the first line, with $transitions = $process->getAllTransitionsWithoutEvent();, and then derives all the rest from that. So it has no chance to find my transition with the onEnter event since it tries to filter it out ($orderItemsWithOnEnterEvent = $this->filterItemsWithOnEnterEvent($orderItems, $processes, $sourceStateBuffer);) from a stack that never contained it to begin with.

U01SE4SRCU9

So, it seems I misunderstood something... apparently, it checks for onEnter events in the TARGET state. So what messed things up here was that the SOURCE state had event as well as condition. Since in the first half of the aforementioned method, it was looking explicitly for eventless transitions, it of course didn't find mine, didn't check it, didn't execute it - and neither could it do so in the second half, since there, it's looking for onEnter events in the TARGET state, so it didn't find it again, as the target state didn't have an event.

So I could solve it by including an intermediary state and moving the event there. The original source state now only has the check. Thus, the OMS is satisfied and can process everything correctly and automatically:

<state name="cancel received" reserved="false" />

<transition condition="CrefoPay/IsCanceledReceived">
    <source>waiting for capture</source>
    <target>cancel received</target>
</transition>

<transition>
    <source>cancel received</source>
    <event>auto cancel</event>
    <target>canceled</target>
</transition>