Developer forum

Forum » Ecommerce - Standard features » How NOT to process shipping methods

How NOT to process shipping methods

Nuno Aguiar
Nuno Aguiar
Reply

Hi,

 

We have a project where we have almost 15 different shipping methods. We cannot exclude them by countries, and only 2 don't calculate any fees, all others are poiting to FedEx and UPS (providers), each with different settings.

 

We only display up to 7 per user, which we need to exclude based on some user settings. That all works, but we have some performance issues:

  • We extended the shipping providers to have notifications so we could stop processing based on the project rules - which works fine
  • However Dynamicweb still requests all of them and it always takes some valuable ms before hitting the notification
  • Dynamicweb is processing all of the shipping providers even when we don't need/want to
    • It takes between 800ms to 1 sec for it to go through the 15 shipping methods and either discard or get the WS response
    • In our Step 1 of checkout, we don't have the shipping methods loop, but we still take the hit

https://www.screencast.com/t/lwTrprPcjYY

Any ideas how we can improve this?

 

I was also surprised to see that the shipping methods were being processed prior to having set addresses on the order. This means we were spending valuable time by even reaching out to providers just to get an expected error by the lack of data. Could we also set minimum requirements to trigger shipping methods within Dynamicweb?

 

We managed to optimize the "Shopping Cart" template (a different page just showing the contents of a cart) by removing all of the shipping methods from the paragraph app settings like this https://www.screencast.com/t/zySU7ymG but we can't do that in the Checkout page.

 

Best Regards,

Nuno Aguiar

Replies

 
Nuno Aguiar
Nuno Aguiar
Reply

Hi,

 

Is it safe to assume this is a bug and that DW should only trigger the shipping methods when the loop is in the template?

 

Best Regards,

Nuno Aguiar

 
Nicolai Pedersen
Nicolai Pedersen
Reply
This post has been marked as an answer

Hi Nuno

No, it is not a bug. Delivery fees are calculated based on country, and there is always a country - set on the user, on the website or the default country. This is to be able to show the default fee for the current country in i.e. the mini cart which is a requirement for most european webshops. The issue here is that you have a lot of delivery methods, all live calculated, which is not exactly a scenario we designed for. We are Scandinavians - less is more... :-).

But we can make some changes and new features to the system so you have better control and can achieve these things.

  1. You should get back to default shipping providers - then we can add a notification at another level in Ecommerce so you can skip a shipping method if needed. I.e. BeforeRenderShipping notification where you can set DoNotRender=True and DoNotCalculate=True. If DoNotRender is true, the method will be totally ignored, if DoNotCalculate is true it will still be rendered, but without a price. The notification args could hold the order, the shipping method and the loopitem template instance - in this way you can also add your own tags, i.e. shippingFeeNotice that will render a "From $10 specifiy address to get price" or whatever you need...
  2. We can introduce a loop exist on the Shippingmethods loop in checkout flow - then the loop and the fees will only get calculated if the loop is there. We will have to do it in a way that does not conflict with the default shipping fee requirement we have.
  3. We can add a feature to not render shipping methods before there is an address (Address, Zip, City, Country all has to have a value). Or better, not calculate the shipping fee before there is an address? Would you want to show the shipping methods, but not the fees, when entering the address?

BR Nicolai

Votes for this answer: 1
 
Nuno Aguiar
Nuno Aguiar
Reply

Hi Nicolai,

 

>> less is more.

Oh man... where do I sign up :) I agree but US, and in particular B2B businesses say more is never enough :P

 

I like your suggestions. Here's some thought about them:

  1. Notifications are always useful. This would give us some much needed control for some projects.
  2. This feels very natural to me (very "Dynamicwebish"). I like this approach and it very simple to explain to developers that they only "pay the performance cost" of what's being called. I understand the complexities around the default shipping fee though.
    The great thing about this is that we can have as many steps as needed, but completely control when shipping methods are triggered.
  3. At first glance this seems to make sense, but the "minimum required shipping fields" may different depending on country, provider or scenario. In Portugal a PO box is enough, otherwise we need all of the fields. If we can keep standard funcionality, but then have the ability (on the App's paragraph settings) to determine the minimum required shipping fields, that would be useful, and avoid triggering requests to providers that are going to fail.

 

Something else we see as well that could be usefull is some sort of caching. Maybe it's too complex to implement with the current Shopping Cart App architecture, but we feel the cart is recalculated too many times. Maybe on a next version have more granular validations to determine whether or not a cart should be recalculated. For example:

  • User refreshed the page - do we need to calculate the cart?
    If lastUpdatedOrderline timestamp and ordermodified timestamp and orderlineQuantity has't changed - why recalculate
    (we use this logic to get the mini cart from localStorage or ajax call for performance reasons in Rizzo)
     
  • If addresses and cart contents don't change - do we need to re-calculate shipping
  • If only address data changes (no country or region) - do we need to recalculate discounts
  • If only user name and email changes - do we need to recalculate taxes

 

Best Regards,

Nuno Aguiar

 

You must be logged in to post in the forum