由Ben微信朋友圈的這本書
想到去年1月份做過的一個優化：
https://blogs.sap.com/2017/02/10/use-abap-multi-thread-programming-to-deal-with-a-real-performance-issue/上下文
Subject: 2016-01-27 task優化 - 中午吃飯時想到一個問題
到目前為止優化的思路都太窄了，僅僅是傳統的避免在LOOP裡做費時的操作。
之前用Java8的parallelStream也寫過一些代碼，task offline 5個node的讀取滿足并行計算的三要素：
可重入
Immutable state
Read only data access
是以可以把每個node 資料的讀取分别放到一個新線程來做，這樣就和gateway 背景實作batch操作的設計完全一緻了。之前研究過gateway的代碼，他們在SPRO裡有個配置控制batch request是串行還是并行實作，預設是并行。
等我把目前這個版本弄穩定再說吧，改成并發讀取之後，現在CL_CRM_ODATA_INITIAL_LOADER裡絕大多數代碼可以重用，但是GET_EXPANDED_ENTITYSET就要完全重寫了，需要在裡面加上線程spawn和線程同步的代碼。
假設5個node 分别消耗的時間是1,2,3,4,5秒. 現在的實作，最後的時間是sum(1,2,3,4,5) = 15秒，改成并發後是max(1,2,3,4,5) 約等于5秒(加上少許線程同步的時間)。 這性能可以完爆BP了。
五種基本RFC調用類型對比
EO=Exactly Once（執行一次）
EOIO=Exactly Once In Order（按順序執行一次）
我blog的題目取為multi-THREAD是為了吸引眼球增加點選率，因為Java裡我們從來不會說多程序程式設計，隻會說多線程程式設計，而且我的blog編輯器裡不支援title裡包含引号，是以我當時偷了個懶。
現在我加上去了。
SAP每台應用伺服器的程序是有限的（BASIS配置的）
類似你的concern早已有一位SCNer提出了：
這是我的回複:
提問的Spencer是大連Global Service Center SD & CRM support的同僚，我2015年做My Opportunity的時候，從他的一篇blog裡學到了很多。
BYD的output management，就是現在Mint team做的類似的東西。點了Send to Biders之後，
會觸發背景一個output操作，把document用ADS render成PDF，然後通過配置好的output channel發送到destination。這個發送動作用bfRFC實作的。