ATG BCC: Link non version Repository to Product Catalog version Repository

Question

I am looking for solution to resolve below requirement

• In the Product Catalog, each product should have "Pre-order stock" custom property which holds integer value at each product level.

• On success full adding to cart that product decreases the count by one and only allows the user to add the product to cart until the value reaches zero.

• When we see the product in BCC it should show the latest count against that product.

I was thinking to have this custom property as part of the product catalog but as product catalog is version repository so its little complicate to update the value from code directly instead of updating from BCC.

Is it possible or good to have separate non-version repository to store "Pre-Order Stock" number and map repository to the product catalog and show the latest count in the product catalog advanced tab?

Thanks

Vivek Singh

Answer 1

Actually, updating versioned repository items from production instances is a very bad practice so in my opinion your proposal is the only possible solution I can imagine. You need a non-versioned persistent repository (let us call it InventoryRepository ) containing item descriptor (let us call it stockLevel ) which keeps track of the products stock.

However, there is a trap that stays behind this approach. In order to guarantee that the product's stock level is up to date, you have to disable caching on stockLevel item descriptor. This brings a risk that the data base will be overloaded with updates, which may lead to efficiency issues.

In one of my projects we worked that problem around by moving stock actualization functionality to another server instance (util) - triggered by asynchronous DMS calls (whose source was customer's action like putting item to the basket). Thanks to that, the production instances were only reading stock levels from InventoryRepository , not updating them.

That was a huge performance improvement but the production instances were still reading non-cached values very frequently. We observed that if the stock level for a particular device is very high, there is no need to check its exact value if only boolean information is required (available or not). So we introduced a cached item-descriptor which assigned a boolean property ( isHighlyAvailable ) to a product id. Until the stock level of a particular product was not reduced to a threshold value (say 100), isHighlyAvailable was set to true and production instances were relying on its value. Once the threshold was reached, the isHighlyAvailable was unset (by asynchronous DMS message), and from now on the exact, uncached stockLevel value was taken into consideration by production instances when evaluating product availability.