Aggregation level-聚集等级/BPC/ input ready query

我将强行翻译成 聚集等级。。。因为我不知道中文怎么翻。
我对aggregation一直不知道，因为这个aggregation一会聚集，一会聚合。
还在Planning下面，我就更不理解了。跟计划啥关系啊。？。。

BPC 是啥

好的，不管三七二十一，我们先来看BPC，我经常看到这个BPC，只知道P是planning
唉，英文缩写真是一大障碍。
我觉得此处得上BPC的解释：Business Planning and Consolidation　业务计划和合并

这个应用提供计划，预算，预测和财务合并功能。可以轻松调整计划和预测，加快预算和关闭周期，确保符合财务报告的标准。

写到这里写不下去了。
是的，预测和预算很重要，但是我没接触过，，，
为啥说预测很总要呢，因为能预测听起来很牛，根据今年的走势来推测明年的，哪里需要加强，哪里需要减投。最早的时候，98年，SAP都没有啥专门的计划工具。SAP ERP 的人都用excel来做计划。直到SEM-BPS发布，他们才有个专门的计划工具。用户可以用SAP的标准的Info Cube和Info Object,保证了数据的完整性。那么这个BPS的优点就在于，用Excel作为集成的前端。
下次的迭代出现在2006年，发布了BI-IP。乍一看，BI-IP和BPS好像很不一样，但是计划的方式还是一样的。就配置步骤的术语不同，比如，BPS里面的planning area在BI-IP里面被称作aggregation level。就像金融人把财务搞那么复杂，SAP非要把计划搞这么复杂。BI-IP还必须得在SAP Portal里面配置。网页前端一个弊端显而易见，就像你在网页里填报名信息，个人简历，不小心哪里点到了刷新,回退啥的，哦吼，你的所有数据都没了。
然后呢，SAP 2007年收购了outlooksoft（OS） ,不是outlook。outlooksoft人家就说了，说它是用户友好型的，财务为中心的计划工具。这可不，比BI-IP和BPS这俩IT直男，又复杂又难用的好太多了。然而，outlook soft太小看IT直男了，它自己集成性差，数据冗余，功能限制，特别是由于性能限制造成维度丢失，到搞复杂的运营计划时，完全扛不动。
但是SAP也不能闲着，收购完了一堆毛病的OS，就像办法把这个新工具和net weaver集成，第一版本的OSforNW，７.０版本，在SAPBW上面运行，但是和标准的内容分离，得在自己的命名空间搞。和其他的BW内容集成需要顾问来卡法，特别时数据集成领域，SAP把BI－IP搞到了SAP　GUI里，就是那个RSPLAN。
直到SAP HANA出来，分歧就来了。传统的BPC和BI-IP都给弄到HANA上了。SAP基本上把BI－IP给重命名成BPC EMbedded，半心半意地要给BPC Embedded建一个EPM Addin。但是这个最终被AnalyisForOffice给断了路。其他的数据审计啊，工作状态啊的功能是强，但是也没强过AFO啊。最强的一点就是和HANA的集成性很好。但从就前端考虑，AFO是和用户交互的主要接口。

那BPCEmbedded路在何方呢？它就跟SAPHANA紧密连接啊，尤其是S４。实时集成和内置的预测功能的加强，谁叫人家嵌入呢。也就是说在ERP里的主数据可用于计划，也不仅仅是主数据了，这个计划模型可以和CP（composite　Provider）来合并实时数据。而且在HANA上，计划逻辑推送到HANA数据库（AMDP）。这就让BPC来处理细节性的产品成本计划啦，逻辑成本计划啦，劳动成本计划模型（通过SAP material，customer和employee的主数据）有很大优势了。

BPC 用来干嘛,怎么用

也就是说这个计划的功能是用来干嘛的？预测啥的？当然了，一切为了利益。为了营利啊。
那怎么弄呢？
得弄一份盈利报告出来啊。你有多少东西，东西定价多少，最后能赚多少。跟实际值也是一一对应的，在我们的计划功能里，有个区分价值类型的。value type,10代表实际值，20代表计划值。
你定计划的时候，肯定要把计划值定高一点。

info provider

信息提供者，也即表或者视图。有些是物理对象，ADSO，有些是虚拟提供者：Composite Provider.
现在我们在计划里，咱都用ADSO。
因为现在到BW7.4 SP8之后，ADSO囊括了DSO，PSA，info Cube和Hybrid Providers众多的功能。
要用到计划功能的ADSO，选择如下：所有特性都为键值。为啥要勾这个选项呢？因为我们接下来要创建这个ADSO的所有特性的子集，也就是aggregation level。

当一个Planning的ADSO被创建后，会生成好几个表：
/BIC/A1 Inbound Table for DataStore
/BIC/A2 Active Data Table for DataStore
/BIC/A3 Change Log for DataStore
/BIC/A6 View for Extraction from DataStore
/BIC/A7 View for Reporting for DataStore

ADSO是二维表结构，我们可以写sql或AMDP来select数据。那从哪张表取数呢？就选7表那个view。
select * from ‘’/BIC/A7 ‘’

这个返回数据就会包括所有1表和2表的数据了，此读取不受BI分析授权的检查。
当然如果你勾了 这个：

你会经常看到ADSO有勾这个的，这代表啥呢？
就是会在HANA上自动建一个view，啥view呢？
是calculation view，一般可以这样写sql：
select * from ‘‘system-local.bw.bw2hana::’’

这个的返回值和7表的返回值是一样的。但是会执行一个权限检查。
这个system-local的存放位置是在这里弄的：
SPRO：


当你生成一个external的HANA view，就会在这个package下面。

composite providers

CP 是几个info provider通过join或者union来的。但是对于planning功能的，只能用union。
而且计划ADSO只能是CP下直接分配的，第一层。不能是第二层。

意思就是你CP下面只能是直接分配的planning的ADSO，不能是CP下还有CP，然后在这个下层的CP下union的planning的ADSO。如果是第二种情况，那虽然也能建planning ready的query.但是保存计划数据会出错。

所以那咋办呢？最好的方式就是ADSO分配给CP之后，在此CP上创建aggregation level,filter,还有query.这样的计划模型就很灵活，很敏捷。因为新的ADSO可以放到CP里面去，比如你要在旧的ADSO上根据区域进行逻辑分区，添加新的有实际数据的ADSO等等，你就只需要对Aggregation level做很小的改动。

当你创建一个CP的时候，你会发现有一个强制性的信息对象会直接加到这个CP里面：
0INFOPROVIDER：

在这里能够限制读取数据的源或者写入数据的目标。而且呢，对于CP本身，咱也能建一个external view. 比如下面这个select语句，决定数据的源：
select * from ''system-local.bw.bw2hana::CMOPOSITE_P01" where “0UBFIORIVIDER” = “ADSO_A01”

这个是从view里取数，由于CP是个虚拟的信息提供者，它是没表的，所以咱不能直接从表读数： select * from ‘0BIC/ACOMPOSITE_P017’ 这个是不行的。

Open ODS view

接下来来看这个view,这个也是能作为一个基础信息提供者，而且它也是虚拟的，不能被底下的表表示。这个虽然不能用做planning的对象，但有个场景，就是Open ODS view呢，能允许实时数据。比如说，我们可以基于ABAP的CDS view来建一个Open ODS view，也就是基于一个SAP交易表。ODS view的底层是原表或者view自己，我们不能写基于Open ODS view的select语句，也不能建一个external的HANA view。

Open ODS view不是物理存储数据在数据库上，它可以基于一个HANA view，ABAP CDS view等等。 虽然不能写select语句，也不能在此view上建一个HANA external view,但是咱可以用LISTCUBE这个事务码在BW４里面查看这个view的数据。
如果这个view是基于view创建并通过HANA　SDA来访问那这个虚拟币和select语句就可以执行。
至于使用Open　ODS　view的场景，以后再看吧。
有个点就是，Open　ODS的association，如果关联了信息对象，那就会自动继承信息对象的属性，如果没有，那就是一个单单的字段：

Aggregation level

好了，现在假设ADSO啦，CP啦，OPenODSview啦都建好了，那么底层这些数据好了以后，怎么搞计划呢？
我们的计划得基于实际，不管实际如何，我们搞计划的同事肯定只想快速的填个计划值，简单，便捷。
所以，这个聚集层级是干嘛的呢？
比如我们想搞销售部门的计划，那他得知道客户，物料等等，他们不需要知道品牌啊，物料组啊，当这个搞计划的同事不想看到这些字段的时候，但这些字段又必须得在的时候。这时候就用到了这个aggregation　level。
这个聚集就是我们的planning信息提供者的子集，有一些我们需要plan的对象。
我们在CP上创建Aggregation　level，这些聚集层级的好处呢，就是你可以直接换掉底层的ADSO，前提是换的那个也有相应的信息对象啊，不影响现在的聚集层级和上面的query啥的。其次呢，这个聚集层级可以让我们从query写入数据到infoprovider，写入到多个ADSO等等。
所以说目的就是写数据到ADSO。那我们不需要写的特性就不要放在aggregation　level里了。

好了，现在在包含CP的infoarea上新建一个Aggregation level，由于是基于CP来建AL，所以会让你选infoprovider:


新建就只有一个默认的信息对象是信息提供者，接下来我们要从左边的info provider拖字段过去。

然后激活。接下来我们要在AL上设置一个filter，为啥呢？
因为AL是用来写数据的，那咱要知道往哪里写。当我们在写计划数据的时候（从query写入数据到planning的ADSO）这时要把数据锁住，尽量我们要少锁，因为可能有很多人在填planning数据，没用到的就不锁。

这个filter是在aggregationlevel上建的，右击，filter。
在filter里面右键添加要filter的值，在属性里做限制。

RSPLAN可以看到：

总结：Aggregation level是用来确定info provider的一个特性子集，要做计划的特性放在这个里面，那么filter是用来决定目标数据范围的，就是填的值到哪里去（一般是到planning的ADSO里去）。

input ready queries

坑待填