如何分析Fiori UI上創(chuàng)建的note和web client UI上note的對應(yīng)關(guān)系

今天就跟大家聊聊有關(guān)如何分析Fiori UI上創(chuàng)建的note和web client UI上note的對應(yīng)關(guān)系，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

SAP CRM Fiori應(yīng)用的note creation，后臺實現(xiàn)的原理比較簡單. GM6上創(chuàng)建一個note：

HTTP post的request payload里就只有opp guid和user輸入的note

后臺返回的response也只有這兩個attribute：

最后到webclient UI上卻發(fā)現(xiàn)兩條只讀的text，類型為Description和Preparation

后臺實現(xiàn):

直接用OPEN SQL 找當前創(chuàng)建的opportunity的transaction type對應(yīng)的text determination 信息。

Opportunity 對應(yīng)的text object type hardcode成CRM_ORDERH，changeable的屬性也寫死成P，因此當前的實現(xiàn)，通過Fiori UI創(chuàng)建出來的note 類型都為log （ changeable = P )

最后Opportunity OData的實現(xiàn)并沒有call 底層的text API，而是直接call One order的modification FM，

只需要把text determination ID和待創(chuàng)建的note content和language傳入 modify FM：

在webclient UI上看到兩個不同text type的note的原因是因為backend system 配置里，指定類型為P的text的content會自動transfer到 changes = R的text里，即Description和Preparation。

看完上述內(nèi)容，你們對如何分析Fiori UI上創(chuàng)建的note和web client UI上note的對應(yīng)關(guān)系有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。