外部系统接口稽核经验谈

新业务流程系统上线接入到集团云门户系统。按设计要求通过了单点登录和待办/待阅任务推送功能。

但是，在接口稽核时，云门户运维人员天天反馈稽核问题，虽然这些不影响单点登录和待办任务处理功能，但是涉及到用户维护考核，开发人员一直未找到原因，很是闹心！

我翻出云门户接口及稽核开发接口规范，经过多次实验及解读，终于理解了！

如上图中的文字“则必须填写调用云门户服务的字段，才能保证能够对数据进行稽核”。

稽核出现问题的关键是稽核日志视图中的每个字段要与推送到云门户上的每个字段内容保持一致。

下图为新业务流程系统推送待办到云门户的日志截图：

下面列举出开发人员的代码与我的修改对照，分析其中的“坑”。

原开发人员的设计：

-- 待办稽核原视图create or replace view bop_pdt.vw_pengding_task as
select t.task_instance_id as pendingcode,t.bo_title as pendingtitle,to_char(t.create_datetime, 'yyyyMMddHHmmss') as pendingDate,t.task_receiver_id as pendingUserID,t.task_receiver as pendingUser,'unicom/workflow/workflow_wrapper.htm?bizInfoInstanceID='||t.biz_instanceid||'&'||'taskID='||t.task_instance_id as pendingurl,t.status as pendingstatus,'0' as pendingLevel,'hl' as pendingCityCode,t.task_sender_id as pendingsourceuserid,t.task_sender as pendingsource,'a' as operatorType,sysdate as createTime,'hl006' as pendingNotefrom pnd_task t;

修改完善的代码

-- 修改完善的视图
create or replace view bop_pdt.vw_pengding_task as
select t.task_instance_id as pendingcode,t.bo_title as pendingtitle,to_char(t.create_datetime + interval '8' hour ,'yyyymmddHH24MIss') as pendingDate,t.task_receiver_id as pendingUserID,t.task_receiver as pendingUser,'http://10.64.50.143/unicom/system/unicom/home/sso_ucloud.htm?userId='||t.task_receiver_id||'&'||'bizInstId='||t.biz_instanceid||'&'||'taskId='||t.task_instance_id||
'&'||'isTask=1'||'&'||'isComplete=0'||'&'||'isProcess=1'||'&'||'orgId='||
substr(t.tenant_dn,3,instr(t.tenant_dn,',')-3) as pendingurl,t.status as pendingstatus,'0' as pendingLevel,'hl' as pendingCityCode,t.task_sender_id as pendingsourceuserid,t.task_sender as pendingsource,'a' as operatorType,'hl006' as pendingNote,t.create_datetime +  interval '8' hour  as createTimefrom pnd_task t;

上述代码差异说明：

pendingurl：此字段的URL拼接出现问题了；
pendingDate：时间表述中的多个问题。

1. 对接口规范理解的想当然，唯技术本位思考

由于pendingurl字段是专业系统自用的参数，而且在本系统中是没有实际使用意义的数据，开发人员从本位思考，想当然认为传个参数就行了。

对于稽核的理解，开发人员也从本位的技术思考理解，认为稽核要稽核关键接口数据，例如ID、用户账号等内容，其他数据无所谓。

2. 对时区及时间处理的易忽视的情况

由于使用的系统平台Cordys产品是国外产品，时间是标准时间，与北京时间差8个时区，也就是少8个小时。

Oracle时间转换字符时，分钟与月份的混淆，如上述原代码想用mm表述分钟，但是SQL中不区分大小写，MM和mm被认为是相同的格式代码，被转换成月份。

所以，正确的表达是要不足8个小时，并正确的转换出分钟字符串，如下所示：

to_char(t.create_datetime + interval '8' hour ,'yyyymmddHH24MIss')

3. 类型转换成字符出现的小数位问题

下面对照待阅稽核视图的差异，上述1、2条已经说过，再请看本段的重点所说数据类型转换所易出现的问题。

原开发人员的设计：

--原待阅稽核视图
create or replace view bop_pdt.vw_pengding_reading as
select t.pnd_reading_id as readingCode,t.bo_title as readingTitle,to_char(t.create_datetime, 'yyyyMMddHHmmss') as readingDate,t.task_receiver_id as readingUserID,t.task_receiver as readingUser,'unicom/workflow/workflow_wrapper_reading.htm?bizInfoInstanceID='||t.biz_instanceid||'&'||'pndReadingID='||t.pnd_reading_id as readingURL,t.status as readingStatus,t.task_sender_id as readingSourceUserID,t.task_sender as readingSource,'hl' as readingCityCode,'a' as operatorType,sysdate as createTime,'hl006' as readingNotefrom pnd_reading t;

修改完善的代码

--更正后的视图
create or replace view bop_pdt.vw_pengding_reading as
select t.pnd_reading_id as readingCode,t.bo_title as readingTitle,to_char(t.create_datetime + interval '8' hour ,'yyyymmddHH24MIss') as readingDate,t.task_receiver_id as readingUserID,t.task_receiver as readingUser,'http://10.64.50.143/unicom/system/unicom/home/sso_ucloud.htm?userId='||t.task_receiver_id||'&'||
'bizInstId='||t.biz_instanceid||'&'||'taskId='||t.pnd_reading_id||
'&'||'isTask=0'||'&'||'isComplete=0'||'&'||'isProcess='||t.type||'.0'||
'&'||'orgId='||substr(t.tenant_dn,3,instr(t.tenant_dn,',')-3) as readingURL,t.status as readingStatus,t.task_sender_id as readingSourceUserID,t.task_sender as readingSource,'hl' as readingCityCode,'a' as operatorType,'hl006' as readingNote,t.create_datetime  +  interval '8' hour as createTimefrom pnd_reading t;

上述代码差异说明：

type，原数据库中此类型为int，在类型转换为字符串时，Cordys系统将其“1”转换为“1.0”，而SQL语句直接为“1”，所以，需要补足差异而增加代码“’.0’”。

但愿本次完善是找到结症，后续再请开发人员把推送内容原封不动的记录到数据库中，避免这种拼接SQL语句的、非正规的方法。

另外，也整理了几条其他需要注意事项：

集群环境中，注意每台主机配置的准确并且对外连接一致，而且要逐台设备测试，例如解析域名的配置；
系统参数配置要每台设备要一致，例如服务器地址、云门户接口设置；
客户端兼容性检测与验证，例如IE浏览器的兼容性。