如果call CRM_ORDER_MAINTAIN的時候傳一個change mode = U – update，但是text content = ‘’進去能不能成功執行?

目前webclient ui上text area清空後傳的是 change mode 的值為 D。

測試：

刪除之前有兩個text entry，然後我點下面Header text的edit icon進去：

把下面文字全部清空，

點back button：

此時傳到CRM_ORDER_MAINTAIN裡的mode是D-delete：

執行後UI上看不到Header text了：

用ST05也能看到delete的operation：

結果是，如果我用CRM_ORDER_MAINTAIN update text，mode設成B ( update ), 但是傳入的to be updated的text ( 放在LINES )裡的內容是initial的：

line 41檢測到這種情況，會將text api內部的一個標示change mode的欄位”function”設定成delete, 最終導致 DELETE_TEXT的呼叫。

也就是說我們想傳一個空的string到CRM_ORDER_MAINTAIN，讓這個空的string overwrite之前已經存在的text instance的這種想法現在看來走不通。

總結

• 如果是log type的text，每次call CRM_ORDER_MAINTAIN時總是creation mode

• 如果是edit type的text, 使用者輸入了一個非空的text：

(1)先讀取對於UI傳入的text object, 是否存在對應的text instance：

對於edit type的text而言， text guid，text object name ( 如上圖0004 ) , text language
這三者唯一確定一個text instance。Text guid本身並不能確定一個edit text instance，因為所有edit text instance的text guid都等於其屬於的opportunity guid。

Text API的輸入引數不包含text change type ( P,R, ‘’ )等，只是text object和change type是1:1關係，能很容易根據text object從customizing裡讀取到其change type。

(2) 如果對應的instance已經存在，change mode = B – Update，否則為A - create

如果是edit type的text，使用者輸入了一個空的text：
還是從DB裡先讀取對應的text instance，如果不存在，什麼也不做。

• 如果存在- change mode傳B ( update ) 和 D ( delete ) 似乎都可以，因為兩者最後都會trigger text deletion，只是傳D的話，semantic上更清晰。

更多Jerry的原創文章，盡在："汪子熙":