您的问题管理数据模板

BMC Helix ITSM

← 返回改进指南

问题管理属性 (19) 问题管理活动 (13) 提取指南 (3)

您的问题管理数据模板

此模板为分析BMC Helix ITSM中的根因调查工作流提供了完整结构，涵盖构建详细事件日志所需的属性和流程活动，并提供实用的数据提取指南。按照本指南操作，您可以识别隐藏瓶颈，缩短问题从发现到永久解决的路径。

根因分析所需的关键数据字段
用于跟踪的标准化流程里程碑
针对BMC Helix ITSM的具体提取指南

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

问题管理属性

此表包含填充事件日志所需的推荐数据字段，用于全面分析问题管理生命周期。

5 必需 9 建议 5 可选

	名称	说明
	事件时间 EventTime	具体活动发生时的时间戳。
说明此属性记录活动发生的准确日期和时间。在BMC Helix ITSM中，对应“Submit Date”“Last Modified Date”等字段，或状态变更历史表中记录的具体时间戳。在分析中，此属性用于按时间顺序排列事件并计算时长。它支持衡量流程中任意两个节点之间的周期时间，例如“Investigation Cycle Time”或“Workaround Publication Lead Time”。精确的时间戳对于识别瓶颈至关重要。通过计算相邻事件之间的时间差，分析人员可以准确定位延迟发生的位置，无论是在初始分配阶段还是最终评审阶段。为什么重要它支持计算所有基于时长的KPI，并确定事件顺序。获取位置与PBM:Problem Investigation关联的历史表或审计日志示例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
	活动 Activity	已发生的具体任务或状态变更事件。
说明此属性表示问题管理生命周期中执行的具体步骤，例如“Problem Record Logged”“Root Cause Identified”或“Solution Database Updated”。在BMC Helix中，这些活动通常源自Status History、Audit Logs或Problem Investigation模块中的具体交易时间戳。此属性是流程发现的核心。通过分析这些活动的顺序，流程挖掘工具可以构建流程图，揭示实际工作流与设计流程之间的差异，并突出显示循环、返工以及偏离标准操作流程的情况。准确的活动名称对于了解生命周期中实际发生的情况至关重要。这些数据支持衡量具体步骤之间的转换时间，例如确定根因到发起变更请求所需的时间。为什么重要它定义流程图中的节点，并支持工作流可视化。获取位置源自PBM:Problem Investigation状态历史记录或PBM:AuditLogSystem 示例问题记录已记录已分配至支持组调查已开始已确定根因
	问题记录 ProblemRecord	问题调查案例的唯一标识符。
说明此属性是问题管理流程的核心案例标识符。在BMC Helix ITSM中，通常对应PBM:Problem Investigation表单中的“Problem ID”字段，例如PBI00000012345。它关联从问题初始记录、最终关闭到实施后评审的所有相关活动。在流程挖掘分析中，此属性用于将单个事件归入同一流程实例，帮助分析人员可视化特定问题调查的端到端历程。没有这一标识符，就无法关联不同支持组和协调人执行的操作序列。此字段是事件日志的主键，对于所有案例级聚合都不可或缺，例如计算每个问题的总周期时间，或统计各优先级的问题数量。为什么重要这是构建流程视图并跟踪特定问题生命周期所需的基础键。获取位置 PBM:Problem Investigation表单中的“Problem ID”字段示例 PBI00000004512PBI00000004513PBI00000004514
	数据最后更新时间 LastDataUpdate	数据提取或最后刷新的时间戳。
说明此属性表示数据最后一次加载到流程挖掘应用的时间，确保分析人员了解当前所查看数据的时效性。通常由提取脚本或数据管道工具生成。在分析中，它有助于避免基于过时数据做出决策。例如，管理人员查看“Open Problem Records”时，数据是一小时前更新的，还是一周前更新的，会显著影响对当前工作负载的判断。它还用于增量数据加载。通过跟踪最后更新时间，ETL流程只需获取自上次提取以来发生变化的记录，从而优化性能并降低系统负载。为什么重要它确保数据保持最新，并支持增量数据加载策略。获取位置提取时的系统时间示例 2023-11-01T00:00:00Z2023-11-01T12:00:00Z
	源系统 SourceSystem	数据来源所在的系统。
说明此属性标识流程数据提取自哪个软件系统，本例中为“BMC Helix ITSM”。在多系统环境中尤其重要，因为流程挖掘可能会汇总来自不同ITSM、开发或外部供应商工具的数据。在分析中，此字段作为元数据标签，用于验证记录来源。如果流程挖掘视图同时整合BMC Helix的问题管理数据和软件开发系统（例如Jira）的数据，此属性可帮助按来源工具拆分分析。它也有助于技术排障。出现数据质量问题时，了解源系统可以帮助数据工程师将问题追溯到具体的提取程序或源数据库。为什么重要它提供可追溯性和上下文信息，在多系统流程视图中尤其有用。获取位置在提取过程中硬编码示例 BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
	SLA到期日期 SLADueDate	必须解决问题的目标日期和时间。
说明此属性保存根据服务级别协议确定的问题解决期限。在BMC Helix中，通常对应“Target Resolution Date”或计算得出的SLA里程碑时间戳。此属性是“SLA Compliance and Breach Trends”仪表板的基准。通过将此时间戳与“Resolution Verified”活动时间戳进行比较，系统可以计算SLA是否达标或违约。将该日期可视化后，分析人员可以了解团队解决问题时距离期限还有多大余量。他们是在到期前几天解决，还是总在违约前几分钟完成？这些洞察可以指导容量规划。为什么重要它是计算所有合规性和及时性指标的参考点。获取位置 PBM:Problem Investigation表单中的“Target Resolution Date”字段示例 2023-12-01T17:00:00Z2023-12-02T09:00:00Z
	优先级 Priority	根据影响和紧急程度计算得出的问题优先级。
说明此属性表示问题记录的优先级，例如Critical、High、Medium、Low。在BMC Helix中，通常根据Impact和Urgency的选择计算得出。在分析中，它用于“Throughput and Priority Volume”仪表板，帮助组织确认资源是否与业务需求正确匹配。例如，与Low优先级问题相比，Critical问题理论上应具有更快的初始分配时间和更短的整体周期时间。按优先级筛选有助于聚焦改进工作。Low优先级流程中的瓶颈可能可以接受，但同样的延迟出现在Critical流程中，则会对业务连续性和SLA合规造成重大风险。为什么重要它按业务关键程度细分分析，并支持SLA分析。获取位置 PBM:Problem Investigation表单中的“Priority”字段示例严重高中低
	关联事件数量 RelatedIncidentCount	与此问题记录关联的事件数量。
说明此属性通过统计关联事件的数量来量化问题影响。在BMC Helix中，通常是HPD:Help Desk表单中与PBM记录关联的记录数量。此属性驱动“Incident Linkage Density”KPI。数量较高表示问题影响较大，并为服务台带来大量干扰。将其与“Priority”关联，可以确认高数量问题是否确实按关键问题处理。它还有助于确定待办事项的优先级。一个关联了500个事件的问题记录，通常应优先于仅关联1个事件的Critical问题，因为解决前者可以释放更多服务台容量。为什么重要它量化问题带来的运营影响和用户困扰。获取位置通过统计HPD:Associations或HPD:Help Desk中的关联行数计算示例 15120
	支持组 SupportGroup	当前负责问题调查的技术团队。
说明此属性反映事件发生时负责问题记录的具体支持组，例如“Server Admin”“Database Support”。在BMC Helix中，对应“Assigned Group”字段。此属性对于“Support Group Workload Distribution”和“Support Group Reassignment Analysis”仪表板至关重要。分析人员可以按团队切分流程图，了解哪些团队处理的数量最多，以及哪些团队成为调查流程中的瓶颈。分析支持组之间的交接，有助于识别“反复转派”行为，即工单在团队之间来回流转却始终未得到解决。这通常表明组织内部职责不清或知识管理不足。为什么重要它支持团队层面的组织分析和瓶颈检测。获取位置 PBM:Problem Investigation表单中的“Assigned Group”字段示例一级服务台后台支持网络管理
	是否违反SLA IsSLABreached	用于标识问题解决是否超过允许时限。
说明此布尔属性表示问题记录是否违反服务级别协议。系统会将“Resolution Verified”时间戳与“SLA Due Date”进行比较，或直接从SLM状态中提取该值。此属性是“SLA Compliance and Breach Trends”仪表板的关键指标，可将流程简单划分为合规与不合规两类，便于识别失败流程的特征，例如“违反SLA的案例是否总是涉及Support Group X？” 它也是分析流程失败根因的主要筛选条件。分析人员可以筛选“IsSLABreached = True”，再查看流程图，了解时间损失发生在哪个环节，例如等待供应商批准的时间过长。为什么重要简化合规报告和失败分析。获取位置 SLM:Measurement表单或计算得出示例 truefalse
	服务配置项 ServiceCI	受影响的主要业务服务或配置项。
说明此属性标识与问题相关的Service Configuration Item（CI），例如“Email Service”“SAP ERP”或“Wi-Fi Network”。在BMC Helix中，通常对应“Service+”字段或主要CI关联关系。在分析中，它支持按产品或服务细分问题记录，帮助IT管理层了解哪些服务最脆弱、产生的问题调查最多。通过增加产品维度，它还可以为“Throughput and Priority Volume”仪表板提供支持。将此属性与“Investigation Cycle Time”关联，可以判断某些复杂服务（如核心银行系统）是否天然需要比通用服务（如打印）更长的调查时间。为什么重要它将流程性能与具体业务产品或服务关联起来。获取位置 PBM:Problem Investigation表单中的“ServiceCI”或“CI Name”字段示例电子邮件服务工资系统企业VPN
	根因类别 RootCauseCategory	对问题根本原因的分类。
说明此属性包含确定根因时选择的类别，例如“Software Error”“Hardware Failure”“Process Gap”。在BMC Helix中，通常从“Root Cause”或“Generic Categorization”菜单中选择。此属性对于“Fix Effectiveness and Quality”视图至关重要。它支持组织将特定根因类型与返工率或较长调查时间关联起来。例如，分析可能显示，“Software Error”问题的解决时间始终是“Hardware Failure”问题的两倍。它还用于计算“Root Cause Categorization Rate”。如果此字段中“Unknown”或“Other”的占比较高，说明需要加强技术培训，或提供更细致的分类选项。为什么重要它支持系统性问题的趋势分析和主动式问题管理。获取位置 PBM:Problem Investigation表单中的“Root Cause”或分类选项卡字段示例软件模块网络基础设施人为错误
	调查驱动因素 InvestigationDriver	发起问题调查的原因。
说明此属性对问题记录的触发原因进行分类，例如“Incident Volume”“Major Incident”“Vendor Notification”或“Proactive Trend Analysis”。在BMC Helix中，对应“Investigation Driver”字段。此属性支持“Proactive Identification Trends”仪表板，帮助组织衡量工作模式从被动救火（响应事件）转向主动式问题管理（在风险显现前识别风险）的变化。按“Investigation Driver”分析流程，可以发现不同的行为模式。例如，“Proactive”问题可能因不会立即造成中断而在队列中停留更久，而由“Major Incident”触发的问题则会被加速处理。为什么重要它区分被动式和主动式工作，是衡量成熟度的关键指标。获取位置 PBM:Problem Investigation表单中的“Investigation Driver”字段示例被动响应主动预防重复事件
	问题协调员 ProblemCoordinator	负责协调调查的个人用户。
说明此属性标识问题记录的具体负责人。在BMC Helix ITSM中，对应“Problem Coordinator”字段。即使任务委派给其他人员，该人员仍负责问题的整个生命周期。此属性支持“Support Group Workload Distribution”仪表板，帮助管理人员识别是否有特定人员承担过多调查任务，而其他人员仍有余量。它还支持个人层面的绩效分析，用于识别培训需求或高绩效人员。在流程挖掘中，此字段作为资源属性，帮助可视化工作在个人之间的流转，并突出显示单点故障，即流程过度依赖某一位专家。为什么重要它支持个人层面的资源分析和工作负载平衡。获取位置 PBM:Problem Investigation表单中的“Problem Coordinator”字段示例 John DoeJane Smith系统管理员
	临时解决方案状态 WorkaroundStatus	表示是否已识别并发布有效的临时解决方案。
说明此属性用于跟踪临时解决方案（Workaround）的状态。它可以是简单的布尔值（Has Workaround），也可以是状态字符串。在BMC Helix中，通常根据“Workaround”字段中是否存在文本或特定状态标志推导得出。此属性是“Workaround Publication Performance”仪表板的关键指标。它用于评估团队在调查根本原因期间缓解影响的效果。按“No Workaround”筛选流程视图，可以突出显示调查期间业务仍承受全部影响的案例。它还支持质量审计。在没有永久修复方案（Change Request）且没有临时解决方案的情况下关闭问题记录，通常意味着流程存在缺陷，需要进行复核。为什么重要用于衡量调查期间缓解影响的效果。获取位置 PBM:Problem Investigation表单，“Workaround”字段内容检查示例活动无已退役
	关联变更请求ID RelatedChangeRequestId	为解决问题而发起的变更请求标识符。
说明此属性包含与问题记录关联的Change Request ID，例如CRQ0000...，代表流程从调查转向永久修复实施。此属性是“Root Cause to Change Lead Time”KPI所必需的。它支持流程挖掘工具衡量确定根因到启动变更流程之间的延迟，这是一个经常出现工作动能丢失的交接点。它还有助于验证流程完整性。问题记录以“Completed”状态关闭，却没有关联的变更请求或临时解决方案，可能表明流程违规，即根因已找到但实际未完成修复。为什么重要它将问题管理流程与变更管理流程关联起来。获取位置 PBM:Investigation Associations或Relationship选项卡示例 CRQ00000021345CRQ00000021346
	区域 Region	与问题关联的地理区域。
说明此属性指定问题产生或管理所在的地理位置，例如“North America”“EMEA”。在BMC Helix中，通常位于与请求人或受影响资产关联的“Region”或“Site”字段中。在分析中，它支持按地理区域细分，帮助识别某些区域是否面临更高的问题量或更慢的解决速度，也可以揭示不同地点在支持人员配置或基础设施质量方面的差异。对于全球化组织而言，它有助于确保服务交付的一致性。如果“APAC”的“Investigation Cycle Time”是“NAM”的两倍，就需要进一步调查该区域的资源分配或流程遵循情况。为什么重要它支持按地理区域比较流程性能。获取位置 PBM:Problem Investigation表单中的“Region”字段示例美洲EMEAAPAC
	调查周期时间 InvestigationCycleTime	从开始调查到识别根本原因所需的时长。
说明这是一个计算得出的时长属性，用于衡量“Investigation Commenced”活动与“Root Cause Identified”活动之间的时间。它代表问题管理流程中创造核心价值的时间。此指标用于“Root Cause Investigation Cycle Time”仪表板，帮助管理人员了解问题的技术复杂度以及调查团队的效率。异常值可能反映调查结果过于仓促，例如用猜测代替分析；而过长的时长则可能表示调查陷入停滞。通过比较不同“Support Groups”和“Priorities”下的该指标，组织可以识别哪些团队需要更好的工具、培训或供应商支持，以更快诊断问题。为什么重要这是技术调查阶段的主要效率指标。获取位置根据活动时间戳计算示例 4500000120000
	重新分配次数 ReassignmentCount	支持组被更改的总次数。
说明此属性统计单个案例中“Assigned to Support Group”活动发生的次数，是衡量流程摩擦和路由效率的直接指标。此属性用于生成“Support Group Reassignment Analysis”图表。数值较高（反复转派）通常表示初始分诊失败，或复杂问题缺乏明确的责任归属，也是周期时间增加的先行指标。管理人员可以据此识别培训机会。例如，Service Desk总是先将“Database”问题转派给“Network”，随后“Network”又将其转回“Database”，此时重新分配次数会明显上升，说明需要改进初始诊断脚本。为什么重要用于识别流程中的浪费、摩擦和责任缺失。获取位置根据活动历史计算示例 015

必需建议可选

问题管理活动

以下是应跟踪的基本流程步骤和状态变化，帮助您全面了解调查与解决阶段。

9 建议 4 可选

	活动	说明
	变更请求已发起	将Infrastructure Change Request关联至Problem Investigation，标志着实施阶段开始。
为什么重要对于“Root Cause to Change Lead Time”KPI以及识别Problem与Change流程之间的孤岛至关重要。获取位置 PBM:Investigation_Associations表，或填充“Infrastructure Change ID”字段。采集在PBM:Investigation_Associations中创建关联时记录事件类型 explicit
	已分配至支持组	将问题记录分配给特定技术团队。通过监控“Assigned Group”字段的变化进行捕获。
为什么重要对于衡量交接、反复转派影响以及“Mean Time to Initial Assignment”KPI至关重要。获取位置 PBM:Problem Investigation表单中的“Assigned Group”字段历史记录或审计日志。采集比较更新前后的“Assigned Group”字段事件类型 inferred
	已定义临时解决方案	在问题记录的Workaround字段中输入或更新文本。此事件表示临时解决方案已完成记录。
为什么重要支持“Workaround Publication Lead Time”KPI，表示已采取措施降低事件影响。获取位置 PBM:Problem Investigation表单中“Workaround”文本字段的变更。采集比较“Workaround”字段内容，识别非空更新事件类型 inferred
	已确定根因	问题记录转换为表明原因已知的状态时刻。当Status变为“Root Cause Identified”时推断该事件发生。
为什么重要 “Root Cause Investigation Cycle Time”仪表板中的关键里程碑，标志着流程从分析转向解决方案制定。获取位置 PBM:Problem Investigation表单中的“Status”字段=“Root Cause Identified”。采集比较Status字段是否转换为Root Cause Identified 事件类型 inferred
	解决方案已验证	确认永久修复成功的时点。当Status变为“Solution Implemented”或“Completed”时推断该事件发生。
为什么重要用于计算“Problem SLA Adherence Rate”，确认技术工作已完成。获取位置 PBM:Problem Investigation表单中的“Status”字段=“Solution Implemented”或“Completed”。采集比较Status字段是否转换为Solution Implemented 事件类型 inferred
	调查已开始	问题记录进入主动分析阶段的转换。当Status字段变为“Under Investigation”时推断该事件发生。
为什么重要标志着实际工作阶段开始，为“Investigation Cycle Time”KPI提供支持。获取位置 PBM:Problem Investigation表单中的“Status”字段=“Under Investigation”。采集比较Status字段是否转换为Under Investigation 事件类型 inferred
	问题记录已关闭	问题记录最终完成行政关闭。此事件终止流程实例。
为什么重要标准结束事件。对于完整的周期时间分析和“Incident Linkage Density”计算不可或缺。获取位置 PBM:Problem Investigation表单中的“Status”字段=“Closed”。采集比较Status字段是否转换为Closed 事件类型 inferred
	问题记录已取消	问题记录在解决前终止。当Status变为“Cancelled”或“Rejected”时进行捕获。
为什么重要识别无效投入或有效重复记录，表示另一种结束路径。获取位置 PBM:Problem Investigation表单中的“Status”字段=“Cancelled”或“Rejected”。采集比较Status字段是否转换为Cancelled 事件类型 inferred
	问题记录已记录	在系统中首次创建Problem Investigation记录。当PBM:Problem Investigation表单中保存新条目时，系统会明确记录此事件。
为什么重要标志着流程实例开始。对于计算整体周期时间和初始响应指标至关重要。获取位置 PBM:Problem Investigation表单中的“Submit Date”时间戳，或“Status”=“Draft”的创建日志。采集创建PBM:Problem Investigation记录时记录事件类型 explicit
	协调人已重新分配	支持组内负责该问题的Problem Coordinator发生变更。通过监控“Problem Coordinator”字段进行捕获。
为什么重要帮助分析工作负载分配和个人资源瓶颈。获取位置 PBM:Problem Investigation表单中的“Problem Coordinator”字段历史记录。采集比较更新前后的“Problem Coordinator”字段事件类型 inferred
	已完成实施后评审	PIR阶段完成。通过离开PIR状态的状态转换，或关闭关联的PIR Task进行捕获。
为什么重要直接支持“Post Implementation Review Compliance”和流程质量审计。获取位置 PBM:Problem Investigation表单中的“PIR Required”特定标记，或关联Task类型为“PIR”的任务完成。采集根据PIR状态完成或PIR Task关闭推导事件类型 inferred
	已提升为已知错误	创建与问题调查关联的Known Error记录。这是一个关联记录创建事件。
为什么重要表示问题已正式归档，便于更广泛地沟通和长期跟踪。获取位置在PBM:Known Error中创建与PBM:Problem Investigation ID关联的记录。采集创建PBM:Known Error记录时记录事件类型 explicit
	解决方案数据库已更新	记录转换为“Solution Database”状态，表示已提出或确定永久修复方案。
为什么重要跟踪解决方案在实施前的定义进度。获取位置 PBM:Problem Investigation表单中的“Status”字段=“Solution Database”。采集比较Status字段是否转换为Solution Database 事件类型 inferred

建议可选

提取指南

如何从BMC Helix ITSM提取问题管理数据

步骤

登录BMC Helix ITSM 使用拥有Problem Master或Report Administrator权限的凭据，访问中间层或Smart IT界面。
进入报表控制台 在Applications菜单中选择AR System Report Console。如果使用Smart IT，请进入Reporting仪表板并选择“Web Report”。
创建新报表 点击新建按钮（绿色加号图标），启动报表向导。
选择数据源（表单） 在“Form Name”字段中搜索并选择PBM:AuditLogSystem（具体名称可能因版本而为PBM:Problem Investigation_AuditLog）。 注意：PBM:Problem Investigation表单包含当前案例数据，而Audit Log表单用于生成数据要求所需的逐行事件历史（例如重新分配、状态变更）。
定义报表名称和类型 输入说明性标题（例如“Problem Management Event Log”），并确保格式设置为Web Report。
添加列（属性） 从Available Fields列表中选择以下字段，并将其移至Selected Fields列表：
- Original Request ID（映射为ProblemRecord）
- Submit Date（映射为EventTime）
- Fields Changed（映射为Activity）
- 用户（映射为User/Coordinator）
- Log Key 1（通常保存原始Status值）
配置筛选条件（Qualification） 点击筛选或Qualification选项卡。构建查询以限制范围：
- 将Form Name设置为等于“PBM:Problem Investigation”（排除Incident/Change审计）。
- 将Submit Date设置为所需范围（例如>= 01/01/2023）。
保存并运行 保存报表配置。点击预览确认返回数据，然后点击导出。
导出为CSV 选择CSV（逗号分隔值）作为导出格式。确保包含表头。
辅助导出（建议用于属性） 在PBM:Problem Investigation上创建第二个简单报表。导出Problem Investigation ID、Priority、ServiceCI和说明。该“案例属性”文件可在分析工具中与事件日志关联，用于填充建议的静态属性（Priority、Service CI），因为这些属性并非每一行审计日志都包含。
数据转换（导出后） 上传到ProcessMind前：
- 将Fields Changed的值映射到标准活动（例如，如果Field Changed = “Status”，则使用Log Key 1中的值判断其为“调查已开始”还是“根因已识别”。）。
- 如无需要，筛除非流程更新（例如外观字段更新）。

配置

表单选择：PBM:AuditLogSystem是主要数据源。直接提取PBM:Problem Investigation只能获取当前状态，无法记录“Coordinator Reassigned”或“Workaround Defined”的历史。
日期筛选：在Audit表单中按Submit Date筛选，而不只是按Case创建日期筛选，以便获取旧Case中的近期活动。
字段“Form Name”：这是关键筛选条件。Audit System表单由整个ITSM共用，您必须设置Form Name = "PBM:Problem Investigation"，避免混入Incident或Change日志。
性能：Audit Log表数据量通常很大。请将导出范围限制为3至6个月，或严格按Original Request ID前缀筛选，例如PBM%。
权限：需要具备查看System Audit表单的权限。如果权限受限，必须由System Administrator执行导出。

a 示例查询 config

Form: PBM:AuditLogSystem
Type: Web Report (AR System Report Console)

// === SELECTION COLUMNS ===
// These fields form the raw event log structure
1. Original Request ID   (Alias: ProblemRecord)
2. Submit Date           (Alias: EventTime)
3. Submitter             (Alias: User)
4. Fields Changed        (Alias: Activity_Type)
5. Log Key 1             (Alias: New_Value)
6. Log Key 2             (Alias: Previous_Value)
7. Form Name             (Alias: Source_Module)

// === SEARCH QUALIFICATION (FILTER) ===
// Copy this logic into the Advanced Search or Qualification builder

('Form Name' = "PBM:Problem Investigation") AND
('Submit Date' >= "2023-01-01 00:00:00") AND
('Fields Changed' != $NULL$)

// === POST-EXPORT LOGIC (Context for Analyst) ===
// The Audit Log captures changes generically. You must map them:
// IF 'Fields Changed' CONTAINS "Status" AND 'Log Key 1' = "Under Investigation" -> Activity = "Investigation Commenced"
// IF 'Fields Changed' CONTAINS "Work Around" -> Activity = "Workaround Defined"
// IF 'Fields Changed' CONTAINS "PBM Coordinator" -> Activity = "Coordinator Reassigned"
// IF 'Fields Changed' = $NULL$ (Create Event) -> Activity = "Problem Record Logged"

步骤

验证前提条件：确保您拥有AR System数据库的读取权限（SELECT权限），尤其是PBM_Problem_Investigation和PBM_Problem_WorkLog视图。确认您的用户账户可以访问相关Company/Support Group数据。
连接数据库：打开您偏好的SQL客户端（例如SQL Server Management Studio、DBeaver或Oracle SQL Developer），并连接到BMC Helix AR System数据库副本或报表数据库。
了解数据模型：确定您所在实例使用的具体表名或视图名。PBM_Problem_Investigation是标准名称，但某些定制环境可能使用PBM_Problem_Investigation_Join或类似名称。验证Problem_ID和Submit_Date列名。
准备查询：复制下方“Query”部分提供的SQL查询。该脚本将主要问题记录数据与工作日志历史合并，创建事务型事件日志。
配置筛选条件：找到脚本中的WHERE子句（由/* Filter by Date */等注释标记），并将日期范围更新为所需的提取窗口（例如Submit_Date >= '2023-01-01'）。
执行提取：运行完整查询。根据问题记录和工作日志的数量，执行可能需要数分钟。请确保数据库客户端不会超时。
验证数据：检查以下关键列的结果：ProblemRecord、活动和EventTime。确保这些必填字段不存在NULL值。
导出数据：将查询结果保存为CSV文件。使用标准编码（UTF-8），并确保包含标题。
设置上传格式：打开CSV，确认日期格式一致（ProcessMind建议使用ISO 8601格式YYYY-MM-DD HH:MM:SS）。如发现文本字段中存在二进制字符或多余空格，请将其删除。
导入ProcessMind：将清理后的CSV上传至ProcessMind，并按照“Settings Overview”中的定义映射列。

配置

时间范围：建议提取3至6个月的数据，在性能与流程可见性之间取得平衡。
系统视图：主要视图为PBM_Problem_Investigation（Header数据）和PBM_Problem_WorkLog（活动历史）。
日期筛选：通常按Problem Investigation的Submit_Date筛选，以保留完整Case；如需严格截取时间范围，则按EventTime筛选。
Company筛选：如果系统承载多个租户，请在所有WHERE子句中加入AND Company = 'YourCompany'，防止数据泄露。
性能：查询使用高效的UNION ALL，但在WorkLog中连接大型CLOB/Text字段可能较慢。请确保数据库使用了Problem_ID索引。

a 示例查询 sql

/* Part 1: Problem Record Logged (Creation) */
SELECT
    P.Problem_ID AS ProblemRecord,
    'Problem Record Logged' AS Activity,
    P.Submit_Date AS EventTime,
    'BMC Helix' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    P.Assigned_Group AS SupportGroup,
    P.Priority AS Priority,
    P.PBM_Coordinator AS ProblemCoordinator,
    P.Generic_Category AS RootCauseCategory,
    P.ServiceCI AS ServiceCI,
    P.Investigation_Driver AS InvestigationDriver,
    P.Target_Date AS SLADueDate,
    (SELECT COUNT(*) FROM HPD_Help_Desk_Associations A WHERE A.Problem_ID = P.Problem_ID) AS RelatedIncidentCount,
    CASE WHEN P.Target_Date < P.Closed_Date THEN 'Yes' ELSE 'No' END AS IsSLABreached
FROM PBM_Problem_Investigation P
WHERE P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 2: Investigation Commenced (Status Transition) */
SELECT
    P.Problem_ID,
    'Investigation Commenced',
    /* Prefer explicit status history timestamp if available, else estimate from Last_Modified if current status matches */
    COALESCE(P.Status_History_Under_Inv_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Under_Inv_Time IS NOT NULL
   OR (P.Status = 1 AND P.Last_Modified_Date IS NOT NULL) /* Status 1 = Under Investigation */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 3: Root Cause Identified (Status Transition) */
SELECT
    P.Problem_ID,
    'Root Cause Identified',
    COALESCE(P.Status_History_Root_Cause_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Root_Cause_Time IS NOT NULL
   OR (P.Status = 2) /* Status 2 = Root Cause Identified */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 4: Solution Database Updated (Status Transition) */
SELECT
    P.Problem_ID,
    'Solution Database Updated',
    COALESCE(P.Status_History_Solution_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Solution_Time IS NOT NULL
   OR (P.Status = 3) /* Status 3 = Solution Database */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 5: Resolution Verified (Inferred from Completed Status) */
SELECT
    P.Problem_ID,
    'Resolution Verified',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Completed_Time IS NOT NULL
   OR (P.Status >= 4) /* Status 4 = Implemented/Completed */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 6: Problem Record Closed */
SELECT
    P.Problem_ID,
    'Problem Record Closed',
    P.Closed_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 5 /* Status 5 = Closed */
  AND P.Closed_Date IS NOT NULL
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 7: Problem Record Cancelled */
SELECT
    P.Problem_ID,
    'Problem Record Cancelled',
    P.Last_Modified_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 6 /* Status 6 = Cancelled */
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 8: Workaround Defined (From Worklog) */
SELECT
    P.Problem_ID,
    'Workaround Defined',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Work_Log_Type = 'Workaround' OR W.Description LIKE '%Workaround%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 9: Assigned to Support Group (From Worklog) */
SELECT
    P.Problem_ID,
    'Assigned to Support Group',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Assigned to Group%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 10: Coordinator Reassigned (From Worklog) */
SELECT
    P.Problem_ID,
    'Coordinator Reassigned',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Coordinator%' AND W.Description LIKE '%Change%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 11: Change Request Initiated (From Worklog or Description) */
SELECT
    P.Problem_ID,
    'Change Request Initiated',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Change Request%' OR W.Description LIKE '%CRQ%')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 12: Known Error Promoted (From Worklog) */
SELECT
    P.Problem_ID,
    'Known Error Promoted',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Known Error%' OR W.Work_Log_Type = 'Known Error')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 13: Post-Implementation Review Conducted */
SELECT
    P.Problem_ID,
    'Post-Implementation Review Conducted',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE (P.Status_Reason = 'PIR' OR P.Investigation_Driver = 'PIR')
  AND P.Status >= 4
  AND P.Submit_Date >= '2023-01-01'

步骤

前提条件：确保提取机器已安装Python 3.x。您还需要requests和pandas库，可通过pip install requests pandas安装。
API访问：向BMC Helix ITSM管理员申请专用集成用户账户。该用户需要具备“Problem Viewer”和“AR System Administrator”（或同等API访问权限）。
确定API网关：获取BMC Helix AR System REST API的基础URL，通常类似于https://[your-instance].onbmc.com/api/arsys/v1。
字段ID映射：BMC Helix使用内部Field ID。脚本会使用useLabels功能尝试获取易读名称，但您仍应在具体部署中通过Developer Studio或执行测试GET请求，核实“Status”“Assigned Group”和“Workaround”的Field ID。
配置脚本：更新所提供Python脚本中的CONFIG字典，设置URL、用户名、密码和提取日期范围。
提取主数据：脚本首先查询PBM:Problem Investigation表单，获取Problem Record基础详情，根据Submit Date创建“Problem Record Logged”活动，并记录当前属性。
提取历史数据：脚本会逐步获取审计轨迹。在BMC Helix中，历史记录通常存储于PBM:AuditLogSystem，或可通过关联关系访问。所提供脚本会查询Audit表单，捕获状态转换（例如Investigation Commenced）和字段更新（例如Assigned to Support Group）。
转换数据：脚本包含映射逻辑，可将BMC Status代码（例如“Under Investigation”“Root Cause Identified”）转换为流程定义所需的具体Activity名称。
验证：以试运行模式执行脚本，仅提取少量记录，以确认字段名称与您的定制一致。检查控制台输出中是否存在连接错误。
执行提取：运行完整提取。脚本会使用offset和limit参数自动处理分页，避免请求超时。
生成输出：脚本将所有事件汇总到单个DataFrame，并导出为problem_management_event_log.csv文件。
最终检查：打开CSV文件，确认“EventTime”列采用正确格式（建议使用ISO 8601），并确认13种Activity类型均已包含，然后再上传到ProcessMind。

配置

API端点：AR System REST API是标准接口。请确保相关端口允许流量通过，通常为443端口。
分页：脚本默认批量大小为1000。请根据网络延迟和服务器超时设置进行调整。
日期筛选：提取时按主记录的Submit Date筛选。请确保查询中的日期格式符合AR System格式，具体格式通常取决于版本，可能是epoch或特定字符串格式。
字段选择：请求中仅包含必要字段，以减少负载。添加description或attachment字段可能会显著降低提取速度。
身份验证：使用JWT（JSON Web Token）身份验证。由于令牌会过期，脚本包含在请求前获取令牌的逻辑。
状态映射：BMC使用整数ID表示状态值，例如0、10、20。脚本会将其映射为易读的Activity。请根据您的ITSM配置核实这些映射。

a 示例查询 python

import requests
import json
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># Configuration
CONFIG = {
    class="hl-string">"base_url": class="hl-string">"https://[your-instance].onbmc.com/api/arsys/v1",
    class="hl-string">"username": class="hl-string">"[API_User]",
    class="hl-string">"password": class="hl-string">"[API_Password]",
    class="hl-string">"start_date": class="hl-string">"2023-01-01T00:00:00.000+0000",
    class="hl-string">"output_file": class="hl-string">"problem_management_event_log.csv",
    class="hl-string">"batch_size": 1000
}

class=class="hl-string">"hl-comment"># Status Map (Standard BMC Helix PBM Status values)
STATUS_MAP = {
    class="hl-string">"Draft": class="hl-string">"Problem Record Logged",
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Commenced",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Solution Database": class="hl-string">"Solution Database Updated",
    class="hl-string">"Solution Implemented": class="hl-string">"Resolution Verified",
    class="hl-string">"Completed": class="hl-string">"Resolution Verified",
    class="hl-string">"Rejected": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Cancelled": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed"
}

class=class="hl-string">"hl-comment"># Global Session
session = requests.Session()

def login():
    url = fclass="hl-string">"{CONFIG['base_url']}/jwt/login"
    headers = {class="hl-string">"Content-Type": class="hl-string">"application/x-www-form-urlencoded"}
    data = {
        class="hl-string">"username": CONFIG[class="hl-string">"username"],
        class="hl-string">"password": CONFIG[class="hl-string">"password"]
    }
    response = session.post(url, headers=headers, data=data)
    if response.status_code == 200:
        session.headers.update({class="hl-string">"Authorization": fclass="hl-string">"AR-JWT {response.text}"})
        print(class="hl-string">"Authentication successful.")
    else:
        raise Exception(fclass="hl-string">"Login failed: {response.text}")

def fetch_records(form_name, fields, query_string):
    all_entries = []
    offset = 0
    
    while True:
        url = fclass="hl-string">"{CONFIG['base_url']}/entry/{form_name}"
        params = {
            class="hl-string">"q": query_string,
            class="hl-string">"fields": fclass="hl-string">"values({','.join(fields)})",
            class="hl-string">"offset": offset,
            class="hl-string">"limit": CONFIG[class="hl-string">"batch_size"],
            class="hl-string">"useLabels": class="hl-string">"true"
        }
        
        resp = session.get(url, params=params)
        if resp.status_code != 200:
            print(fclass="hl-string">"Error fetching data: {resp.text}")
            break
            
        data = resp.json()
        entries = data.get(class="hl-string">'entries', [])
        if not entries:
            break
            
        for entry in entries:
            all_entries.append(entry[class="hl-string">'values'])
            
        offset += len(entries)
        print(fclass="hl-string">"Fetched {len(all_entries)} records from {form_name}...")
        
    return all_entries

def generate_event_log():
    class=class="hl-string">"hl-comment"># 1. Fetch Main Problem Records
    print(class="hl-string">"Fetching Problem Investigations...")
    pbm_fields = [
        class="hl-string">"Problem ID", class="hl-string">"Submit Date", class="hl-string">"Last Modified Date", class="hl-string">"Status", 
        class="hl-string">"Assigned Group", class="hl-string">"Priority", class="hl-string">"Problem Coordinator", 
        class="hl-string">"Description", class="hl-string">"Workaround", class="hl-string">"Investigation Driver"
    ]
    class=class="hl-string">"hl-comment"># Query syntax: class="hl-string">'Submit Date' > class="hl-string">"start_date"
    pbm_query = fclass="hl-string">"'Submit Date' > \"{CONFIG[class="hl-string">'start_date']}\class="hl-string">""
    
    problems = fetch_records(class="hl-string">"PBM:Problem Investigation", pbm_fields, pbm_query)
    
    event_log = []
    
    class=class="hl-string">"hl-comment"># Map of Problem ID to attributes for enrichment
    pbm_lookup = {}

    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        pbm_lookup[pid] = p
        
        class=class="hl-string">"hl-comment"># Event 1: Problem Record Logged (Creation)
        event_log.append({
            class="hl-string">"ProblemRecord": pid,
            class="hl-string">"Activity": class="hl-string">"Problem Record Logged",
            class="hl-string">"EventTime": p.get(class="hl-string">"Submit Date"),
            class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
            class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
            class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
            class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
            class="hl-string">"LastDataUpdate": datetime.now().isoformat()
        })

    class=class="hl-string">"hl-comment"># 2. Fetch Audit Logs / History
    class=class="hl-string">"hl-comment"># Note: Fetching PBM:AuditLogSystem or PBM:Problem Investigation_AuditLog
    class=class="hl-string">"hl-comment"># We filter by the Problem IDs we just fetched to optimize
    print(class="hl-string">"Fetching Audit Logs...")
    
    class=class="hl-string">"hl-comment"># In a real scenario, chunk this query if too many IDs, here simplified
    class=class="hl-string">"hl-comment"># We look for field changes relevant to our activities
    audit_fields = [class="hl-string">"Original Request ID", class="hl-string">"Fields Changed", class="hl-string">"Log Date", class="hl-string">"User", class="hl-string">"New Value"]
    
    class=class="hl-string">"hl-comment"># Iterate through problems to get history (Alternative: fetch bulk audit if API allows complex ORs)
    class=class="hl-string">"hl-comment"># For this script, we assume we fetch audit based on the main form query logic mapping
    class=class="hl-string">"hl-comment"># WARNING: Fetching audit for all records can be slow. 
    
    class=class="hl-string">"hl-comment"># For demonstration, we simulate fetching audit entries. 
    class=class="hl-string">"hl-comment"># In production, query class="hl-string">'PBM:Problem Investigation_AuditLog' where class="hl-string">'Original Request ID' IN (...)
    
    class=class="hl-string">"hl-comment"># Placeholder for audit data retrieval logic
    class=class="hl-string">"hl-comment"># Simulating a loop over retrieved problems to get their specific audit trails
    class=class="hl-string">"hl-comment"># This is a logical representation; in high volume, use a bulk export method
    
    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        
        class=class="hl-string">"hl-comment"># Query specific audit form for this problem
        class=class="hl-string">"hl-comment"># Using PBM:Problem Investigation_AuditLog as the standard history container
        audit_query = fclass="hl-string">"'Original Request ID' = \"{pid}\class="hl-string">""
        class=class="hl-string">"hl-comment"># We only need specific fields changed
        audit_entries = fetch_records(class="hl-string">"PBM:Problem Investigation_AuditLog", audit_fields, audit_query)
        
        for audit in audit_entries:
            fields_changed = audit.get(class="hl-string">"Fields Changed", class="hl-string">"")
            new_val = audit.get(class="hl-string">"New Value", class="hl-string">"")
            log_date = audit.get(class="hl-string">"Log Date")
            
            activity = None
            
            class=class="hl-string">"hl-comment"># Map Fields to Activities
            if class="hl-string">"Status" in fields_changed:
                class=class="hl-string">"hl-comment"># Map status string to activity
                activity = STATUS_MAP.get(new_val)
                
            elif class="hl-string">"Assigned Group" in fields_changed:
                activity = class="hl-string">"Assigned to Support Group"
                
            elif class="hl-string">"Workaround" in fields_changed:
                activity = class="hl-string">"Workaround Defined"
                
            elif class="hl-string">"Problem Coordinator" in fields_changed:
                activity = class="hl-string">"Coordinator Reassigned"
                
            elif class="hl-string">"Infrastructure Change ID" in fields_changed or class="hl-string">"Change Request" in fields_changed:
                activity = class="hl-string">"Change Request Initiated"
                
            elif class="hl-string">"Known Error" in fields_changed:
                activity = class="hl-string">"Known Error Promoted"

            class=class="hl-string">"hl-comment"># PIR Inference: If status moves to class="hl-string">'Closed' and PIR task exists (simplified here to Status)
            if activity == class="hl-string">"Problem Record Closed" and p.get(class="hl-string">"PIR Required") == class="hl-string">"Yes":
                 class=class="hl-string">"hl-comment"># Insert PIR event just before close if not explicitly found
                 event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": class="hl-string">"Post-Implementation Review Conducted",
                    class="hl-string">"EventTime": log_date, class=class="hl-string">"hl-comment"># Same time as close for this logic
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

            if activity:
                event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": activity,
                    class="hl-string">"EventTime": log_date,
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"), class=class="hl-string">"hl-comment"># Use current or historical if parsed
                    class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
                    class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Sorting
    if not df.empty:
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ProblemRecord', class="hl-string">'EventTime'])
        
        class=class="hl-string">"hl-comment"># Export
        df.to_csv(CONFIG[class="hl-string">'output_file'], index=False)
        print(fclass="hl-string">"Extraction complete. Data saved to {CONFIG['output_file']}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    try:
        login()
        generate_event_log()
    except Exception as e:
        print(fclass="hl-string">"An error occurred: {e}")

准备开始了吗？

立即将此模板应用于您的BMC Helix ITSM数据，提升服务稳定性。如果您对设置有任何疑问，我们的团队随时可以提供帮助。

返回改进指南下载模板

立即解决问题管理瓶颈

将周期时间缩短30%，提升服务稳定性。

开始免费试用

无需信用卡，几分钟即可完成设置。

您的问题管理数据模板

您的问题管理数据模板

问题管理属性

问题管理活动

提取指南

BMC Helix AR System Report Console导出

步骤

配置

a 示例查询 config

直接查询AR System数据库视图

步骤

配置

a 示例查询 sql

通过AR System REST API使用Python提取

步骤

配置

a 示例查询 python

准备开始了吗？

立即解决问题管理瓶颈

您的问题管理数据模板

您的问题管理数据模板

问题管理属性

问题管理活动

提取指南

BMC Helix AR System Report Console导出

步骤

配置

a 示例查询 config

直接查询AR System数据库视图

步骤

配置

a 示例查询 sql

通过AR System REST API使用Python提取

步骤

配置

a 示例查询 python

准备开始了吗？

立即解决问题管理瓶颈

我们重视您的隐私