首先大家都知道关于SAP的长文本从表里是不能直接获取到的,它是以binary形式存放于STXL表中,之前我们获取长文本都是通过LOOP中嵌套READ_TEXT函数来进行长文本的获取,这并不是一个高效的解决方案,因为每次都会操作数据库读取,所以我试图寻找其他的替代方案,在查阅资料后,发现以下两种解决方案,为了明显的比较这几种方式的区别,写了一个demo程序,通过SAT性能检测工具来进行对比,几种方式实现如下.
1.首先获取到测试所用订单数据↓
2. 使用三种方式来分别获取每条订单对应的长文本
3.传统READ_TEXT的方式
4.使用IMPORT FROM INTERNAL TABLE的方式
5.使用READ_TEXT_TABLE功能实现(READ_MULTIPLE_TEXTS也有同样的效果)
6.另外关于TLINE的读取也有系统已经封装好的函数来进行转换,可按需使用
通过多次运行SAT进行性能测试(只截取了两张图来说明问题),可以发现IMPORT的方式完全碾压LOOP中套用READ_TEXT的方式,大约提升约10倍性能,其次为READ_TEXT_TABLE的方式,也大约比嵌套READ_TEXT的方式快了约6倍,所以以后对于长文本的获取可以采用新的方式。
发现了新的方法后,我在想既然可以IMPORT将binary形式数据转为可读数据,那反向是否可以实现根据长文本精准反向查找对应订单,很遗憾,SAP不支持在where condition中使用LRAW类型的字段,不管是在ABAP SQL,还是EXEC SQL,或者在CDS,AMDP中均无法通过标准check,CDS也不支持将LRAW类型通过CAST转换为String或者其他类型,所以如果有这种需求目前只能通过先将所有STXL数据查询出来,通过IMPORT FROM INTERNAL TABLE的方式解析完再进行匹配,能提前限制范围最好,也算是曲线救国吧,效率也算是可以接受的。
CDS以及AMDP中也是同样类似的报错。
另外,在CDS中其实是可以实现查询长文本的功能,借助Virtual Elements可以实现该效果,但很遗憾的是它只能应用于ODATA服务,在SE16N或者程序中调用该CDS,不会得到任何结果
实现方式如下:
1.创建虚拟字段,并为其添加如下注释
@ObjectModel.readOnly: true
@ObjectModel.virtualElement: true
@ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_DEMO_CDS_TEST'
2.其次在SE24创建自定义类,并实现接口IF_SADL_EXIT_CALC_ELEMENT_READ
3.实现接口中的两个方法
其中GET_CALCULATION_INFO方法只是提供处理所需的字段列表,不需要添加额外代码,但是依旧需要点进去激活,CALCULATE方法实现如下:
所有coding部分结束,进行服务测试,下图可见成功取得长文本
/sap/opu/odata/sap/ZLONG_TEXT_CDS/ZLONG_TEXT(tdobject='VBBK',tdname='2000011414',tdid='Z101',tdspras='J')
以上,在UI5或者FIORI面板中可以正常展示,利用其他注解可以实现将虚拟字段添加为筛选字段或者排序字段
@ObjectModel.filter annotation 实现添加为筛选字段
@ObjectModel.sort annotation 实现添加为排序字段
具体实现方式参考官方地址:https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.51.7/en-US/a7fc007921d44263b09ccc092392b05f.html