今天在讨论 SAP Gateway 时，开发人员很容易把注意力全部放在 OData Service 能不能返回数据、GET请求是否成功、POST是否写入数据库这些功能性问题上。但一个真正进入生产系统的 SAP Gateway 服务，仅仅做到功能正确远远不够。当一个 SAP Fiori 应用在测试系统运行正常，到了生产环境却偶尔出现HTTP 500，当同一个 OData 请求上午只需要300 ms，下午高峰期突然变成8 s，当 SAP UI5 前端收到的数据结构异常但后台没有出现 Dump，或者当 CDS View 已经修改，浏览器拿到的$metadata却依然是旧版本时，问题已经从单纯的开发进入另一个领域，也就是Supportability。这里的Supportability很难只翻译成支持能力，它更接近一种工程属性。我们的 SAP Gateway 应用出了问题以后，系统有没有留下足够的信息，开发人员能不能重现问题，Basis 团队能不能判断问题发生在哪一层，性能团队能不能找到耗时点，SAP Support 能不能拿到足够证据继续分析，这些都属于可支持性的范畴。SAP Gateway Foundation 对这一点考虑得相当深入。SAP 官方至今仍然把错误日志、性能跟踪、Payload 跟踪、Gateway Client、Notification Monitor、Application Log Viewer 等作为 Gateway 故障分析的重要工具，并继续在SAP_GWFND