In the current blog I have not planned to share the basics of listing in general, I rather would like to point out to a couple of frequently misunderstood methods, that are more and more often used by our customers.
The topics covered will be the
Top 2: missing entries (MARC, MBEW, MVKE) and
locking.
Missing entries
Usually the pain point is not the missing listing condition itself (WLK1), if that is missing, this is usually due to some basic customizing. Normally, it’s the necessary article segments (MARC, MBEW, MVKE) that are missing, so I will detail this part.
First of all, it is important to clarify at the beginning that article segment creation is not triggered by all means when executing any of the listing transactions.
The most painful part of the listing from performance point of view is the generation of article master segments. Actually, in case of working with long-existing articles, we do not want to take care of them, as these articles were already in use earlier as well, so it would be a pure waste of resources to check the existence of all article segments each time.
Therefore, the listing process was designed to check (and trigger the creation of) the necessary article segments only when performing the listing of an article and site (assortment user) combination for the very first time. This is the so-called initial listing. The determine whether the listing is initial, it is simply checked whether any WLK1 entry for article and site exists (even if expired).
If there is any – maybe already expired – listing condition for this combination, the article segment creation will be not triggered, hence it is apparently expected to already have them.
The two cases of missing article segment (was an initial listing or not) must be handled separately:
Initial listing:
If the user has executed the listing transaction for a higher amount of article/site combinations, it might be confusing, that even after the listing transaction itself has finished (message about successful listing is also displayed in the status bar), the article segment generation part is still in process. Namely, while the WLK1 entries can be generated pretty quickly, and appear in the DB table almost immediately, the creation of MARC, MBEW, MVKE etc. entries is a more time consuming process, which is probably still running in the background as update task. So, please be patient, the bigger part of the processing time is still left.
An application log is created whenever an article segment failed to be generated. Transaction WSPL is a short cut to this application log, where the reasons can be easily collected. The usual issues are almost always locks (see also next chapter), therefore in a production usage it is not necessary to check this log manually each time. It is however recommended to run transaction WSPK on daily basis with the logs since the last run. This transaction has been designed to trigger automatically the article segment generation of log entries in WSPL. Ergo, this is limiting the system load and manual efforts, because it deals only with the relevant articles.
While performing tests in a quality or test system, it might make sense to check WSPL transaction also to discover failures in time due to missing mandatory fields, for example.
Non-initial listing:
It has to be clear, that starting the listing transaction again and again will never create the missing article segment(s) anymore. If the initial listing was long time ago, we will not have any clue, why they are missing, the only task is to produce them retroactively.
For such situation SAP has released the RWDIFFERENCEMARCWLK1_ENHANCED report, which is available in standard from ECC 6.0 already, and still valid for S/4 releases. This report is a great tool to complete this activity with parallelization and test mode option as well.
BUT unfortunately, more and more customers tend to use this report as part of daily process, which is absolutely not desired, see the chapter for performance issues of listing.
Locking concept in Listing
Without starting to tell about obvious reasons why locks are necessary, I would rather point out, what type and kind of locks should we expect when performing listing, and how to avoid locking conflicts.
Not surprisingly locks might appear for all those tables, that are going to be updated/inserted (eg. WLK1, MARC, MBEW, MVKE) but locks must be placed also on MARA, in order to ensure the consistency between the to-be-created entries and those which do already exist in the DB.
The locks are ‘Exclusive’ and must ensure the client wide lock on the processed article. This important clause means the issue most of the time for the users, certainly.
Basically, no activity can be performed with the article in scope until the specific lock object is getting dequeued.
Fundamentally, we can say the initial listing process – that is probably one of the most performance intensive processes in Retail – should be always scheduled outside of business hours. This is the first step to avoid locking issues during listing.
A further essential step to avoid locking conflicts is to use parallelization, and the correct setup of the packages. Why?
In mass listing – besides the parallelization – the package size plays an important role, especially from the locking perspective. Namely the number of locked articles at the same time is controlled by this package size, but certainly it is also influencing the performance of the whole listing job finally.
So, the smaller the package size, the smaller the number of locked articles at once. Of course, it also does not make much sense to decrease the package size to an extremely low value due to variants of generic articles, for example. It is also recommended to leave at least 15 minutes between starting jobs to reduce the chance of locking conflicts.
The general recommendation is to set the package size to 1000-5000 of articles/site combinations.
In practice: if you want to list articles to a global assortment having assigned to 50 sites, then 20-100 articles mean the optimal amount. But if you list only single articles, a package size of 1 with 50 processes might provide even much better results.
Key takeaways
I tried to clarify few elementary concept and terminology of Retail Listing by current post, enabling you to understand the intended everyday usage.
After reading this post I hope you will have a better understanding on how to avoid locking issues during listing jobs and what circumstances should be considered when setting up parallelization.
Probably you will have never doubt anymore when to use RWDIFFERENCEMARCWLK1_ENHANCED report, and when it does not make sense. Hopefully you will benefit from understanding the difference of an initial and not-initial listing, and there won't be anymore inexplicably missing article segment.
Last but not at least, in case you would be happy to read any further topic related to Retail Listing, let's hear your voice, and I will work out the most popular request(s) in my next blog post.
