防止长时间不操作掉线和进度条

本文介绍了如何在SAP系统中防止因长时间无操作导致的掉线问题,通过SAPGUI_PROGRESS_INDICATOR函数进行死循环报消息,实现不掉线的效果。同时,还分享了一种优化方案,在确保页面为本系统唯一时打开额外页面,以维持连接。代码来源于SAP刘梦的博客。

平时在使用培训系统时,总是会出现长时间不操作系统掉线需要重新登陆的情况,之前一个小伙伴分享给了我一段防止掉线的代码,现分享如下:

DATA : TEXT TYPE STRING,
       TIME TYPE I.
TIME = 0.
CONCATENATE 'Please open another session for working' '!' INTO TEXT.
DO.
  CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
    EXPORTING
      PERCENTAGE = TIME
      TEXT       = TEXT
    EXCEPTIONS
      OTHERS     = 1.
  TIME = TIME + 1.
  IF TIME = 999.
    TIME = 0.
  ENDIF.
  WAIT UP TO 10 SECONDS.
ENDDO.

主要原理就是利用SAPGUI_PROGRESS_INDICATOR这个函数死循环报消息,这个函数还可以用来提示进度哦,具体使用方法如下:

*&---------------------------------------------------------------------*
*&      Form  frm_gui_progress
*&---------------------------------------------------------------------*
*       text 进度条 加强版
*----------------------------------------------------------------------*
*      -->P_PERCENT  text
*      -->P_STRING   text
*----------------------------------------------------------------------*
FORM frm_gui_progress_xxf  USING  p_string  p_count p_all.
  DATA: l_all(10)          TYPE n,
        l_count(10)        TYPE n.
  DATA: l_message(150)     TYPE c,
        l_string(100)      TYPE c.
  DATA: l_percent          TYPE i.
  DATA: l_tmp TYPE i.

  l_tmp = p_count MOD 500."每500个报一次
  IF l_tmp = 0.

    l_count  = p_count."当前数目
    l_all    = p_all."总数目
    l_string = p_string.
    CONCATENATE 'Processing ( ' l_count '/' l_all  ' ) -- ' l_string INTO l_message."此处为拼接出的消息

    l_percent = l_count * 100 / l_all.
    IF l_percent > 100.
      l_percent = 100.
    ENDIF.


    IF sy-batch <> 'X'.
      CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
        EXPORTING
          percentage = l_percent
          text       = l_message.
    ENDIF.
  ENDIF.
ENDFORM.                    " FRM_GUI_PROGRESS

后来发现了一个防止掉线的优化版本,也就是在前面加了一个判断当前页面是不是本系统唯一的,如果是就再打开一个页面:

*&---------------------------------------------------------------------*
*& Report Z20043_CONTINUE2
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT Z20043_CONTINUE2.
 DATA: text TYPE string,
      time TYPE i.
time = 0.
IF sy-langu = '1'.
  CONCATENATE '请使用其他会话进行工作' '!' INTO text.
ELSE.
  CONCATENATE 'Please use another session for working' '!' INTO text.
ENDIF.

DATA:gt_info TYPE TABLE OF uinfo2,
      gv_num TYPE i.

"获取当前用户的会话数
CALL FUNCTION 'TH_LONG_USR_INFO'
  EXPORTING
    user      = sy-uname
  TABLES
    user_info = gt_info.
DESCRIBE TABLE gt_info LINES gv_num.

"对当前打开的会话数进行判断,如果只打开了一个,那么再另外打开一个新的会话供用户使用
IF gv_num = 1.
  CALL FUNCTION 'TH_CREATE_FOREIGN_MODE'
    EXPORTING
      client           = sy-mandt
      user             = sy-uname
*     TCODE            =
*     RETURN_ERROR     = 1
*     CREATE_EXCLUSIVE = 0
    EXCEPTIONS
      user_not_found   = 1
      cant_create_mode = 2
      OTHERS           = 3.
  IF sy-subrc <> 0.
* Implement suitable error handling here
  ENDIF.

ENDIF.

DO.
  CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
    EXPORTING
      percentage = time
      text       = text
    EXCEPTIONS
      OTHERS     = 1.
  time = time + 1.
  IF time = 101.
    time = 0.
  ENDIF.
  WAIT UP TO 10 SECONDS.
ENDDO.

上一段代码源自
SAP刘梦的博客:http://blog.sina.com.cn/s/blog_c0978c9b0102x4wk.html
侵删。

这是目前的报告,该补充的补充,该修改的修改,可以结合报告、我们之前的讨论把整个“设备添加进度推送”画一个时序图,plantUMl,主体为user、frontEnd、api-gateway、vms-identityAccess、vms-manager,vms-manager执行添加逻辑、添加流程、返回业务消息给api-gateway,api-gateway上进行包装:目录 1. 课题背景 1 1.1 VMS WEBSOCKET消息现状 1 1.2 进度推送丢失问题现状 2 1.3 乱序问题背景 2 1.4 断线重连背景 3 2. 课题内容 3 3. 课题要求 3 4. 研究思路方法 4 4.1 思路与方法 4 4.2 WEBSOCKET标准数据格式 5 4.2.1 设计出发点 5 4.2.2 格式设计 5 4.2.3 兼容性设计 6 4.3 推送进度丢失问题 6 4.3.1 核心思路 6 4.3.2 方法设计 6 4.4 乱序问题 7 4.5 断线重连问题 7 5. 重点难点 8 6. 开展计划 8 1. 课题背景 VMS的WebSocket功能,在实际使用中存在一系列体验性能问题,包括: (1)WebSocket内容格式统一; (2)推送进度丢失问题; (3)乱序问题; (4)断连问题。 对于以上问题,需要一套切实可行的方案进行优化与解决。 1.1 VMS WebSocket消息现状 现在VMS WebSocket相关的业务在推送消息时没有统一封装,无论是广播还是单播,web端通过SimpMessagingTemplate下的发送消息的方法推送信息给用户,消息内容为StompMessage.payload,该JSON字段仅包含具体的业务内容,由各自业务决定。 以“添加设备”为例,返回前端的WebSocket消息如图所示: 该场景是添加3个设备,成功一个、失败两个情况下前端得到的WebSocket内容。其中,Payload包含errorCode、message、result三个部分,可以看到result中包含failList字段,该字段有受控的风险,如果大规模添加设备时出现问题,该数据量会很大;其次,所有响应消息推送消息的标识字段都是“MESSAGE”,可以做一个区分;等等。 【目标】:为了方便前端统一处理,需要对该业务数据进行封装,加入额外字段。 1.2 进度推送丢失问题现状 目前的进度推送存在如下问题: (1)时间差问题:前端先发起HTTP请求触发业务逻辑,后端处理完成后,前端才完成 WebSocket Topic订阅。导致订阅完成时,后端已推送消息,前端无法接收。 (2)冗余逻辑:要维护 HTTP WebSocket 双重通信机制,增加复杂度。 简单示例如图所示: 【目标】:设计合理的方案,规避这种情况。 1.3 乱序问题背景 WebSocket作为应用层协议继承TCP的特性,尽管TCP有解决乱序的措施,但是保证消息到达的顺序。目前业务的场景如下: 后端按顺序发送:【状态1:10%】→【状态2:30%】→【状态3:50%】。 前端可能收到:【状态1】→【状态3】→【状态2】。 导致进度条从 10% → 50% → 30%,从视觉上引起了倒退,影响用户体验。 【当前应对方式】:使用Sleep方式、通过固定延迟,缓解乱序问题,该方式在大规模场景下严重影响性能;同时无法动态适应网络波动,乱序仍可能发生。 【目标】:实现更有效的方法减缓或者避免这种情况。 1.4 断线重连背景 前端与后端Pod通过WebSocket建立长连接,订阅特定Topic接收实时消息。当前实现存在以下问题: (1)短线场景:网络波动、Pod重启/崩溃、服务端主动断开等导致连接中断。 (2)重连策略:前端重试3次后放弃,可能导致消息丢失或业务中断。 (3)订阅状态:旧Pod挂掉时,后端未主动通知业务系统停止推送消息,可能引发资源浪费或数据一致。 目标:优化断线重连机制,确保消息可靠传输,明确前后端职责。 2. 课题内容 课题内容可分为以下六部分: (1)制定前后端websocket标准数据格式 (2)设计方案解决推送进度丢失问题 :前端websocket topic订阅慢于http请求问题,导致订阅完成时,后端推送已完成。设计基于topic订阅时携带业务参数的方案,去除http请求触发请求逻辑,通过规避时间差的方式解决问题。 (3)设计方案解决乱序问题:通过设计序号、状态码等方式,缓解用户进度条显示倒退的问题 (4)设计方案优化断连问题:设计实现断连重连机制 (5)方案落地于设备添加进度推送功能,达到速度、体验优化的效果 (6)设计大数据VMS Local支持设备推送方案,解决大数据量推送时缓冲区满导致断连问题(可选) 3. 课题要求 阶段性需求: 1.学习websocket知识,熟悉VMS设计(1周) 2.完成需求分析概要设计文档(2周) 3.完成代码开发自测(2.5周) 4.验证性能优化情况,输出性能测试文档,输出可用的VMS Local软件包(0.5周) 指标要求: 1.需求分析概要设计符合组内规范,按照文档模板编写。 2.严格按照团队项目流程规范开展工作,组织需求评审会议、概要设计评审会议、设计&代码评审会议; 3.核心代码单元测试并输出完整的自测用例; 4.合理打印日志,合理调整日志打印级别。 4. 研究思路方法 4.1 研究思路与方法 1. 现状分析与需求对齐 【目标】:明确现有项目WebSocket实现的瓶颈业务需求。 方法: (1)代码审查: 分析现有WebSocket配置、消息处理器、消息转换器。检查现有数据格式是否统一,是否存在冗余字段或解析错误。 (2)场景复现: 使用ipc-simulator-port-local-1.1模拟高并发WebSocket连接,复现多种业务下的WebSocket推送消息格式、复现推送进度丢失问题、复现乱序问题、复现断线重连问题。 2. 技术选型与方案验证 【目标】:选择最适合现有项目的技术方案,避免过度改造。 方法: 4.2 WebSocket标准数据格式 4.2.1 核心思路 1.统一协议:确保客户端服务端对消息格式有一致理解。 2.支持多业务场景:兼容消息推送、订阅响应、状态同步等需求。 3.易于扩展:未来新增功能时破坏现有逻辑。 4.安全性:防止数据篡改、注入攻击。 5.可调试性:便于日志记录问题排查。 4.2.2 格式设计 1.消息载荷内容格式 { “type”: String, “status”: String, “errorCode”: Number, “seq”: Number, “sn”: String, “cookie”: String, “payload”: Object } 2.字段含义 (1)type:包含SUBSCRIBE、MESSAGE、ERROR。即订阅响应、推送消息、错误信息三类,错误信息可用于统一错误处理。 (2)status:RUNNING、COMPLETE。对进度类推送任务,未完成时标为RUNNING状态,结束时标为COMPLETE。其他类型的topic固定传COMPLETE (3)errorCode:错误码。对进度类推送任务,有失败情况时置为非0,前端在COMPLETE时通过errorCode判断是否执行失败逻辑。其他类型的topic默认传0 (4)data:业务内容,必须为一个对象。SUBSCRIBE无data 【注意】data中需控制推送对象大小。进度类推送任务禁止将失败结果列表直接放入对象中推送,防止数据量受控膨胀 (5)number:消息编号,每个topic从0开始递增。SUBSCRIBE无number 【注意】使用此字段时需要确保topic有随机字符区分每次任务,需要各业务在处理时每次加1后推送。无随机字符的topic使用时保持number字段未空,前端执行乱序处理逻辑 (6)sn:随机值,进度类推送任务topic中的随机字符 (7)cookie:与http请求响应中的Set-Cookie内容一致,由api-gateway统一处理填充。例:"VMS_SID=v-aed7d4cd-5da5-4e85-9ef2-be3dd0aed0bc; Max-Age=1800; Expires=Wed, 03 Jul 2024 03:00:25 GMT; Path=/; Secure; HttpOnly" 4.2.3 兼容性设计 之前的业务相关的响应消息 4.3 推送进度丢失问题 4.3.1 核心思路 1.移除HTTP触发:前端直接通过 WebSocket 订阅 Topic 并携带业务参数,后端根据参数立即处理并推送结果。 2.参数透传:在 WebSocket的 headers 或 body 中携带业务参数,比如taskId。 3.同步:HTTP参数带进订阅参数,将原来的异步操作改成同步,以规避这个时间差。 4.3.2 方法设计 1.在MessageInboundInterceptor中解析headers或者body; 2.提取业务参数taskId; 3.根据业务参数触发业务逻辑; 4.将结果通过SimpMessagingTemplate推送到订阅的Topic。 简化的时序图如图所示: 4.4 乱序问题 4.4.1 核心思路 1.序列号seq:为推送进度相关的Topic下的同一任务的消息设置一个递增序列号,从0开始,用于区分任务。前端按需处理。无Sn的topic保持seq字段为空,前端执行乱序处理逻辑。 2.状态码state:RUNNING、COMPLETE。对进度类推送任务,未完成时标为RUNNING状态,结束时标为COMPLETE。其他类型的topic固定传COMPLETE。 3.错误码errorCode:对进度类推送任务,有失败情况时置为非0,前端在COMPLETE时通过errorCode判断是否执行失败逻辑。其他类型的topic默认传0。 4.唯一标识码Sn:利用Snowflake生成全局唯一标识码,标识Topic下的任务,避免分布式场景下的问题。 4.4.2 方法设计 1.规则: 进度类 Topic:必填 taskId、seq、state;errorCode 默认 0。 非进度类 Topic:seq 为空,state 固定 COMPLETE。 2.正常功能流程如下: 主要逻辑:若发生乱序,则判断当前seq上一个seq大小,若小于上一个seq,直接丢弃,进入进度条处理逻辑。 4.5 断线重连问题 1.经过讨论与分析,该问题的主要工作集中在前端,原因如下: (1)连接状态感知:前端是连接发起方,能第一时间检测断线 (2)订阅状态管理:前端需记录已订阅的Topic列表,重连后需重新订阅。 (3)用户体验:无限重试可避免因临时故障导致业务中断 2.后端的职责 资源清理:旧Pod挂掉时,需通知业务系统停止向该连接推送消息。 3.思路与方法 Pod挂掉时的清理逻辑:通过Kubernetes的PreStop钩子,在Pod终止前发送取消订阅事件。 简化流程如图所示: 5. 重点难点 6. 开展计划 任务模式 任务名称 工期 开始时间 完成时间 前置任务 自动计划 摘要 1 5 个工作日 2022年9月6日 2022年9月12日 自动计划 任务 1 2 个工作日 2022年9月6日 2022年9月7日 自动计划 任务 2 3 个工作日 2022年9月8日 2022年9月12日 2 自动计划 摘要 1 完成 0 个工作日 2022年9月12日 2022年9月12日 3 自动计划 摘要 2 9 个工作日 2022年9月13日 2022年9月23日 自动计划 任务 3 3 个工作日 2022年9月13日 2022年9月15日 4 自动计划 任务 4 4 个工作日 2022年9月16日 2022年9月21日 6 自动计划 任务 5 2 个工作日 2022年9月22日 2022年9月23日 7 自动计划 摘要 2 完成 0 个工作日 2022年9月23日 2022年9月23日 8 自动计划 摘要 3 3 个工作日 2022年9月26日 2022年9月28日 手动计划 任务 6 3 个工作日 2022年9月26日 2022年9月28日 9 手动计划 任务 7 2 个工作日 手动计划 任务 8 TBD
最新发布
09-12
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值