2018-02-13
(1) search by product id ( report ZCRMS4_SEARCH_ORDER_PRODUCT_ID in QGP/504)
(2) search by sold to party id ( report ZCRMS4_SEARCH_ORDER_PARTY in QGP/504)
(3) search by sold to party name ( report ZCRMS4_SEARCH_ORDER_PARTY_NAME in QGP/504)
In product search scenario, the item CDS view is searched with inner join on header CDS view.
CRMS4_SERVHSRCH INNER JOIN CRMS4_SERVISRCH ON CRMS4_SERVISRCH~OBJECT_ID = CRMS4_SERVHSRCH~OBJECT_ID
See the sixth row below, since the product id is already available in item view, why we need to join it on header view here? Is it because we need to display some fields from header view in result list?
(1) Please still refer to above screenshot, see second row: object type for both header and item appear there. Why they are needed for OBJECT_TYPE?
(2) In Sold to party id search scenario, still the inner join on CRMS4D_PARTNER is used:
CRMS4_SERVHSRCH INNER JOIN CRMS4D_PARTNER ON CRMS4D_PARTNER~OBJECT_ID = CRMS4_SERVHSRCH~OBJECT_ID
Since Sold to Party ID is already available in header CDS view, why we still need to inner join on CRMS4D_PARTNER?
In Sold to party name scenario, the value specified by criteria SOLD_TO_PARTY_NAME will be converted to Partner ID by function module BUPA_SEARCH_2.
Then Partner ID is searched against field SOLD_TO_PARTY in header CDS view.
There is another approach to avoid the BUPA_SEARCH_2 call. I have built this approach in my prototype done last year:
define an association _partner to BP cds view I_BusinessPartner in my header view. There is no performance loss if we don't do any query against the fields in association.
how I dynamically generate where statement
Check this for example:
2018-04-10 Sync with Carsten
Current performance in QGP/504:
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
要获取更多Jerry的原创文章，请关注公众号"汪子熙":