IBM Cognos 最佳实践: IBM Cognos 8 BI 调度程序路由详解

文档性质:指南;产品:IBM Cognos 8 BI;关注领域:基础架构;版本:1.0

这篇短文解释 IBM Cognos 8 Dispatchers 路由请求过程中涉及的主要概念。

Cognos Proven Practices Team, Cognos 最佳实践团队, IBM USA

Cognos 最佳实践团队。



2011 年 7 月 22 日

免费下载:IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

目的

本文是 IBM Cognos 8 产品文档 Security and Administration GuideArchitecture and Deployment Guide 部分的一个补充。本文将解释 Dispatcher 路由涉及的概念,包括负载平衡和 Advanced Routing。

适用性

本文描述的概念适用于 IBM Cognos 8 BI 所有版本。

例外与除外责任

本文仅限于基于 Dispatcher 的路由,不涉及 Service 路由。本文读者应该熟悉 Architecture and Deployment Guide 中描述的概念。


IBM Cognos 8 中的路由

路由?为什么?

IBM Cognos 8 基于一个 Service Oriented Architecture (SOA),这意味着该产品在一个网络上通过 SOAP 通信。有许多不同的服务,它们都实现不同的产品特性。每个服务只能服务某种请求类型。SOA 中的一个路由挑战是将请求路由到能服务该请求类型的服务。

SOA 中的另一个路由挑战是负载平衡和/或故障转移。同一种服务类型在整个系统中可能有多个实例。如果存在多个实例,就可能发生负载平衡(每个实例被分配该请求类型的一个可配置百分比)或故障转移(针对某种服务类型的请求被重新路由到一个活动实例,原因是另一个失败)。

Dispatcher

这两个路由挑战都通过一个名为 Dispatcher 的软件组件处理。从技术上讲,这个 Dispatcher 是一个 servlet,处理 HTML 输入并生成 HTML 输出。对于 IBM Cognos 8,输入和输出工作负载实际上是 SOAP(通过 HTTP 传输的 XML)。

每个 Dispatcher 都托管一组服务,具体取决于 IBM Cognos 8 实例上安装的系统组件。服务被注册到 Dispatcher 并由 Dispatcher 控制。与此同时,Dispatcher “知道” 它托管了哪些服务实例,进而知道能本地服务哪些请求类型。

当一个 Dispatcher 启动时,将使用活动 Content Manager (CM) 注册自身。它将报告自己托管的服务并从 CM 获取关于系统的信息。通过这个过程,每个 Dispatcher 都 “知道” 系统中的其他所有 Dispatchers 以及它们托管的服务。

尽管一个简单的服务器环境对于测试来说可能已经足够了,但生产系统通常包含几个节点,每个节点都运行一个注册了自己的服务集的 Dispatcher。 借助多个节点,负载平衡和故障转移变得可能。IBM Cognos 8 架构通过一个逻辑总线来实现这一点,该逻辑总线位于每个节点上的 Dispatchers 之间。在这个逻辑总线上,请求在一个系统中的 Dispatchers 之间传递/路由,最终到达某个 Dispatchers 注册的一个特定服务实例。这个过程能实现本文将解释的负载平衡和服务可用性。

客户机请求 — 无论用户通过他们的浏览器还是 SDK 程序 — 发送请求到一个 Dispatcher 以获取服务。一个系统的 Dispatchers 将确保请求被路由到适当服务类型的一个服务实例,该实例将处理请求并将结果传送回客户端。

入口点上的考虑

由于 Dispatcher 是一个 servlet,因此它必须部署到一个 Servlet Container/Java Application Server,这意味着它位于一个经典三层架构的 Application 层中。通常认为,向终端用户暴露应用程序层存在潜在风险,因此,作为一个最佳实践,通常使用 web 层中的其他某个组件(比如一个 web 服务器)来处理与外部客户机的通信。

在 IBM Cognos 8 架构中,实现途径是 IBM Cognos 8 Gateway,它有 6 种不同的实现:CGI、MOD、MOD2、MOD2_2、ISAPI 和一个额外的 servlet 实现。典型的安装使用单个或多个 Gateways 充当 IBM Cognos 8 系统的入口点。但 Gateway 组件只是将请求中继到它的已配置调度程序列表中的第一个可用 Dispatcher。Gateway 并不负责路由,它是一个静态链接,只在已配置的 Dispatcher 无法达到时更改。只有遇到这种情况,Gateway 才尝试将请求转发到它的列表中的第二个调度程序,以此类推。由此看来,路由直到一个请求第一次到达一个调度程序时才开始。首先接收到请求的 Dispatcher 称为 FRONT Dispatcher。这对于几个涉及身份验证的特定请求流很重要(请参阅 “附录 A”)。

但是,从技术上讲,无论入口点是什么(Dispatcher 或 Gateway),都没有关系。这一点很好,因为这意味着可以使用 web 服务器插件这样的应用程序服务器特性,以与 IBM Cognos 8 Gateway 相同的方式,将在 web 层中接收到的请求代理到应用程序层。

对于本文余下部分,将不再区分 Dispatcher 和 Gateway,无论何时需要,我们都将引用一个入口点来简化说明。


路由概念

下一小节将解释 IBM Cognos 8 路由的主要概念。

Server Groups

第一个要描述的概念是一个 Server Groups

Server Group (SG) 是一组 Dispatchers。每个 Dispatcher 一次只分配一个 Server Group。

默认情况下,当系统被安装时,不会为 Dispatchers 定义任何显式 Server Group 设置。这将自动使它们成为 “默认 Server Group” 的一个成员。但是,管理员可以在 IBM Cognos Administration 中为 Dispatcher 对象的 Server Group 属性指定一个字符串值,向一个 SG 显式分配一个 Dispatcher。这个值隐式定义一个该名称的新 Server Group,如果它不存在的话。如果存在,则将该 Dispatcher 添加到 Server Group。

图 1. 分配到 SG “Endor” 的 Dispatcher
分配到 SG

Server Groups 很重要,因为它们通常定义负载平衡和服务分配的范围。只要 Dispatchers 查找具体服务的一个活动实例,则该查找的范围就是它所在的 Server Group。一个 Dispatcher 永远都不能将请求路由到它的 SG 之外的服务,惟一的例外是 ContentManager Service。当 Dispatchers 考虑 Load Balancing 时,它们将只针对它们在的 SG 中的服务。这是需要记住的两个非常重要的事实。

最后,Server Groups 是使用 Advanced Routing 的先决条件,我们将稍后讨论。

Server Groups 存储在 Content Store 中,只有 CM 能将 Dispatcher 分配的信息提供给一个 Server Group。只能通过向 Dispatchers 的 Server Group 属性提供值来隐式管理它们,也就是说,如果输入一个以前没有存在的新值,一个新的 Server Group 将被隐式定义。如果没有任何 Dispatcher 再使用值 X,那么 Server Group X 将被删除。Server Groups 列表可视为一个系统中所有 Dispatchers 的 Server Group Property 上的一个 “SELECT DISTINCT”。

IBM Cognos Administration 允许按文件夹分组 Dispatchers。但这并不意味着一个 Server Group,这只是一种组织分组方式。通过使用文件夹,可以一次将属性应用到多个 Dispatchers。默认情况下,Dispatchers 将从父对象集成属性值,就像一个文件夹一样。

Dispatcher 集群信息

要能将请求分配给适当的服务并正确路由它们,Dispatcher 必须拥有大量信息,包括:

  • 哪些 Dispatchers 已在 IBM Cognos 8 系统中启动并运行。
  • 哪些调度程序下属的 Server Groups。
  • 与每个调度程序关联的服务。
  • 每个服务的运行状态。

这些信息称为 “Dispatcher 集群信息”

如前面的 2.2 节所述,每个 Dispatcher 都会在启动时将自己注册到 Content Manager。在这个注册过程中,Dispatcher 将通知 CM 它托管的服务及其运行状态(启用/禁用)。CM 将这些信息添加到已经收集到的 Dispatcher 集群信息。然后,Dispatcher 将查询 CM,获取 Dispatcher 集群信息的一个子集,并从中创建一个 Dispatcher 集群视图。这个集群视图包含所有服务及其关联的调度程序,以便最终每个 Dispatcher 都拥有关于其他所有 Dispatchers 及其关联服务的信息。

Dispatcher 集群信息仅当使用一个特殊调用(reconfigure)时才更新,该调用触发 Dispatcher 从 CM 请求更新后的信息并重建它的集群视图。当 IBM Cognos 8 系统中的某个 Dispatcher 有意(被管理员停止或启动)或无意(也称为 “崩溃”)改变其运行状态时,这个调用将被 Content Manager 执行。这导致 CM 中的 Dispatcher 集群信息被更新,更新后的信息必须分发给系统中的每个 Dispatcher。操作方法是将这个 reconfigure 调用发送给每个 Dispatcher。CM 中的集群信息更新后,可能最多需要 1 分钟使其他所有 Dispatchers 提取并应用更改。这是因为每个调度程序都拥有一个 30 秒 “保持活力” ping,这意味着它们每 30 秒都向 CM 报告一次:它们还活着。与此同时,在 30 秒最大时限之后,CM 将意识到某个 Dispatcher 不可用。

在 Dispatcher 集群信息之后,需要使用服务的运行状态更新每个调度程序的集群视图。但是,这仅当管理员更改服务的运行状态时才发生。在那种情况下,托管那个特殊服务实例的 Dispatcher 将通知 CM 该更改,CM 然后通知其他 Dispatchers。

可以通过使用以下 URL 查看一个 Dispatcher 的集群视图:

http://<INTERNAL_DISPATCHER_URI>?b_action=p2plbDiag

访问这个 URL 的用户需要 “canUseAdministrationPortal” 功能,且 Cognos Application Firewall (CAF) 必须针对被访问的 Dispatcher 被禁用。

图 2. /p2plbDiag URL 的集群视图输出
/p2plbDiag URL 的集群视图输出

负载平衡

只要一个 Server Group 中的一个 IBM Cognos 8 服务有多个实例可用,就可以应用负载平衡概念。不同服务器组中的同一个服务的不同实例不适用负载平衡。

但是,并非所有服务都适用负载平衡,下面几节将进一步介绍。

在 IBM Cognos 8 中,负载平衡可以启用或禁用。使用外部负载平衡器在节点(Dispatchers)之间分发负载时,可能需要禁用 IBM Cognos 内置负载平衡。在 WebSphere 集群中部署 IBM Cognos 8 时就需要这个设置。但是,那种路由并非基于 IBM Cognos 8 服务可用性或负载,只是基于 Dispatcher 可用性和负载。由于在一个集群中,所有节点都必须一致,因此它们将全部运行相同的服务。因此,重新路由请求是再一次事与愿违。

第二个用例是在调度程序之间使用外部硬件/软件负载平衡时,但是,这两个用例都非常特别,因此通常为 IBM Cognos 8 启用负载平衡。

负载平衡通过调度程序的 “Load Balancing Mode” 设置控制。该设置可以设置为 “Weighted Round Robin”(也称为 “启用”)或 “Cluster Compatible”(也称为 “禁用”)。需要特别注意的是,一个系统中的所有调度程序都必须使用相同的模式,否则路由可能出现冲突,该产品无法正常工作。

模式 “weighted Round Robin” 表示 IBM Cognos 8 应该路由适用的请求。路由将采用 Round Robin 方法的一个变体来在服务的多个实例之间分发请求。尽管 Round Robin 是一种简单直观的请求分配方法,但它并不考虑服务之间的可能存在的差异。由于 IBM Cognos 8 使用一个 SOA,因此那些实例很可能位于不同的物理机器上,因此它们可以使用的资源(内存堆量、CPU 数量)可能差异很大。这导致这样的理解:并非所有服务实例的潜能力都是相同。在一个拥有多核 CPU 和大量内存的机器上运行的服务比在一个只有单个 CPU 和 2GB 内存的机器上运行的服务可以处理更多负载。为处理这种情况,一个权重已经被添加到分配请求的 Round Robin 方法。这个权重影响一个实例将获取的请求的数量。事实上,这个权重被分配给调度程序,而不在服务级别上,因此它适用于调度程序托管的所有服务,由于它们都共享相同的硬件,因此这种分配很有意义。这个权重在调度程序的 Processing Capacity 属性(见图 1)中定义。考虑到这种能力,Round Robin 的工作方式如下:

示例:

4 个 Dispatchers 定义了不同的 Processing Capacity。

Dispatcher A, Weight 1
Dispatcher B: Weight 2
Dispatcher C: Weight 1
Dispatcher D: Weight 4

请求将以以下顺序分配给 Dispatchers:A, B, B, C, D, D, D, D, A, B, B, C, D, D, D, D, ...

负载平衡模式的第二个值是 “Cluster Compatible”。这个名称表明了它的用途。如前所述,此值用于阻止重新路由一些适用请求,这些请求已经被故意路由到一个特定调度程序,从而路由到已经在那里托管的一个服务实例。这个值通常用于集群化环境,或其中使用一个外部负载平衡器的设置。需要特别注意的是,不受负载平衡影响的请求仍将路由到正确的调度程序/服务。

Cluster Compatible 路由模式排除了使用 Advanced Routing(稍后将介绍)的可能性,因此使得显式 Server Groups 的定义也变得无效。

请求密切关系

前面提到过,并非所有请求都适用于负载平衡。这是因为还有一个概念定义用于衡量它的重要性的度量指标,某个请求通过一个特定 Dispatcher 上的一个 IBM Cognos 8 服务实例处理。这个度量指标称为请求密切关系(request affinity)。如果某个请求是密切的,那么它不能被负载平衡。

请求的密切关系取决于它请求的服务和操作类型。请求密切关系在请求创建时由 IBM Cognos 8 系统隐式设置,不能被控制或更改。请求密切关系存储在请求的 SOAP 动作头部的一个值中。IBM Cognos 8 中有 5 个不同的密切关系值。

  1. (none) – 不密切。
    请求可以被路由到目标 IBM Cognos 8 服务正在运行的任何实例。
  2. high – 高密切关系。
    请求应该被路由到 nodeID 参数中指定的 Dispatcher。这个参数是高密切关系请求的必需参数,因此必须在请求的 SOAP 头部中设置。如果请求的 Dispatcher 无法达到,则请求将被视为 “不密切”。
  3. session – 会话密切关系。
    这个值与高密切关系相同,惟一不同的是 nodeID 是可选的。如果没有指定 nodeID,那么它将被视为 “不密切”。
  4. absolute – 绝对密切关系。
    Dispatcher 必须将请求路由到 nodeID 指定的 Dispatcher。如果指定的 Dispatcher 无法达到,则请求将失败并返回一个 SOAP Fault。
  5. control – 控制密切关系。
    与绝对密切关系相同,但这是一些系统操作专用的,这些操作涉及执行报告,比如取消一个报告。

需要记住的一点是,只有不密切请求能被负载平衡。

Advanced Routing

当 Server Groups 概念被引入时,Server Groups 将如何应用并不完全明朗。本文最后讨论的概念将揭示这一点。

每个 Dispatcher 在任何时候都是一个 Server Group 的一部分。默认情况下,一个 IBM Cognos 8 系统中的所有 Dispatchers 只属于一个 Server Group。IBM Cognos 8 Load Balancing 只在这个 Server Group 中进行,这意味着,在正常情况下,一旦一个请求被分配到一个 Server Group,它就永远无法离开那个服务器组。

这意味着,如果运行 (Batch)ReportService,所有 Dispatchers 都是平等的,这是因为它们对各种请求可用并共享相同的数据库连通性。但是,这并不足以满足所有用例的需求。

有人可能想确保某些报告执行由某些特定调度程序处理,可能的原因包括:

  • 执行官执行的报告应该在专用硬件上处理。
  • 来自一个位置的用户的报告应该通过本地服务器处理,尽管整个系统在地理上是分布式的。
  • 某种数据库连通性类型只在特定 Dispatchers 上存在/不存在。例如,如果整个系统拥有在 Windows 和 UNIX 上运行的 Dispatchers,Microsoft SQL Server 在 UNIX 上没有针对 SQL Server 的数据库客户端。必须确保针对 SQL Server 运行的报告由 Windows 上运行的一个 Dispatcher 托管的 ReportService 的一个实例处理。
  • 针对 IBM Cognos PowerCubes 运行的报告要求多维数据集文件(cube files)本地可用。与将它们复制到多台机器相比,您可能更想在拥有相应文件的机器上基于那些多维数据集处理所有报告。

这些只是通过实现 Server Groups 和 Advanced Routing 可以支持的用例的一部分。

Advanced Routing 允许基于 Routing Rules 将请求 (Batch)ReportService 和 PowerPlay Service 的非密切请求路由到特定 Server Groups。一旦它们被分配到一个 Server Group,它们就受制于那个 Server Group 的 Load-Balancing。

Routing Rules 将所谓的 Routing Sets 映射到 Server Groups。Routing Rules 针对整个 IBM Cognos 8 系统全局定义。它们存储在单个列表中,由 Content Manager 通过 Cognos Administration 管理。

图 3. Cognos Administration 中的 “Specify Routing Rules” 按钮
Cognos Administration 中的

根据 Routing Rules 匹配报告执行请求由 CM(不是 Dispatcher)处理。规则按顺序解析,第一个匹配的规则触发,同时阻止进一步评估规则。强调一下,尽管一个请求可能同时匹配规则 #1 和 #3,它将总是根据规则 #1 处理,因为第一个匹配的规则将触发。

向 (Batch)ReportService 或 PowerPlay Service 发送请求的 IBM Cognos 8 服务负责调用 CM 来评估 Routing Rules,并将 Server Group Information 放置到传递到一个 Dispatcher 的请求中。例如,如果一个报告通过 Cognos Connection 以交互式方式调用,将由 Presentation Service (XTS) 负责询问 CM,了解要执行的报告是否受制于任何路由规则。如果是这样,CM Service 将使用一个 Server Group 名称进行响应,Presentation Service 然后将该名称添加到它传递到本地 Dispatcher 进行处理的请求。这是因为经过调度的报告将由 Job 和 Monitoring Service (JMS) 和处理。

图 4. Cognos Administration 中的 Routing Rules 的定义
Cognos Administration 中的 Routing Rules 的定义

最后,由 Routing Sets 定义将对哪些报告执行应用高级路由。Routing Set 是一个名称 — 应用到一个特定类型的对象集的标签。有三种 Routing Sets 类型,通过对象集中的对象类型区分:

  • Package Routing Set:
    由 Packages 组成。基于已定义包的数据的报告执行将被路由到一个指定 Server Group。
  • Group Routing Set:
    由安全 Groups 组成。如果某个用户是集合中的一个组的成员,则由该用户运行的报告执行将被路由到指定的 Server Group。
  • Role Routing Set:
    由安全 Roles 组成。如果某个用户是集合中的角色的成员,则由该用户运行的报告执行将被路由到指定的 Server Group。

Routing Set 只包含一种类型的元素。例如,无法定义一个包含一个包、两个组和一个角色的集合。这些必须分为三个集合。

要向集合添加对象,管理员在对象属性的相应部分指定集合名称。如果该名称的集合还不存在,则该集合将自动创建。请参阅产品文档,了解关于如何向路由集合分配 Groups、Roles 或 Packages。

最终,一个报告执行请求((Batch-)ReportSevice 或 PowerPlay Service)将根据定义的 Routing Rules 被检查。如果它匹配一个规则,那么它将被路由到那个目标 Server Group 中的一个 Dispatcher。在目标 Server Group 中,Load-Balancing 可能会发生,最终请求被分配到请求的服务的一个实例。如果没有匹配的 IBM Cognos 8 服务可用,请求将失败并报告一个错误,表明没有可用服务可以处理这种请求类型。

Advanced Routing 的用途非常广泛,通过路由到专用资源,能极大地改进总体负载处理或流量形成。


路由过程

前面介绍了所有必要概念,现在终于可以定义路由过程了。路由过程大致包含 5 个步骤。

注意:这里的说明是概念性的,并不一定准确描述每个操作的步骤。但是,对于理解本文描述的概念,这足够了。

识别操作

Dispatcher 拥有一个所谓的处理器静态列表。每个处理器都被查询,以了解它是否能处理相关请求。这里有可用于处理身份验证、负载平衡等的处理器。无需详细介绍,您应该能够理解,每个处理器都有自己的步骤序列,用于处理请求。

例如,当 Dispatcher 收到一个请求时,首先执行的一个操作就是验证该请求所属的会话是否已经通过身份验证。如果没有,身份验证处理器将被使用,该处理器运行几个步骤,只有身份验证成功通过后,才会重新发出原始请求进行后续处理。

对于后续步骤,可以安全地假定会话已经通过身份验证。

识别目标服务

下一步是识别能处理请求的目标服务。目标服务基于以下信息(按先后顺序)识别。

  • SOAPAction HTTP 头部
    例如 http://developer.cognos.com/schemas/reportService/1
    在本例中,SOAPAction 头部将包含对特定架构的引用,暗示要使用的服务。
  • 服务映射
    每个调度程序都拥有一个 SOAPAction -> Service mappings 的静态列表,从中派生目标服务。
  • “b_action” URL 参数
    针对 Dispatcher 的 HTTP GET 或 POST 命令可能会包含 b_action 参数,该参数的值将表明目标服务。
    例如 b_action=xts.run targets the Presentation Service (XTS)
  • 请求的 PATH_INFO
    有些 URLs 路径表明了一个目标服务
    例如 /cgi-bin/cognosisapi.dll/gd/… 表明一个特定操作(检索一个预先定义的图表或 Diagram),该操作通过一个特定处理器/服务处理。
  • 如果请求没有指定上述任何信息,就会被转发到 IBM Cognos Connection 主页。

此时,请求已通过身份验证,目标服务已识别。

处理 Content Manager 请求

如果目标服务是 Content Manager Service,则请求被路由到活动 Content Manager,而不管任何 Advanced Routing、Server Groups 或 Load-Balancing。这对于此产品正常工作很重要。

处理报告执行请求

如果这是一个请求 (Batch-)Report Service 或 PowerPlay Service 的服务,因此是一个实际执行某种报告的服务,那么如果它不是关系密切的,就会受制于 Advanced Routing。

所有密切请求将被路由到指定 Dispatcher,而对于非密切请求,将应用 Advanced Routing(如果已定义)。

此时,请求应该已经进入 Server Group。

处理 Load-Balancing

现在请求已经被分配到一个 Server Group,它应该受制于 Load-Balancing,当然前提是它是非关系密切的。根据 Server Group 中可用的目标服务的实例数量,请求要么直接被分配(只有一个可用实例),要么根据加权 Round Robin 计算的结果被分配(有多个可用目标服务实例)。

如果完全没有可用的目标服务实例,请求将失败,一条错误消息返回客户机,表明 Server Group 中没有可用的目标服务。


附录 A – 已知挑战

SSO 可能只在 FRONT Dispatchers 上需要 STS

由于身份验证处理器的当前实现,某些环境中可能有一种情况使 SSO 失败。

这只适用于不使用 Gateway 组件的设置,通常是 IBM Cognos 8 被部署到一个应用程序服务器(比如 IBM WebSphere)且应用程序服务器被使用时。在那些设置中,有这样一个要求:所有访问只通过 FRONT Dispatchers 完成,且每个 FRONT Dispatcher 都运行 Presentation Service。

如果一个非 FRONT Dispatcher 也运行 Presentation Service,就会发生这样的情况:用户将使 XML 返回自己的浏览器,而不是使身份验证发挥作用。

每个 Server Group 至少需要一个 Dispatcher Service 实例

当 Server Groups 被定义时,重要的是要确保每个 Server Group 至少运行一个 Dispatcher Service 实例,否则请求可能不会被正确路由。例如,如果一个只包含一个节点(该节点只是一个 Content Manager 组件的安装)被定义,这种情况就会发生。默认情况下,CM 只安装、而不运行 Dispatcher Service。

最佳实践是以下面的方式定义 Server Groups:只有运行 (Batch-)ReportService 和 PowerPlay Service 等报告执行服务的节点被添加到显式定义的 Server Groups,而其他节点仍然位于默认 Server Group 中。

参考资料

学习

获得产品和技术

讨论

  • 参与 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=677120
ArticleTitle=IBM Cognos 最佳实践: IBM Cognos 8 BI 调度程序路由详解
publish-date=07222011