搜索
一、BWDTP非法字符问题无非就是业务上搞出一堆乱七八糟的字符，这些字符到了BW这边，就变成了井号（#）这个解决办法有这么几种：1、直接改PSAPSA可以修改，可是这样治标不治本，顶多是我们这边数据上载正常了，可是数据跟业务上的录入还是有差别2、在转换中写StartRoutine方法类似，不过是把'#'替换成''或者''也是和方法1类似，只不过是升级了一下，不用手工操作，代价就是上载的效率和传输的流程3、增强数据源这个方法比较惨，因为井号（#）在源系统中指不定是啥字符呢，仔细算算得有十几个，都控制的话代价比较大，不如写StartRoutine，只不过一个PSA可能会上载到多个模型，就得写多个StartRoutine。4、找业务修改R3的数据这个好，改完了BW再抽一遍完事儿，不过协调起来比较复杂5、增强业务系统在用户输入或者批导的时候，控制输入，当遇到这种垃圾字符的时候，就提示错误，禁止写入，这是最好的办法。二、现在有一个QUERY运行十分慢,所以我想在BW里找到一个工具来分析这个QUERY是怎么运行的.想知道慢在什么地方,用了多少时间等一些具体信息.1、在BW中使用交易代码RSRT2、填上需要测试的报表的技术名称3、单击执行+调试4、勾选弹出的调试选项对话框的其他中的显示统计数据和未使用高速缓存5、输入Querry的所需要的变量，运行结果回来之后，F3返回统计数据界面：将持续时间求和减去时间等待时间、用户的时间，得到的时间作为该报表的统计时间报表执行的速度一般都是cacheBIAAggregateCube自身..所以第二次执行，能从cache（缓存）取数的话，自然就快了三、我在激活一个DSO时，由于数据量比较大，差不多有2千多万条的数据，之前的传输进程都是绿灯，可在激活过程中，就变成了红灯，不管激活多少次也是红灯，请问这个是什么原因啊？这个DSO是主要做报表用，还是做数据存放及delta用，如果是后者的话，更改DSO的属性把“SIDsGenerationuponActivation激活之后生产主数据标识”的勾弃掉，如果是前者，可以通过事务“RSODSO_SETTINGS”调整相应参数来提高你的active的效率。ParameterforSIDGeneration中，MaximumpackageSize是2万，maximumwaittimeforprocess是600(10分钟)，这个数字是否是越大越好?MaximumpackageSize是根据你的内存来设的，maximumwaittimeforprocess可以长一点。四、执行“分配工作簿”后，收到了邮件，可是Excel里的中文都是井号“#######”，请问该怎么解决？谢谢！BW是3.5的。a)退出BW系统，关闭所有BW系统的窗口和EXCEL的窗口；b)右键点击“我的电脑”，选择“属性”――“高级”――“环境变量”--“系统变量”--“新建”，变量名：SAP_CODEPAGE变量值：8400c)依次点击“确定”，保存新增的环境变量.不行的话，重启下机器，另外注意用户名密码输入界面下的语言输入ZH1.我目前在做一个供应商分析的报表的时候碰到了一个过滤不出过滤条件的问题，望各位大侠能帮忙！谢谢！报表是在信息提供者：设备主数据上出的。供应商是设备主数据的一个属性（导航）。在query里制作报表的时候行上是‘供应商’，列上是‘设备数’。目的是分析该供应商都提供了多少设备。当然自由特性里有个设备号，可以追溯。但当我用rsrt测试报表的时候，*正常显示是没有问题的*，但想过滤出特定的供应商的时候总是过滤不出来。再追踪的时候出现如下提示：’在特性ZZCZZS的主数据表中不存在特性值#####################。因此，无法将此值传输到内部SID中。‘另外在ecc的时候供应商就是中文，并不像其他的设备的属性一样有个编号，然后编号可以对应一个中文。是不是和中文有关，因为在提示里的特性值是#####。有没有解决的办法？谢谢了！！！还有在不论是设备主数据还是供应商主数据中中文显示都正常，我在过滤的时候是选择的，而不是输入问题。用RSRCcheck你的那二个特征，并修复。rsa1--工具--应用层次结构/属性更改--信息对象清单，检查设备特性是否在列表里，选中执行属性更改1.SAP后勤数据的抽取，使用的增量队列，财务数据的抽取，使用的是时间戳，这句话对不对？财务数据使用时间戳，就是说不通过增量队列，数据由业务系统直接到达BW系统，似乎与实际情况不符。1、使用RSA7查看增量队列时，确实可以看到财务数据源：0FI_GL_4,0FI_GL_6,2、总账凭证过账后，立即进行数据抽取，0FI_GL_4并不能立刻抽取到数据，而0FI_GL_6立刻就可以抽取到最新数据，这是怎么回事呢？或者我哪里理解错了？SAP后勤数据的抽取，使用的增量队列，财务数据的抽取，使用的是时间戳，这句话是对的，总账凭证过账后，立即进行数据抽取，0FI_GL_4并不能立刻抽取到数据，而0FI_GL_6立刻就可以抽取到最新数据，这是怎么回事呢？那是原因这二个的时间戳的粒度不一样，一个是到时分秒的，一个只是到postingdate的。0FI_GL_10和0FI_GL_14都是为newGL提供的datasouce.0FI_GL_4和0FI_GL_6在BW7.x也都是可用的。BW请求数据，在R3端执行对应的FM操作，获取数据，写入增量队列。1.我现在有个问题，对于同一个Transformation，其中有个字段，需要针对不同的DTP，赋予不同的值，请问如果处理，谢谢！1可以在表tvarvc中建一个变量2然后在不同的dtp中的transfertroutine里写赋值给上面变量的code:比如dtpA执行则赋变量的值为A若dtpB则变量的值为B。。。。3然后在transformationstartroutine中去读变量的值看是从哪个dtp过来的，然后更改处理规则。1、建立一个表；2、在DTP的过滤条件中写代码给表插入一条记录；3、在转换中去读取该表中的记录，并在结束例程中删除表中记录。1.DSO用来存储明细数据，其结构比较简单,对于值的转换,既可以使用合计，也可以使用覆盖的方式。因在源端,如果存在相同的customer记录,需要合并,为了省事,并没有写abap代码,直接启用了合计的方式,如果使用合计的方式，可以用delta吗（最终的DSO）?如果可以,该用什么类型的delta.如果不可以,又不想写代码,如何能实现合计和delta的两种功能.确定你的情况必须要要用合计?用合计的kf一般要谨慎的确定你在的kf合计出的结果的正确性，不然整个dso里的数据都会错误。delta是适用的recordmode用afterimage即可.可以用RSA2查到每个数据源的delta属性，比如2lis_03_bf是ABR,这表示这个数据有afterimage、beforeimage、reviseimage.不是说ods用合计不能做delta，而是说ods一般用来记录的是合计每条数据的详细情况，如果ods里不做报表你可以把kf当charactestic来理解，而在cube里面来合计是相对于不同的diemension来合计你的kf这样是为报表多维分析服务的。ods的delta是把changelog表的变化记录往上更新,合计是key值相同下,keyfigure累加的.你可以用DSO,但是得用两层DSO,第一层DSO1用Overwrite方式,用来正确获取Delta的Changelog数据,第二层DSO2从DSO1更新,可以使用Sum方式.O的数据源都是ADD的，差额镜像，E，可以直接上述到cube，如果上述到dso，则需要设置成sum，不能设置overwrite。FI的基本都是AIE，后镜像，E，不能直接上述到cube，必须先上述到dso，并且要设置overwrite；LO的基本都是ABR，这个就不用说了，很明细，新、前、后、翻转的镜像都存，量很大，可是上述cube，可以上述dso，对于dso的设置也没有关系，D自建的默认是AIE，同FI（BT的是没有提供更改方法，所以自建的统一都是AIE），E主数据的一般采用AIE、AIM和NEWE，说明比较侧重结果和新增数据下面简述下AIE和ABR的区别：ABR的方式注定了，不仅适合直接上载到DSO，可以直接上载到CUBE，不通过DSO，因为不仅序列化，而且是连带各种镜像。AIE不同，只支持后镜像，也就是说，只能首先加载到DSO，然后进行分析，会在激活数据时帮我们补齐前镜像，到DSO的LOG表里，从而保证了DSO的明细要求，又能在CUBE提取LOG表的时候获得正确的数据。因为CUBE只有汇总，没有覆盖功能。Deleteimage上述时的kf是空，所有不能直接上述cube，可以上述到dso，但是必须用overwrite；Reverseimage翻转像可以上述到cube，也可上述到dso可以设置成sum和overwrite；1.由于每隔一段时间需要对PSA进行清理，PSA的数量多，而且每一个我只懂用右键-管理，然后一条一条地选择需要删除的记录（批量一个时间段的，如1-3个月的每日Delta）。请问各位高手，有没有更好的方法可以清理PSA的数据。1、仅成功登记/更新请求====就是指成功更新到DSO或者CUBE的数据请求2、仅那些未在数据目标中登记的带有错误的请求====就是出错了，没有更新到DSO或者CUBE的请求3、仅删除装载请求，不要删除激活请求（ODSR...)====这个应该是说成功装载但是没有上传到DSO或者CUBE的请求吧。一般来说，我们是删除前30天的请求，保留一个月的请求数据即可，这样做的好处是还能节省一下磁盘空间。1.FI怎么抽取当天的数据？FI-AP、AR的设计就是抽取前面一天的数据，因此增量不能抽取到当天的数据。如果数据量不大的话，建议进行全量抽取，然后在BW使用DSO进行增量的处理。1.安全上下限BW中，存在两种数据抽取方式，完全更新与增量更新，完全更新是每次把截至到某个时间的数据全部抽取，增量抽取则只抽取上次和本次抽取之间更新的数据，很显然，增量抽取能够提高系统效率，根据SAP帮助的说法，增量更新又分为时间戳和增量队列两种方法，其中财务数据的抽取为时间戳增量法，后勤数据的抽取为增强队列法。对于增量更新，都需要先对数据抽取进行初始化，然后再进行增量的抽取。对于时间戳增量法，系统存在一个延迟时间，即时间戳设置时间与记账时间的差异，比如时间戳是根据创建时间（或输入时间）来确定是否更新的依据，而在抽取开始时（时间戳已标记），此时凭证已创建而未记账（即未更新至数据库），则此次无法抽取到该凭证，但下次抽取时，由于已在时间戳范围之外，也不再进行抽取，从而导致抽取数据遗漏，避免此问题，SAP帮助上给出了通过设置安全抽取时间的方法，设置视图为BWOM2_V_SAFETY，可根据不同的数据源设置不同的安全时间，两个小时为推荐设置这个安全时间是对于已经创建但未保存在凭证而言，如果在这个安全时间内保存了，则此次抽取将包含在内，比如你6小时抽取一次数据，假如你第一次在12:00抽取，那么下次应该是18:00抽取，那么应该来说18:00抽取的数据是12:00-18:00的数据才对，但是有种情况需要你考虑，比如我11:55在做一个凭证，但是中间我去吃饭，12:30才回来完成这个凭证，那么这个凭证就是11:55创建的，在12:00抽取的时候，由于凭证没有产生，因此无法抽取，但是下次18:00抽取的时候，由于这个凭证是在11:55创建的，所以也无法抽取到。做BW数据仓库最重要的一条准则就是“不重复、不遗漏”，那么这样你就遗漏了数据，那么SAP就想了个办法，就是比如这次我抽取从06:00-12:00，那么下次我抽取从11:30-18:00，这样上面的凭证就能抽取出来了吧，这时候11:30-12:00就有半个小时的重复，这个就叫做LowerLimit。同上，比如我12:00抽取的时候，不想抽取06:00-12