BW:SAP STMS配置
1、SM59，删除所有包含STMS的连接
2、STMS，Overview-System，删除所有配置
3、登陆至Client 000
| UserName | SAP* |
| PassWord | Pass |
4、STMS，新建传输控制域，新建Visual System
配置Transport Routes，
BW:EU_INIT, EU_REORG, EU_PUT Canceled
SAP Note 18023
Jobs EU_INIT, EU_REORG, EU_PUT
if you have problem, search oss note like
Multiple scheduling of the jobs EU_PUT and EU_REORG
SAP Note Number: 174645
Symptom
What are the jobs EU_INIT (program SAPRSEUC), EU_REORG (program SAPRSLOG), and EU_PUT (program SAPRSEUT), which are automatically scheduled by the ABAP Workbench, used for?
Other terms
SE80
Reason and Prerequisites
The EU jobs are used to reconstruct or update the indexes (where-used lists, navigation indexes, object lists) that are important for the ABAP Workbench.
Solution
When you start transaction SE80 for the first time, the three EU jobs are scheduled automatically: EU_INIT (single start), EU_REORG (periodically each night), and EU_PUT (periodically each night). Alternatively, You can also schedule the three jobs by manually executing program SAPRSEUJ.
Short description of the individual jobs:
EU_INIT:
EU_INIT is used to completely rebuild the indexes and therefore has a correspondingly long runtime. It starts program SAPRSEUI. All customer-defined programs (selection according to the naming convention) are analyzed, and an index is created that is used in the EU for the where-used lists of function modules, error messages, reports, and do on. This index is automatically updated in dialog mode. The job can be repeated at any time. After a termination, the job is automatically scheduled for the next day; it then starts at the point of termination. (EU_INIT can therefore be terminated deliberately, if it disturbs other activities in the system.)
EU_REORG:
As mentioned above, the indexes are automatically updated online by the tools. To keep the effort for updating these indices as low as possible, only the changes are logged, which means a reorganization of the complete index for each program is required from time to time. So that this reorganization does not interfere with the online system, the EU_REORG job runs every night and performs this task. If the EU_REORG job did not run one night, this simply means that the reorganization takes place more often online.
EU_PUT:
The EU_PUT job also runs every night. It starts program SAPRSEUT. This program checks whether customer-defined development objects have been transported into the SAP system with the SAP transport system, and generates or updates the indexes described above whenever required.
To create the indexes, the EU jobs analyze the program sources of the development objects. Faulty ABAP programs (sources with grave syntax errors, for example, a literal that is too long because a concluding inverted comma is missing) are skipped. The relevant job continued the analysis with the next program and issues the names of all programs with errors in a list.
After correcting the faulty programs, you can update the object lists of the relevant programs in the Repository Browser. To do this, proceed as follows:
Up to Release 6.10: Choose “Update”.
As of Release 6. 20: go to context menu “Other functions”->”Rebuild object list”.
源文档 <https://forums.sdn.sap.com/thread.jspa?messageID=2813006?>
Queries
RSZELTDIR Directory of the reporting component elements
RSZELTTXT Texts of reporting component elements
RSZELTXREF Directory of query element references
RSRREPDIR Directory of all reports (Query GENUNIID)
RSZCOMPDIR Directory of reporting components
Workbooks
RSRWBINDEX List of binary large objects (Excel workbooks)
RSRWBINDEXT Titles of binary objects (Excel workbooks)
RSRWBSTORE Storage for binary large objects (Excel workbooks)
RSRWBTEMPLATE Assignment of Excel workbooks as personal templates
RSRWORKBOOK ‘Where-used list’ for reports in workbooks
Web templates
RSZWOBJ Storage of the Web Objects
RSZWOBJTXT Texts for Templates/Items/Views
RSZWOBJXREF Structure of the BW Objects in a Template
RSZWTEMPLATE Header Table for BW HTML Templates
BTW: There are only 26,000 tables in our small installation of BW 3.5.
Posted In: admin , bex , char , delta , elem , event , genuinid , global , infopak , init , lbwq, qrfc , query , rsa7 , settings , tables , text , varia , variant , workbook . By Srinivas Neelam
Custome Infoobjects Tabels:
/BIC/M — View of Master data Tables
/BIC/P — Master data Table, Time Independent attributes
/BIC/Q — Master data Table, Time Dependent attributes
/BIC/X — SID Table, Time Independent
/BIC/Y — SID Tabel, Time Dependent
/BIC/T — Text Table
/BIC/H — Heirarchy Table
/BIC/K — Heirarchy SID Table
Standard Infoobjects Tabels(Buss. Content):
Replace “C” with “0″ in above tables.
Ex: /BI0/M — View of Master data Tables
Standard InfoCUBE Tables :
/BI0/F — Fact Table(Before Compression)
/BI0/E — Fact Table(After Compression)
/BI0/P — Dimension Table - Data Package
/BI0/T — Dimension Table - Time
/BI0/U — Dimension Table - Unit
/BI0/1, 2, 3, …….A,B,C,D : — Dimension Tables
BW Tables:
BTCEVTJOB – To check List of jobs waiting for events
ROOSOURCE — Control parameters for Datasource
ROOSFIELD – Control parameters for Datasource
ROOSPRMSC — Control parameters for Datasource
ROOSPRMSF — Control parameters for Datasource
– More info @ ROOSOURCE weblog
RSOLTPSOURCE – Replicate Table for OLTP source in BW
RSDMDELTA – Datamart Delta Management
RSSDLINITSEL, RSSDLINITDEL
– Last valid Initialization to an OLTP Source
RSUPDINFO — Infocube to Infosource correlation
RSUPDDAT – Update rules key figures
RSUPDENQ – Removal of locks in the update rules
RSUPDFORM — BW: Update Rules - Formulas - Checking Table
RSUPDINFO — Update info (status and program)
RSUPDKEY — Update rule: Key per key figure
RSUPDROUT — Update rules - ABAP routine - check table
RSUPDSIMULD – Table for saving simulation data update
RSUPDSIMULH — Table for saving simulation data header information
RSDCUBEIOBJ – Infoobjects per Infocube
RSIS – Infosouce Info
RSUPDINFO — Update Rules Info
RSTS – Transfer Rules Info
RSKSFIELD – Communication Structure fields
RSALLOWEDCHAR – Special Characters Table(T Code : RSKC, To maintain)
RSDLPSEL – Selection Table for fields scheduler(Infpak’s)
RSDLPIO – Log data packet no
RSMONICTAB – Monitor, Data Targets(Infocube/ODS) Table, request related info
RSTSODS — Operational data store for Transfer structure
RSZELTDIR – Query Elements
RSZGLOBV – BEx Variables
RXSELTXREF, RSCOMPDIR – Reports/query relavent tables
RSCUSTV – Query settings
RSDIOBJ – Infoobjects
RSLDPSEL — Selection table for fields scheduler(Info pak list)
RSMONIPTAB – InfoPackage for the monitor
RSRWORKBOOK – Workbooks & related query genunid’s
RSRREPDIR – Contains Genuin id, Rep Name, author, etc…
RSRINDEXT – Workbook ID & Name
RSREQDONE – Monitor: Saving of the QM entries
RSSELDONE – Monitor : Selection for exected requests
RSLDTDONE – Texts on the requeasted infopacks & groups
RSUICDONE – BIW: Selection table for user-selection update Infocubes’s
RSSDBATCH – Table for Batch run scheduler
RSLDPDEL – Selection table for deleting with full update scheduler
RSADMINSV – RS Administration
RSSDLINIT — Last Valid Initializations to an OLTP Source
BTCEVTJOB –To check event status(scheduled or not)
VARI – ABAP Variant related Table
VARIDESC – Selection Variants: Description
T Code : SMQ1 –> QRFC Monitor(Out Bound)
T Code : SM13 –> Update Records status
T Code : LBWQ –> QRFC related Tables
TRFCQOUT,
QREFTID,
ARFCSDATA
SAP Data Dictionary用表
DD02L - SAP tables
DD02T - R/3 DD: SAP table text
DD03L - Table Fields
DD03T - DD: Texts for fields (language dependent)
EDD04L - Data elements
DD04T - R/3 DD: Data element texts
DD01L - Domains
DD01T - R/3 DD: domain texts
DD07L - R/3 DD: values for the domains
DD07T - DD: Texts for Domain Fixed Values (Language-Dependent)
Transparent tables can be identified using DD02L-TABCLASS = ‘TRANSP’.
1 同一个变量名的UID可能有多个，记得注意
2 在查找时要注意技术名称还是名称，因为查询时会在两个中进行，模糊查询时要细心，FV与V都可以查到
3 复制的时候注意长度，过长的会不能显示
4 开着Query不能删除
5 se01 Transport Organizer
6 行列只是用来放特征和关键值
7 行和列都是死的是固定报表，行和列都是灵活的是灵活报表，行或列有一个是死的，有一个是灵活的是半灵活报表
8 SAP portal增量链接的时候别忘记打开目的地，不然不会显示菜单的
9 P采购 purchasing，I库存 inventory
10 传输请求的时候，DSO传输过，转换会变灰，就是说底层变，上层会有问题
11 M版本不等于A版本，可能是修改以后没有激活
12 SID — Surrogate-ID
13 YTD，QTD，PTD 年初至今，季初至今，期初至今
14 BOM 物料清单
15 报表和BEx请求要进ZBW_LYHG包，其余的都进ZBW包
16 请求出错，到英文系统看明细日志
17 mb51，收+，发-
18 312为测试系统，300-302，200-222
19 收集转换的时候要收集例程，收集DTP的时候要带信息包
20 se03 显示/更改命名空间，可以看到类似于/BIO/ /BIC/的文本描述
/BI0/ 业务信息仓库：SAP 命名空间 SAP AG Walldorf
/BIC/ 业务信息仓库：客户命名空间 客户名称空间
21 有时候，结果行的显示会有错误，可以再Query里将 计算结果 改为 合计
22 主链修改后需要计划之，即执行
23 做完报表要传Portal的
24 用户出口：SD，绑定给一个，不能重用；客户出口，ALL；BTE业务交易事件，FI；BADI业务附加(NEW)，用户出口与BTE的结合
25 RRM_SV_VAR_WHERE_USED_LIST_GET
26 01交易数据，02主数据，03层次，04空
27 压缩：F事实表压缩至E事实表，压缩之后F表清空，直接从E表取数，加快速度。如果有聚集，要先上传至聚集，再压缩。
28 开发类：逻辑上相关的一组对象，也就是说，这组对象必须一起开发、维护和传输
本地对象：将对象指派给$TMP，不可传输到其他系统
自建开发类：以Y或者Z开头
29 CCMS: Computer center Management System
30 TCODE: SSAA
31 关于DB Statistics，计算统计数据时，SAP_ANALYZE_ALL_INFOCUBES
使用的信息立方体数据量<=20%时，BW将会使用10%的信息立方体数据来估计统计数据，
否则，BW将计算实际的统计数据。此时，Oracle PL/SQL包DBMS_STATS就是更好的选择，如果可能会调用并行的查询来收集统计数据；否则调用一个顺序查询或者ANALYZE语句。索引统计数据并不是并行收集的。TCODE: DB20
32 每次加载数据时，自动刷新统计信息：Environment–>Automatic Request Processing
33 分区查看：SE11–>Utilities–>Database Object–>Database Utilities–>Storage Parameters–>Partition
34 分区管理：打开Cube–>Extras–>DB Performance–>Partitioning，来个例子，很简单的解释，很透彻
我选择额的是0CALMONTH，按月来分区：
Example
Value range for FYear/Calendar Month
- from 01.1998
- to 12.2003
6 Years * 12 Months + 2 = 74 partitions will be created (2 partitions for values that lie outside of the range, meaning <01.1998 or > 12.2003).
35 如果可能，在传输规则而不是更新规则中执行数据的转换。传输规则：PSA–>DSO，更新规则：DSO–>Cube
36 考虑使用数据库的NOARCHIVELOG模式
37 将实例的描述参数rdisp/max_wprun_time设置为0，允许对话工作进程占用无限的CPU时间
38 加载交易数据时：
1、加载所有的主数据
2、删除信息立方体及其聚集的索引
3、打开数字范围缓冲（Number range buffering）
4、设置一个合适的数据包大小
5、加载交易数据
6、重建索引
7、关闭数字范围缓冲
8、刷新统计数据
39 事实表命名：</BIC|/BIO>/F<信息立方体名>，同理，E事实表
| </BIC|/BIO>/D<信息立方体名>P | 数据包维度 | Package |
| </BIC|/BIO>/D<信息立方体名>T | 时间维度 | Time |
| </BIC|/BIO>/D<信息立方体名>U | 单位维度 | Unit |
40 SID：Surrogate-ID（替代标识）
| </BIC|/BIO>/S<特征名> | SID表 |
| </BIC|/BIO>/P<特征名> | 主数据表 |
| </BIC|/BIO>/T<特征名> | 文本表 |
| </BIC|/BIO>/H<特征名> | 层次表 |
| </BIC|/BIO>/I<特征名> | 层次表I |
| </BIC|/BIO>/K<特征名> | 层次表K |
| </BIC|/BIO>/S<特征名> | 层次表S |
| </BIC|/BIO>/M<特征名> | 主数据视图 |
维度表和SID表之间，主数据表和SID表之间，都是虚线关系，虚线关系表示由ABAP程序维护，不受到外键补充。使得我们能够加载交易数据，即使数据库中不存在任何主数据也可以。Always update data, even if no master data exists for the data!
41 BW多种建模，参照BW Accelerator, Multi-Dimensional Modeling with BW
42 维度特征 or 维度属性：
1、如果**数据包含在交易数据中，那么应将**用作为维度特征，而不要用做维度属性。
2、如果**频繁用于导航，那么应将**用做维度特征，而不要用做维度属性。
43 维度：
1、如果特征具有一对多的关系，那么应将它们组合在同一维度中。
2、如果特征具有多对多的关系，那么应将他们组合在不同维度中。（合并关系很小除外）
44 复合属性（组合属性 Compounding）：
除非绝对必要，不要采用复合属性，代价比较大。
理解：IO_HOUSE拥有一条White house的记录，为了区别是来自政府源系统还是家居网站，将IO_HOUSE和0SOURCESYSTEM复合起来澄清特征的具体含义。
45 线性项维度：
如果维度只有一个特征，可以设为线性项特征。导致并未创建维度表，关键字是SID表的SID，事实表通过SID表连接到主数据、文本和层级表，同时删除了维度表的一个中间层，提高效率。
46 粒度（Granularity）：信息具体的程度
47 PSA：数据以包为单位进行传输
48 IDoc：数据以IDoc为单位进行传输，字符格式中，传输结构不能超过1000字节
49 BW收集传输数据步骤：
1、BW传递一个加载请求IDoc给R/3
2、在加载请求IDoc触发时，R/3将启动一个后台任务。后台任务从数据库中收集数据，并保存在事先定义好大小的包中
3、收集了第一个数据包以后，后台任务启动一个对话工作进程（如果可用），将第一个数据包从R/3传递给BW
4、如果需要传递更多数据，后台工作将继续收集第二个包的数据，而不必等第一个数据包完成其传递过程。收集完毕发送
5、在前面的步骤进行时，R/3传递信息IDoc给BW，通知BW数据抽取的传输状态
6、按照上面的方式过程继续进行，直到所有请求的数据得以传输和选择
因此，信息包的大小很重要
上面两张图，一个是表ROIDOCPRMS，里面存储的是关于信息包的设置
设置方法：SBIW–>General Settings–>Maintain Control Parameters for Data Transfer
另一个是数据抽取的过程：几个IDoc的Info status分别是：
| 0 | Data request received |
| 1 | Data selection started |
| 2 | Data selection running |
| 5 | Error in data selection |
| 6 | Transfer structure obsolete, transfer rules regeneration |
| 8 | No data available, data selection ended |
| 9 | Data selection ended |
这里的几个状态分别为：
| Info IDoc 1 | Info Idoc 2 | Info Idoc 3 | Info Idoc 4 | Info Idoc 5 |
| 0 | 1 | 2 | 2 | 9 |
很简单的逻辑，收到请求，开始数据选择，一直跑一直跑，一直跑到结束
50 加载数据到InfoCube时，会使用数据范围缓冲（Number range buffering）
是通过数据范围对象（Number range object）来实现的。
设置方式：
SE37–>RSD_CUBE_GET–>I_INFOCUBE和I_BYPASS_BUFFER=X–>E_T_DIME–>NOBJECT–>SNRO–>Edit–>Set-up buffering–>Main memory
也许会用到的是SE03–>Set System Change Option–>General SAP name Range=Modifiable
例子里设置的是500
51 对SAP传输，自己有一点点小的见解
| D系统 | Development | 开发系统 |
| Q系统 | Quality Assurance | 质量保障系统 |
| P系统 | Production | 生产系统 |
释放：从技术角度来讲，释放一个传输请求实际上就是把传输对象从传输请求中导出。
52 状态：
| D | SAP传输（Delivery）状态 |
| A | 活动（Active）状态 |
| M | 修改（Modified）状态 |
安装BC的时候，选Install，覆盖A状态；选Match，无操作；都选，合并（未必全合并）
53 STMS Transport Management System
54 InfoCube 类型：
| Basic Cube | 基本CUBE |
| Multi Cube | 多立方体 |
| SAP Remote Cube | SAP远程立方体 |
| Gen Remote Cube | 一般远程立方体 |
55 工作簿在数据库中保存为二进制大对象（Binary Large Object， BLOB）的。
56 BW场景：
| Today-is-yesterday | 时间>当前 |
| Yesterday-is-today | 时间<当前 |
| Yesterday-or-today | |
| Yesterday-and-today |
57 对于主特性，聚集中能采用SUM、MIN和MAX而不能采用AVG
58 Info Cube层级设计：
依赖于时间的整体层级
维度特征
依赖于时间的导航属性
59 D包不要把灯从黄色改成绿色，可是适当的改成红色，如果没有数据传输的话。尽量不要改
60 尴尬，NWDS 和 WAS一定要是同一个版本才行，很烦人啊很烦人，另外Notes号码是：718949
61 DSO，三个表
| A表 | 激活后的数据 |
| LOG表 | 存放数据详细动作，用于上载到CUBE |
| N表 | 数据抽取到DSO后存放在N表，激活后清空 |
62 DSO分为覆盖和合计两种，在转换中点Detail，双击Key Figure，可以选。
63 DTP：
如果是单转换，会有：
语义组（错误堆栈关键字段选择），会有包大小的选择（一般为5w），执行的处理模式为连续提取，立即平行处理
如果有信息源，则：
没有语义组，包大小与源中的包大小一致.在运行时间动态确定，执行的处理模式为连续提取和源包的处理（这俩是一个意思）
64 Variable Processing By:
Manual Input/Default Value
Replacement Path
Customer exit
Authorization
65 Cube<–DSO
| DELTA | LOG表 |
| FULL | A表和LOG表 |
66 BW3.5的数据包直接上载，是不生成请求的
67 BW报表权限：角色中的业务智能分析权限
业务浏览器 - 业务浏览器可重复使用的 web 项目 (NW 7.0+)
业务浏览器 - BEx Web 模板(NW 7.0+)
业务浏览器 - 组件
业务浏览器 - 组件: 对所有人的增强
业务浏览器 - 数据访问服务
68 制作进程链的时候，要注意3.5的DSO，他们会选择自动激活和自动更新
69 几种DSO:
-
标准数据存储对象
- 使用数据传输进程提供的数据
- 可以生成的主数据标识值
- 在激活期间集合了带有相同代码的数据记录
- 激活后数据可用于报告
-
写优化的数据存储对象
- 使用数据传输进程提供的数据
- 不能生成的主数据标识值
- 未集合带有相同代码的记录
- 装载数据后此数据后可立即用于报告
-
直接更新的数据存储对象
- 使用应用程序接口提供的数据
- 不能生成的主数据标识
- 未集合带有相同代码的记录
关于更多信息, 请通过以下路径参阅 SAP 库:
http://help.sap.com/saphelp_nw04s/helpdata/en/F9/45503C242B4A67E10000000A114084/content.htm
70 千万不要忘记主数据的Change Run
71 激活的时候，要求有连续性，就是从第一个开始，到最后一个结束，前置的请求必须执行
72 主数据有权限相关，可以细分权限，权限TCode：RSECADMIN
73 激活的时候，默认会把一起激活的数据放在一个请求里
74 Reconstruction，重新建造是针对3.5的抽取来讲的，请求到达其下级的时候，这里会显示传输结构状态为成功
数据目标中有效的请求为 失败，点重建或插入，则类似于执行DTP操作，填充数据
75 几个处理后台事务的TCode：
| SE06 | 全局配置 |
| SCC4 | 集团配置 |
| SM59 | RFC配置 |
| STMS | 传输配置 |
| SU02 | 参数文件（权限） |
| SM50 | 后台进程控制 |
| SM21 | 系统日志 |
| ST11 | 轨迹日志 |
| ST22 | ABAP Runtime Error |
| SM37 | 作业选择 |
| ST04 | 后台监控 |
| ST06 | OS监控 |
| ST06N | OS监控 |
| ST05 | 执行分析（追踪） |
| SM30 | 初始屏幕 |
| SM64 | 事件历史 |
| SM51 | SAP Server |
76 几个财务的TCode：
| VF03 | BILLING凭证 |
| VA43 | 合同 |
| VA03 | 销售凭证 |
| FD10N | 客户余额 |
77 货币转换步骤：
RSUOM设置，然后到Query里这是Conversions
Unit Conversion：Conversion Type和Target Unit选上
78 InfoSet的outer join是需要谨慎操作的，不然会出大问题
79 关于SAP与其他程序的接口，我有了一点新的理解：
从外部到SAP，可以调用BAPI，如果外部也是SAP就CALL FUNCTION，如果外部不是SAP，就用.NET或者JAVA来做
还可以写在EXCEL里，做个任务，定期执行
从SAP到外部，可以让外部掉BAPI，取数
80 查用户名：USER21，USR12，ADRP
81 RRM_SV_VAR_WHERE_USED_LIST_GET
82 RSBBS，可以设置从一个Query跳转到另一个Query
83 RSDS，迁移回3.X必备
84 取一个月的最后一天，可以使用FM：
SLS_MISC_GET_LAST_DAY_OF_MONTH
85 维度越多，Cube可以合并的数据就越少，效率就越低
86 对于单价这种KF，可以做成特性，因为Cube对同样的数据只能做合计，而DSO却可以覆盖
96 DSO能做分区么：在SP13以及之前是可以的（Write-Optimized DSO是按照请求号）
DSO能做聚集么：如果数据库是DB2的话，标准和直接写入的DSO是可以的，写优化的不行
97 RZ11
98 啥是Data Mart啊，the bw system can be a source to another bw system or to itself
the ods/cube/infoprovider which provide data to another systm are called data marts。
99 Event：SM62
100 都100条了，来点儿有意思的。3.x的时候，multi provider不能加DSO，只能用CUBE
infoset不能加CUBE，只能用DSO和Master Data，现在看来，有点儿不可思议了。
101 InfoCube：最大维度16个，去掉三个预先定义的time、unit、request，有13个可用
最大key figure数233
最大characteristic数248
DSO：
- You can create a maximum of 16 key fields (if you have more key fields, you can combine fields using a routine for a key field (concatenate).)
- You can create a maximum of 749 fields
- You can use 1962 bytes (minus 44 bytes for the change log)
- You cannot include key figures as key fields
Pasted from <http://help.sap.com/saphelp_nw04/helpdata/en/4a/e71f39488fee0ce10000000a114084/content.htm>
TABLE:
- All the key fields of a table must be stored together at the beginning of the table. A non-key field may not occur between two key fields.
- A maximum of 16 key fields per table is permitted. The maximum length of the table key is 255.
- If the key length is greater than 120, there are restrictions when transporting table entries. The key can only be specified up to a maximum of 120 places in a transport. If the key is larger than 120, table entries must be transported generically.
- A table may not have more than 249 fields. The sum of all field lengths is limited to 1962 (whereby fields with data type LRAW and LCHR are not counted).
- Fields of types LRAW or LCHR must be at the end of the table. Only one such field is allowed per table. There must also be a field of type INT2 directly in front of such a field. The actual length of the field can be entered there by the database interface.
Pasted from <http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb6e446011d189700000e8322d00/content.htm>
87 将黄灯状态改成红灯状态：运行事物码SE37，执行函数RSBM_GUI_CHANGE_USTATE
88 sap时间是从19910101开始的（？？）
89 几个新认识的Tcode
| SCOT | SAP Connect |
| SOST | SAP |
| SE14 | ABAP Dictionary |
| SM30 | Maintain Table |
| RSPCM | Monitor of RSPC |
| RSMO | Monitor of All |
| ALRTCATDEF | |
| ME22N | PO |
| ME23N | PO |
| ME21 | PO List |
| ME53N | Purchasing Plan |
| XD03 | Customer |
| KS03 | Cost Center |
| FSS0 | 总账科目 |
| FB03 | 总账凭证 |
| AFAB | 折旧记账 |
| FAGLL03 | 总账科目行项目 |
| CHANGERUNMONI | Change run monitor |
| ST01 | System trace |
| ST05 | Performance Analysis |
| FB03 | 显示凭证 |
| FD10N | 客户余额 |
| FAGLB03 | 总账余额 |
| SHDB | Transaction Recorder |
| SM19 | BADI |
| RSCUR | 货币转换 |
| RSZC | Query 复制 |
| SE24 | Class Builder |
| SE91 | MSG |
| SNOTE | Note |
| SU21 | Maintain Authorization Object |
| SE54 | Generate the required maintenance dialog. |
90 PC建议并行4条
91 CT是基于小汇总的百分比， GT是基于total的计算，
92 你看这是啥：Data Flow Overview in BI
BW3.5
93 写优化的DSO是不能做报表的，因为没有SID?不是的，可以出报表，只是没有意义，因为key都是些请求啊，数据编号之类的
94 数据源中，选择：BW提取时，可以当做选择条件进行筛选的字段。隐藏：在BW中不体现的字段
95 货币问题事务码：
OX15 OX02 OX06
96 DSO能做分区么：在SP13以及之前是可以的（Write-Optimized DSO是按照请求号）
DSO能做聚集么：如果数据库是DB2的话，标准和直接写入的DSO是可以的，写优化的不行
97 RZ11
98 啥是Data Mart啊，the bw system can be a source to another bw system or to itself
the ods/cube/infoprovider which provide data to another systm are called data marts。
99 Event：SM62
100 都100条了，来点儿有意思的。3.x的时候，multi provider不能加DSO，只能用CUBE
infoset不能加CUBE，只能用DSO和Master Data，现在看来，有点儿不可思议了。
101 InfoCube：最大维度16个，去掉三个预先定义的time、unit、request，有13个可用
最大key figure数233
最大characteristic数248
DSO：
- You can create a maximum of 16 key fields (if you have more key fields, you can combine fields using a routine for a key field (concatenate).)
- You can create a maximum of 749 fields
- You can use 1962 bytes (minus 44 bytes for the change log)
- You cannot include key figures as key fields
Pasted from <http://help.sap.com/saphelp_nw04/helpdata/en/4a/e71f39488fee0ce10000000a114084/content.htm>
TABLE:
- All the key fields of a table must be stored together at the beginning of the table. A non-key field may not occur between two key fields.
- A maximum of 16 key fields per table is permitted. The maximum length of the table key is 255.
- If the key length is greater than 120, there are restrictions when transporting table entries. The key can only be specified up to a maximum of 120 places in a transport. If the key is larger than 120, table entries must be transported generically.
- A table may not have more than 249 fields. The sum of all field lengths is limited to 1962 (whereby fields with data type LRAW and LCHR are not counted).
- Fields of types LRAW or LCHR must be at the end of the table. Only one such field is allowed per table. There must also be a field of type INT2 directly in front of such a field. The actual length of the field can be entered there by the database interface.
Pasted from <http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb6e446011d189700000e8322d00/content.htm>
102 你觉得Activate Data Automatically和Update Data Automatically能省事儿么，其实不是滴，因为Process Chain对这俩flag ignored
103 DSO的SID？我开始还以为在Activation Queue里，因为那个表里有SID这个字段，里面填的是Request_ID，
后来才知道根本不是这个，显示数据，里面有SID的，其实就是把文本的Key换成数字Key，能提速。
104 看DSO的请求用TCODE：RSICCONT
105 权限：InfoCube based approach info area, cube, dso
Query name based approach query
Dataset approach characteristics, key figures
106 How many fields you can assign to authorization object : 10
107 权限值‘：’
1、使用户可以访问不包含权限所限制对象的query，就是说，假如在Cube A里有IO_A，如果Query里不含IO_A，则用上‘：’之前也不能访问，之后就可以。
2、可以查看统计值，如果不去看明细的话。就是说，假如我们限制用户只能看客户A的资料，但是他还是可以看该公司的全部收入的。只要不明细到客户这一层。
108 权限值：‘$’
109 Templates of authorizations : SU24
110 Archival: SARA
111 Table:RSBFILE, Open Hub Files
112 DSO中包含从两个模型里上载过来的请求，必须分开激活
113 BW 单位：T006，货币：TCURR
114 从7.0 Query转到3.5 Query
There’s a reversal tool you can run….with which you can undo the query migratie to 7.0.
Go to SE38 and run COMPONENT_RESTORE
Not sure if it’s a custom program, but the coding can be found on OSS/SDN
115 activate master data 其实是 Change run:因为你手动加，是M版本（对于已经存在的，如果没有存在，就直接是A版本），要activate 起A版本，query 只取A版本。
116 sm66
117 看一个表是否使用了buffer：SE11,然后技术设置
118 如何传输设置到$TMP的object：
119 时间相关的特性没有P表，只有Q表
120 SU21，授权对象
121 System –> Status
122 ALPHA，数字自动填0
123 RSSDLINIT？RSREQDONE？SE38–RSREQUEST？
Yeah！查PSA的请求，用这个就靠谱。
查ODS和CUBE的，用Table：RSICCONT。
124 SE14，删除各种数据库表
125 SE93，查看Tcode
126 DSO，数据先上再到N表，然后激活到A表和LOG表
127 传输Table的时候，技术设置要单独进去保存才能进请求
128 想看Request，表RSBKREQUEST
129 做断点的时候，用BREAK USERNAME.
130 修复SID，RSRV
131 PSA查看，RSTSODS
132 RSPRECADMIN，预计算
133 权限Table：
| Role | AGR_1251 |
| Authorization | RSECVAL |
134 收集信息对象的时候，信息范围最好不要放里面
135 会计上，法律实体一定是会计主体，而会计主体未必一定是法律主体。就像上面的，分公司是会计主体，却并非法律实体。因此，会计主体对应到CompanyCode层次，而法而法律实体对应到Company层次是可以满足两个层次分别出具报表要求的。
136 收集权限时，组合角色下的角色会被一起收集进去
137 想查请求内容，E071
138 BI Content升级影响的是D版本
139 和Query相关的几个Table
RSZCOMPDIR
RSZCOMPIC
140 If the number of records to be loaded is larger than 15%-20% of the target table, then drop indexes. Otherwise, do not drop.
141 DSO的Secondary Index
1. Call transaction RSA1 (Administrator Workbench: Modeling → InfoProvider).
Double-click the ODS object on which you want to create a secondary index.
2. On the Edit ODS Object screen, right-click Indexes and choose Create
142 查看转换内容，RSTRANFIELD
143 属性的层次结构有修改时，在change run之前必须加保存层次结构
144 BX数据取的是初始库存，之后用BF和UM（填Setup table的时候要按照公司）
145 收集处理链的时候可以把相关的变式、信息包、处理链一起添加进去
146 Note 750156 - Entry <XXX…> not found in the DKF
147 T.Codes to fill up the Set Up tables for all the applications.
- 02 Purchasing => OLI3BW
- 03 Inventory Controlling => OLI1BW, OLIZBW
- 04 Shop Floor Control => OLI4BW, OLIFBW
- 08 Shipments => VIFBW, VTBW
- 11 SD Sales BW => OLI7BW
- 12 LE Shipping BW => OLI8BW
- 13 SD Billing BW => OLI9BW
148 STO：公司间销售
149 Note 559119 - Call disconnections in the syslog or dev_rd
Operating system call recv failed (error no. 73 )
Communication error, CPIC return code 020, SAP return code 223
150 WorkBook：RSRWORKBOOK
元数据仓库里面也可以看到，但是没有表里准确（只包含有效的Query）
151 AL11，查看服务器上的文件
152 角色的传输和模型不同，传输后，最后修改人将和开发机一致…
153 Query提示没有权限修改，可能是因为Patch打的比上次更改人的低
154 HR组织机构维护 PPOCE，PPOME，PPOSE
155 处理弹窗：SY-BINPT为空则弹出，为X则不弹
156 传输处理链的时候，如果有必要，需要调整源系统分配，甚至传输源系统
另外，转换的对应设置在：RSA1，工具，转换逻辑系统名称
157 For All Entry 之前要判断是否为空，否则效率很低
158 看虚拟Cube的FM：复制一下，看看Detail里的函数名。
eg： RSSEM_CONSOLIDATION_INFOPROV
RSSEM_CONSOLIDATION_INFOPROV3
159 OAER，更换excel模板
160 从模型删除字段的时候，需要把模型的数据清空，添加字段却不需要
161 IDOC WE21
162 RFC RSCUSTA
163 COPA KE24，CPB1
164 AGR_HIER表可以看到WorkBook对应的权限
165 RSZELTDIR Query元素查找
166 查看query运行的时间的事务代码是ST03
167 总账科目余额FBL5N，FS10n能查余额
168 RS_VC_GET_QUERY_VIEW_DATA可以做APD的Backup
169 SRET_TIME_DIFF_GET，通过seconds和hours来计算timestamp的时间差
170 处理链的明细视图还可以用来查看单个变式的执行时间
Delta Process
ABR:Forming deltas with after, before and reverse images that are updated directly in the delta queue,采用前镜像、后镜像和反转镜像的更新模式，既支持覆盖又支持累加，所以数据源可以更新到DSO或者CUBE
AIM/AIMD:Forming deltas with after image, which are updated directly in the delta queue. 采用后镜像模式，只支持覆盖，不支持累加，所以该类型数据源不能直接加载到CUBE，一般会先加载到DSO;在FI-AR/AP中此种增量处理方式应用较多
ADD只支持累加，采用的是附加镜像的更新方式，所以既可以更新到DSO又可以更新到CUBE
V3 Update Mode
V1同步更新模式，即凭证产生就更新增量，与业务数据同步更新；
V2异步更新模式，就如一个两步的操作一样，第一步业务凭证更新了，然后再更新第二步的数据源增量表
V3异步更新模式，与V2的区别在于他的更新时通过后台事件来触发的，即定一个任务定是收集增量并更新至增量表
Update Mode:
Direct Delta:这就是一种V1模式，比如销售订单产生之后，订单数据同步更新到R/3的Delta Queue中，这种模式系统负荷很重，特别是对于业务量大的凭证；
Queued Delta：数据先被收集到一个 Exctraction Queue中（V1模式），然后被送到Delta Queue（V3模式）
Unsterilized V3 Update：此类型的最大特征是 没有序列化，就是说Delta Queue 中销售订单是无序的，这个对于采用overwrite 模式的模型来说是最致命的，所以如果目标队列是DSO的话，还是不要采用这种模式好。
Check Delta Queue（RSA7）
Delta Update表示当前Delta Queue的数据
Delta Repetition表示的是上一次提取的Delta数据
Image supported by Datasource
New Image:new record if no same key exit.
Anafter imageshows the status after the change, abefore imagethe status before the change with a negative sign and thereverse imagealso shows the negative sign next to the record while indicating it for deletion.
Deletion:Delete
Acumulated:ADD
Delta Queue:
The delta queue is a data store for new or changed data records for a DataSource (that have occurred since the last data request). The new or changed data records are either written to the delta queue automatically using an update process in the source system, or by means of the DataSource extractor when a data request is received from the BI system (details will be provided later).
A
Aggregate
An aggregate is a subset of an InfoCube. The objective when using aggregates is to reduce I/O volume.The BW OLAP processor selects an appropriate aggregate during a query run or a navigation step. If no appropriate aggregate exists, the BW OLAP processor retrieves data from the original InfoCube instead.
For examples, assume you may have 10 dimensions and each one have 10 value, that means you may have up to 10^10 possible records. If high level manager often access the report focus revenue in 2008 by customer, that’s mean only 2 dimension are involved. You can do aggregate and it may only contain 2 dimensions with 100 records. It reduce the I/O and improve the performance.
Aggregate rollup
Aggregate rollup is a procedure to update aggregates with new data loads. Reference Aggregate
Application component
Application components are used to organize InfoSources. They are similar to the InfoAreas used with InfoCubes. The maximum number of characters allowed for the technical name is 32.
Authorization
An authorization defines what a user can do, and to which SAP objects. For example, a user with an authorization can display and execute, but not change, a query. Authorizations are defined using authorization objects.
Authorization object
An authorization object is used to define user authorizations. It has fields with values to specify authorized activities, such as display and execution, on authorized business objects, such as queries. The maximum number of characters allowed for the technical name is 10.
Authorization profile
An authorization profile is made up of multiple authorizations. The maximum number of characters allowed for the technical name is 10.
B
BEx
Short for Business Explorer. It includes following tools to present the reports to end user: Analyzer / Web Application Designer / Report Designer / Web Analyzer.
Bitmap index
A bitmap index uses maps of bits to locate records in a table. Bitmap indices are very effective for Boolean operations of the WHERE clause of a SELECT statement. When the cardinality of a column is low, a bitmap index size will be small, thereby reducing I/O volume.
Another possible choice in BW on this topic is B-tree index.
Business Content
Business Content is a complete set of BW objects developed by SAP to support the OLAP tasks. It contains roles, workbooks, queries, InfoCubes, key figures, characteristics, update rules, InfoSources, and extractors for SAP R/3, and other mySAP solutions.
You can simply use business content directly, or take it as template for your project to speed up implementations.
BW
BW is a Data Warehousing solution from SAP.
When we talking about BW, it often talking about BW3.5. The latest version is SAP Business Intelligence 7.0.
BW Monitor
BW Monitor displays data loading status and provides assistance in troubleshooting if errors occur. T-code: RSMO
BW Scheduler
BW Scheduler specifies when to load data. It is based on the same techniques used for scheduling R/3 background jobs.
BW Statistics
BW Statistics is a tool for recording and reporting system activity and performance information.
BWA / BIA
BW/BI Accelarator is a tool that improves the performance of BW 7.x queries on InfoCubes. It enables quick access to any data with a low amount of administrative effort and is especially useful for sophisticated scenarios with unpredictable query types, high data volume and high frequency of queriesC
Cache / OLAP Cache
A technology to improve the performance. Cache buffers query result data, in order to provider them for further accesses.
Cache Mode
Determines whether and in what way the query result and navigational states are to be saved in the OLAP Cache.
Change run
Change run is a procedure used to activate characteristic data changes.
Characteristic
Characteristics are descriptions of fields, such as Customer ID, Material Number, Sales Representative ID, Unit of Measure, and Transaction Date. The maximum number of characters allowed for the technical name is 9.
Client
A client is a subset of data in an SAP system. Data shared by all clients is called client-independent data, as compared with client-dependent data. When logging on to an SAP system, a user must specify which client to use. Once in the system, the user has access to both client-dependent data and client-independent data.
Communication structure
The communication structure is the structure underlying the InfoSource.
Compound attribute
A compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. For example, if the same characteristic data from different source systems mean different things, then we can add the compound attribute 0SOURSYSTEM (source system ID) to the characteristic; 0SOURSYSTEM is provided with the Business Content.
Compress
Compressing will bringing data from different requests together into one single request (request ID 0) in Infocube.
When you load data into Infocube, they are group with Requests ID. You can easily manage the data with Request ID. But the request ID have disadvantages cause the same data record (with same characteristics but different request ID) to appear more than once in the fact table. It waste the table space and affects query performance.
You can eliminate these disadvantages by compressing data and bringing data from different requests together into one single request (request ID 0).
Technically, Compress will move the data in F table to E table and aggregate the records with same char. automatically.
It is widly used when you are sure that the data in InfoCube is correct and you won’t need Request ID in the future. And be careful if you defined your own delta mechanism.
D
Data packet size
For the same amount of data, the data packet size determines how work processes will be used in data loading. The smaller the data packet size, the more work processes needed.You can set it in SPRO
Data Mining
Data mining is the process of extracting hidden patterns from data. It is one of the function provided by SAP BI.
Take the most famous story “beer and diapers” as example. Wall-Mart noticed that men often bought beer at the same time they bought diapers. They mined its receipts and proved the observations. So they put diapers next to the beer coolers, and sales skyrocketed. The story is a myth, but it shows how data mining seeks to understand the relationship between different actions.
Data Warehouse
Data Warehouse is a dedicated reporting and analysis environment based on the star schema (Extended) database design technique and requiring special attention to the data ETTL process.
DataMart
The distribution of contents of ODS or InfoCube into other BW data targets on the same or on other BW systems
DataSource
A DataSource is not only a structure in which source system fields are logically grouped together, but also an object that contains ETTL-related information. Four types of DataSources exist:
- DataSources for transaction data
- DataSources for characteristic attributes
- DataSources for characteristic texts
- DataSources for characteristic hierarchies
If the source system is R/3, replicating DataSources from a source system will create identical DataSource structures in the BW system. The maximum number of characters allowed for a DataSource’s technical name is 32.
DB Connect
A BW function that offers flexible options for extracting data directly into the BW from tables and views in database management systems that are connected to the BW in addition to the default connection. You can use tables and views from the database management systems that are supported by SAP to transfer data. DataSources are used to make data known to the BW, where it is then processed in the same way as data from all other sources.
Delta Caching
Additional requests will be read from the InfoCube’s (F) fact table. These additional requests will be updated into the OLAP Cache. In this way, when they are changes to the data basis, the complete data for the query no longer has to be read from the database again.
Delta update
The Delta update option in the InfoPackage definition requests BW to load only the data that have been accumulated since the last update. Before a delta update occurs, the delta process must be initialized.
Development class
A development class is a group of objects that are logically related.
Dimension table
Part of the Star Schema structure for InfoCubes. Dim tables contain pointers to the Fact tables & to the Master Data (SID tables).
Display attribute
A display attribute provides supplemental information to a characteristic. Reference Navigation attribute
Drill-down
Drill-down is a user navigation step intended to get further detailed information. For example, you can drill-down to detail report through free characteristic
DSO
Short for Data Store Object. Reference ODS in BW3.5
A DataStore object serves as a storage location for consolidated and cleansed transaction data or master data on a document (atomic) level. This data can be evaluated using a BEx query.
A DataStore object contains key fields (such as document number, document item) and data fields that, in addition to key figures, can also contain character fields (such as order status, customer). The data from a DataStore object can be updated with a delta update into InfoCubes (standard) and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems.
There are 3 kinds of DSO: Standard DataStore Object / Write-Optimized DataStore Objects / DataStore Objects for Direct Update. Check the definition and example at:http://help.sap.com/saphelp_nw2004s/helpdata/en/f9/45503c242b4a67e10000000a114084/frameset.htm
DTP
The Data Transfer Process (DTP) transfers data from source objects to target objects in BI 7.x. You can also use the data transfer process to access InfoProvider data directly. Prerequisite: a transformation to define the data flow between the source and target object.
E
EDW
The Enterprise Data Warehouse, a comprehensive / harmonized data warehouse solution, is design to avoid isolated applications. Reference BW330.
ETTL
ETTL, one of the most challenging tasks in building a data warehouse, is the process of extracting, transforming, transferring, and loading data correctly and quickly. Also known as ETL.
Extraction Structure
The data structure used by the extraction program to extract data. Its fields are mapped to the fields of the SAP Source System DataSource.
F
Fact tables
The Fact table is the central table of the InfoCube. Here key figures & pointers to the dimension tables are stored. There are two fact tables: the F-fact table and the E-fact table. If you upload data into an InfoCube, it is always written into the F-fact table. If you compress the data, the data is shifted from the F-fact table to the E-fact table. The F-fact tables for aggregates are always empty, since aggregates are compressed automatically. After a changerun, the F-fact table can have entries as well as when you use the functionality ‘do not compress requests’ for Aggregates.
E-fact table is optimized for Reading => good for Queries. F-fact table is optimized for Writing => good for Loads
Free characteristic
A free characteristic is a characteristic in a query used for drill-downs. It is not displayed in the initial result of a query run.
Full update
The Full update option in the InfoPackage definition requests BW to load all data that meet the selection criteria specified via the Select data tab. Reference Delta update
Filter
Filter is used to restrict data to a certain business sector, product group, or time period. And these can be saved and reused in the in othercontexts. Here the data is filtered and showed in the intial result of the query.
G
Generic data extraction
Generic data extraction is a function in Business Content that allows us to create DataSources based on database views or InfoSet queries. InfoSet is similar to a view but allows outer joins between tables.
Granularity
Granularity describes the level of detail in a data warehouse. It is determined by business requirements and technology capabilities. For high level reports, manager tend to high aggregated report such as by month or by BU. But operational reports always require more detail information such as by day or by product spec.
H
High Cardinality
means that this dimension contains a high number of attributes. This information is used to execute physical optimizations, depending on the database platform. For example, different index types from those in a standard case are used. Generally, a dimension has a high cardinality if the number of dimension entries is 20% (or more) of the number of fact table entries.
I
IDoc
IDoc (Intermediate Document) is used in SAP to transfer data between two systems. It is a specific instance of a data structure called the IDoc Type, whose processing logic is defined in the IDoc Interface. See:IDOC Basics
Index
An index is a technique used to locate needed records in a database table quickly. BW uses two types of indices: B-tree indices for regular database tables and bitmap indices for fact tables and aggregate tables.
InfoArea
InfoAreas are used to organize InfoCubes and InfoObjects. Each InfoCube is assigned to an InfoArea. Through an InfoObject Catalog, each InfoObject is assigned to an InfoArea as well. The maximum number of characters allowed for the technical name is 30.
InfoCube
An InfoCube is a fact table and its associated dimension tables in the star schema. The maximum number of characters allowed for the technical name is 30.
InfoCube compression
InfoCube compression is a procedure used to aggregate multiple data loads at the request level.
InfoObject
In BW, key figures and characteristics are collectively called InfoObjects. See:https://wiki.sdn.sap.com/wiki/display/BI/Characterstic+and+Key+FiguresCharacteristic and key figures
InfoObject Catalog
InfoObject Catalogs organize InfoObjects. Two types of InfoObject Catalogs exist: one for characteristics, and one for key figures. The maximum number of characters allowed for the technical name is 30.
InfoPackage
An InfoPackage specifies when and how to load data from a given source system. BW generates a 30-digit code starting with ZPAK as an InfoPackage’s technical name.
InfoSource
An InfoSource is a structure in which InfoObjects are logically grouped together. InfoCubes and characteristics interact with InfoSources to get source system data. The maximum number of characters allowed for the technical name is 32. In BW 3.5 it is a MUST and in BI 7.0 it is optional.
The difference:http://help.sap.com/saphelp_nw2004s/helpdata/en/a4/1be541f321c717e10000000a155106/content.htm
And the Recommendations for Using InfoSources in BI 7.0:http://help.sap.com/saphelp_nw2004s/helpdata/en/44/0243dd8ae1603ae10000000a1553f6/content.htm
Information Lifecycle Mangement
Generally, the data was generated in OLTP system such as R/3. In BW, Information Lifecycle Management includes data target management and data archiving.
Reference ADK and archiving for more information. And online help:http://help.sap.com/saphelp_nw2004s/helpdata/en/d0/84e5414f070640e10000000a1550b0/frameset.htm
K
Key figure
Key figures are numeric values or quantities, such as Per Unit Sales Price, Quantity Sold, and Sales Revenue. The maximum number of characters allowed for the technical name is 9. Reference Characteristic.
L
Line item dimension
A line item dimension in a fact table connects directly with the SID table of its sole characteristic.
When you creating a InfoCube, you have chance to use this feature on define dimension. It is only possible if exactly one characteristic in a dimension. It help to improve the performance because we do not need to join SID table when accessing the master data.
Logical system
A logical system is the name of a client in an SAP system.
M
Metadata Repository
Metadata repository contains information about the metadata objects of SAP NetWeaver Business Intelligence, important object properties and their relationships with other objects. Metadata contains data about data.
Multi-cube
A multi-cube is a union of basic cubes. The multi-cube itself does not contain any data; rather, data reside in the basic cubes. To a user, the multi-cube is similar to a basic cube. When creating a query, the user can select characteristics and key figures from different basic cubes.
N
Navigational attribute
A navigational attribute indicates a characteristic-to-characteristic relationship between two characteristics. It provides supplemental information about a characteristic and enables navigation from characteristic to characteristic during a query.
The naming convention for a navigational attribute is: InfoObject_Attribute, such as 0customer_0country
Number range
A number range is a range of numbers that resides in application server memory for quick number assignments.
O
ODS
ODS is a BW architectural component located between PSA and InfoCubes that allows BEx reporting. It is not based on the star schema and is used primarily for detail reporting, rather than for dimensional analysis. ODS objects do not aggregate data as InfoCubes do. Instead, data are loaded into an ODS object by inserting new records, updating existing records, or deleting old records, as specified by the 0RECORDMODE value.
Reference DSO.
Open Hub Service
The open hub service enables you to distribute data from an SAP BW system into external data marts, analytical applications, and other applications.
OLTP / OLAP
Short for Online Transaction Processing / Online Analytical Processing.
OLTP system are Transacton-Orientated, which means it is generally used to support the daily operation. For example, SAP R/3, ERP / PDM / MES …
OLAP is generally used to analysis data. For examples, SAP BW, DDS - Decision Support System, EIS - Executive information systems.
P
Parallel query
A parallel query uses multiple database processes, when available, to execute a query.
Partition
A partition is a piece of physical storage for database tables and indices. If the needed data reside in one or a few partitions, then only those partitions will be selected and examined by a SQL statement, thereby significantly reducing I/O volume. It can be done in Cube or DB level.
The benefit of using partition is mainly focus on:
- Well balanced partition / fragments
- Improve read performance
- Fast of delete partition by “Drop” instead of “Delete from where”
Fact table can be partitioned over a time characteristic either 0CALMONTH or 0FISCPER(Fiscal year/period). Repartition is possible in SAP BI 7.0. Seehttps://wiki.sdn.sap.com/wiki/x/N4C4AQRepartitioning
Partitioning Type
For MultiProvider queries, Partitioning Type provides options for handling the data that is returned by the individual InfoProviders from the MultiProvider separately and saving it in the cache separately.
- No Partitioning: All results of the InfoProviders are summarized as one result and cached.
- Partitioning in Groups: Infocubes in one group, and other infoproviders are saved together in groups according to their properties.
- Partitioning in Groups: Basis Cubes Separate: similar as above. individual Infocubes are saved separately.
- Each InfoProvider Separate: All InfoProviders are saved separately.
Process Chain
A process chain is a sequence of processes that are scheduled to wait in the background for an event. You can include process chains in other process chains to manage a group of them, known as meta. chains.
It is design at the implementation phase and one of the most important jobs in support and maintenance phase.
More information please reference:http://help.sap.com/saphelp_nw2004s/helpdata/en/8f/c08b3baaa59649e10000000a11402f/frameset.htm
Profile Generator
Profile Generator is a tool used to create authorization profiles.
PSA
The Persistent Staging Area (PSA) is a data staging area in BW. It allows us to check data in an intermediate location, before the data are sent to its destinations in BW.
Q
Query
A BW query is a selection of characteristics and key figures for the analysis of the data in an InfoCube. A query refers to only one InfoCube, and its result is presented in a BEx Excel sheet. The maximum number of characters allowed for the technical name is 30.
R
Read mode
Read mode determines how often the OLAP processor reads data from the database during navigation.
- Read all data
- Read during navigation
- Read during navigation & expanding hierarchy
Reconstruct
Reconstruct is a procedure used to restore load requests from PSA.
Request
A request is a data load request from BW Scheduler. Each time that BW Scheduler loads data into an InfoCube, a unique request ID is created in the data packet dimension table of the InfoCube.
RFC
RFC (Remote Function Call) is a call to a function module in a system different from the caller’s usually another SAP system on the local network.
Role
In Profile Generator, an authorization profile corresponds to a role. A user assigned to that role also has the corresponding authorization profile. A user can be assigned to multiple roles. The maximum number of characters allowed for the technical name is 30.
Reclustering
It allows you to change the clustering of Infocubes and Data store objects that already contain data.
S
SID
SID (Surrogate-ID) translates a potentially long key for an InfoObject into a short four-byte integer, which saves I/O and memory during OLAP.
Source system
A source system is a protocol that BW uses to find and extract data. When the source system is a non-SAP system, such as a flat file or a third-party tool, the maximum number of characters allowed for the technical name is 10. When the source system is an SAP system, either R/3 or BW, the technical name matches the logical system name. The maximum number of characters allowed for the technical name is 32.
Star schema
A star schema is a technique used in the data warehouse database design to help data retrieval for online analytical processing.
SAP BW use extended star schema with following advantage compare to classical star schema:
- Use of generated key (short number) for faster access
- External hierarchy
- Multi-language support
- Master data are separated. It is common to all cubes
- Support slowly changing dimensions
- Aggregates in its own tables for faster access
Statistics
For a SQL statement, many execution plans are possible. The database optimizer generates the most efficient execution plan based on either the heuristic ranking of available execution plans or the cost calculation of available execution plans. Statistics is the information that the cost-based optimizer uses to calculate the cost of available execution plans and select the most appropriate one for execution. BW uses the cost-base optimizer for Oracle databases.
System Administration Assistant
System Administration Assistant is a collection of tools used to monitor and analyze general system operation conditions.
System landscape
The system landscape specifies the role of each system and the paths used in transporting objects among the various systems.
T
Time-dependent entire hierarchy
A time-dependent entire hierarchy is a time-dependent hierarchy whose nodes and leaves are not time-dependent.
For example, you have two hierarchy which presents organization of company in 2007 and 2008.
Time-dependent hierarchy structure
A time-dependent hierarchy structure consists of nodes or leaves that are time-dependent, but the hierarchy itself is not time-dependent.
For example, you have one hierarchy but one of his node was changed from 2007 and 2008. HR may belong to administration division before 2007 and belong to supporting division after 2008.
Transfer rule
Transfer rules specify how DataSource fields are mapped to InfoSource InfoObjects.
In BI 7.0, transfer rule and update rule are replaced by transformation.
Transfer structure
A transfer structure maps DataSource fields to InfoSource InfoObjects.
Transformations (TRF)
TRFs connect source objects (DataSources, DSOs, InfoCubes, InfoSets) to Data Targets (InfoProviders) of a data-staging process. They replace combination of transfer rules & update rules. The TRF process allows you to consolidate, cleanse & integrate data. You must use DTP to load data to InfoProvider.
U V W X Y Z
Update rule
An update rule specifies how data will be updated into their targets. The data target can be an InfoCube or an ODS object. If the update rule is applied to data from an InfoSource, the update rule’s technical name will match the InfoSource’s technical name. If the update rule is applied to data from an ODS object, the update rule’s technical name will match the ODS object’s technical name prefixed with number 8.
In BI 7.0, transfer rule and update rule are replaced by transformation. But we still have chance to use it in BI 7.0
Variable
A variable is a query parameter. It gets its value from user input or takes a default value set by the variable creator.
Variables act as placeholders for:
- Characteristic values
- Hierarchies
- Hierarchy nodes
- Texts
- Formula elements
Virtual InfoProvider
A Virtual Provider is a type of InfoCube where the data is not managed in BI. Only the structure of the VirtualProvider is defined in BI, the data is read for reporting using an interface with another system.
Workbook
A BW workbook is an Excel file with a BEx query result saved in BDS. BW assigns a 25-digit ID to each workbook. Users need merely name a workbook’s title.
为什么要Emulate 3.x datasource in BW 7.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BW Issue Note: ETL - 3.X datasource not found
Summary
主要原因是3.5的datasource作为7.0 datasource导入了，需要将7.0 datasource 恢复到3.5。SAP提供了restore的选项。
Symptom
You have replicated one or more DataSources from the source system. You now want to create a mapping between a 3.x DataSource and 3.x InfoSource and then maintain the transfer rules.
However, the system does not find the 3.x DataSource.
Other terms
Replication, dialog box
Reason and Prerequisites
The object exists as a (new) DataSource (R3TR RSDS) rather than a 3.x DataSource (R3TR ISFS).
You can identify 3.x DataSources by the word “emulated” under the “Compare with” button in the DataSource display and maintenance environments.
This problem may occur due to one of the following reasons:
- The DataSource was replicated as a (new) DataSource instead of a 3.x DataSource because of a program error (see the related notes).
- During replication, the system displayed a dialog box asking you whether you wanted to replicate the DataSource as a “DataSource” or “3.x DataSource”. You chose “DataSource”.
- A (new) DataSource was wrongly delivered with BI Content 7.03. This is called the “incorrect content” in the rest of this note.
A (new) DataSource (R3TR RSDS) cannot be used with a transfer rule. You have to use a 3.x DataSource (R3TR ISFS) to do this.
Solution
If you incorrectly replicated some of the DataSources as (new) DataSources or if the problem is caused by the “incorrect content”, proceed as follows:
Call transaction RSDS then specify the technical name of the DataSource and the source system.
Choose the “Restore 3.x DataSource” option from the “DataSource” menu.
If the problem is caused by the “incorrect content”, you must also reinstall the 3.x data flow from the content with object types “InfoPackage, 3.x DataSource, transfer structure, transfer rules, and 3.x InfoSource”.
You cannot use program RSDS_REPL_RESET (described below) in the case of the “incorrect content”.
If the problem occurs because you have replicated a large number of DataSources into the incorrect (new) DataSource object type and if you have imported at least Support Package 07 for SAP NetWeaver 2004s BI into your system, execute the report “RSDS_REPL_RESET” in transaction SE38.
Caution: Do not use this report if your system has a Support Package level lower than Support Package 07 for SAP NetWeaver 2004s BI otherwise serious inconsistences may occur.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Blog 地址：http://chenweiqin1981.spaces.live.com/?_c11_BlogPart_pagedir=Next&_c11_BlogPart_handle=cns!1675D48BEA05A462!1820&_c11_BlogPart_BlogPart=blogview&_c=BlogPart
Question 1:
Answer:
The ‘Total’ column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the next delta request. An LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.
Question 2:
What is an LUW in the delta queue?
Answer:
An LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet from an application extractor.
Question 3:
Why does the number in the ‘Total’ column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
The number on the overview screen corresponds to the total number of LUWs (see also question 1) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the next delta request are displayed on the detail screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer exit.
Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the BW System. The LUWs of the previous delta may then be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change if the first delta is loaded into the BW System.
Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.
Question 6:
Why is there a DataSource with ‘0′ records in RSA7 if delta exists and has been loaded successfully?
Answer:
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor . You can display the current delta data for these DataSources using TA RSA3 (update mode =’D’)
Question 7:
Do the entries in Table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
Answer:
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area, and so on).
Caution: As of PlugIn 2000.2 patch 3, the entries in Table ROIDOCPRMS are as effective for the delta queue as for a full update. Note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the delta queue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.
Question 8:
Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
Answer:
With PlugIn 2001.1 the display was changed: you are now able to define the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the ‘actual’ delta data and the data intended for repetition, and so on.
Question 9:
What is the purpose of the function ‘Delete Data and Meta. Data in a Queue’ in RSA7? What exactly is deleted?
Answer:
You should act with extreme caution when you use the delete function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. Not only do you delete all data of this DataSource for the affected BW System, but you also lose all the information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, this confirms the LUWs kept in the qRFC queue for the corresponding target system. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The delete function is intended for example, for cases where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.
Question 10:
Why does it take so long to delete from the delta queue (for example half a day)?
Answer:
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.
Question 11:
Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
Answer:
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. A successful delta initialization (the corresponding request must have QM status ‘green’ in the BW System) is a prerequisite for the application data to be written to the delta queue.
Question 12:
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
Answer:
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix ‘BW, the client and the short name of the DataSource. For DataSources whose name is shorter than 20 characters, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in Table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.
Question 13:
Why is there data in the delta queue although the V3 update has not yet been started?
Answer:
You posted data in the background. This means that the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.
Question 14:
Why does the ‘Repeatable’ button on the RSA7 data details screen not only show data loaded into BW during the last delta but also newly-added data, in other words, ‘pure’ delta records?
Answer:
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.
Question 15:
I loaded several delta inits with various selections. For which one
is the delta loaded?
Answer:
For delta, all selections made via delta inits are summed up. This
means a delta for the ‘total’ of all delta initializations is loaded.
Question 16:
How many selections for delta inits are possible in the system?
Answer:
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many ‘where’ lines are generated in the generatedABAPsource code which may exceed the memory limit.
Question 17:
I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Answer:
Before you copy a source client or source system, make sure that your deltas have been fetched from the delta queue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump ‘MESSAGE_TYPE_X’ occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.
Question 18.
Am I permitted to use the functions in Transaction SMQ1 to manually control processes?
Answer:
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after informing BW Support or only if this is explicitly requested in a note for Component ‘BC-BW’ or ‘BW-WHM-SAPI’.
Question 19.
Despite the delta request only being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this “splitting”?
Answer:
The collective run submits the open V2 documents to the task handler for processing. The task handler processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large “safety time window” between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.
Question 20.
Despite deleting the delta init, LUWs are still written into the DeltaQueue
Answer:
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If you started the internal mode at a time when the delta initialization was still active, you post data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.
Question 21.
In SMQ1 (qRFC Monitor) I have status ‘NOSEND’. In the Table TRFCQOUT, some entries have the status ‘READY’, others ‘RECORDED’. ARFCSSTATE is ‘READ’. What do these statuses mean? Which values in the field ‘Status’ mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
Answer:
Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this still does not mean that the record has successfully reached the BW. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the delta queue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a delta extraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which confirms and deletes records loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status indicates an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903). However the value ‘U’ in field ‘NOSEND’ of table TRFCQOUT is of concern.
Question 22.
The extract structure was changed when the delta queue was empty. Afterwards new delta records were written to the delta queue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the delta queue are listed via the detail display. Why is the data displayed differently? What can be done?
Answer:
Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. We recommend resetting the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta. When the problem occurs, the delta needs to be re-initialized.
Question 23. How and where can I control whether a repeat delta is requested?
Answer:
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type ‘Repeat’. If you need to repeat the last load for any reason, manually set the request in the monitor to red. For the contents of the repeat, see Question 14. Delta requests set to red when data is already updated lead to duplicate records in a subsequent repeat, if they have not already been deleted from the data targets concerned.
Question 24.
As of PI 2003.1, the Logistic Cockpit offers various types of update methods. Which update method is recommended in logistics? According to which criteria should the decision be made? How can I choose an update method in logistics?
Answer:
See the recommendation in Note 505700.
Question 25.
Are there particular recommendations regarding the maximum data volume of the delta queue to avoid danger of a read failure due to memory problems?
Answer:
There is no strict limit (except for the restricted number area of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating “soft” limits, both the number of LUWs and the average data volume per LUW are important. As a rule, we recommend bundling data (usually documents) as soon as you write to the delta queue to keep number of LUWs low (this can partly be set in the applications, for example in the Logistics Cockpit). The data volume of a single LUW should not be much larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volume of about 1 GByte per work process, 100 MByte per LUW should not be exceeded). This limit is of rather small practical importance as well since a comparable limit already applies when writing to the delta queue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data is fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not exceed one delta request per hour.
To avoid memory problems, a program-internal limit ensures that no more than 1 million LUWs are ever read and fetched from the database per delta request. If this limit is reached within a request, the delta queue must be emptied by several successive delta requests. We recommend, however, to try not to reach that limit but trigger the fetching of data from the connected BWs as soon as the number of LUWs reaches a 5-digit value.
通常在SAP BW 中数据建模的数据存在下面的一些表中：
维度表- Dtable
SID表- Stable
主数据表：包括文本表 Ttable， 属性表 Ptable 和 Qtable
InfoCube Tables
Dimension Tables （最多支持16个维度）
- /BIO/D[#]:# Numbering of the dimension (automatically assigned by the system): The DIM
numbers contain the following elements: P, T, U, 1, 2, … 9, A, B, C, D.
P DataPackage
T Time
U Unit
A (10.Dimension)
B (11.Dimension)
C (12.Dimension)
D (13.Dimension)
Fact Tables
- F table
- E table: 用于存放聚集后的汇总事实数据。
Modeling InfoObjects
When you activate a master data-bearing characteristic,master data tables (attributes,
settings you have made on the tab pages.
Master Data Tables
Text Table
- Naming conventions in thetext table:
-
- /BIC/T<technical name of the characteristic> (for customer-defined characteristics)
-
- /BI0/T<technical name of the characteristic> (for SAP standard characteristics)
Attribute Tables
- a view (/BIC/M<name of characteristic>) is automatically generated using P or Q or P and Q.
- You can choose to define attributes as display attributes and navigation attributes as either time-independent
or time-dependent attributes.
- Naming conventions in the attribute table:
-
- /BIC/P<technical name of the characteristic> (for customer-defined characteristics that have attributes that arenot time-dependent)
-
- /BI0/P<technical name of the characteristic> (for standard SAP characteristics that have attributes that arenot time-dependent)
- /BIC/Q<technical name of the characteristic> (for customer-defined characteristics that havetime-dependentattributes)
- /BI0/Q<technical name of the characteristic> (for standard SAP characteristics that havetime-dependentattributes)
SID Tables
- link betweenmaster data-bearing characteristics, navigation attributes, and external hierarchies
- TheS tableis generated when a characteristic is activated
- TheX tableis only generated if at least onetime-independentattributeis defined as anavigation attribute
- TheY tableis only generated if at least onetime-dependentattributeis defined as anavigation attribute.
- Changes to the Characteristic InfoObject
You can make the following changes to a characteristic after the master data has
been loaded:
• Display attribute (time-independent) → Navigation attribute (time-independent)
• Display attribute (time-independent) → Navigation attribute (time-dependent)
• Display attribute (time-independent) → Display attribute (time-dependent)
• Display attribute (time-dependent) → Navigation attribute (time-dependent) - TheI tabledisplays the relationships between nodes/nodes and nodes/leaves (Hierarchies)
- TheK tablenodes are assigned negative SID values (K table)
Characteristic InfoObjects
- Characteristicsin BI are the central memory objects ofmaster data. We differentiate
between the following types of master data:
-
- Attributes
- Texts
- Hierarchies
- Hierarchies
- Hierarchies are used in analysis to describe alternative views of the data
- The data structures for the display hierarchies are stored outside of the InfoCube
in accordance with the concept of the enhanced star schema - The hierarchy table (H table) is used to store the hierarchical relationships between
characteristic values ifexternal hierarchiesare used for the characteristic. - They appear as global fields (meta. information) in the RSHIEDIR table instead.??????
- Definition:
A hierarchy is a method of displaying a characteristic structured and grouped according to individual evaluation criteria.
Structure:
a) Nodes
A hierarchy is created from nodes. The uppermost node is the root.
b) Roots
A hierarchy can have several roots. They do not have superior nodes.
c) Hierarchy Levels
All nodes on the same level of the hierarchy (nodes that are the same distance away from the root) form. a hierarchy level. The roots of a hierarchy form. level 1. The level of a node denotes the distance from the node to the root.
d) Leaves
The leaves of a hierarchy consist of characteristic values for the basic characteristic and therefore can also have entries in the fact table. A leaf cannot have any sub nodes.
e) Basic Characteristic
Hierarchies can be created only for those characteristics that do not reference other characteristics.
Properties :
A BW hierarchy has the following properties:
• Hierarchies are created for basic characteristics
• Hierarchies are stored in special master data tables. They behave in a similar way to master data,
• and can therefore be used and modified in all Info Cubes.
• You can define several hierarchies for a single characteristic.
• A hierarchy can have a maximum of 98 levels. - http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3113
| 1 | RSA1 | Administrator Work Bench |
| 2 | RSA11 | Calling up AWB with the IC tree |
| 3 | RSA12 | Calling up AWB with the IS tree |
| 4 | RSA13 | Calling up AWB with the LG tree |
| 5 | RSA14 | Calling up AWB with the IO tree |
| 6 | RSA15 | Calling up AWB with the ODS tree |
| 7 | RSA2 | OLTP Metadata Repository |
| 8 | RSA3 | Extractor Checker |
| 9 | RSA5 | Install Business Content |
| 10 | RSA6 | Maintain DataSources |
| 11 | RSA7 | BW Delta Queue Monitor |
| 12 | RSA8 | DataSource Repository |
| 13 | RSA9 | Transfer Application Components |
| 14 | RSD1 | Characteristic maintenance |
| 15 | RSD2 | Maintenance of key figures |
| 16 | RSD3 | Maintenance of units |
| 17 | RSD4 | Maintenance of time characteristics |
| 18 | RSDBC | DB connect |
| 19 | RSDCUBE | Start: InfoCube editing |
| 20 | RSDCUBED | Start: InfoCube editing |
| 21 | RSDCUBEM | Start: InfoCube editing |
| 22 | RSDDV | Maintaining |
| 23 | RSDIOBC | Start: InfoObject catalog editing |
| 24 | RSDIOBCD | Start: InfoObject catalog editing |
| 25 | RSDIOBCM | Start: InfoObject catalog editing |
| 26 | RSDL | DB Connect - Test Program |
| 27 | RSDMD | Master Data Maintenance w.Prev. Sel. |
| 28 | RSDMD_TEST | Master Data Test |
| 29 | RSDMPRO | Initial Screen: MultiProvider Proc. |
| 30 | RSDMPROD | Initial Screen: MultiProvider Proc. |
| 31 | RSDMPROM | Initial Screen: MultiProvider Proc. |
| 32 | RSDMWB | Customer Behavior. Modeling |
| 33 | RSDODS | Initial Screen: ODS Object Processng |
| 34 | RSIMPCUR | Load Exchange Rates from File |
| 35 | RSINPUT | Manual Data Entry |
| 36 | RSIS1 | Create InfoSource |
| 37 | RSIS2 | Change InfoSource |
| 38 | RSIS3 | Display InfoSource |
| 39 | RSISET | Maintain InfoSets |
| 40 | RSKC | Maintaining the Permittd Extra Chars |
| 41 | RSLGMP | Maintain RSLOGSYSMAP |
| 42 | RSMO | Data Load Monitor Start |
| 43 | RSMON | BW Administrator Workbench |
| 44 | RSOR | BW Metadata Repository |
| 45 | RSORBCT | BI Business Content Transfer |
| 46 | RSORMDR | BW Metadata Repository |
| 47 | RSPC | Process Chain Maintenance |
| 48 | RSPC1 | Process Chain Display |
| 49 | RSPCM | Monitor daily process chains |
| 50 | RSRCACHE | OLAP: Cache Monitor |
| 51 | RSRT | Start of the report monitor |
| 52 | RSRT1 | Start of the Report Monitor |
| 53 | RSRT2 | Start of the Report Monitor |
| 54 | RSRTRACE | Set trace configuration |
| 55 | RSRTRACETEST | Trace tool configuration |
| 56 | RSRV | Analysis and Repair of BW Objects |
| 57 | SE03 | Transport Organizer Tools |
| 58 | SE06 | Set Up Transport Organizer |
| 59 | SE07 | CTS Status Display |
| 60 | SE09 | Transport Organizer |
| 61 | SE10 | Transport Organizer |
| 62 | SE11 | ABAP Dictionary |
| 63 | SE18 | Business Add-Ins: Definitions |
| 64 | SE18_OLD | Business Add-Ins: Definitions (Old) |
| 65 | SE19 | Business Add-Ins: Implementations |
| 66 | SE19_OLD | Business Add-Ins: Implementations |
| 67 | SE21 | Package Builder |
| 68 | SE24 | Class Builder |
| 69 | SE80 | Object Navigator |
| 70 | RSCUSTA | Maintain BW Settings |
| 71 | RSCUSTA2 | ODS Settings |
| 72 | RSCUSTV* |
|
| 73 | RSSM | Authorizations for Reporting |
| 74 | SM04 | User List |
| 75 | SM12 | Display and Delete Locks |
| 76 | SM21 | Online System Log Analysis |
| 77 | SM37 | Overview of job selection |
| 78 | SM50 | Work Process Overview |
| 79 | SM51 | List of SAP Systems |
| 80 | SM58 | Asynchronous RFC Error Log |
| 81 | SM59 | RFC Destinations (Display/Maintain) |
| 82 | LISTCUBE | List viewer for InfoCubes |
| 83 | LISTSCHEMA | Show InfoCube schema |
| 84 | WE02 | Display IDoc |
| 85 | WE05 | IDoc Lists |
| 86 | WE06 | Active IDoc monitoring |
| 87 | WE07 | IDoc statistics |
| 88 | WE08 | Status File Interface |
| 89 | WE09 | Search for IDoc in Database |
| 90 | WE10 | Search for IDoc in Archive |
| 91 | WE11 | Delete IDocs |
| 92 | WE12 | Test Modified Inbound File |
| 93 | WE14 | Test Outbound Processing |
| 94 | WE15 | Test Outbound Processing from MC |
| 95 | WE16 | Test Inbound File |
| 96 | WE17 | Test Status File |
| 97 | WE18 | Generate Status File |
| 98 | WE19 | Test tool |
| 99 | WE20 | Partner Profiles |
| 100 | WE21 | Port definition |
| 101 | WE23 | Verification of IDoc processing |
| 102 | DB02 | Tables and Indexes Monitor |
| 103 | DB14 | Display DBA Operation Logs |
| 104 | DB16 | Display DB Check Results |
| 105 | DB20 | Update DB Statistics |
扫一扫
674
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
