Developer forum

Hi Imar,

it looks like the Live integration is a bit old, can you try to update to more recent 7.4.*?
That can happen once the country is not found, it is missed for the  finding the Stock level, so it takes first found country for the VatCountryCode attribute.
Can you also try to check if removing/commenting out the Stock tags helps? (If the issue will occur after the Live integration update)
BR, Dmitrij

I see. Will upgrade and test out the stock changes if needed, and then report back here.

Cheers,

Imar

I upgraded the DLL to the latest and still see the same. Which stock tags to disable are you talking about specifically?

Hi Imar,

If its a template then those tags are triggering StockLevelProvider:
Ecom:Product.Stock
Ecom:Product.AvailableAmount
"VariantCombinations" loop

If it is a WebApi the those properties:
StockLevel
StockStatus
StockDeliveryText
StockDeliveryValue

What is your solution url? ​
BR, Dmitrij

Hi Imar,
there is a new version for the Live integration released: https://www.nuget.org/packages/Dynamicweb.Ecommerce.DynamicwebLiveIntegration/7.4.8
It will use the default currency in the first request which always come from the StockLevelProvider.

The current StockLevelProvider api in DW9 does not provide any other ability to determine the current Currency
So the requests run in this order:
For the Page with product list the first request is oftern made for the first product with StockProvider as a trigger to get its stock (and also a price)
second request is made for the all products that are on the page from the PriceManager.PreparePrices method, next StockProvider calls will use the cached values.
For the one product list there always will be 2 requests

For the one product details page: 1 request if default currency matches the frontend currency, otherwise 2 requests - first for Stock, second for Price (with correct frontend currency)

Now with the new version 7.4.8 if the default currency is the same as your current frontend currency there will be one request for the specific one product details (if you are browsing one product detail page), previously the first request which always comes from the StockLevelProvider was with empty CurrencyCode in the request xml, so that is why the second request was made because it can not determing in which currency the first request was.

BR, Dmitrij

Something changed with that update but I am not sure if it's better. I now see 50 requests on a page with 50 products, like the following:

<GetEcomData ExternalUserId="202040" AccessUserCustomerNumber="202040" VatCountryCode="DK" VatPostingGroup="">
  <tables>
    <Products type="filter">
      <Product>
        <ProductId>16051259</ProductId>
        <ProductVariantId></ProductVariantId>
        <ProductNumber>16051259</ProductNumber>
        <ProductUnitId>Unit_EA</ProductUnitId>
        <ProductIdentifier>16051259..EN</ProductIdentifier>
        <CurrencyCode>GBP</CurrencyCode>
        <Quantity>1</Quantity>
      </Product>
    </Products>
  </tables>
</GetEcomData>

That's similar to how it was, but now without the one big request with all 50 products. So we went from N+1 to N.

Making so many individual requests is going to kill performance. Can't we change this so it makes a single call for all products on the current page and combines the stock and price lookup in a single request?

Imar

It combines that, but it needs to call the PriceManager.PreparePrices. So if you don't have any Price tags then the Price manager is not called, so that is why only the StockManager is called causing so much amount of requests. Can you check if you have any Price tags?
Also you add "&debug=true" to the request page and that will give you more details on what subscribers are called and in what order from the LiveIntegration.
BR, Dmitrij

I do have prices on the page; it's a standard Swift product list page. When I log in as a user and browse a catalog page, debug=true first shows me this:

This gets repeated 50 times. This also contains the (incorrect?) VAT code: VatCountryCode="DK" 

Then after those 50 calls, I get this, again repeated 50 times:

So it seems there's some kind of ordering issue: the stock provider kicks in first and makes 50 calls. The request also contains the price which then (so it seems) is used by the price provider.

What I would like to see is a single request for all 50 products, returning stock and price info.

More info:

1. Latest LI: 7.4.8.0
2. DW 9.16.2
3. The user is logged in
4. We don't have anonymous prices checked in the LI settings
5. The templates have price tags (that is, they output prices which should come from a tag or ViewModel somehow).

Shall I send you the URL to the site and some account info to log in with?

Thanks for your continued support!

Hi Imar,
after checking - indeed it is a bug, will be fixed in this PR.
BR, Dmitrij

>> It combines that, but it needs to call the PriceManager.PreparePrices. So if you don't have any Price tags then the Price manager is not called,

Do you know where in the DW source code this is being checked? I have a site where I like to disable live prices on list pages, but it keeps running. Trying to find out which tag(s) are causing the lookup.

Thanks!

Imar

Hi Imar,

it depends from where it can be called. But you can try to use the &debug=true to see the logs from where it is triggered.
Those are the places from where it is called:

Dynamicweb\src\77 - Ecommerce\Dynamicweb.Ecommerce\ProductCatalog\ViewEngine.cs
method: BulkCreateView, see where the lines have the "ref pricesHasBeenPrepared" used

(probably for just old templates like Rapido):

Git\Dynamicweb\src\77 - Ecommerce\Dynamicweb.Ecommerce\Frontend\Frontend.cs
method: ListProducts

BR, Dmitrij

Hi Dmitrij,

I am continuing work on this site and now run into some other issues. We upgraded to the 9.18 and LI 7.4.10 which should give us the latest of everything.

Now when I navigate the site I see this:

1. On a product list page, prices are looked up using LI which is good.
2. On a product details page, the price is looked up using LI which is good.
3. When I add a product to the cart, NO call is made for CalculateOrder which is NOT good.
4. When I go to the first cart page, NO call is made for CalculateOrder which is NOT good.
5. When I navigate through the pages of the cart, at some point the CalculateOrder is made and I get the correct prices (with a discount)
6. When I navigate backwards, sometimes the prices with discounts stay, sometimes they reset as if there's no LI call.

Am I missing a setting somewhere? We have full cart communication, live prices and cache at the page level.

Happy to send you a URL and a more detailed description if you think that helps.

Imar
 

Hi Imar,
yes, I can take a look, so you can send me the details on email.
BR, Dmitrij

Wow, just wow! Thank you very much. I never looked at this, thinking that the site settings drive the Live Integration. Also, since it jumped around a bit when navigating, I figured it was cache or so.

I’ll carry on testing!

Thanks!!

Imar