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