The detail page keeps loading forever is because the response of this odata request never returns:

https://sap04277.zeiss.org:12016/sap/opu/odata/sap/CRM_APPOINTMENT_SRV/AppointmentSet(guid’55AC7BAD-0643-29B0-E100-80000AA70246’)?$expand=Attendee%2CAccountRel%2FLogo%2CDocumentHistory%2CAppointmentLogSet%2CAppointmentToAttachment&sap-client=010

Then I debug the implementation of this odata request. The call is finally delegated to 1order FM: CRM_BSP_OIC_1O_SEARCH_FROM_RF. This API returns totally 14513 entries for a single guid search ( !? ).

Right after that, these 14513 guids are passed to read API below to try to read all details data, and this never ends, simply because lots of data are to be read.

So the question is: why there are 14513 entries returned, instead of 1 as expected, since here I use guid as search criteria?

I debug a little bit further, you see in 1order framework code, after the very appointment is found via OPEN SQL, also the interaction objects are fetched as well:

The below screenshot demonstrates the dynamic OPEN SQL which fetches additional FOUR Interaction objects in AG3/001:

CRMD_IM_ML_ITEM~CHANNEL IN (‘03’, ‘04’, ‘05’, ‘06’, ‘08’, ‘10’) AND
CRMD_IM_ML_ITEM~ADD_PARTNER_GUID = ‘00163EA720041ED29BD49E5FAD477D37’ ---- this is my responsible employee ID 4031140 in AG3.

In AG3, finally five results are returned, only the first one represents the very appointment, all the other four records are interaction objects belonging to my user ( this could be identified by object_type: BUS20004 – interaction object )

And those interaction objects are removed from the result set in line 116.

This customizing controls the behavior whether interaction object is considered in one order application. I have tested in our internal system: once I un-select the check box for the highlighted entry below, the interaction object would be excluded from one order search as expected.

What I am unsure is whether this interaction object is required in customer business. Would you please kindly test with customer guy in their test system about this checkbox?

Sent: Wednesday, 22 July, 2015 2:10 PM

I found the root cause. My finding yesterday is still correct. In a word, the one order search via guid consists of the following two processes:

Populate the dynamic open SQL to search the host transaction via the passed guid.

Search other interaction objects ( optional, controlled by switch )

And you said customer didn’t switch on settings for process 2, this is ok. So let’s focus on process 1.

In AG3, the single appointment is searched by guid as expected, thanks to the FOR ALL ENTRIES below.

However, in customer system, the FAE is not executed at all. I debugged and find the logic in one order framework:

If there is sort operation passed to one order framework, then the method containing FOR ALL ENTRIES is never executed – it is wrapped in an IF evaluation.

In AG3, the sort option is initial, so FOR ALL ENTRIES is executed as expected.

However, in customer system, there is sort operation maintained by the table SMOFPARSFA, see highlighted entry below:

I just checked in our internal system AG3, QHD and QDD, there is no such entry maintained. So please kindly ask Zeiss to remove the entry and retest.

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的One order search by guid uuid的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。