前言:
归纳总结是个好习惯,我们都值得拥有.
每一个业务的开发需求,都是一次归纳的契机.
根据业务特定的需求分析,是否可以概括出一个通用需求?
特定业务需求是否完全包含在这个通用需求中呢?
是否可以根据这个通用需求概括出一个通用处理模型?
该模型是否可以解决这一类的业务需求?
怎么用特定的语言(ABAP)开发这个模型?
怎么给业务最大的自由度去使用这个配置使用这个模型?
如果你是一个业务人员,带着这些问题去和你的开发沟通.(你毛病呀,半天就可以写完的程序,你想整一周?)
如果你是一个开发人员,带着这些问题去和需求提出者沟通(你找事呀,按我的需求做就完事了,要不你来写功能说明书?)
或者,你也会碰到志同道合的. 嗯,这个提议不错, 咱们一起来完善一下这个设计.
尝试更多的去理解业务,去归纳业务,用开发的思想去重建功能设计.
正文
监控的目的是为了及时发现系统中的问题,在问题的影响扩大之前,解决问题消除影响. 系统中的问题大概分两大类
技术类问题:属于系统管理员工作范围,包含操作系统硬件,可用存储空间,数据库备份情况等. 这个比较专业,不在本文讨论范畴.
业务类问题:后台自动程序的执行情况,异步接口的处理情况等.
对业务类的问题的及时处理,可以避免问题的连锁反应. (比如:收货接口的报错如果没有及时处理,就会影响后续的发货过程)
业务的问题往往分散在很多不同的环节.
怎么才能把不同环节的业务报错集中在一个界面呈现?
怎么才能把不同环节的业务报错及时通知相关负责人?
这些问题就是集中监控程序需要解决的.
要监控业务问题,需要假设这些问题都被记录在了对应的表中.那么集中监控程序可以开放一个配置表,配置每个业务问题(监控点)需要监控的表,及表中报错信息的识别方式. 最后把这些信息统一呈现即可.
基于上述的分析,设计了这个集中监控程序,它提供了一个配置表,可以配置监控内容的识别方式:
可以配置如下的内容:
监控ID,监控名称,英文监控名称,监控表名,监控字段,监控字段值 ,成功标识值 ,失败标识值 ,单据号的字段名 ,日期字段,补充条件字段1,补充条件值1,补充条件字段2,补充条件值2,附加SQL条件,跳转的TCODE,链接TCODE 的参数ID,补充的跳转传递的选择条件,RFC 目标系统,监控通知人员,通知的阀值
然后通过一个统一界面呈现所有监控的内容,同时支持点击链接转到特定业务报错的专门处理程序.
如果监控程序定义成后台定期执行,他会获取监控条目配置的负责人,通过系统消息/邮件/企业微信等定制的通讯方式,发送信息给他们.
集中监控程序也可以配置监控系统标准环节:
如果有必要, 你也可以配置它监控每天各种单据的创建情况.
你也可以RFC目标系统配置它监控另外一个系统的业务执行情况.
对于接口监控部分,可以参考文章
接口监控部分详见 接口框架
无峰，公众号：ABAP开发技巧SAP开发框架系列之 接口框架
集中监控程序在多个项目中得以应用,把自动单据,IDOC处理,系统标准环节等报错信息整合到了一个统一的界面呈现,极大的方便了运维组对系统业务运行情况的把控.
SAP开发框架系列是我对开篇前言中问题的解答,这个系列提供的是一种思维方式,有些涉及到的代码/工具,会在后续文章中陆续发布.
如果你对这篇文章感兴趣,请帮忙转发分享, 并且勾选微信 <看一看>.文章右上角的按钮点击后,点击<在看>(或者文章末尾的右下角<在看>),即可. (如果你真的喜欢这篇文章,请记得回来打个赏,作为支持我继续下去的动力,这是一个正反馈过程. 越多的人打赏,作者越有动力分享,读者就能享受更多的福利. 毕竟打赏的金额富不了我,穷不了你,却能支持这个公众号长久发文.)
扫码关注公众号,获取更多好用的SAP应用程序
