由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实现的。