Attachment 的metadata里定义的data type和runtime时的data type不一样

Metadata里是这个structure：

Runtime变成了这个：

这些BPID和file_size 是runtime 生成的？这个structure里header_guid也没了。

Attachment和其他四个节点不太一样。

当用新的service url访问时，https://lag3:44354/sap/opu/odata/sap/CRM_ODATA/TaskCollection

动态生成的structure是BP 定义的common structure，如下：

用老的service url：https://ldag3:44354/sap/opu/odata/sap/CRM_TASK/Tasks?$filter

则动态生成的structure是我们task自己的attachment structure。

优化后的代码需要能够同时handle 这两种情况。有两种办法。

方法1：如果line 15 ASSIGN失败，说明当前的internal table类型是BP定义的。

其实就是通过line 17设置的标志位，如果是BP的structure，就用BP的field symbol接，否则用task 的field symbol接。

这种方法好处是速度比较快，因为只有1处泛型处理。缺点是在代码里出现了BP的structure crmt_bp_odata_attachment_t.

方法2：这种办法从直接上能发现不需要引入对BP structure的依赖，代码里只需要我们自己的attachment structure。

a. 在line 10~11 动态assign一个field symbol

b. 其目的是line 23用来接真实的attachment数据，然后line 24写回到result container里去。

注意这里line 24的两个field symbol都是完全generic的，而且赋值在LOOP里完成，所以方法2的泛型处理次数为 1 + task个数。

所有高级语言的guideline都说尽量避免泛型处理，除非没其他办法。那这两种办法性能有多少差异？因为Zclass里attachment 都是hard code的，所以比较的性能差异其实就是泛型处理的overhead。

当处理10个task时，相差300微秒

100个task：方法1就比方法2快1倍了

500个task：

1000个task：

1万个task：

这时差距就甩开了，方法2所有操作都是在memory里做的，居然也消耗了0.2秒。