在 ABAP Development Tools 里完成一个 Logical External Schema 之后，很容易产生一种错觉，既然代表远程数据库的设计期对象已经存在，ABAP 系统似乎就应该知道该到哪里读取数据了。真正运行一次 CDS External Entity 或 ABAP SQL 后才会发现，Logical External Schema 自己并不会建立任何网络连接，它只是整个远程数据访问模型中的一个设计期锚点。真正把这个锚点连接到外部 SAP HANA、SAP Datasphere，或者其他受支持远程数据库的，是另一组对象共同完成的工作，其中最关键的几个角色就是 Outbound Service、Communication Scenario、Communication System 和 Communication Arrangement。这套机制看起来对象比较多，但 SAP 这样设计有很明确的目的。开发阶段只描述应用需要什么样的通信能力，生产环境究竟连接哪台服务器、使用哪个端口、哪个技术用户以及哪一种认证方式，则留给系统管理员配置。开发对象和环境配置由此被分开，ABAP 代码不需要硬编码主机名、端口和密码，也不会因为开发、测试、生产系统的地址不同而修改代码。这正是 ABAP Cloud 和 Clean Core 思路里很重要的一条边界。在当前 ABAP Development Tools 的模型中，Communication Scenario 是两个通信参与方如何交互的设计期描述。它可以包含 Inbound Service，也可以包含 Outbound Service，还可以同时包含两种方向的服务，并描述通信过程中允许使用的认证机制。SAP 官方文档同样把 Communicat
在 ABAP Development Tools 里完成一个 Logical External Schema 之后，很容易产生一种错觉，既然代表远程数据库的设计期对象已经存在，ABAP 系统似乎就应该知道该到哪里读取数据了。真正运行一次 CDS External Entity 或 ABAP SQL 后才会发现，Logical External Schema 自己并不会建立任何网络连接，它只是整个远程数据访问模型中的一个设计期锚点。真正把这个锚点连接到外部 SAP HANA、SAP Datasphere，或者其他受支持远程数据库的，是另一组对象共同完成的工作，其中最关键的几个角色就是 Outbound Service、Communication Scenario、Communication System 和 Communication Arrangement。这套机制看起来对象比较多，但 SAP 这样设计有很明确的目的。开发阶段只描述应用需要什么样的通信能力，生产环境究竟连接哪台服务器、使用哪个端口、哪个技术用户以及哪一种认证方式，则留给系统管理员配置。开发对象和环境配置由此被分开，ABAP 代码不需要硬编码主机名、端口和密码，也不会因为开发、测试、生产系统的地址不同而修改代码。这正是 ABAP Cloud 和 Clean Core 思路里很重要的一条边界。在当前 ABAP Development Tools 的模型中，Communication Scenario 是两个通信参与方如何交互的设计期描述。它可以包含 Inbound Service，也可以包含 Outbound Service，还可以同时包含两种方向的服务，并描述通信过程中允许使用的认证机制。SAP 官方文档同样把 Communicat
