如您所知，SAP 提供了一整套软件，用于维护交易数据以及在分析和报告系统中处理这些数据。特别是SAP Business Warehouse（SAP BW）平台是一个具有广泛技术能力的存储和分析数据的工具包。尽管 SAP BW 系统具有所有客观优势，但它有一个显着的缺点。这是存储和处理数据的高昂成本，在 Hana 上使用基于云的 SAP BW 时尤其明显。
如果您开始使用一些非 SAP 并且最好是开源产品作为存储怎么办？我们 X5 Retail Group 选择了 GreenPlum。当然，这解决了成本问题，但与此同时，使用 SAP BW 时几乎默认解决的问题立即出现。
特别是，如何从源系统（主要是 SAP 解决方案）检索数据？
HR Metrics 是第一个需要解决这个问题的项目。我们的目标是创建人力资源数据存储库，并在与员工合作的领域建立分析报告。在本例中，主要数据源是 SAP HCM 事务系统，所有人事、组织和薪资活动均在该系统中进行。
数据提取
SAP BW 中有适用于 SAP 系统的标准数据提取器。这些提取器可以自动收集必要的数据、监控其完整性并确定变化增量。例如，这里是员工属性 0EMPLOYEE_ATTR 的标准数据源：
从中提取一名员工的数据的结果：
如有必要，可以修改此类提取器以满足您自己的要求，或者可以创建您自己的提取器。
出现的第一个想法是重复使用它们的可能性。不幸的是，事实证明这是一项不可能完成的任务。大多数逻辑是在 SAP BW 端实现的，并且不可能轻松地将源头的提取器与 SAP BW 分离。
很明显，我们需要开发自己的机制来从 SAP 系统中提取数据。
SAP HCM 中的数据存储结构
要了解这种机制的要求，我们首先需要确定我们需要什么数据。
SAP HCM 中的大多数数据都存储在平面 SQL 表中。 SAP 应用程序基于此数据，向用户可视化组织结构、员工和其他人力资源信息。例如，SAP HCM 中的组织结构如下所示：
从物理上讲，这样的树存储在两个表中 - hrp1000 对象中和 hrp1001 中这些对象之间的连接。
对象“部门 1”和“办公室 1”：
对象之间的关系：
可能存在大量的两种类型的对象以及它们之间的连接类型。对象之间既有标准连接，也有根据您自己的特定需求定制的连接。例如，组织单位和全职职位之间的标准 B012 关系表示部门负责人。
SAP中的经理显示：
存储在数据库表中：
员工数据存储在 pa* 表中。例如，员工的人事事件数据存储在表 pa0000 中
我们决定 GreenPlum 将采用“原始”数据，即只需从 SAP 表中复制它们即可。它们将直接在 GreenPlum 中进行处理并转换为物理对象（例如部门或员工）和指标（例如平均人数）。
定义了大约 70 个表，其中的数据必须传输到 GreenPlum。之后我们开始研究传输这些数据的方法。
SAP 提供了大量的集成机制。但最简单的方法是由于许可限制而禁止直接访问数据库。因此，所有集成流程必须在应用程序服务器级别实现。
下一个问题是 SAP 数据库中缺少有关已删除记录的数据。当您删除数据库中的一行时，它会被物理删除。那些。基于变化时间形成变化增量是不可能的。
当然，SAP HCM 具有记录数据更改的机制。例如，对于随后传输到接收方系统，存在记录任何更改的更改指针，并在此基础上形成 Idoc（用于传输到外部系统的对象）。
用于更改人员编号为 0302 的员工的信息类型 1251445 的 IDoc 示例：
或者在 DBTABLOG 表中保存数据更改日志。
从hrp53216375表中删除键为QK1000的记录的日志示例：
但这些机制并不适用于所有必要的数据，并且它们在应用程序服务器级别的处理可能会消耗相当多的资源。因此，在所有必要的表上大量启用日志记录可能会导致系统性能明显下降。
下一个主要问题是聚簇表。 SAP HCM RDBMS 版本中的时间估算和工资数据存储为每个员工每次计算的一组逻辑表。这些逻辑表作为二进制数据存储在表 pcl2 中。
薪资集群：
来自聚簇表的数据不能被视为SQL命令，而是需要使用SAP HCM宏或特殊功能模块。因此，此类表的读取速度会相当低。另一方面，此类集群存储每月仅需要一次的数据 - 最终工资单和时间估算。所以在这种情况下速度并不那么重要。
在评估形成数据更改增量的选项时，我们决定还考虑完全卸载的选项。每天在系统之间传输千兆字节的未更改数据的选择可能看起来不太好。然而，它也有许多优点——不需要在源端实现增量并在接收器端实现该增量的嵌入。因此，降低了成本和实施时间，并且提高了集成的可靠性。同时，我们确定 SAP HR 中的几乎所有变化都发生在当前日期之前的三个月内。因此，决定选择在当前日期前 N 个月从 SAP HR 每日完整下载数据，以及每月完整下载。 N参数取决于具体表格
范围从 1 到 15。
提出了以下数据提取方案：
外部系统生成请求并将其发送到 SAP HCM，在 SAP HCM 中检查该请求的数据完整性和访问表的权限。如果检查成功，SAP HCM 会运行一个程序来收集必要的数据并将其传输到 Fuse 集成解决方案。 Fuse 确定 Kafka 中所需的主题并将数据传输到那里。接下来，来自Kafka的数据被传输到Stage Area GP。
在这个链条中，我们感兴趣的是从 SAP HCM 中提取数据的问题。让我们更详细地看看它。
SAP HCM-FUSE 交互图。
外部系统确定最后一次成功向 SAP 发出请求的时间。
该流程可以通过计时器或其他事件启动，包括设置超时以等待 SAP 的数据响应并启动重复请求。然后它生成一个增量请求并将其发送到 SAP。
请求数据以json格式发送到body。
方法http：POST。
请求示例：
SAP 服务监视请求的完整性、是否符合当前 SAP 结构以及所请求表的访问权限的可用性。
如果出现错误，服务将返回带有适当代码和描述的响应。如果控制成功，它会创建一个后台进程来生成样本，生成并同步返回唯一的会话id。
如果出现错误，外部系统会将其记录在日志中。如果响应成功，它将传输会话 ID 和发出请求的表的名称。
外部系统将当前会话注册为打开。如果该表还有其他会话，它们将被关闭并记录警告。
SAP后台作业根据指定的参数和指定大小的数据包生成游标。批次大小是进程从数据库读取的最大记录数。默认情况下，假定等于 2000。如果数据库样本中的记录多于所使用的数据包大小，则在传输第一个数据包后，将使用相应的偏移量和递增的数据包编号形成下一个块。数字加 1 并严格按顺序发送。
接下来，SAP 将数据包作为输入传递到外部系统的 Web 服务。系统对传入的数据包进行控制。具有接收到的 ID 的会话必须在系统中注册，并且必须处于打开状态。如果包裹编号> 1，系统应记录成功接收前一个包裹（package_id-1）。
如果控制成功，外部系统解析并保存表数据。
此外，如果包中存在最终标志并且序列化成功，则会通知集成模块会话处理已成功完成，并且该模块会更新会话状态。
如果出现控制/解析错误，则会记录该错误，并且该会话的数据包将被外部系统拒绝。
同样，在相反的情况下，当外部系统返回错误时，会记录该错误并停止数据包传输。
为了请求 SAP HСM 端的数据，实施了集成服务。该服务是在 ICF 框架（SAP Internet Communication Framework - ）。它允许您使用特定表从 SAP HCM 系统查询数据。创建数据请求时，可以指定特定字段的列表和过滤参数，以获得必要的数据。同时，服务的实现并不隐含任何业务逻辑。计算delta、查询参数、完整性监控等算法也在外部系统侧实现。
这种机制允许您在几个小时内收集和传输所有必要的数据。这个速度已经可以接受了，所以我们认为这个解决方案是一个临时的解决方案，它可以满足项目上对提取工具的需求。
在目标图中，为了解决数据提取问题，正在探索使用Oracle Golden Gate等CDC系统或SAP DS等ETL工具的选项。
来源： habr.com