处理链加载数据出错的可能原因-process chain loading error

处理链最底层，那就是别的系统的数据。
以最常见的ECC系统为例。

当我去跑处理链，那么数据其实是从ECC系统过来的。
ECC系统和我们的BW系统之间是通过RFC连接的。SM59可以查看。
当然这些都是Basis组的人干的。

当我这个ECC系统每周或者每月进行一次更新维护的时候，是有RFC断连的可能的。
那么我们这边就会有连不上源系统的这么个错。
这个可以去检查：

如果connection fail了，那么让basis的人帮忙了。让他们重建这个连接。
或者有一种可能是ECC dump了，那就是大面积处理链错误。

那么当我去正常跑数据的时候，其实去ECC系统去要数据，首先肯定是要通过RFC用你自己的账户去登录人家的ECC系统的，然后再在人家的系统建一个job。
这个job就是去人家的源表要数据了，然后把数据准备成一个data package的样式，就是idoc。这些格式的数据就会被传送到BW里面来。然后BW会告诉ECC，好了，我收到这些数据了，那么这个通话过程就结束了。
这就回到我上次看到的那个DTP错误了。现在都没有infopackage了。
那么我怎么去看这个在ECC系统里面的job呢？
我是要去看这个DTP么？

这个问题的根源就在于，如果我这个DTP跑失败了。那么我怎么去查看它对应的在ECC系统里面的job是怎么了。如果ECC的job成功了，那这个失败就是我BW这边的问题了。如果是它的job失败了，我还能再去查看ECC的问题。

如果还是基于用infopackage, 可以在environment下面的job 里面去查看source 的job。
但是现在用DTP，是在源系统的ODQMON里面去看：
现在用的是ODP方式。在ECC的DTP里面能够看到后台JOB。点头上那个小绿色的job就能看到。


从SM37去看这个job,后台用户名都是我们RFC连接ECC的那里的名字。
这个里面一个个BEGIN end的就是一个个的数据包。一个包多少条也有。
关于这里面的
我就有点疑惑了，暂时我也不能解释，因为在这个exit里我也没有啥code啊？暂时不理解。

再往下，万一job没有起来，或者被cancel掉了。有可能是系统原因，那你可以叫basis查看下到底啥问题。
可能是啥问题呢，可以先去SM51看下系统server。
有多少server，每个server里有多少dialog进程，有多少background进程。

这些进程就是说，系统现在要干的活的人手还有多少。
谁正在干啥。
对于DTP来讲，它都要background的人给它干活，其他不需要的。
那么一个DTP，需要多少进程？
这个在这里能看到：最少要3个进程。

你去看DTP request的job，能看到有三个：

如果此时好多DTP在跑，那么有可能你的background process就不够了，那咋办，就只能去等，等有空的process出来。那么这个job再去占用process，如果一直等不到，到一定时间阈值，那就会出错了。

所以说有可能你DTP跑不了了，出错了，是background process不够了的原因。
这个process是可以根据时间来调整的，这个是basis的活，早上background job少，晚上background job多。

但是process数量是有限制的，每个process都是要占内存的，不是说能随便增加process数量的。
dialog的是我登录系统会有的。

到这里就会有一个问题了，如果我的Delta DTP出错了，变红了。那么下一步怎么办?
在处理链里，是直接修复的。修复的操作是回到之前请求的时间戳，或者是pointer，去把所有的数据再取一遍出来。

以前是去取LUW（logical unit of work）数据。（就是数据库的插入，更新，更改和删除的操作单元，LUW在commit之后来更改数据库）这个LUW是在UPDATE的进程里弄的。
现在也还是这么个意思。

如果你直接进到DTP里面去手动执行，那它会提醒你要删掉之前的红色请求。实际是一样的操作。
再往里聚焦到这个DTP出错，有哪些可能呢？
下面这个是SubStep End routine，说明错出在了转换的routine里面。这些咱们写的code出了错。
有可能是啥错？

我这个错是因为现在用BW Modeling Tools，结果每次我打开只能是Edit，如果我直接关上，状态就会被变成更改。然后再执行DTP就会出这个错。
或者也有可能是ABAP Code有错。

除了这些错，还有可能是Master data错。
一般情况下，我们都是先抽主数据，再抽交易数据。
但是有些情况是在交易数据里有个我们主数据里没有的新主数据，这时候就会报错了，交易数据想要给这条新的创建一条记录。但是转换里头说不行，我主数据里没有，我要把好这个门，不给你交易数据进来。
比如说销售组,主数据只有G01,G02,G03，但是你交易数据里头有个G04，我抽数据到inbound表没问题，但是激活DSO的时候就会有问题了，SID无法生成的问题。
这种问题，如果交易数据有效G04真实存在那就再跑一遍主数据然后来重新激活。如果无效那就去删掉这条数据。或者在inbound表里改下这条数据。

也就是以前的参照完整性。每条数据都必须检查它的主数据在不在我的主数据表里。
如果不在就重抽主数据表。

一般这种需求是源系统不是R3的，从文本来的，可能有重复主数据的，错误主数据的。
DSO激活的时候，就会检查SID表，然后创建出一条新的。

还有一种可能就是BW这边后台process不够了。如果你后台background进程只有15个，你一个DTP要用3个，但是你处理链里并行了6个DTP，那么同时跑的话，有一个DTP就要等进程，可是万一你那几个DTP都跑了很久，超过了等待阈值时间，那你这个第6个DTP就会报没有资源的错了。

再有一种原因就是传输转换的时候，把DTP搞失活了。
因为反正DTP不传，都用RSDG_TRFN_ACTIVATE来直接激活。
所以有时候给搞失活了。那就得去再激活一下。

这个是因为我们在生产上要经常修改DTP的过滤值啊，而且SAP它就是提供更改选项给DTP，所以会有这个问题。

还有一个错是啥错呢？就是你昨天的DTP出错了，有个RED。那你就会有个LOCK的错。就是previous request has status “red”.

除了这种被前一个错的锁住了的问题，当然如果删除前一个就能解决，那就很好。如果前一个DTP有啥错误指示，那就去解决了再重抽。

另外一种lock就是你有两个DSO可能都正在跑。你DSO2要从DSO1有个look up在routine里面要去取它的主数据啥的。
但是此时DSO1还正在抽取数据，要准备激活呢，这时候系统会给DSO1上锁。说我正在往DSO1里写数据，所以其他人不能读，那么你DSO2此刻正在读DSO1的数据的话，那就会有个lock的错。这个lock的错是在DSO2等着读的时间阈值到了，就会有这个错。如果在等着读的时间阈值内，就不会有这个错。

如果不是从routine里面去lookup的话，也有另外一种可能就是你DSO2直接去从DSO1读数。
这个也是看时间点的，当你DSO1的DTP刚跑，数据在往new table表进的时候，如果此时DSO2的DTP执行delta（从 change log表读数），或者执行Full（从active表读数）这两种都不会有错。
但是当你DSO1的DTP请求到执行active的时候，那系统就会锁住DSO1的active表和change log表，这时候DSO2的DTP在执行，那就会在等待读的时间过了之后报一个lock的错。

最后就是可能会有个ST22的memory allocation错，当你去执行DTP的时候，系统会分配memory给你这个进程。系统只有1GB给你跑logic，但是你这个DTP执行的时候需要2GB的buffer memory，那就会报错。
那你就得去你的routine里面看看你select的表的行数放到内表里的，是不是太大了。要不要加点过滤值。内表最大只能给分配2GB好像。
ST22进去看ABAP runtime error就有可能看到这个。那error可老多了。

比如什么offset error。什么field symbol error。这些都是ABAP code的错。
比如你20220607+6(2)是有的，万一你传输过来的是2022，那就取不到offset值了，就报错。
比如你field symbol指向被删。