建模的时候呢，不要烦躁。先从建ADSO开始。先给自己打打气。
要不然看到这些乱七八糟的建模模板，会真的很气：
气多伤身啊，要淡定。当你看到一个ADSO，你要知道它就是一个二维表。也不是一个啦，是很多个。
查看ADSO的数据
假设你不认识什么ADSO，但是你系统里肯定有的。你就算直接激活BI content也是有的。我们先来看看怎么看ADSO的数据：
双击一个ADSO进去，到他的属性里面去。在DDIC下面可以看到它有很多表。至于有多少表，取决于烦人的建模属性。
这是个标准ADSO，于是它必然有三张123的inbound表，激活表和日志表。
但是我们看ADSO的数据的时候，是看7表。为啥呢？因为这个7是个view，它是包含了你可能此刻还在inbound表里没激活的数据。它是个inbound和active的集合。
除了在这里看display data以外，当然它会显示一个表咯：
还有另外一种方式：右上的data preview，会显示成一个query的样子：
这两种样式呢，也就是和你在ADSO上右键显示报表试图数据和数据预览是一个样子的。
删除ADSO的数据
现在在eclipse里面，没有删除ADSO数据的选项怎么办？
在刚才的右键上，有个：manage the datastore object,点进去到cockpit里面去。
或者你去这里：
这两个地方你将能到Cockpit里面去。这里你可以manage你的对象，monitor你的对象，还可以创建process chain。其他就干不了了。
当你点进去了manage你的ADSO了，这里就跟以前的一样了。你可以删除内容，也可以选择性删除。
从复制数据源开始
右键在你的DataSource下面，选择ERP的数据源replicate。
当你replicate的时候，会有很多不同状态的数据源：
比如说equal，是说现在数据源和你BW系统的版本一样。
compatible呢，就是说版本兼容，会覆盖掉之前在BW里面的版本。
incompatible呢，就是说版本不兼容，不会直接更新，会先删除之前的版本，然后重新复制。
这是第一种方法，你可以一次复制好多数据源。
第二种方法，去GUI里面RSDS去复制单个的。
复制完了之后，可以在eclipse的数据源中看到这样的：
这里看的很清楚啊，是个财务的数据源，在我的ODQMON那篇写了，这是个AIE类型的数据源。也就是after image extraction。delta是直接覆盖的，没有多加一条反转删除的。而且从SAP用ODP来抽取的，没有支持streaming方式。
最后的ODQ数据源会添加两个字段。这两个字段的组合决定了数据更新方式。
下面来更新数据的话，就可以走捷径：
现在你可以在这里建一个data flow object。这个里面可以建一个ADSO，但是是个空的。这个就是从底向上建模。
这个就是以前的查看数据流：默认就它自己，点击向上向下能看到它的整个流。哎，我之前不知道这两个箭头能点。。。
建模基于字段的ADSO
建了一个ADSO，会有空的转换和DTP。
此时，你要去建一个真实的：
默认是staging ADSO，我们改成标准ADSO，为啥呢，因为这个熟悉。
改完之后，就不截图了。那么从数据源直接上来的ADSO是个啥呢？它是个基于字段的ADSO：
没有信息对象的，没有和infoobject关联的。
好了，现在去激活，那将得到一个错。没有key。
这里就是奇怪了，为啥没有key呢？
如果保持是默认的staging ADSO，那么你只有inbound表，这个表里有啥呢？你去请求看的时候，会有request TSN这个是个technique key，请求编号它是个技术主键。还有package ID之类的都是技术主键。
但是一旦到了激活表，就没有请求号这个技术主键了，也就是说active表是没有主键的。那此时咋办？
要去标准ADSO里给它一个语义主键。
语义主键是和业务相关的主键，比如公司代码，凭证编号。
那么你回到details去，加key。
这里就还涉及到另外一个问题了，就是说，如果我想改这个ADSO的类型，比如我本来是staging类型的，现在要改成standard类型了。我能随便改么？
在ADSO没有数据的时候，你是可以改的，它会给你报警告，但是不是报错。但是当你有数据的时候，要么你删掉数据搞，要么用remodeling，它会给你一个remodeling的请求。
初始化请求
好了，现在你的ADSO建好了，激活后。去data flow去继续搞转换和DTP。这就很简单了。
这个有个空的转换，就直接右键建就行了，因为你这个转换还没有激活，所以没有DTP，默认是HANA runtime，在group下面适合语义组一样。错误堆栈会以你的这里的字段来分组。把同一个组的数据放到一个package里面。DTP里面也有语义组。如果DTP里面组是A，这里组是B，那么最终会是A+B作为组分类。
在转换里，有两个非常重要的界面，一个是outline，一个是properties，就开在那吧。
在这两个界面里，你能看到具体的rule。
这里面从source来到ADSO的update mode，是从ODQ的两个字段计算来的。
然后再去建一个DTP。这时候你跑了这个DTP，在header里面能看到是个初始化增量请求。
然后你去ODQMON能看到，对于这个数据源建了一个subscription。也就是初始化增量请求有了一个后续。
（但是这里也可能不止一条，对于在这个数据源queue下有很多个空的subscription的，是full请求，因为不会建subscription。如果有很多subscription的，那就有可能是别的后续DTP要求的。也是别人建的初始化请求，这种初始化请求如果被后续的往上层ADSO的DTP调用了，那么24小时候就会被reorganization job删掉，如果没有被调用，那就会在10天后被删掉。这个在我另外一篇ODQMON里面有.而且即使你删掉了DTP的initial的请求，在ODQMON这里如果你不reorganization这些subscription，它就会在那里。）
这个subscription数据会放在ODQDATA_C里。
在你的这个initialrequest里面。因为现在是inbound表，所以你可以改这个表里的数据，相当于以前的PSA.（这些只有特定ADSO支持改inbound表）
在inbound表里，key值只是请求号，业务数据主键这里没有啊。所以就算你改一些凭证编号也是可以的。那么问题就在于，一般人是不会改这些的。如果你改了这些，到激活表ADSO是会overwrite的。数据就出错了。
对于在inbound表里面的更新状态，也就是record Mode这个字段，是根据下面来的。
C是说你的record是新的。U是说你这个记录在数据源里改了。在ODQ那篇我也写了，更新是有两种情况的，一种是带反转的两条，另一种是直接覆盖。这样就会说前面一种情况是带-前象+后象，而后面是只有后象。A的不常见，但是就是个+。具体还得看。
至于两个D，一个在change log里有，一个没有。
增量请求
初始化请求完成之后，接下来就是增量请求。
那么增量请求会从ODQMON的queue里面拿数据。这里需要有增量数据，那么就是ERP那边有人新增了数据或者改了删了。当有新增操作，一方面数据会存放到底表，另一方面数据会被存储到queue里面，这个怎么进去的呢？
就是V3job去搞的。这个在另一篇LO数据源写了。LBWE。
现在如果有人去改了一个东西。改完后你去delta，也是没有的。
为啥呢？不是说进了queue了么？对于LO delta先进的是lbwq的extraction queue。而不去deltaqueue。这个就可以去LO的数据源的Job control那里去查，看Job的执行。从这里看到这个Job的Schedule频率。可能是5分钟执行一次。你要等5分钟后查看。在不在ODQDATA表。
那么对于FI的数据源呢？别搞混了，FI的数据源是没有setup表的概念的。那么这个Delta是直接从底表来的。来的时候在ODQ里面加了个时间戳。
等Job跑之后，你去ODQDATA看就有了，那么接下来，就跑个delta的DTP。
如果是ABR类型的数据源，那你的DTPrequest有两条数据。分别是U-1和U1。
在change log表还在的情况下，删除active的request之后，重抽数据来验证。