ODP_SAP 增量管理

1. 增量流程

数据抽取两种方式: full和delta。
full就是全抽。有时候可以用来修复delta里面用语义过滤的records。
delta就是值抽取上次抽取后更改的。

处理方式：是指抽取，转换和传输的步骤。还有你转换是ABAP runtime还是HANA runtime。或者你HANA runtime有个ABAP end routine的那就是部分HANA runtime。

对于Delta机制，SAP给出了三种。

1. 第一种是应用application自己去填增量队列，不需要增量字段。就是填STORNO记录或者添加的增量记录。
2. 是提取器extractor基于增量字段去填增量队列，就是根据时间戳，序列号。
3. 源数据不能提供增量，BW4HANA来根据增量字段，比如时间戳和序列号来过滤增量值实现增量。

这个增量实施在源那边就是一个增量队列。增加的记录会被按序填充到增量队列里。然后监控从这个队列的抽取。
增量过程就是说数据是怎么传输的。一个自带增量功能的数据源可以自己搞增量传输。

1.1 序列

记录的来源。谁先谁后。
因为你数据要往上层ADSO去。ADSO要激活，而且key figure的值如果是直接覆盖。那么这些增量的记录先后顺序就非常重要。后改的要覆盖掉先改的，以最终数据记录为准。

No serialization take place.
Serialization is required between requests. The data packages within a request do not need to be serialized.
Serialization is required at data package level. The data packages in a request must also be serialized.
这个呢是这个提取器只能有后象。然后一个请求里会有很多条同主键记录。那我们就也得在包里也搞序列。

1.2 增量类型

以下这个图和增量处理类型对应。一般数据源的两种增量方式，从extractor弄增量的是pull,extractor是根据时间戳啊，序列号来搞增量，一般都是财务数据源。而push推的方式一般都是后勤数据源，application自己会把增量写到增量队列。不论财务还是后勤，都从delta queue里面拿增量数据。

RODELTAM-DELTATYPE这个delta属性呢就是说delta是怎么处理的。
空，没有增量。
A，Application Link Enabling(ALE) update pointer这个应用更新指针来确定delta。主要用于属性和文本数据源。如果底层主数据表支持也能用来让一般数据源提供delta数据。
D，SAP应用写入增量数据（直接push）到增量队列。应用层（比如FI-AR/AP 或者LO cockpit的直接delta）在保存或者更新交易的时候会把数据记录保存到增量队列。或者是通过应用的一些特定的job，把更新后的增量记录批量写到增量队列。这种就是说数据源没办法根据字段或者应用表的控制表来确定增量。所以就这样通过应用写增量。然后增量更新到BW系统。
E，数据源通过extractor来提供增量，那边有request了，那么这边extractor就去拉增量数据了。拉的增量extractor先放在增量队列里面。然后传到目标BW系统。如果你这个数据增量初始化请求在不同的BW系统里，或者一个BW系统有过个增量初始化，那这个提取器会把增量请求都存储下来，分别给不同的目标请求存着。这种就是数据源可以通过字段或者是底表的控制表决定增量的。
F，文本文件传输delta。用不着ODQ。这个标志就是说告诉用户这个文本应该有delta。

那么除了增量类型，每个数据源还有个增量方式。一般交易数据数据源会有NIM，BIM，AIM之类的，还有R啥的。这些record mode。

1.3 记录模式

以下这个图有误。
record mode是在BW里面增量处理时的记录0RECORDMODE。在数据源里是ROCANCEL这个字段。如果一个数据源有多重更新模式，可以是后象，可以是删除。（这个具体看数据源属性，有些是ABR，有些ADD啥的）那这个ROCANCEL字段就会自动变成数据源的一部分。
如果更改。

1. 可以是一个前象X，后象空。两条记录
2. 可以是一条ADD。
3. 可以是直接更改的后象。
   如果删除。
4. 可以是-10的反转R。
5. 可以是-10的删除D。
   
   对于ADSO呢，如果是标准ADSO带有激活的，那关键值可以是sum或者覆盖。对于cube类型ADSO，所有特性都是key，就只有sum。
   建模ADSO选类型的时候，要考虑到你的数据源，能提供什么个增量image。是直接后象，还是前象，后象啥的。如果像那种只有直接后象的。那就用不到sum。
   
   记录模式：
6. 空，更改后只提供后像。就是更改后的样子。记录有增减或者更改后记录状态只有后像。对于Cube类型的DSO有了前像的，那这种就只能直接更新。
7. X：有两条。和后像一对一。就是更改前的样子。前像是后像的反转镜像。对于反转的那条的反转符号+或者-要么是由extractor来提供，要么是SAPI（service application programming interface）提供。往上层ADSO（有激活模式的）的时候，只加载后像。
8. A：增加（减少）。就是直接加增加的或者减少的值。那它只能更改数值部分。这种对于Cube的就直接更新可以。
9. D：删除。这种就只有Key会被加载，所以只能往上到ADSO（标准或者staging），就是说要删除这条。
10. R : 反转。内容和新像一样，和N一对一。就是激活到ADSO时跟这个R记录 一样Key的就会被删除。
11. N：新。就是没有前像的后像。也就是它是新建的。

你的数据源呢，是支持delta的时候，会在源系统里有个字段专门放这些记录模式：ROCANCLE这个字段会更新到0RECORDMODE.

不同更新模式类型的delta数据源可以更新到的目标如下：
对于累加型的，必须得保证数值经过加法最终是正确的。
要注意的是如果是有ADD类型的，那上层不能是覆盖了。只能是累加。
对于after image的，只能是覆盖。
那好像AIE、ABR、AIM类型的数据源比较好用。对于既有前像又有后像的，激活的时候（覆盖）只有后像在ADSO的激活队列，（累加）前后像都在。
R 可以在Cube和ADSO里通用。
D 就只能在ADSO中用，Cube里面不行。因为需要这个激活操作。激活的时候会把ADSO中的N删除。但是Cube就不能搞删除。

就算知道以上，在数据处理过程中还是会有很多问题。因为需要细致了解对于支持不同增量数据处理类型的数据源的数据最终更新方式。你才能最终知道这个数据源传输到最后的目标，以及它中间的各种更改会如何反应到最终目标里。

1.4 增量方式

比如说这个LO数据源，增量处理是ABR的方式。delta type是D。就是Push。是application去放到队列里的。
那么这个push可以是direct delta（直接从应用更新，V1-updating）。
也可以是queued delta（就是从应用先到抽取队列V1)然后从抽取队列被一次性收集到增量队列。
那么增量被抽取后，这个ABR数据源也还是会一直有B像，A像，R像的数据记录。那么这个数据源可以被更新到标准的，Staging的和Cube的ADSO。

对于这个AIE类型的财务数据源，AIE是E类型的pull的方式。那么pull的话就是由数据源的提取器来拉数据的。把数据拉到ODQ里面然后再传输到BW去。
只有后象的数据源是不能直接更新到Cube去的。只能更新到有激活或者压缩操作的ADSO去。而且关键值也只能是覆盖。

总结一下，就是不同数据源有不同的增量方式。这个增量方式取决于环境和应用的不同数据模型。财务数据源的增量基于它底表的时间戳字段，由数据源中的提取器根据这个时间戳字段来选择过来增量记录。
后勤数据的原表没有这个前提条件，那就在对话交易的时候就由应用更新这个增量去。然后被后续目标提取。
增量的一整个流程由 ： 更新模式（ABR…)+ 增量类型（D、E…推，拉)+序列（V1，V2 按时间发生顺序，是否打包）决定。
以上最终决定这个数据源能否以sum、overwrite等方式更新到最顶层的目标。

1.5 增量初始化

初始化增量请求在你DTP第一次执行时就会有，DTP去执行请求找数据源要数据。那么数据源要哦是去找应用表要数据，如果是LO数据源，应用表这时候说，我把数据都给了增量队列了，你去那里拿。（增量队列如果V2方式会每天由job跑了放到里面，先是一个一个的到提取队列里，有更新就先到提取队列，然后再批量到增量队列）
如果是FI数据源，那么这个DTP请求要数据了，数据源就会找extractor提取器去拿数据到增量队列里，这个是即时的。然后从增量队列里把数据给DTP。
这个增量队列里会放数据。增量队列里的空间有三部分，分别是C表，F表和ODQDATA表。
C表是初始化请求表，F表是Full请求数据，ODQDATA就是压缩的增量请求数据。

那么要注意的一点是，当你去初始化请求时候，就是说我要先把所有ERP的数据拿到BW里面，那么要保证我把所有的都拿来。要先停止ERP那边的交易处理啊。不能说我今天8点拿，拿到8点半。那么下次我增量会从8点半开始取新增的数。但是8点到8点半直接这段可能的新增的就掉了。

所以初始化这段时间，要停止更新。在ERP那边怎么停，就是你初始化的时候，定个初始化的时间。然后顺手设个别让他更新。对于财务数据呢，就是从请求生成的时候开始。
对于上次请求结束后源系统的新增，修改数据，就是我们增量请求需要的数据。临时存储的增量数据在ODQDATA表里。

对于初始化历史数据，有两种选择。

1. 数据少。1个Delta DTP建起来，第一次跑就是ODQ的Delta initialization，第二次跑就是ODQ的正常Delta load。
2. 数据多。2个DTP，第一个Full，会比delta initialization快，而且可以搞过滤，把数据量分开，先搞前两年，再搞后两年。第二个Delta，选择请求处理上是Delta init w/o data. 就是说执行个delta initialization，但是如果已经被拿过的数据，这次就只要标记成拿过了，不要再取一遍了，有新的再取。然后把这第二个Delta的请求选项不要勾，正常弄delta。

两个表：ROOSOURCE、RODELTAM。

2. 提取后勤数据

下一篇link.

5. ODQ的增量逻辑

6. GL数据提取