使用策略监视 JobFramework 开发自定义 KPI

本文探讨了 JobFramework 的基本结构以及它在定义自定义 KPI 上的应用,并使用 Latency KPI 作为一个示例。Latency KPI 计算了将来自数据源的数据更改传播到操作服务器所需的时间,这是数据一致性和可信性的一个重要特征。本文还将介绍如何使用 IBM® Cognos® Business Intelligence Server 操纵新的 Latency KPI 报告。

Somak Bhattacharya, 软件开发人员, IBM

Somak Bhattacharya 是 IBM 的 InfoSphere Master Data Management (MDM) 产品组合的开发人员,曾帮助构建 MDM SE 中的主数据策略监视功能。



Srinivasa Parkala, 资深软件开发人员, IBM

Srinivasa Parkala 是 IBM 的 InfoSphere Master Data Management (MDM) 产品组合的资深开发人员,曾帮助设计和开发 MDM SE 中的主数据策略监视功能。



Puneet Sharma, 资深产品架构师, IBM

Puneet Sharma 是 IBM 的 InfoSphere Master Data Management (MDM) 产品组合的资深产品架构师,在过去几年设计了 MDM 产品组合的许多重要功能。他目前致力于为 MDM 产品组合构建下一代主数据治理功能。



2014 年 2 月 24 日

简介

主数据策略监视是 InfoSphere® MDM 的一个组件,它使组织能够报告数据质量和适用性,建立符合数据质量阈值的策略。策略监视的一个重要组件是 JobFramework,它被开发为独立的 Java 代码。JobFramework 提供了一个基础架构,以便在多线程环境中运行 Java 任务。策略监视包含许多现成的度量指标和报告。策略监视使您能够使用 JobFramework 定义关键绩效指标 (KPI),对 InfoSphere MDM 操作服务器运行 KPI 计算。JobFramework 有助于您将精力集中在 KPI 定义上,依靠 JobFramework 来处理与多线程和性能相关的技术。

策略监视包含一组内置的 KPI。但是,您的组织对数据治理 KPI 的需求可能与策略监视中包含的 KPI 不同。理解 JobFramework 可帮助您实现自己的 KPI。通过进一步理解 IBM Cognos 报告,您就能够使用实用的图形对象(比如曲线图和图表)来设计和表示计算的 KPI 数据,从而帮助理解。

使用 JobFramework,您可以简化多线程应用程序的设计和开发。JobFramework 控制一个任务的运行、线程生命周期和运行线程的策略。JobFramework 是利用 Java 自己的线程池实现 ExecutorService 接口来开发的。Latency KPI 识别一次数据更改从来源系统传播到 InfoSphere MDM 操作服务器所需的滞后时间。组织可识别延迟最高的数据源。将延迟降低到来源的可接受水平,帮助您从 InfoSphere MDM 操作服务器获得更实时的信息。本文介绍了如何使用 JobFramework 实现 Latency KPI,以及如何使用 IBM Cognos 报告发布计算的结果。

先决条件

您必须基本理解以下组件并拥有一定的动手经验:

  • InfoSphere MDM version 11.0, Advanced Edition 和主数据策略监视功能
  • IBM Cognos Business Intelligence Server 10.1.1
  • DB2® for Linux®, Unix®, and Windows® 10.1.0

策略监视 JobFramework 概述

JobFramework 提供了在多线程环境中运行 Java 任务的基础架构。JobFramework 处理多线程和性能的细节,让您能够将精力集中在核心 KPI 实现逻辑上。通常使用 JobFramework 实现自定义 KPI。JobFramework 概述分为以下小节:

  • JobFramework 使用的术语
  • JobFramework 的基本组件
  • 使用策略监视 JobFramework 实现自定义 KPI

JobFramework 使用的术语

任务:任务是一个工作单元,它在某一点开始,需要执行某种活动或计算,然后终止。

线程:线程是任务的运行实例。

线程池:线程池表示一个等待分配任务的线程集合。线程的生命周期管理(比如创建和拆卸线程)由 JobFramework 自动管理。线程数量和线程池名称也是外部化的、可配置的参数。

有界队列 (Bounded Queue):JobFramework 在逻辑上将任务的提交和运行分开。您可以提交一个要运行的任务,但 JobFramework 会从线程池寻找可用的线程来运行该任务。有界队列充当着新提交的任务的容器。除非该任务已添加到队列中,否则 JobFramework 不会运行它。有界队列的大小是一个可配置的参数。

错误处理程序:在 JobFramework 运行任务失败时,会得到适当的处理和记录。

JobFramework 的基本组件

JobFramework 的组件可大体分类为以下部分:

  • JobFramework 接口
  • JobFramework 配置模块

JobFramework 接口

JobFramework 提供了一组接口,您可以使用它们来实现任务。

ITask 接口

ITask 接口可用于在一个单独线程中运行代码。您需要实现该接口并提供 executeTask 方法的定义。方法签名如下所示:

public void executeTask(TaskContext context);

IChainTask 接口

IChainTask 接口用于运行序列中的任务。序列中的每个任务在一个独立的线程中运行。例如,任务 A 调用任务 B,任务 B 调用任务 C,等等。IChainTask 接口扩展了 ITask 接口。使用此接口时,您必须实现 executeTask 方法和 createAndScheduleNextTasks 方法。方法签名如下所示:

public void executeTask(TaskContext context);

public void createAndScheduleNextTasks(TaskContext taskContext);

IMultiOccuranceChainTask 接口

IMultiOccuranceChainTask 接口使您能够运行一些任务,其中一些任务是并发性的,剩余任务是顺序性的。IMultiOccuranceChainTask 接口扩展 IChainTask 接口。使用此接口时,必须实现 executeTask 方法、createAndScheduleNextTasks 方法和 isExecutionOverForAllInstances 方法。方法签名如下所示:

public void executeTask(TaskContext context);

public void createAndScheduleNextTasks(TaskContext taskContext);

public boolean isExecutionOverForAllInstances(TaskContext taskContext);

例如,有 10 个整数数组,其中每个数组包含 5 个整数。您希望获取每个数组中的整数数量,然后乘以这些值。例如,任务 A 获取每个整数数组中的数量,任务 B 乘以聚合的值。

要实现上述情景,JobFramework 需要并行运行任务 A 的 10 个实例。完成这些实例后,JobFramework 运行任务 B 的一个实例来获取最终结果。IMultiOccuranceChainTask 接口适合前面提到的场景。它还实现了 isExecutionOverForAllInstances 方法来验证任务 A 的所有实例是否都已在调用任务 B 之前运行。

JobFramework 配置模块

JobFramework 配置模块包含 JobframeworkConfig.xml 文件,它用于控制与运行任务相关的各种参数。使用这个 XML 文件,您可以创建多个线程池,指定每个线程池中的线程数量,以及有界队列的大小。

ThreadPools 用于将线程分组到一个池中。

MaxThreads 表示线程池中允许的最大线程数量。

MaxQueueSize 表示提交给线程池执行程序的最大任务数量。如果提交的任务数量超过了 MaxQueueSize,那么任务就会被拦截,直到有线程可供运行。

使用策略监视 JobFramework 实现自定义 KPI

我们看看下面这个示例,在该示例中,您希望创建一个新 KPI。任务 A 从数据库读取一些记录。任务 A 读取的每条记录由任务 B 的一个实例处理,以执行 KPI 计算。因此,任务 B 的多个实例可并行运行。

实现 JobFramework 接口

由于任务 A 在一个单独的线程中运行并调用任务 B,所以任务 A 实现了 IChainTask 接口。IChainTask 接口的 executeTask 方法实现了连接到数据库并读取所有记录的代码。IChainTask 接口的 createAndScheduleNextTasks 方法为从数据库读取的每条记录调用了任务 B 的一个实例。

任务 B 的每个实例在一个新线程中运行并实现了 ITask 接口。KPI 实现逻辑存在于任务 B 的 executeTask 方法中。假设任务 A 和任务 B 已实现为 Java 类,分别名为 Task_A.class 和 Task_B.class。

您不用创建任何任务的实例,JobFramework 提供了工厂来创建和运行这些任务,如清单 1 中所示:

清单 1. 任务 A 的 createAndScheduleNextTasks 方法的实现
public void createAndScheduleNextTasks(TaskContext taskContext) {
                
//Create the factory instance of ExecutionManager, which is used to run the task
                
ExecutionManager executionManager = ExecutionManager.getInstance();
                
//Submit Task B for run
                
executionManager.createAndExecuteTask(Task_B.class.getName(),taskContext);
                
}

更新 JobframeworkConfig.xml 文件

JobframeworkConfig.xml 文件可帮助您定义与 JobFramework 相关的参数。清单 2 中的代码显示了前面提及的自定义 KPI 实现所需的更改:

清单 2. 针对自定义 KPI 的 JobframeworkConfig.xml 配置
<threadPool name="four">
                
  <maxThreads>10</maxThreads>
                
  <maxQueueSize>100</maxQueueSize>

  <tasks>
                
    <task className="Task_A" isStartTask="true"/>
                
    <task className="Task_B"/>
                
  </tasks>
                
  </threadPool>

基于 清单 2 中的定义,总共使用了 10 个线程来运行任务 A 和任务 B。任务 A 使用了一个线程,剩余 9 个线程由任务 B 使用。isStartTask=”true” 属性可识别 JobFramework 用于发起运行的任务类。


Latency KPI 概述

在某个时间点(比如 2013 年 5 月 1 日)更新了来源系统上的一条成员记录。由于各种原因(比如操作服务器中的异步更新),该更新在未来某个时间点(比如 2013 年 5 月 2 日)才反映到 InfoSphere MDM 操作服务器中。在这些情况下,具体的成员记录的延迟为:

InfoSphere MDM 操作服务器上发生的成员记录更新 - 来源系统上发生的实际更新。

操作系统上的更新日期 - 来源系统上的更新日期 = 1 天。

对于加载到服务器中的每个成员记录,InfoSphere MDM 操作服务器数据库中都包含一行数据。mpi_memhead 表中每条记录的 “MAUDRECNO” 列对应于 mpi_audhead 表中的一条审计记录。InfoSphere MDM 操作服务器数据库中的 mpi_audhead 表包含对发生的每次交互(比如 memget、memput)的审计记录。

mpi_memhead 和 mpi_audhead 表的数据模型描述可在 虚拟 MDM 数据模型描述 中找到。

对于批量加载(假设加载 10,000 条成员记录),memput 操作会在内部被调用 10,000 次。

但是,基于您的选择,可能出现以下场景:

场景 1:mpi_audhead 表包含一条审计记录,它与加载到 mpi_memhead 表的所有 10,000 成员记录都有交叉链接。

场景 2:mpi_audhead 表包含加载到 mpi_memhead 表的所有 10,000 条成员记录的各个审计记录。

要实现 Latency KPI,必须使用场景 2。在将数据加载到操作服务器中时,来源系统必须提供实际的记录修改日期。mpi_audhead 表中的 EVTCTIME 和 AUDCTIME 列分别用于持久保存来源和操作服务器上的记录更新日期。

我们于 2013 年 8 月 23 日将 2 条成员记录加载到操作服务器数据库中的 mpi_memhead 表中,具有表 1 中所示的细节:

表 1. 加载到操作服务器数据库中的成员记录
来源 ID来源名称来源记录编号成员 ID来源上的记录修改日期
INSInsurance218100-00000000012013-08-12
CLClinic214100-00000000022013-8-8

相应的 mpi_memhead 和 mpi_audhead 表条目如表 2 和表 3 中所示:

表 2. 包含已加载的成员记录的 mpi_memhead 表
MEMRECNOMEMSEQNOCAUDRECNOMAUDRECNOMEMSTATMEMVERNOSRCRECNOMEMIDNUM
11122A0218100-0000000001
21133A0214100-0000000002
表 3. 包含已加载的成员审计记录的 mpi_audhead 表
AUDRECNOAUDSEQNOUSRRECNOIXNRECNOAUDCTIMEEVTCTIMEEVTTYPENOEVTINITIATOREVTLOCATION
20171Aug 23, 2013 11:56:14 AM 000000Aug 12, 2013 0:00:00 AM 0000000
30171Aug 23, 2013 11:56:14 AM 000000Aug 8, 2013 0:00:00 AM 0000000

对于成员记录 100-0000000001,延迟为 AUDCTIME (2013-08-23 11:56:14.0) - EVTCTIME (2013-08-12 12:00:00.0) = 11 天。

像策略监视框架中其他现有的 KPI 一样,Latency KPI 计算也分 3 个执行阶段:着陆、暂存和集市。

在着陆区表中,持久保存了各个成员记录和它们的延迟。着陆区中存储的成员记录数量很多。因此,我们需要在此数据上执行进一步的聚合来获取综合结果。

在暂存区表中,使用以下公式计算了经过舍入的延迟值:

ROUND (LATENCY/<ROUND_UP_DIGIT>,0)* <ROUND_UP_DIGIT> 其中 ROUND_UP_DIGIT 是一个用户可配置的参数。

假设我们在着陆区表中具有以下成员记录(如表 4 中所示),ROUND_UP_DIGIT 的值为 3:

表 4. 着陆表中的成员记录
成员记录编号延迟天数
18
26
311
412
517

应用此公式有助于获取每条成员记录的以下经过舍入的延迟值,如表 5 所示:

表 5. 舍入的延迟值 ROUND_UP_DIGIT=3 的成员记录
成员记录编号经过舍入的延迟天数
16
26
39
412
515

在暂存区表中,计算了具有相同的舍入延迟值的成员记录数量,如表 6 中所示。这有助于将大量成员记录分类为相对较少数量的舍入延迟分组。

表 6. ROUND_UP_DIGIT=3 的暂存区表
经过舍入的延迟天数成员记录数量ROUND_UP_DIGIT
623
913
1213
1513

如果 ROUND_UP_DIGIT 值从 3 更改为 9,那么暂存区表中的总行数也会从 4(如表 6 中所示)更改为 2(如表 8 中所示):

表 7. 舍入的延迟值 ROUND_UP_DIGIT=9 的成员记录
经过舍入的延迟天数成员记录数量
10
20
39
49
59
表 8. ROUND_UP_DIGIT=9 的暂存区表
经过舍入的延迟天数成员记录数量ROUND_UP_DIGIT
029
939

在集市区表中,我们持久保存每次策略监视运行的最长和最短的舍入延迟。在内部,我们将 Latency KPI 细分为两个子 KPI,以方便报告:

  • Maximum Rounded Latency 表示所有来源中的最大舍入延迟值(以天数为单位)。
  • Minimum Rounded Latency 表示所有来源中的最小舍入延迟值(以天数为单位)。

使用策略监视 JobFramework 实现 Latency KPI

要实现 Latency KPI,可执行本节中的步骤。

将数据加载到 InfoSphere MDM 操作服务器中

在加载成员记录期间,来源系统应提供了每条成员记录的最新修改日期。日期显示在 mpi_memhead 表中的 EVTCTIME 列中。您还需要确保在 mpi_audhead 表中为加载到操作服务器数据库的 mpi_memhead 表中的每条成员记录创建了各个审计记录。

运行 Latency KPI

在运行 Latency KPI 之前,您应设置一个现有的策略监视功能,并能够访问基于 Eclipse 的 Java 编辑器。运行 Latency KPI 包含以下步骤:

  1. 从附加的 LatencyKPIartifacts.zip 文件中的 javaProject 目录下获取 Java 项目 LatencyKPI。在一个 Eclipse 编辑器中打开该项目。该项目包含以下 3 个 Java 类:LatencyKPITask.java、LatencyProperties.java 和包 com.ibm.mdm.mdpm.latency 下的 ReadMemRecds.java。LatencyProperties.java 类包含所有属性,比如 InfoSphere MDM 操作服务器数据库属性、InfoSphere MDM 操作服务器连接属性,以及策略监视数据库属性。

    您应基于自己的环境来编辑这些属性。对于策略监视数据库,可使用现有的策略监视数据库,无需创建新数据库。Latency KPI 对现有的策略监视表存有一些依赖关系。

  2. 将 db2jcc.jar、madapi.jar 和 com.ibm.mdm.mdph.job.jar 文件添加到 Java 项目 LatencyKPI 的类路径。这些 JAR 文件可在 <policy monitoring INSTALL_PATH>\com.ibm.mdm.mdph\lib 目录下找到。

    <policy monitoring INSTALL_PATH> 是您安装主数据策略监视功能的位置。

  3. 构建该 Java 项目并从 LatencyKPI 项目创建一个 Java 归档文件 (JAR)。假设该 JAR 文件的名称为 latencykpi.jar。

  4. 将 latencykpi.jar 文件复制到 <policy monitoring INSTALL_PATH>\com.ibm.mdm.mdph\lib 文件夹中。

  5. 打开 JobframeworkConfig.xml 文件(它位于 <policy monitoring INSTALL_PATH>\com.ibm.mdm.mdph\config 目录中),并将清单 3 中的代码添加到该文件的 XML 元素 <threadPools> 内:

    清单 3. 针对 Latency KPI 执行的 JobframeworkConfig.xml 修改
    <threadPool name="latencyKPI">
                            
    <!--The maxThreads configuration specifies number of threads (for a thread pool)
    which will pick the tasks from the queue for parallel processing -->
                            
    <maxThreads>10</maxThreads>
                            
    <!-- The maxQueueSize configuration specifies the number of 
    tasks which can be added to a queue which is defined for a 
    thread pool. A task is first added to the queue for 
    processing, if the queue is full then the system waits
    till the queue become available. -->
                            
    <maxQueueSize>100</maxQueueSize>
                            
    <tasks>
                            
    <!-- The "task" configuration element provide details                      
    about the task which needs to be executed.-->
                            
    <!-- The "isStartTask" attribute specifies                        
    if a task is the first task in the chain of tasks. 
                            
    If "isStartTask" is specified as "true" then                        
    the JobFramework itself will create the task instance                         
    and will schedule it for execution. 
                            
    "isStartTask" attribute can have values as "true" or "false". -->
                            
    <task className="com.ibm.mdm.mdpm.latency.ReadMemRecds" isStartTask="true" />
                            
    <task className="com.ibm.mdm.mdpm.latency.LatencyKPITask" />
                            
    </tasks>
                            
    </threadPool>

    这可以确保 JobFramework 在策略监视运行期间一起运行 Latency KPI 和现有的 KPI。com.ibm.mdm.mdpm.latency.ReadMemRecds.java 类是 threadPool latencyKPI 的起始类,它从操作服务器数据库读取成员记录和审计细节。该类将会计算每条成员记录的延迟,并将计算结果持久存储在着陆区表中。

    然后,com.ibm.mdm.mdpm.latency.LatencyKPITask.java 类将数据聚合在一起,并将它们持久保存在暂存和集市区表中。

  6. 打开 execute_mdph.xml 文件(位于 <policy monitoring INSTALL_PATH>\com.ibm.mdm.mdph\scripts 目录下),并将 <include name="latencykpi.jar"/> 添加到目标名称 “executeMdph” 下,如清单 4 中所示。这可以确保所需的 Latency KPI 类在策略监视运行时可用。

    清单 4. 将 latencykpi.jar 包含在 execute_mdph.xml 文件中
    <target name="executeMdph" description="execute mdph" 
      depends="loadMdphProperties,print,replacelogpathWindows,replacelogpathUnix">
                            
    <java classname="com.ibm.mdm.mdpm.job.execute.JobExecutionUtil" 
      fork="true" spawn="false" failonerror="true" >
                            
      <classpath>
      <pathelement location="${log4j.jarpath}" />
      <pathelement path="${db.jdbcjars}"/>
      <fileset dir="${basedir}/lib">
        <include name="com.ibm.mdm.mdph.common.jar"/>
        <include name="com.ibm.mdm.mdph.deployment.jar"/>
        <include name="madapi.jar"/>
        <include name="com.ibm.ws.admin.client_8.0.0.jar" />
        <include name="com.ibm.mdm.mdph.job.jar"/>
        <include name="com.ibm.mdm.mds.roc.jar"/>
        <include name="com.ibm.mdm.mdph.db.conpool.jar"/>
        <include name="commons-logging.jar"/>
        <include name="commons-math.jar"/>
        <include name="com.ibm.mdm.mds.common.jar"/>
        <include name="xercesImpl.jar"/>
        <include name="latencykpi.jar"/>
      </fileset>
    </classpath>
    <arg value="-MPDH_ROOT"/>
    <arg value="${basedir}"/>
    <arg value="-RUNTIME_XML"/>
    <arg value="${runtime.xml}"/>
    <jvmarg value="-Xms${sheapsizemegabytes}m"/>
    <jvmarg value="-Xmx${xheapsizemegabytes}m"/>
    <sysproperty key="java.library.path" path="${basedir}/lib"/>
    </java>
    <echo message="Mdph execution completed"/>
    </target>
  7. 找到 createTableLatency.sql 文件,它位于 LatencyKPIartifacts.zip 文件中的 dbScript 目录下。替换占位符值后,对现有的策略监视数据库运行该文件来创建额外的 Latency KPI 相关表。

  8. 运行策略监视。

  9. 成功完成策略监视运行后,可通过 IBM Cognos 报告查看记录的 Latency KPI 数据。

  10. 在 IBM Cognos 环境中,为策略监视数据库创建一个名为 dsn_latency_kpi 的数据源。

  11. 在 IBM Cognos 环境中,导入 LatencyKPIReports.zip 文件,它位于 LatencyKPIartifacts.zip 文件中的 cognosReport 目录下。

成功运行这些步骤后,将会计算 Latency KPI。


了解 Latency KPI 的策略监视报告

可打开 Latency-KPI-Report-Summary 报告,开始与 Latency KPI Cognos 报告交互。这个摘要报告显示了所有来源上的最新运行的最大和最小舍入延迟值,如图 1 所示:

图 1. Latency-KPI-Report-Summary Cognos 报告
Latency-KPI-Report-Summary Cognos 报告显示了最新的策略监视运行的最大和最小舍入延迟

下钻到 “Rounded latency in Days” 列的值,打开 Latency-KPI-Report-Level-1。Latency-KPI-Report-Level-1 显示了不同策略监视运行的最大和最小舍入延迟的趋势,如图 2 所示:

图 2. 不同运行的最大和最小舍入延迟的趋势
该图显示了不同运行的最大和最小舍入延迟的趋势

Latency-KPI-Report-Level-1 报告还显示了舍入的延迟值的成员记录数量分布。它还显示了所有来源上具有相同的舍入延迟值的成员记录数量,如图 3 所示:

图 3. 舍入的延迟值和记录计数的详细信息
该图显示了每个舍入的延迟值及其分布的记录计数

您可以下钻到任何舍入的延迟值上,以查看 Latency-KPI-Report-Level-2 中的相关成员记录的详细信息,如图 4 所示:

图 4. 与特定的舍入延迟值相关的成员记录详细信息
该图显示了一个特定的舍入延迟值的成员记录详细信息

将 Latency KPI Cognos 报告与现有的策略监视报告合并

本节介绍如何将 Latency KPI Cognos 报告与现有的策略监视 IBM Cognos 报告合并:

  1. 打开现有的 IBM Cognos 框架管理器项目 MDPMCognos.zip,并使用 “Metadata Wizard” 导入以下表:

    • LND_LATENCY_KPI
    • STG_LATENCY_KPI
    • MRT_LATENCY_KPI

    在导入期间,使用以下选项,让现有的表关系与表一起导入,如图 5 所示:

    图 5. 使用 IBM Cognos 框架管理器导入表
    该图显示了 IBM Cognos 框架管理器内在导入表期间可选择的选项

    您还需要在框架表达式项目内对新创建的数据源使用宏表达式 #prompt('Schema Name:','token')#,以更新属性 Schema 的值,如图 6 所示:

    图 6. 使用宏表达式更新属性 Schema 的值
    该图显示了要用于 Schema 属性值的 prompt 表达式
  2. 保存项目并发布更新的 IBM Cognos 框架管理器项目。

  3. 更新 Report-Summary 页面,在现有的 IBM Cognos List 对象底部添加一个额外的 IBM Cognos List 对象。List 对象包含计算的 Maximum Rounded Latency 和 Minimum Rounded Latency KPI 的值。您还需要创建 Rounded latency in Days 列上的下钻定义。同样可以使用 Latency-KPI-Report-Summary 报告作为参考。

  4. 将 Latency-KPI-Report-Level-1 和 Latency-KPI-Report-Level-2 报告复制到现有的策略监视 Cognos 报告的内容存储中。

  5. 现有的策略监视 Cognos 报告将数据源名称命名为 dsn_mdpm。策略监视 Cognos 报告的包名称也与 Latency KPI Cognos 报告的包名称不同。合并之后,必须手动打开和修复 Latency KPI Cognos 报告的所有与数据源和包相关的问题,然后才能运行策略监视。


结束语

本文介绍了如何利用策略监视 JobFramework 的功能来构建自定义 KPI。文中还展示了如何使用现有的 IBM Cognos 环境为自定义 KPI 构建新报告。


下载

描述名字大小
用于计算 Latency KPI 的样例工件dm-1310LatencyKPIartifacts.zip26KB

参考资料

条评论

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=963881
ArticleTitle=使用策略监视 JobFramework 开发自定义 KPI
publish-date=02242014