在本系列的第一篇博文中，我们重点介绍了OData服务中属性的alpha转换的一个简单示例。在我们讨论SAP Gateway Foundation内置转换工具的更多详细功能和问题之前，我们需要了解堆栈的一些细节。

这篇文章将阐明服务模型的一些方面以及SAP Gateway Foundation不同层之间的数据传输。虽然我们坚持转换的特性，但解释也有助于理解SAP Gateway Foundation在其他上下文中的运行时行为。

服务模型

OData服务主要在两个资源中公开其模型信息：

服务文档–GET…//元数据文档–GET…//$metadata

服务文档描述可寻址实体集和函数导入，元数据文档提供有关实体类型/复杂类型及其（导航）属性（包括其定义属性）的详细信息，并包括注释。服务使用者使用此信息与服务交互。

SAP Gateway Foundation承担处理OData请求的任务，数据分析工具有哪些，什么是云，将它们转换为对数据提供者的适当调用（请参阅下面的堆栈概述）。sapgatewayfoundation提供了许多支持服务实现的特性，其中之一就是转换的执行。我们已经看到，所需的信息（例如转换出口的名称）是通过模型提供者类的实现提供的。或者，在使用某些模型api时，它是自动确定的。此转换信息也成为模型的一部分。

概括地说，模型描述了服务的结构和行为：

了解服务模型包含的控制服务行为的数据比暴露给服务使用者的数据要多得多，这一点很重要。

以下数据是模型的一部分，是直接的或间接与转换有关，但并非专门用于此目的：

本系列第一篇博文中讨论的转换开关属性级别上的转换出口属性级别上的单位或货币代码语义以及对此类属性的引用ABAP数据类型信息在属性级别

虽然最后一点不是很明显ABAP数据类型信息是最复杂的数据集，对转换非常重要，可能是问题和事件的来源。如果我们看一下SAP Gateway Foundation内部的数据传输，就可以更好地理解数据类型信息，这也将揭示转换的执行位置。

数据传输

SAP Gateway Foundation中处理OData请求的框架由不同的组件和层组成。所谓的hub组件包括OData库和hub框架层。集线器组件可以在单独的系统上运行，例如FIORI前端服务器。后端组件包含后端框架层，并将请求处理委托给特定于服务的模型和数据提供程序类。

我们将首先分析出站数据流，云服务器服务好，即从数据提供程序类中提供数据到最终http响应负载的流。并且，我们坚持第一篇博文中的示例：

为了响应实体集GET请求，数据提供者从数据库表VBAK中选择数据，并可能将这些数据存储在具有类似结构的内部表中。这些数据提供给框架，作为这种内部表的参考。包含相关数据类型的行结构由数据提供程序定义。因此，我们将此内部表称为提供者数据容器。

框架通过两个步骤将提供者数据容器的内容传输到内部数据容器：

同样，内部数据容器是一个内部表，但行结构在运行时由后端或集线器框架层生成。使用的数据类型派生自服务模型。在我们的示例中，内部数据容器的ABAP数据类型需要与表示sales order头的相应属性的EDM类型匹配。稍后，OData库序列化来自内部数据容器的OData响应。

请注意，在集线器部署场景中，内部数据容器是在集线器和后端框架层生成的–内部数据容器内容是序列化的，并通过集线器之间的RFC连接传输系统。在协同部署场景中，有一个内部数据容器实例。

在数据容器之间移动数据的第一步已经是转换。当使用$expand时，容器的结构可能很深。因此，使用带有ID转换的序列化/反序列化来传输数据–此过程"转换"一些已经存在的表示。在7.50版本中，如果可能的话，框架使用了deepmove-corresponding（移动相应的扩展嵌套表）。棘手的一点是，ID转换与deep move在某些细节上有所不同–框架预先分析模型并决定正确的用法，以确保不同版本之间的兼容性。

在我们的示例中，第一步之后，内部数据容器的字段VBELN仍将携带带前导零的值。

第二步是整个讨论的起点。因此，提供者数据容器形成出站转换的输入，结果存储在创建OData响应的内部数据容器中。

现在，执行alpha转换后，字段VBELN包含不带前导零的值。

对于另一个方向，我们需要区分两种情况：

第二种情况下的数据流与我们上面讨论的非常相似：请求负载反序列化到内部数据容器中，然后传输到提供程序包括按需执行转换的数据容器。我们将在最后一章中看到这一点。