Notes

BPM One To Many V.S Rest

從程式面角度：

OneToMany下 最先會想到的問題 :
我要如何決定要塞哪個值，這個值作完rest，我要怎麼知道這個是第幾列
1. 這時候就會想到，假設有多個input值，基本上就要多次 --> 從這個角度來看，「有多少種值就是call幾次」
2. 或是從另一個角度來看，有多個要接收的element，也是要call多次 -->從這個角度來看，畫了多少個element就要做多少次


1. 接收者(關聯outputparam)有多個
*問題點(類似前提)
(1) 接受的，或該說formitem (畫的)數量要能確認，但是一般來說，outputparam不是直接指向這些formitem，
而是formitem所關聯、用到的 fomitemattribute、dataitem等等。
即需要能透過 formitemattribute、dataitem 和 formitem 的 attrkey 作關聯
a. formitemattribute 需先藉此抓出 formitem --> formitem 有了，問題點變成要怎麼跟attrkey作關聯? 或要有其他手段「知道此formitem畫了幾次」(主要的重點)
b. dataitem --> dataitem 要抓 formitem 不是做不到，但很機車。因為dataitem對於formitem是一對多，
所以要想辦法找出是在該form底下用到dataitem的狀況，可能有2方法
i. 每次在找一次DB....這大概會死掉
ii. 在做DomTreeMap時應該會有類似的副產物.......，這個是程式方面會有負擔加重。





優點

a. 接收者的數量是比較確保的，也不會因為有沒有SYNC等各種操作狀況而有隨便的改變(?)。

缺點

a. 優點a也導致缺點，因為確保，相對的，假設其實webservice結果會一樣(一般來說代表 input 一樣)，這樣可能會多做幾次同樣的事。





v.s



二. 送出來源(關聯inputparam)有多個

問題點

a. inputparam並非只關連到 dataitem，dataitem的值是從 data 的 cache 資料抓出，這已有實作，並且可應付one to many。

問題點在於其他值 「是否需考慮到類似one to many 這種，值很多的情況」



i.

多種值有兩階段狀況，

一個是因為one to many ，本來就多列了，

但是多列不代表值都是不一樣的

-->本來就一定要有個東西來分析「實際上有幾種值」，

並記錄分別的orderindex ? (因為row1 可能與row3 都為A)





但這樣做在要組合時又會死掉，舉例如下:



dataitemId 當作key，值的list ?

{

"2037" : {

"1" : "apple",

"2" : "orange",

"3" : "apple"

},

"2094" : {

"1" : "water",

"2" : "grass",

"3" : "grass"

}

}



假設現在有webservice ，其inputparam 牽扯到 datitem 2037 和 dataitem 2094 。

假設是按照 orderindex 對應



即

1. apple + water

2. orange + grass

3. apple + grass

-->此種狀況就無法縮減call rest 次數







dataListMappedByDataitemidMap > 以找 50372 為例，他其實只有兩種值， "123" 和 "321"，"123"可給orderindex "1"和"2"



假設同一webservice 遇到多個 inputparam來源皆one to many 狀況?







優點:

a. 可能可以想辦法判斷有多少種input，在input值相同時，避免掉call webservice 上次數的浪費





缺點:

a. 假設沒有值時，是否真的不用做webservice是個疑慮點。換個說法也可以說， dataListMappedByDataitemidMap 裡的數量，

其實是不一定完全等於 one to many 底下的數量的