*ALL* persistence and workinginprogress events will trigger a reindex job
- Namely, any updates of business object will trigger Index entry, even if no indexing happens, it needs to modify the IndexStatus > column ModifyStampA2 to current date.
- when performing Bulk Index OR check Index Status, the logic behind is collecting the objects with object's modifyStampA2 > indexStatus's modifyStampA2.
This update event logic can lead to multiple READY indexing jobs for the same object ID and can be caused by
1. user interaction like move, share, update master attributes
2. customizations which update the object after check in or during create
Material Class setting
New Vendor Part added to AVL
Interface ODATA Proxy ID
3. on changes where summary reports get generated on object basis or release baselines created
To avoid the useless execution of earlier index jobs except the latest the earlier jobs should be purged prior execution. There should be always only one READY entry per OID.
This improves throughput and reduces carbon footprint caused by waisted CPU power