回答一位同事的问题。

像SAP BYD的field extension，从extension artifact的存储位置角度说，算是in-app extension，即扩展出的字段，和被扩展的应用存储在同一物理系统里。同时，SAP BYD field extension，通过工具创建出的扩展字段，采取的是end to end，bottom - up 的扩展方式，即数据库层，API 层，服务层，Data transfer object 即DTO层，再到消费端，比如UI，Form，Report，统统被扩展。因此，这种in-app extension的扩展方式，要求扩展工具对被扩展应用的设计明细有清晰的了解，而Kyma设计之初，目的是提供一种基于事件驱动的松耦合方式，去扩展SAP解决方案。因此，SAP BYD的field extension，不适合通过Kyma去实现。

Kyma的典型使用场景的一个例子：SAP解决方案在业务流程进行到某一步骤时，会发布一个标准事件，比如Order Check. 如果这个解决方案已经同Kyma集成了，那么当该SAP解决方案，即某个具体的SAP系统，同Kyma实例建立连接之后，该Order Check事件就能出现在Kyma实例的Service Catalog里。这样，二次开发人员，就能直接在Kyma里，编写Order Check的事件响应函数。在运行时，当新建一个订单时，SAP系统发布Order Check事件，自动触发Kyma上编写的事件响应函数。这个类似SAP BYD里的post exit，只是事件响应函数不是像post exit那样写在SAP BYD的ABAP系统的，而是写在Kyma里的，像这种扩展逻辑和被扩展系统，物理上位于不同服务器的扩展方式，称为side by side extension.

可以参考我2019年写的这篇文章：基于SAP Kyma的订单编排增强介绍