在SAP Gateway Service Builder里完成一个项目的数据模型定义后，项目树看起来往往已经相当完整。Entity Type有了，Entity Set有了，属性、关联关系以及数据源映射也可能已经配置妥当。可到了这个阶段，浏览器还不能因为这些设计时定义就直接访问我们的业务数据，SAPUI5和Fiori Elements也不会凭空得到一个可以发送HTTP GET请求的服务地址。真正把这些设计时元数据送进SAP Gateway Runtime的，是Generate Runtime Objects，也就是很多资料里所说的Generating Runtime Artifacts。SAP 官方文档对这一步的描述很直接，在元数据定义完成之后，需要生成运行时工件。SAP Service Builder会自动生成让服务符合OData规范并能够被SAP Gateway使用的代码，同时把数据模型分配给生成出来的服务。服务的数据模型实现类和数据访问实现类也会在这个过程中建立起来。所以，在SEGW开发流程里，Generate Runtime Objects很像一道明显的分界线。分界线之前，我们主要处理的是设计时对象。分界线之后，系统里开始出现真正能够参与OData Runtim
在SAP Gateway Service Builder里完成一个项目的数据模型定义后，项目树看起来往往已经相当完整。Entity Type有了，Entity Set有了，属性、关联关系以及数据源映射也可能已经配置妥当。可到了这个阶段，浏览器还不能因为这些设计时定义就直接访问我们的业务数据，SAPUI5和Fiori Elements也不会凭空得到一个可以发送HTTP GET请求的服务地址。真正把这些设计时元数据送进SAP Gateway Runtime的，是Generate Runtime Objects，也就是很多资料里所说的Generating Runtime Artifacts。SAP 官方文档对这一步的描述很直接，在元数据定义完成之后，需要生成运行时工件。SAP Service Builder会自动生成让服务符合OData规范并能够被SAP Gateway使用的代码，同时把数据模型分配给生成出来的服务。服务的数据模型实现类和数据访问实现类也会在这个过程中建立起来。所以，在SEGW开发流程里，Generate Runtime Objects很像一道明显的分界线。分界线之前，我们主要处理的是设计时对象。分界线之后，系统里开始出现真正能够参与OData Runtim
)
