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秒。
