SAP BI 学习手册Word下载.docx

SAP BI 学习手册Word下载.docx

《SAP BI 学习手册Word下载.docx》由会员分享，可在线阅读，更多相关《SAP BI 学习手册Word下载.docx（14页珍藏版）》请在冰豆网上搜索。

TYPE（表示数据源的类型）

EXMETHOD：

ExtractionMethod（抽取方法）

TFMETHODS：

TransferMethods（传输方法）

ZDD_ABLE字段表示是否支持“早期增量初始化”，这个表示在初始化时候是否继续收集增量；

DETLA（DeltaProcessforaDataSource）（这个字段很重要）

增量流程是指数据的传输过程。

它指定如何在BI中确定数据目标的数据。

例如，这使您能设计出DataSource适合的数据目标、更新方法以及序列化的完成方法

从上图可以看到它有20种增量流程，我们接着开始了解下一些重要的增量流程。

增量过程字段都存储在下面这个表中。

RODELTAM表：

定义了每种增量提取方式的方法，这里的增量过程表也是需要讲解一些重要字段，方便对增量有更深入和全方位的了解。

（下面图中的X表示Yes的意思，“”空表示NO）

下图是每个字段的解释（看不懂没关系，后面会有更深入的介绍）。

好的我们继续介绍几种重要的增量流程方法的详细含义：

ABR采用前镜像、后镜像和反转镜像的更新模式，既支持覆盖又支持累加，所以数据源可以更新到DSO或者CUBE；

AIE采用后镜像模式，只支持覆盖，不支持累加，所以该类型数据源不能直接加载到CUBE，一般会先加载到DSO;

在FI-AR/AP中此种增量处理方式应用较多；

ADD只支持累加，采用的是附加镜像的更新方式，所以既可以更新到DSO又可以更新到CUBE。

一般来说：

CO的数据源都是ADD的，差额镜像，E

FI的基本都是AIE，后镜像，E

LO的基本都是ABR，这个就不用说了，很明细，新、前、后、翻转的镜像都存，量很大，D

自建的默认是AIE，同FI（BT的是没有提供更改方法，所以自建的统一都是AIE），E

主数据的一般采用AIE、AIM和NEWE，说明比较侧重结果和新增数据。

GenericDelta通用增量流程服务

如果需要，您也可以集成“通用DataSource”的增量流程。

但是，需要符合某些前提条件。

必须具有一种确认已传输数据记录的方式，以便能够确定增量。

也就是说怎么去判断记录是增量产生的。

一般来说非后勤和主数据还有自建的数据源都是GenericDelta。

输入T-Code“RSO2”进入数据源管理，如果要使用“通用增量流程”，点击下图中红圈按钮。

进入下图界面：

这个界面是做什么用的哪？

这里就是前面说的设置判断数据是否为增量数据的地方。

有四中字段类型来选择：

1Timestamp（UTC）世界通用时间

2Timestamp（Local）本地时间

3CalendarDay日历日

4NumericPointer数字指针（例如凭证编号等）

设置增量选择的安全间隔上下限

安全间隔上限

如果此值为初始值，则存在提取期间产生的记录无法提取的危险。

示例：

使用时戳指定增量。

上次读取的时戳是12:

00:

00。

下次增量提取从12:

30:

00开始。

因此，选择间隔从12:

00到12:

提取结束时，计数器设置为12:

比如文档记录的创建时间是12:

25，保存时间是12:

35。

此记录不包括在已提取数据范围之内，但下次由于记录的时戳，也不提取此记录。

为此，读取和传输数据之间的安全间隔应总是大于为此DataSource（为时戳增量）创建记录所需的最大时间范围，或应该是足够大的数据间隔（使用连续的数字指定增量）。

安全间隔下限

此字段包括必须从上次增量提取的最大值进行提取的值，以确定下次增量提取的时戳下限。

提取的数据为主数据：

仅传输后像，覆盖BI中的状态。

对于此类数据，记录可能提取到BI两次而不会出现问题。

考虑到这一情况，总是将当前时戳用作提取期间的上限：

然后，下次提取的下限不会无缝连接到上次提取的上限。

然而，它接受与此上限减去安全间隔相符合的值。

此安全间隔必须足够大，以便提取可以包含上次提取时已经收到时戳但未读取的所有值。

当然，记录或许可以传输两次，但这不会因上述原因而带来任何影响。

也可以选择增量的类型，如NewStatusforChangedReocrds（适合DSO和Cube）,AdditiveDelta（适合DSO）.

同事我们也可以查看设置增量的队列状态信息。

RSA7进入增量队列管理，如下图

上面穿插的介绍了通用数据源的增量方法。

下面接着讲解标准数据源的参数。

我们接着RODELTAM表其他字段来讲解。

增量类型字段（RODELTAM-DELTATYPE）是增量流程的属性。

它描述了如何在增量流程中加载增量。

以下特性值是允许的：

•'

'

:

未定义增量类型。

A'

DataSource使用ALE更新指针确定增量。

此方法主要与DataSource结合使用，用于SAP源系统的属性和文本中。

它也用于使通用DataSource能够提供增量值（提供基础主数据表支持通用DataSource）。

主数据的ALE更新指针已经提供了很多年。

在过去，它们用于协调SAP系统外的主数据。

D'

SAP应用程序将增量数据记录直接写入至DataSource的增量队列（“推送”）。

每条数据记录a）在保存/更新应用程序的相应事务时单独储存在增量队列中（例如，FI-AR/AP或LOCockpit中的直接增量）b）通过应用程序特定的作业写入至增量队列的增量数据记录组中（在更新事务后）。

但是，在每一种情况下，增量数据记录在执行增量更新前仍然是SAP源系统增量队列中的记录。

如果是DataSource增量更新，则读取此增量队列，并将增量队列中的数据记录传输到BI系统。

此增量类型通常用于通过字段或控制表无法为基础应用程序表确定增量数据记录的应用程序中。

E'

DataSource在请求时通过提取器确定增量。

这表示请求时提取器必须能够为DataSource提供增量记录（“拉取”）。

提取器将已经确定的增量数据记录放在增量队列中，然后再从增量队列中传输到请求的BI目标系统。

如果已经为多个BI系统执行了增量初始化，或为同个BI系统执行了多次增量初始化，则提取器必须加载所有增量初始化的增量记录，并将增量记录保存在特定于BI目标系统的所有增量队列中。

此增量类型通常用于通过字段或控制表能够为基础应用程序表确定增量数据记录的应用程序中（例如，每个增量记录的时戳信息）。

•‘F‘:

通过平面文件加载增量数据记录。

这种增量类型仅用于平面文件源系统的DataSource中。

在执行InfoPackage时，将平面文件导入到PSA。

然后开始数据加载流程。

这里不使用增量队列。

这里再穿插介绍下平面文件的增量流程。

重要的DeltaType：

DGenericDeltaforServiceAPI---PUSH方式

EExtractorDeliversOLTPSourceDelta---PULL方式

序列化请求DREQSER字段。

下图是是增量流程中的序列化请求的3种方式。

1无序列化。

2对请求序列化。

3对数据包的序列化。

通过上面学习我们知道了：

一个数据源支持什么样的增量更新；

数据能更新到什么样的对象中；

增量更新的类型和序列化方式；

我们来简单列一下增量提取的操作步骤：

1分析要提取的数据源（RSO2），然后查看其是否可以做Delta，它的增量流程用哪个，增量类型用哪个，增量怎样序列化。

2到BI数据源（RSA1）进行复制数据源。

3创建InfoPackage，对其进行增量参数选择，要匹配在R/3数据源端的配置。

4然后抽取数据到对应的DSO或者Cube中。

现在记录模式描述了数据记录包含的更改类型。

各种增量流程间的差异是每个增量流程仅支持七个可能特性值的子集。

如果DataSource实施的增量流程使用多个特性值，则字段ROCANCEL（保存记录模式）自动成为此DataSource的一部分。

DataSource的此字段会分配到BI系统的InfoObject0RECORDMODE中。

特性值如下：

记录提供后像。

在更改记录或添加数据后传输记录状态。

只有在请求相应的前像时，才会将记录直接更新到InfoCube（稍后解释）。

X'

记录提供前像。

在更改或删除记录前传输记录状态。

所有可以汇总（关键值）的记录属性必须用加/减冲销符号进行传输。

冲销加/减符号由提取器（缺省）或服务ServiceAPI负责。

这些记录在DataStore对象的非附加（覆盖）更新中予以忽略。

前像补充后像。

记录提供附加图像。

如果属性可以集合，则仅传输更改。

如果属性无法集合，则传输数据更改或创建后的状态。

记录可以无限制地更新到InfoCube，但需要对DataStore对象进行附加更新。

记录必须删除。

仅传输代码。

此记录只能更新到DataSource对象（因此DataStore也���能更新到DataSource对象）。

R'

记录提供倒像。

此记录的内容与前像相同。

唯一的区别是更新DataStore对象时：

删除代码相同的现有记录。

N'

记录提供新像。

此记录的内容与没有前像的后像相同。

创建记录时，应传输新像而不是后像。

新像补充倒像。

在表RODELTAM中，可以确定增量更新（列UPDM_NIM、UPDM_BIM、UPDM_AIM、UPDM_ADDUPDM_DEL和UPDM_RIM）所使用的特性值。

该表必须确保增量流程中只使用上述有用的特性值组合。

在以“增量更新”模式提取数据时，使用增量流程的DataSource仅为记录模式提供增量流程中指定的、已提取记录的特性值。

文件增量流程

如果增量流程使用平面文件，数据不会通过增量队列传输到BI。

而是直接从DataSource加载到PSA。

在此平面文件DataSource的传输规则中设置的增量流程必须得到关于基本数据和其增量属性的通知。

FIL0增量数据（后像）

FIL1增量数据（增量图像）

LO增量流程

LIS的更新方法（早期更新方法）：

同步更新（V1）：

DELTA队列与凭证同步更新，如果DELTA队列写入出现错误，那么凭证也被取消。

异步修改（V2）：

与V1相比，写入DELTA若出现错误，不对凭证的保存产生影响。

异步收集更新（V3）：

与做凭证没有关系。

在后台定义一程序，定时运行，收集产生变化的数据到DELTA队列。

知道了早期3种更新模式后，再来看LBWE中的几种增量模式：

DirectDelta:

这就是一种V1模式，数据同步更新到增量队列，这种模式系统负荷很重，特别是对于业务量大的凭证；

这是一种V1，直接V1到DeltaQueue，我们目前的LO数据源统统采用这个；

“直接增量”的好处与属性：

•通过在V1过帐流程中写入增量队列，使用应用程序的排队概念来保证按凭证进行的序列化。

•对于凭证较少的客户，如果在重组期间的初始化流程和增量初始化请求中出现停机时间，则建议采用该流程。

•此流程会比V3或“队列化增量”更加重V1的负担。

对于具有上述凭证数量的客户，这实际上并不是一个因素。

•提取与V2更新无关。

•对更新数据或提取队列进行其他监控是没有必要的。

QueuedDelta：

类似于V3的更新模式，与V3更新的区别在于，数据先被收集到一个抽取队列中（V1模式），然后被送到增量队列（V3模式）。

QueueDelta:

这是一种混合型，先V1到ExtractionQueue，后V3到DeltaQueue；

借助于此更新模式，在提取队列中收集受影响应用程序中的提取数据，而不是在更新数据中收集，并且可以将这些提取数据通过更新集中运行以类似于V3更新的方式传输到增量队列。

根据应用程序，可以将多达10,000次的凭证增量提取集中到每DataSource增量队列中的LUW。

“队列化增量”的好处和属性：

•通过在V1更新流程中写入提取队列，使用应用程序的排队概念来确保按凭证进行的序列化。

•由于在定期处理（SAP建议每小时执行一次）的提取队列中收集数据，所以特别建议凭证数量很多的客户采用该流程。

•收集运行使用与以前相同的报告（RMBWV311,...）。

•在初始化过程中，在增量初始化请求过程中收集新凭证数据会减少重组运行的停机时间（填充设置表）。

•V1比V3更难使用。

•与V3集中运行相比，该集中运行可实现最后的目标，且可以安排后续流程。

在完成应用程序的集中运行后，会自动触发可以在后续作业开始时使用的事件（&

MCEX_11,...）。

UnserializedV3Update：

此类型的最大特征是没有序列化，就是说增量队列中凭证是无序的，这个对于采用覆盖模式的模型来说是最致命的，所以如果目标队列是DSO的话，还是不要采用这种模式好。

这是一种V3，先V3到UpdateTable，后V3到DeltaQueue。

借助于此更新模式，将正在查看的应用程序的提取数据写入含有V3更新模块的更新表，这些数据在使用更新集中运行读取和处理之前会一直保留在该更新表中。

不过会从更新表读取更新集中运行中的数据且不考虑顺序，然后将其传输到增量队列。

三种增量区别，你参照小结里的这些内容

直接增量V1：

order（VA01）--->

deltaqueue（rsa7）

队列化增量V2：

order（va01）--->

extractorqueue（LBWO）--->

jobcontrol（LBWE）--->

未序列化的V3：

order（VA01）-updatetable（SM13）--->

deltaqueue（RSA7）updatetable--->

deltaqueue