Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Is it somehow possible to move only the whole order in the OMS if a condition is met? Imagine havin

Options
U018XELUZS9
U018XELUZS9 Posts: 167 🧑🏻‍🚀 - Cadet

Is it somehow possible to move only the whole order in the OMS if a condition is met?

Imagine having an order with multiple items and an OMS transition from new to paid with the condition IsPaid. The oms:check-condition starts to check the condition for the first item, but it's false at this moment. The process picks the next item. In the meantime, the notification arrived and suddenly all remaining items from that order are in the paid state, but the first one is still in new. Any ideas on how to solve this?

I already tried to couple that condition with an empty command that implements CommandByOrderInterface, but this does not work as expected.

Comments

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    Hi, yes it is possible. You can create a command which implements CommandByOrderInterface or you can also create an external event processor.

  • U018XELUZS9
    U018XELUZS9 Posts: 167 🧑🏻‍🚀 - Cadet
    Options

    Thanks for your answer, are you talking about this package: https://packagist.org/packages/fond-of-spryker/oms-external-processor ? Is there any kind of documentation except the Readme?

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    This package is our implementation and only a wrapper for execution our plugins like https://packagist.org/packages/fond-of-spryker/oms-external-processor-payone

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    I can try to answer your questions if you got some

  • U018XELUZS9
    U018XELUZS9 Posts: 167 🧑🏻‍🚀 - Cadet
    Options

    I'm not sure if we really want to use that, it has no release yet, there is no CI configured and the last commit is more than a year old. I'll try this out anyway and see if that can solve our problem.

  • U018XELUZS9
    U018XELUZS9 Posts: 167 🧑🏻‍🚀 - Cadet
    Options

    As far as I see, the module fond-of-spryker/oms-external-processor-payone is not really restricted to payone, but could also be used as a general module for all kinds of use-cases, is that right? I did not found anything that is specific for payone in the code at least.

    As far as I understand this it's only possible to use that for one source and target combination or did I miss something?

    So maybe we will build our own module on top af the wrapper, that handles our use-case, but wouldn't it make much more sense to be able to have some sort of ConditionByOrderInterface that checks a condition not by order-item, but only by the whole order?

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    edited November 2021
    Options

    It has no release, since we started to move our packages to new namespace (fond-of-oryx).

    We had the problem that sometimes the order export was splitted since the payone response was also splitted.

    For this we did the external processor and the payone plugin.

    if i remember correctly, you can use it for other cases too, just configure the oms state and event name. By default it use the payone default for our oms configuration

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    I think my first try was with CommandByOrderInterface but without success since it did not work as expected

  • U023LUXS8MR
    U023LUXS8MR Posts: 5 🧑🏻‍🚀 - Cadet
    Options

    Hi Alfred.

    One can work around the issue of per-item conditions by exploiting Propel’s feature of virtual columns. All items in an OMS execution belonging to the same order also share a reference to the same SpySalesOrder object. This means that you can perform the actual condition check when called for the first item of the respective order, store the check’s result in the associated SpySalesOrder object as a virtual column and then return this stored / cached result for all the other items of the same order.

    Note, however, that this virtual column may then also affect subsequent transitions and condition checks of that order, until the containing SpySalesOrder object is garbage collected.