《BO报表发布流程》PPT课件.ppt

BO报报表发发布流程 * 信息技术术部研发发广州分中心 卢卢斌晖晖 目录录 *2 1.1 发发布的概念 3* 发布是什么？ 发布是BO中的一种对象，可以理解为一个信 息集合。通过执 行发布在后台批量刷新多张报 表 并按指定的格式保存结果，然后将保存的结果分 发到指定收件人的BO收件箱或FTP上。 1.2 发发布的要素 1.常规属性：发布名称 2.源文档：需要发布的报表 3.Enterprise收件人：报表的收件人 4.格式：报表保存的格式，可为WEBI,XLS,PDF,MHTML 5.目标：可为BO收件箱、FTP、EMAIL,及发布后报表的名称 6.提示：查询 条件 7.重复发生：运行的频率，立刻运行，指定时间 运行、或周期性运行 8.事件：事件触发，实现 任务链 9.计划服务器组：选择 运行的服务器组 4* 1.2 发发布的要素 1.常规属性：发布名称 5* 1.2 发发布的要素 2. 源文档：需要发布的报表 6* 1.2 发发布的要素 3.Enterprise收件人：报表的收件人 收件人即BO系统用户，分公司指定由哪个用户接收本公司的报表。 7* 1.2 发发布的要素 4. 格式：报表保存的格式，可为WEBI,XLS,PDF,MHTML 8* 1.2 发发布的要素 5. 目标：可为BO收件箱、FTP、EMAIL,及发布后报表的名称 9* 1.2 发发布的要素 6. 提示：查询 条件 10* 1.2 发发布的要素 7. 重复发生：运行的频率，立刻运行，指定时间 运行、或周期性运行 11* 1.2 发发布的要素 8. 事件：事件触发，实现 任务链 12* 1.2 发发布的要素 9. 计划服务器组：选择 运行的服务器组 13* 1.2 发发布的要素 以上九个要素中，只有提示，事件，计划服务器组需在每次月结发 布 时手动修改，其他要素在新建发布的时候已设定好。 BO服务器执行发布后，会把报表实例的数据以文件的形式保存并发至 用户收件箱，所有用户登录infoview系统都能查看他自己的收件箱，用户 在查看收件箱报表时实际 上是查看已保存的文件中的数据，而不是实时 查询 BW数据库。通过执 行“发布”来产生报表实例能缩短报表查询时间 降低消耗服务器资源。 14* 1.3 在实时实时 数据和已保存数据之间选择间选择 实时数据 查询平台的报表。实时访问 BW数据仓库，能查询到BW 最新的数据，代价是增加网络流量和消耗服务器资源、以 及查询时间 。 在BW抽数后，省市公司可通过查询 平台报表实时查看数 据,用户需输入统计日期和公司代码，要等待较长时间 数 据才会被显示。 15* 1.3 查查看实时实时 数据 16* 1.3 在实时实时 数据和已保存数据之间选择间选择 已保存数据 通过执 行“发布”产生报表实例，报表实例的数据以文件的形式保存并 分发给 收件人，收件人可进入infoview收件箱查看这些已保存的数据 ，查询过 程不会触发对BW数据库的查询 。减少了网络流量降低服务 器资源消耗。 现发 布的报表都是多维度表，实时查询 需要等待几十分钟甚至一个多 小时，如晚上批量发布，白天可直接查看查询 好了的数据。 用户进 入InfoView系统，打开“收件箱”即可看到“发布”所产生的报表实 例，双击报 表实例后数据可马上呈现。 17* 1.3 查查看已保存数据 18* 目录录 *19 2.1 月结结BO发发布任务务和时间时间 点 20* 上月最后一天17:00修改查询查询 平台报报表统计统计 月 4日2:00-9:00BW抽数 4日9:00-12:00 BO报表校验（省、地） (大约1.5小时执 行完毕) 4日4日晚-5日9:00前县支报表发布（大约8小时执 行完毕） 5日5日晚-6日9:00前 省、市报表发布（大约19小时执 行完毕） 6日6日晚-7日9点前 首先执行4.1总公司机构发布。 然后执行4.2总公司发布。 （大约6小时执 行完毕） 2.2 月结发结发 布总览总览 BO发布任务持续三天，其中耗时最长的环节 是发布县支报表和 省、市报表。 21* 2.2 月结发结发 布总览总览 县级 ：共346个发布，每个发布处理6张报 表。 市级：共346个发布，每个发布处理26张报 表。 省级：共38个发布，每个发布处理26张报 表。 地市的所有县支公司由一个发布处理，所以县级发 布数量和市级 发布数量相同。一个县级发 布有多个收件人（该地市下所有县支公司 的用户）。 整个BO发布过程通过数据校验、BO CMC，PUBTOOLS，三个 系统完成。下面结合各系统的作用介绍BO发布的各环节 。 22* 目录录 *23 3. 修改查询查询 平台统计统计 月 修改总、省、市的查询 平台报表统计 月份 这三个文件夹内存放了多个webi报表。只要完成了BW抽数，总，省 ，市公司不必等待报表发布完成，通过刷新这些报表即可实时查询 上月的财务 数据(速度慢，占用服务器资源多)。 24* 3. 修改查询查询 平台统计统计 月 修改上面三个文件夹内的所有webi的统计 月 25* 3. 修改查询查询 平台统计统计 月 需要修改的对象数量较多，手工逐个修改非常耗时。为解决BO报表 发布过程中需要重复大量手工操作的问题 ，通过PUBTOOLS系统可 以批量修改报表和发布的统计 月。 26* 3. 修改查询查询 平台统计统计 月 只需针对三个文件夹分别执行此操作就能修改查询平台的所 有报表统计月，极大提高了处理效率。 27* 目录录 *28 4.1 BO报报表校验验 29* 需求： 将BO查询平台的总省市三级报表，进行表内、表间、期间校验。 实现实现 方案： 将查询 平台的报表以xls格式发布到ftp，用ETL工具抽取到数据库落地，利用 ORACLE存储过 程来进行表内、表间、跨期间的校验。 BO校验执验执 行流 程： 校验报 表发布 xls转为 csv ETL工具抽数 校验程序运行 结果展现 将查询平台 的报表设置 为按省、市 分节，发布 xls到ELT服 务器上 把xls用程序 转为文本文 件csv 使用 Informatica 工具将csv中 的数据按照 设计好的 mapping模板 抽取到校验 系统数据库 通过oracle的 存储过程， 为所有总省 市机构都进 行一遍3万条 规则的校验 ，如果未通 过则记录 在 结果表中 开发一张基 于关系型数 据库的BO报 表，读取结 果表，并设 置权限，供 分公司用户 查看 4.2 校验报验报 表发发布 发布出来的xls，共计179各xls文件: 30* 4.3 xls转为转为 csv 转为csv: 31* 4.4 ETL工具抽数 使用Informatica作为ETL工具，将csv抽取到oracle 32* 4.5 校验验系统统数据库结库结 构 BO校验系统数据库表按坐标存数。 由三张表描述一张BO报表： 1.BOGST07表：存放 X轴科目名称 33* 4.5 校验验系统统数据库结库结 构 2.BOGST08表：存放y轴维度 34* 4.5 校验验系统统数据库结库结 构 3.BOGST13:按月份、机构、表id、坐标存放数据 35* 4.5 校验验系统统数据库结库结 构 4.规则表：BOGST_RULE 36* 4.5 校验验系统统数据库结库结 构 5.校验结果表BOGST_RESULT 37* 4.6 执执行BO校验验 以08.2013为例，校验今年8月的数据。 利用BO辅助工具，执行全国校验发布。 登录Informatica服务器，将D:bogenst下的两个配置文件 中的日期改为本次校验的日期 打开Informatica PowerCenter Workflow Manager,运行工 作流 自动弹出Informatica PowerCenter Workflow Monitor,监控 作业进度，完成后，便可通知分公司查看校验结果 38* 4.6 执执行BO校验验(校验发验发 布) 39* 4.6 执执行BO校验验 点击Start Workflow From Task 40* 4.7 查查看校验结验结 果 查看校验结果 41* 4.8 BO校验验系统统耗时时 42* 最初： 发布：6小时 抽数：1小时 校验：16小时 总共:23小时 后来： 发布：5小时 抽数：1小时 校验：3小时 总共：9小时 现现在： 发布：20分钟 抽数：1小时 校验：20分钟 总共：不到2小时 目录录 *43 5.1 BO管理工具：CMC-中央管理控制台 CMC是基于 Web 的应用程序，用来管理 BO的门户系统。包 括以下几点管理功能： 用户管理：如设置身份验证以及添加用户和组 内容管理：发布、组织所有 BO 内容并为这些内容设置安 全级别 服务管理：管理服务器和创建服务器组 这章主要介绍服务管理和内容管理中的发布管理 44* 5.1 BO管理工具：CMC-中央管理控制台 从浏览器直接登录到 CMC 45* 5.2 BO服务务器组组 46* 现BO系统共设有10个服务器组，每个服务器组都包含5类 服务器（实为进 程），且相同类型的服务器在所有服务器 组上的数量相同，包括： AdaptiveJobServer(AJS)3个 AdaptiveProcessingServer(APS)3个 DestinationJobServer(DJS)1个 PublicationJobServer(PJS)1个 WebIntelligenceProcessingServer(WPS)6个 5.2 BO服务务器组组 47* 5.2 BO服务务器组组 48* 报表发布的过程需要上面5类服务器互相配合才能完成。每种服务器的作用如下： Web Intelligence Processing Server(WPS) 专门处 理webi格式报表的服务，包括打开、运行查询 、展示结果。 Publication Job Server(PJS) 负责 管理和调度发布（Publication），控制发布的流程，协调 发布所需的其他服务器 Adaptive Job Server(AJS) 负责 选取一个空闲的webi用来查询报 表 Adaptive Processing Server(APS) 公共的服务，负责协调 、通信 Destination Job Server(DJS) 负责 将发布生成报表分发到不同的目的，如个人收件箱，或者电子邮件，或者ftp 5.2 BO服务务器组组 49* 在批量发布报表之前最好先重置各服务器，清空其占用的内 存，并监控服务器状态，待所有服务器进入正常状态以后才 开始发布，这样可保证批量发布速度较快和较低的失败几率 。 5.3 事件的触发发机制 多个发布被平均分配到10个服务器组，正常情况下一个 服务器组在一个时刻只执行一个发布，被分配到同一个服务 器组的发布串联执行（处理异常时才有可能一个服务器组同 时运行两个或三个发布）。 通过消息机制实现多个发布串联执行，后一个发布必须 接收到前一个发布完成的消息后才开始运行。 50* 5.3 事件的触发发机制 51* 等待事件触发发事件 发发布1无Event1 发发布2Event1Event2 发发布3Event2Event3 一起运行发发布1成功发发布2成功发发布3成功 发发布1正在运行 成功成功成功 发发布2挂起正在运行 成功成功 发发布3挂起挂起正在运行 成功 5.4 PUBTOOLS 功能：批量修改发布统计月、发布服务器分组、批量执行发 布，以程序取代大量重复的手工操作，提高工作效率。 52* 5.5 批量执执行发发布 1. 日历统计历统计 月批量修改 2. 批量设设置服务务器组组 3. 批量设设置定时时任务务 县县支，省，市，总总的发发布都执执行上面三个步骤骤 53* 5.5 批量执执行发发布 1.批量设置日历统计 月：发布元素-提示 54* 5.5 批量执执行发发布 2.批量设置服务器组：发布元素-事件、计划服务器组 55* 5.5 批量执执行发发布 3.批量设置定时任务 发布元素-重复发生、计划 56* 目录录 *57 6.1 服务务器组组及其服务务器 58* 现BO系统共设有10个服务器组，每个服务器组都包含5类服 务器（实为进 程），且相同类型的服务器在所有服务器组上 的数量相同，包括： AdaptiveJobServer(AJS)3个 AdaptiveProcessingServer(APS)3个 DestinationJobServer(DJS)1个 PublicationJobServer(PJS)1个 WebIntelligenceProcessingServer(Webi)6个 6.1 服务务器组组及其服务务器 59* 6.2 并行作业业 60* 这些服务器均并发执 行多个作业，AJS服务器执行AJS作业，DJS服务 器执行DJS作业，其他的如此类推。单一服务器最大的并发作业数列举 如下： 一个AJS服务器最多并发执 行20个AJS作业。 一个DJS60DJS。 一个PJS5PJS。 一个Webi300Webi。 APS服务器是并行处理作业，但没有资料显示最大并发作业数，配置 了3个APS服务器是避免这个服务器成为处 理瓶颈。 6.2 并行作业业 查看各服务器的“属性”，可得到其最大并行作业数。 61* 6.2 并行作业业 一个服务器组能并发处理的最大作业数列举如下： AJS作业最大并发数 = 3*20 DJS作业最大并发数 = 1*60 PJS作业最大并发数 = 1*5 Webi作业最大并发数 = 6*300 62* 6.3 服务务器量度 另需关注PJS，AJS，DJS这三类服务器的量度。其中一数值 “并行作业数”表示此服务器在当前时刻并发处理的作业数。 此数值与发布过程中的处理对象有如下对应关系 PJS服务器的并行作业数 = 此服务器正处理的发布数 AJS服务器的并行作业数 = 此服务器正处理的表数 DJS服务器的并行作业数 = 当前正在从此服务器接收表文 件的收件人数(同一张表同时分发给n个收件人将占用n个DJS 作业) 63* 6.3 服务务器量度 64* 6.3 服务务器量度 现在月结发布过程在正常情况下是一个服务器组执行一个发布，现列出单服 务器组各类作业最大并发数与单个发布所占用的各种作业数量。 65* PJSAJSWebiDJS 单服务器组各类作 业最大并发数量 560180060 单个县支发布（6 张表） 166(同时处 理6个报表 实例) 6*20(每个县支报表 平均需分发给 20个 收件人) 单个省发布（26张 表） 1262626*1(省报表为单 个 收件人) 单个市发布（26张 表） 1262626*1(市表为单 个收 件人) 6.3 服务务器量度 从上表可看出，只有县支报表调用DJS作业次数超过了单服务器组DJS作业最 大并发数量。而单个县支发布所调用的其他作业数和其他发布所调用的作业数均 少于单服务器组各类作业最大并发数量。而DJS作业的操作主要是拷贝文件，耗 时较短，即使一个DJS作业在一个发布过程中需多次分发文件亦不会导致性能缓 慢。因此当前各类型服务器数量的配置已能很好地满足月结发布的资源需求。 66* 目录录 *67 7.1 发发布过过程中的异常 由于目前使用3.1版本BO系统，版本比较老，稳定性比新版本差，而且仍 存在较多bug未修复，因此在大批量发布过程中容易导致异常情况： 1.多个发布失败。 2.失败的发布集中在一个服务器组。 3.多个发布被长时间 挂起。 68* 7.2 发发布失败败的处处理办办法 假如有某个发布失败，可执行如下操作： 1.重试这个发布。 2.重新计划发布。如果执行1后仍然失败，在实例管理器中右键点击该发 布， 重新计划，更换服务器组，删除等待事件，重复发生选“现在”，再次执行发 布。这时候可看到两个相同的发布(一个失败一个运行中或者挂起)。最后把失 败的那个发布删除即可。 69* 7.2 发发布失败败的处处理办办法 70* 7.3 同一服务务器组组有多个发发布失败败的处处理办办法 在处理失败的发布时应当记录其服务器组，如果大部分失败的发布集中在某 个服务器组，尤其是同一服务器组上多个紧邻的发布都失败过，那基本上就是这 个服务器组上的四类进程出问题了。可以在CMC的“服务器”选项卡服务器组 -定位到这个服务器组。手动释放AJS，APS，DJS，PJS这四类进程的内存 。 在释放相关进程的内存之前不要将失败的发布分配到这些服务器组。 71* 7.4 大量发发布挂起的处处理办办法 如果当前有多个正在运行的发布，突然有一半甚至更多的发布变成“挂起”状 态，而且持续挂起时间比较长，必须“重新计划”这些挂起的发布（参照7.1节