cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Indexing Server should skip duplicated entries during processing to avoid waiste of resources

Indexing Server should skip duplicated entries during processing to avoid waiste of resources

*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
e.g

Name Setting
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
1 Comment
Marble

DELETE FROM QUEUEENTRY qe

        where qe.ida3a5 in (select ida2a2 from ProcessingQueue where name like 'IndexQueue%')

        and qe.IDA2A2 NOT IN

        (

            select MAX(qeu.IDA2A2)

            FROM QUEUEENTRY qeu

            JOIN ProcessingQueue pqo on pqo.IDA2A2 = qeu.IDA3A5

            WHERE pqo.NAME like 'IndexQueue%'

            AND qeu.CODEC5 = 'READY'

            GROUP BY qeu.TARGETMETHOD, qeu.ARGS

        );