DSO的记录模式Record Mode字段测试

不管是哪种DSO,表里的数据都会有Record Mode这一字段,NEW表与Active表里的该字段是由数据源上传上来的,而Chang Log则是由BW系统在激活时由抽取上来的数据与Change Log里原有数据进行比对得到的,并且 后像、A像 都以是 X前像+后像来记录,R像与D像 则还是以本身的像类型记录
 
(注:Push方式的Delta-Queue里的数据也会带有记录模式,这种是用户在维护数据时SAP系统记录的(并且不同的Delta Proess增量处理模式,则会导致Delta-Queue存入数据有不同的记录模式Record Mode),但不知道Pull方式的Delta-Queue是否也带?需测试
 
下面以上面文件数据源为源,来测试记录模式
 
新建标准DSO,将文件中的数据抽到此DSO中:
5267fa63-2804-4789-9ed4-2f8739c8d4bf  bbcf6033-5047-43be-bae1-a625da538862
7385aab9-4fee-4295-86aa-cc1c497a550c
激活前,New中的数据如下,此时Record Mode并没有数据:
3d092462-2e5f-4173-8965-e9a2c8de6ec8
激活后,Active表与Change Log中的数据如下:
2a3bcc64-9ceb-4be7-8173-f2c6960e746f
2cd1221e-2ab6-4c0e-b33d-73d411f2dd9c
Active表中的Record Mode也是空的,只有Change Log表里的Record Mode有数据,且都是新像,它是由系统自己对比数据自动设置的,但是New表与Active表里的Record Mode的值是由数据源本身提供的,但此时的文件数据源没有提供,所以是空的
a1b3ef0f-dc13-4a25-adb0-81dff3fea20e
 
修改文件里的数据,再抽:
b88ee917-4d6e-4fd5-9adf-c9513fe93c9d
94e89a8a-7240-4a35-86b9-1aa5121aa72f  b248fd0b-2ff5-4fe3-a687-d93c7c6df57b
抽到DSO后激活,再看Active表与Change Log表里的数据如下:
cc7d8982-ea80-4990-b7ef-fc19cacdece5
dc83b183-4afb-4a39-a613-9cc341a3e52e
由于500那条记录没有作修改,所以这次抽取时,Change Log没有增加与它相关的数据
从Change Log可以看出,在DSO做激活时,系统会拿本次抽上来的数据与Change Log表里的数据作比对,然后生成修改过程的数据(如前像),正是因为有了Change Log表,所以AIE增量处理方式的数据源原本数据是不能直接抽到累加型的DSO与CUBE中的,但如果中间通过标准覆盖型DSO后,就可以再将数据抽到累加型的DSO与CUBE中
 
问题引出:通过DSO关键值字段默认覆盖特点,上面对修改新增都会支持的很好,如果数据源中的数据被物理删除了,那么怎么让DSO也知道呢?
其实在Transformateion中,我们可以看到Record Mode其实是技术字段,那么只要我们的上来的数据中有Record Mode这样一个字段时,实质上也是可以抽到DSO的New与Active表中的Record Mode中的:
e0b0b484-1aea-430b-a1a6-e0678bd07adf
下面我们在上面文件数据源上加上Record Mode这样一个字段:
c3b894f3-af33-4736-8750-04930d19fb28
然后在文件中也加上一列 Record Mode
685f843e-bd9c-45cd-8d33-fbbd820e12ea
然后Transformateion做一下字段映射,映射之前需要将常量修改为直接分配规则方式:
fadc62ce-df48-4b4a-8fed-abbc2d58976f
3b8e1d0c-1bb5-4006-8601-9baaf4eafc20
再开始传数据,此时PSA里的数据如下:
daab3e2c-2277-4a88-bc4c-f3bba4800e94
运行信息包后,DSO表中数据如下:
71a9b375-92b5-469a-834b-887e63098c95
此时发现将N像新增像)统一变成了X后像,即修改结果像
4d4801e5-d8bd-430a-8df9-9c79fb0bcbd4
发现Active表里少了一条数据了,即R像的数据被删除
37de7839-bef8-4f7b-8074-2249714b356f
此时Chage Log里会增加一条R像的数据,即Active中被删除的那条数据。但1001、1002都没有变化,因为转过来时的Record Mode分别为新项与后项,最后都将它们看做是后项即修改,但数据又没有发生任何变化,所以日志表里对这两条记录没有记录任何日志
 
下面来测试一下A像(累加项),在做之前,需要重新创建另外一个DSO,其金额字段转换规则需要使用累加型(默认情况下是覆盖型的,如上面的DSO):
6e54cbce-f32b-444d-8529-a825562231da
82e197a3-656a-4eba-b651-3c19ea84f7d4 744d18d6-0bc9-4ff6-a3d5-02b64de72817
再修改文件内容,都修改成后像
cef4daec-80f8-4abb-8172-747b89d2be35
在测试之前,删除数据源中PSA里以前抽的所有数据请求Request
 
再运行信息包:
b29854a9-1969-4922-979f-f49ec0e03c00
运行DTP,查看DSO的Active表:
6c39dc97-a8b0-4358-89ba-719b433eeb7a
再次运行信息包与DTP后,Active表中发现Amount累加(2倍)
f952cde8-6cfd-43fc-a2cf-bca6f2e4fa7f
Change Log表中,后像的值都是累加后的值(2倍值),而不是传过来的文件里设置的值:
2d6ae66d-0377-469c-a3ae-b06d49a605c7
 
 
下面再次修改文件,使用A像
466c8f00-3ab2-45eb-8b76-e50aa22122bc
运行信息包与DTP后,New表:
bee1848a-6071-45ea-b37c-2bd547d112d4
Active表里的数据变成了3倍
b22b5c4e-1ab1-4a59-970c-f020167ca7b0
Change Log表
e07a1a5c-9838-41bc-a54a-c27e881498b7
再运行一次信息包与DTP后:
b22c122b-8d2e-4090-a233-eaf0063b6634
d2d05372-d587-4cdf-a17a-89bf124da168
 
再修改文件成R像
e1e03f5a-ead5-4910-8e42-299b3d9660b1
运行信息包与DTP:
f959ccee-6292-4098-b63c-552d6ca0e21b
8862bc40-77c6-440e-941f-beef6ae21495
此时Active里没有数据了,发现全部被删除了:
dfe39dc8-fe3c-4282-9b93-5e4a90ed22f9
(原因:因为是R像,R像本意最终是要将记录删除的,所以Active表里的数据最后被全部删除了,既然是删除则R反冲多少已经并不重要了,重要的是要将对应的数据删除掉)
 
此时的日志表里的数据不会被删除(因为是日志表嘛,不会直接删除,它是要记录数据变化的整个过程的),但最终的结果也要与Active表里数据结果相同,即要求将最终的累计结果冲为零,所以最后加了以下三项反冲,但反冲的数值并不是我们文件中的值,而原来有多少就冲多少(即好比数据被删除了):
da1537b9-7412-406b-af0e-dc6308836bfb
posted @ 2015-02-22 09:52  江正军  阅读(4113)  评论(0编辑  收藏  举报