Developer forum

Forum » Feature requests » More granular tracing in Checkout flow

More granular tracing in Checkout flow

Nuno Aguiar Dynamicweb Employee
Nuno Aguiar
Reply

Hi,

 

TL;DR;

We'd like to have more granular tracing in the Checkout flow, by explaining which methods DW runs and in which order.

 

Summary

By adding debug=true we can get a glimpse of what's going on, particularly when some DB calls are being triggered. However a lot of the events have no context and we can't tell what's going on. It becomes a challenge to understand what's actually causing the delay:

  • Amount of user addresses
  • Amount of Shipping Providers
  • A specific shipping providers
  • Address validation
  • Discounts

 

It would be nice to have a better understanding or tracing of the stack. Currently we can "remove all custom code and deactivate providers and discounts and start adding them one by one". This becomes very time consuming and imprecise.

 

Examples

The following screendumps were all taken from a single rendering. We can't tell what happens, making it very difficult to fix whatever that might be (users, orders, orderline fields, addresses,...)

 

The checkout flow is one of the most intensive processes because it takes multiple types of data (user, order, product, providers, discounts, taxes, validation,...). On top of all of that, we have the need to customize some of that. Having insight will allow us to understand what needs attention.

 

Acceptance criteria

By using debug=true, be able to get a clearer picture of what Dynamicweb is requesting and by which order; which shipping method is called first, second, (..) and last, when are addresses requested and so on. By exposing that information more clearly, it will enlighten us where problems might be coming from.

Since intensive logging/tracing have a performance cost, I believe it would be accetable to have a flag to enable/disable it. It could be the existing GlobalSetting flag or a new one, as long as it's explicit that having it ON (even when not used) would cause a performance hit from the granular reporting (some other CMS behave in a similar matter).

 

Best Regards,

Nuno Aguiar


Replies