很多人聊信创适配,关注点大多集中在芯片、操作系统、数据库这些底层硬件软件。但在真实项目实施阶段,上层业务系统和CTI中间件的API对接改造,才是消耗项目最多人力、时间的环节。
不少项目底层国产化环境部署顺利,却卡在接口联调环节。原有业务系统跑了很多年,代码改动风险大,一旦接口逻辑发生变化,就要大规模修改业务代码,测试、回归、割接全部重来,工期直接拉长数月。
国产化替换,不只是把CTI软件迁移到国产服务器,更重要的是API接口层的平滑兼容。本篇从项目实操角度,聊聊CTI中间件在国产化环境下,API兼容改造该怎么落地。
一、最容易踩的误区:底层换了,接口就要跟着改
部分厂商做国产化适配的思路很直接:底层全部重新改写,对外API也顺势调整。
从软件研发角度,新版本接口重构看着很清爽,但对于集成商、对于存量业务系统,却是灾难。
政务、国企的业务系统,很多已经稳定运行5‑8年。业务代码年代久远,开发人员早已更迭。改动对接代码,就要重新做全量回归测试,还要协调多方厂商排期。一旦改写出错,会直接影响热线、客服业务稳定。
现实场景:某政务热线改造项目,CTI完成国产化部署,但回调接口字段、请求格式全部变更。原有工单系统、坐席弹屏全部失效,项目工期直接延期2个月。
优秀的国产化CTI改造原则:底层技术栈可以全部替换,但对外业务API尽量保持不变。
底层芯片、操作系统、数据库随便切换,上层业务调用方无感知,不需要修改业务代码,做到“换底座不换接口”。
二、两类接口,国产化改造需要重点关注
CTI中间件对外接口分为业务调用接口、媒体控制接口两大类,国产化适配两者都不能忽视。
1、业务HTTP API接口
也就是业务系统调用的:呼叫发起、挂断、坐席签入签出、获取通话记录、录音获取、事件回调通知。
国产化环境下,很多人以为HTTP接口与底层硬件无关,不需要改动。实际会遇到这些问题:
1)国产操作系统加密组件差异,HTTPS证书校验行为不一致;
2)内网环境,部分依赖外网的签名组件失效;
3)数据库底层语法变化,导致接口返回字段顺序、时间格式出现细微差别。
很多接口看似能调通,但回调事件的时间戳、状态码发生微小改动,上层业务解析逻辑就会出错。
实操要点:接口要做到输入输出格式、状态码、回调事件完全对齐原有x86版本。即便底层内部实现逻辑全部重写,对外暴露的接口契约不能变。
2、媒体控制接口(MRCP/SIP)
这是语音链路的核心,也最容易被忽略。
流式MRCP用来对接ASR/TTS语音引擎,实现语音识别、智能打断。如果CTI迁移到ARM国产环境,MRCP媒体服务组件没有原生编译适配,只能依靠代理转发到x86机器,就会多出一层中转,增加时延,也破坏信创合规性。
很多项目,业务API跑通了,但是流式语音交互频繁断流、识别卡顿,根源就在MRCP组件没有做国产化原生适配。
三、API兼容改造的3个实操步骤
步骤1:锁定接口契约,输出完整接口比对文档
切换国产化版本之前,先导出原有系统全部接口文档,整理一份接口契约清单:请求地址、入参、返回字段、状态码、回调事件、时间格式、错误码。
国产化版本开发完成之后,逐条做比对测试。只要对外行为有改动,就要评估是否会影响上层业务,非必要不修改接口契约。
步骤2:搭建一套完整接口自动化回归测试用例
靠人工逐条测接口效率太低,还容易漏掉边缘场景。
搭建自动化测试脚本,覆盖:外呼、呼入、坐席切换、IVR流转、录音查询、各类通话异常事件(挂断、放弃呼叫、线路异常)。
同一套测试脚本,同时跑在传统x86环境和国产化环境,对比返回结果。只要返回存在差异,就定位修改,保证两套环境对外表现完全一致。
小经验:很多bug不会出现在正常通话,而是出现在异常场景,比如来电中途挂断、网络抖动、坐席异常离线,这部分测试用例千万不能省略。
步骤3:做好灰度割接,降低业务切换风险
即便是接口完全兼容,上线也不建议直接一刀切割接。
条件允许情况下,采用双机并行模式:原有老系统继续跑业务,新国产化CTI中间件并行部署,少量坐席、少量线路先切过去跑一段时间。观察接口回调、通话业务、录音存储是否正常,稳定之后再逐步全量切换。
四、特殊场景:老项目接口不标准怎么办
有些老旧政务项目,早期没有严格遵循接口规范,大量定制化私有接口。
面对这种情况,iSoftCall中间件提供接口适配层,不用去修改老业务系统。在CTI中间件内部做转换,把老系统的私有请求格式,转换成内部标准逻辑,返回老系统能够识别的数据格式。
相当于在中间件内部做一层“翻译器”,上层业务完全不动,实现国产化底座替换。
五、配套交付物料,保障集成商落地
接口适配完成不等于万事大吉,交付物料同样关键:
1)国产化环境完整接口文档,明确标注哪些接口完全兼容,哪些接口存在差异;
2)调试工具:接口调试工具、事件日志查看工具,方便集成商排查联调问题;
3)常见联调故障排查手册,针对国产系统下HTTPS、网络、数据库相关接口报错给出解决方案。
国产化CTI中间件改造,大家目光总聚焦硬件、证书,却常常低估API接口改造的工作量。底层软硬件只是底座,API接口才是CTI中间件和上层业务系统之间的桥梁。桥梁不动,只换桥下的地基,业务系统才可以平稳过渡。
iSoftCall呼叫中心中间件,在国产化改造中坚持接口契约优先,底层全栈适配国产软硬件,对外接口保持兼容,最大程度降低存量政务、国企项目的对接改造成本。