> 持续流程改进 > 服务请求管理 > BMC Helix ITSM > 数据模板

您的服务请求管理数据模板

BMC Helix ITSM

← 返回改进指南

服务请求管理属性 (20) 服务请求管理活动 (14) 提取指南 (3)

您的服务请求管理数据模板

此模板清晰概述了服务请求管理流程中需要收集的核心数据属性和追踪的关键活动。它还包括关于如何从 BMC Helix ITSM 高效提取这些数据的实用指南。利用此资源简化您的数据准备工作，并满怀信心地启动流程挖掘计划。

建议收集的属性
需要追踪的关键活动
BMC Helix ITSM 提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

服务请求管理属性

这些数据字段对于创建完整的事件日志至关重要，能够对您的服务请求管理流程进行深度分析。

5 必填 6 推荐 9 可选

	名称	描述
	开始时间 EventStartTime	指示特定活动或事件开始的时间戳。
描述此属性记录活动开始的精确日期和时间。日志中的每个事件（从初始提交到最终关闭）都必须有开始时间，以建立流程的时间序列。此时间戳对于所有基于时间的流程挖掘分析都至关重要。它用于计算周期时间、活动持续时间、步骤之间的等待时间，并检查 SLA 合规性。它支持瓶颈发现以及随时间推移的流程绩效分析。为何重要开始时间提供了事件的时间顺序，这对于计算流程持续时间、识别延迟以及理解流程时间线至关重要。获取方式这对应于与“SRM:Request”表单关联的审核日志或状态历史表中的时间戳字段，例如初始事件的“提交日期”。示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	服务请求 ID ServiceRequestId	每个服务请求的唯一标识符，作为追踪整个生命周期的主键。
描述服务请求 ID 用于唯一标识用户或系统提交的每个服务请求。它是连接从初始记录到最终关闭的所有后续事件的核心线索，能够实现对每个服务请求历程的完整端到端分析。在流程挖掘中，此 ID 对于重建每个个案的活动序列至关重要。它允许工具将所有相关事件（如“已提交请求”、“已分配请求”和“已关闭服务请求”）分组到单个流程实例中，从而构成所有流程分析的基础。为何重要这是基本的个案标识符。如果没有它，就无法追踪服务请求的端到端历程，从而无法进行流程发现和分析。获取方式这通常是 BMC Helix ITSM 中“SRM:Request”表单里的“InstanceId”或“请求编号”字段。示例 SR000010572931SR000010572932SR000010572933
	活动 ActivityName	在服务请求生命周期的某个时间点发生的特定事件或任务的名称。
描述此属性描述服务请求流程中的特定步骤或状态变更，例如“请求审核中”、“履行中”或“服务请求已解决”。每个活动代表服务请求端到端历程中的单个事件。分析活动的顺序和频率是流程挖掘的核心。它支持流程图的发现、瓶颈识别以及流程变体分析。了解发生了哪些活动、发生的顺序以及频率，对于流程优化至关重要。为何重要活动构成了流程图的基石。追踪这些活动可以实现流程流向的可视化和分析，揭示工作的真实开展方式。获取方式这通常源自“SRM:Request”表单或相关履行应用程序日志（例如事件、工作单）中“状态”和“状态原因”字段的更改。示例请求待审批交付进行中服务请求已解决服务请求已关闭
	最后数据更新 LastDataUpdate	此流程的数据最后一次从源系统刷新的时间戳。
描述此属性指示从 BMC Helix ITSM 进行最近一次数据提取的日期和时间。它向用户提供所分析数据的时效性背景，确保他们了解分析所涵盖的时间段。这是任何流程挖掘仪表板或分析的关键元数据属性。它让用户了解见解是基于近乎实时的数据还是历史快照，这会影响所得出结论的有效性和相关性。为何重要它告知用户 data 的时效性，这对于基于当前最新的流程绩效信息做出决策至关重要。获取方式此时间戳是在数据提取和加载过程中生成并添加的。示例 2024-05-21T08:00:00Z
	源系统 SourceSystem	用于标识数据提取自哪个系统。
描述此属性指定流程数据的来源。对于此视图，它将静态设置为“BMC Helix ITSM”，表示与服务请求相关的所有事件均源自该系统。在具有多个集成系统的环境中，此字段对于理解数据血缘和根据来源划分数据至关重要。它确保了清晰度和可追溯性，尤其是在合并来自不同平台的数据时。为何重要它提供了关于 data 来源的上下文，这对于多系统环境下的 data 治理、可追溯性和故障排除非常重要。获取方式这是一个在数据提取和转换过程中添加的静态值，而非 BMC Helix ITSM 本身中的字段。示例 BMC Helix ITSM
	优先级 Priority	分配给服务请求的优先级，反映其业务影响和紧急程度。
描述优先级决定了请求处理的顺序和速度。常见值包括“Critical”、“High”、“Medium”和“Low”。分配通常基于请求对业务的影响及其紧急程度的综合评估。按优先级进行分析对于评估高优先级请求是否比低优先级请求处理得更快至关重要。它是解决时间和 SLA 合规性仪表板中的关键维度，有助于确保资源被适当地分配给最关键的业务需求。为何重要它有助于评估流程是否正确排定了工作优先级，并是否达到了具有不同业务影响级别的请求所预期的服务水平。获取方式这是“SRM:Request”表单上的“优先级”字段。示例严重高中低
	指派团队 AssignedTeam	当前分配给该服务请求的支持组或团队。
描述此属性标识负责处理请求的职能组，例如“服务台”、“网络团队”或“数据库管理”。此字段的更改表示团队之间的职责交接。基于分配团队的分析有助于识别团队层面的瓶颈、分析团队间的交接，并评估不同支持小组的效率。它是“请求返工与重新分配”及“分流效率”仪表板的关键，揭示了工作在组织内路由的模式。为何重要它支持分析不同职能组之间的流程流向，有助于识别路由低效点并衡量团队层级的绩效。获取方式这对应于与服务请求关联的履行记录（例如工作单、事件）上的“分配组”字段。示例服务台基础设施支持应用支持二线
	指派处理人 AssignedAgent	当前被分配处理该服务请求的具体用户。
描述此属性标识在特定时间点负责请求的具体 IT 坐席或支持人员。在单个请求的生命周期内，此字段的更改表示交接或重新分配。此属性对于坐席绩效和工作负载分析至关重要。它支持跟踪每个坐席处理的请求数量、平均解决时间以及重新分配的频率。这些数据为资源管理和培训机会的识别提供支持。为何重要追踪分配的坐席对于分析交接、衡量个人绩效以及了解整个支持团队的工作负载分布至关重要。获取方式这对应于与服务请求关联的履行记录（例如工作单、事件）上的“受派人”或“分配至”字段。示例 Bob Smith爱丽丝·约翰逊Charlie Brown
	服务类型 ServiceType	用户请求的服务类别或类型。
描述服务类型 (Service Type) 对请求的性质进行分类，例如“请求新软件”、“密码重置”或“新员工入职”。它是过滤和细分流程数据的基本维度。在流程分析中，此属性用于比较不同类型请求的绩效。它有助于回答诸如“哪些服务类型解决时间最长？”或“哪些服务类型返工最多？”等问题。这对于“解决时间”和“SLA 合规性”仪表板至关重要。为何重要它允许对服务请求进行细分，以比较流程流向、识别特定类型的问题并有效地定制优化工作。获取方式这些数据通常可以在“SRM:Request”表单的“标题”或分类字段中找到，源自目录中选定的服务。示例新硬件请求软件访问请求VPN 访问设置
	结束时间 EventEndTime	指示特定活动或事件完成时间的精确时间戳。
描述结束时间标志着一项活动的完成。虽然 ITSM 系统中的许多活动只是瞬间的状态变更，但某些活动具有可衡量的持续时间。具备结束时间可以精确计算此类活动的耗时。在分析中，结束时间与开始时间结合使用，以计算单个活动的执行时间。这有助于精准定位哪些具体任务（而不只是步骤之间的等待时间）消耗了流程中最多的时间。为何重要它支持计算活动处理时间，这对于识别低效步骤以及了解资源的时间分配至关重要。获取方式这是可以派生的。一个活动的结束时间通常是同一个案中下一个顺序活动的开始时间。对于最后一项活动，它将是解决或关闭的时间戳。示例 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	请求状态 RequestStatus	事件发生时服务请求的状态，例如“处理中”、“挂起”或“已关闭”。
描述此属性捕获服务请求在其生命周期中不同时间点的状态。状态为每个活动提供背景，且通常是“活动”属性本身的来源。按状态分析有助于了解请求在某些状态（如“等待客户”或“等待审批”）下花费的时间。这对于识别由外部依赖关系或内部队列引起的瓶颈和延迟至关重要。它直接为“瓶颈识别”仪表板提供支持。为何重要它提供了请求状态的快照，支持分析在等待状态与活动状态中耗费的时间，这是识别瓶颈的关键。获取方式这是“SRM:Request”表单上的“状态”字段。历史值可以在审核日志中找到。示例计划中进行中挂起已解决已结案
	SLA 目标日期 SlaTargetDate	根据服务水平协议 (SLA) 预计解决服务请求的日期和时间。
描述 SLA 目标日期是一个计算出的时间戳，代表完成服务请求的截止日期。它由服务协议规则决定，通常会考虑请求的优先级和类型等因素。此属性是“SLA 合规性概览”仪表板的基础。它作为衡量实际解决时间的基准。通过将最终解决活动的 'EventEndTime' 与此目标日期进行比较，我们可以确定是否履行了服务承诺。为何重要这是衡量服务绩效是否符合承诺的主要基准，因此对于 SLA 合规性监控和报告至关重要。获取方式此日期由服务水平管理 (SLM) 模块计算并存储，可以在与服务请求关联的相关 SLM 表单中找到。示例 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	关闭代码 CloseCode	一个指示最终结果或关闭服务请求原因的编码。
描述关闭代码 (Close Code) 提供了一种标准化的方式来对服务请求的解决结果进行分类。例如：“由服务台解决”、“用户取消”或“重复请求”。分析关闭代码有助于了解请求的常见结果。它可以突出一些问题，比如大量请求被用户取消（可能表明流程过于冗长），或者存在许多重复请求（可能指向系统或沟通问题）。该属性为“解决分类准确性”仪表板提供支持。为何重要它提供关于请求结果的结构化 data，支持分析解决有效性以及未完成或取消的原因。获取方式此信息通常可以在与服务请求关联的履行工单上的“解决”或“关闭代码”字段中找到。示例成功由用户取消不再需要自动解决
	提交渠道 SubmissionChannel	提交服务请求的方法或渠道。
描述此属性记录服务请求的启动方式，例如通过自服务门户、电子邮件、拨打服务台电话或自动化系统警报。不同渠道可能导致不同的流程变体和解决时间。按提交渠道分析流程可以揭示与特定摄取方法相关的效率低下或最佳实践。例如，由于初始数据质量更好，通过自服务门户提交的请求可能会更快得到解决，而来自电子邮件的请求可能需要更多人工分流。为何重要它有助于理解受理方式如何影响流程效率、data 质量和整体 Cycle Time，从而能够对特定渠道进行针对性改进。获取方式这通常可以从“SRM:Request”表单或相关的履行工单上的“客户类型”或“上报来源”等字段推断出来。示例自助服务门户电子邮件电话系统生成
	是否升级 IsEscalated	一个布尔标记，指示服务请求是否已被升级处理。
描述如果服务请求经历了功能性或层级性升级，则此标志设置为 true。升级通常发生在请求未按预期进展、即将违反 SLA 或需要更高权限审批或采取行动时。此属性是“请求升级效率分析”仪表板的关键。它支持过滤和分析升级请求的流程路径，以了解触发因素、升级后的解决时间以及升级流程的有效性。为何重要它允许隔离并分析需要升级处理的请求子集，帮助识别标准流程中的薄弱环节或复杂问题的触发因素。获取方式这通常不是单个字段。它是通过检查审核日志中特定的升级相关活动，或遵循升级协议的优先级/分配更改而派生出来的。示例 truefalse
	是否发生SLA违约 IsSlaBreached	一个布尔标记，指示服务请求是否在 SLA 目标日期之后才解决。
描述如果服务请求的最终解决时间戳晚于其“SLA 目标日期”，则此计算标志设置为 true。它为每个请求的 SLA 绩效提供简单的二元结果。此属性对于“SLA 合规性概览”仪表板和“SLA 达成率”KPI 至关重要。它支持轻松聚合以计算整体合规率，并允许通过过滤来分析违规请求与合规请求的流程特征，从而协助识别 SLA 失败的根本原因。为何重要它通过将 timestamp 对比转换为简单的布尔标记，简化了 SLA 绩效分析，使合规率的衡量和可视化变得轻松。获取方式这是一个计算字段。逻辑为：如果“解决时间戳”>“SlaTargetDate”，则为 true，否则为 false。示例 truefalse
	是否返工 IsRework	一个布尔标记，指示服务请求是否经历过返工，例如返回到之前的阶段。
描述此标志标识在流程流中经历过循环或返工的服务请求。例如，请求从“履行中”退回到“审核中”将被视为返工。确切定义取决于业务流程逻辑。该属性直接为“请求返工与重新分配分析”仪表板和“请求返工率”KPI 提供支持。它支持量化返工频率并分析常见原因（如初始评估错误或信息不完整），从而发现导致流程低效的根源。为何重要它通过标记偏离“快乐路径”的 case 来量化流程低效，帮助识别环路和重复工作的根本原因。获取方式这是一个派生自事件日志活动序列的计算属性。需要逻辑来检测流程流中的回退操作。示例 truefalse
	申请人部门 RequestorDepartment	提交请求的用户的业务部门或单位。
描述此属性标识请求服务的个案所在组织部门，例如“财务”、“人力资源”或“IT”。此信息通常源自系统中的用户个人资料。按部门细分流程分析，可以识别各部门的特定需求、请求模式以及有针对性的培训或服务改进的潜在领域。它可以帮助回答诸如“财务部门的请求是否经历了更长的等待时间？”之类的问题。为何重要它支持按业务部门分析服务消耗和流程绩效，从而突出特定部门的问题或趋势。获取方式此信息通常从“SRM:Request”表单上与“请求人”关联的用户个人资料中检索。示例财务销售人力资源信息技术
	解决分类 ResolutionCategory	用于解决请求的方案分类。
描述此属性提供了请求解决方式的结构化分类，例如“软件修复”、“用户培训”或“数据纠正”。它超越了简单的关闭代码，描述了解决办法的性质。这对于“解决分类准确性”仪表板至关重要，可以在其中将其与初始服务类型进行比较以检查一致性。分析解决类别有助于识别问题趋势并为主动问题管理提供信息，例如，如果许多请求是通过用户培训解决的。为何重要它提供了对解决方案性质的洞察，有助于识别重复性问题的趋势，以及主动问题管理或用户培训的机会。获取方式此信息是履行工单上操作和产品分类字段的一部分，通常标记为“解决类别”。示例账号管理硬件故障软件升级提供信息
	转派次数 HandoffCount	一个服务请求在不同坐席或团队之间重新分配的总次数。
描述此计算指标统计单个服务请求中“分配坐席”或“分配团队”更改的次数。交接次数过高可能表明流程碎片化、缺乏首次呼叫解决能力或路由低效。该属性是“每个请求的平均坐席交接次数”KPI 的基础，并用于“请求返工与重新分配”仪表板。分析交接次数较多的个案可以发现改进分流、提供更好培训或简化解决流程的机会，从而减少延迟并提升客户满意度。为何重要它衡量流程碎片化程度和沟通开销。高频率的交接通常与更长的解决时间和更低的流程效率相关。获取方式这是一个计算指标，通过计算每个唯一服务请求 ID 的“分配坐席”或“分配团队”属性中不同值的数量得出。示例 0135

必填推荐可选

服务请求管理活动

应在事件日志中捕获这些关键流程步骤和里程碑，以实现准确的流程挖掘和可视化。

6 推荐 8 可选

	活动	描述
	交付进行中	指定的坐席或团队已开始积极处理服务请求。这表明请求已从队列进入到活动的工作状态。
为何重要标志着增值交付工作的开始。分析在此阶段花费的时间有助于了解资源生产力和交付复杂度。获取方式根据 `SRM:Request` 表单状态变更为“In Progress”推断。捕获 SRM:Request“状态”字段更改为“处理中”的更新事件时间戳。事件类型 inferred
	服务请求已关闭	服务请求正式关闭并转入只读的存档状态。这发生在解决并度过确认期之后。
为何重要此活动代表流程的最终结束。“已解决”和“已关闭”之间的时间跨度可以突出关闭程序中的低效之处。获取方式根据 `SRM:Request` 表单中最终状态变更为“Closed”推断。捕获 SRM:Request“状态”字段更改为“已关闭”的更新事件时间戳。事件类型 inferred
	服务请求已取消	在履行完成前，申请人或服务台撤回了该服务请求。这是请求的终止状态。
为何重要追踪取消情况有助于识别模式（例如用户提交了错误的请求或不再需要某些服务），从而为改进服务目录提供依据。获取方式根据 `SRM:Request` 表单状态变更为“Canceled”推断。捕获 SRM:Request“状态”字段更改为“已取消”的更新事件时间戳。事件类型 inferred
	服务请求已提交	此活动标志着用户创建并提交了新的服务请求。当在 SRM:Request 表单中创建初始状态通常为“已提交”的新分录时，即捕获此活动。
为何重要这是每个服务请求个案的起点，对于衡量总生命周期持续时间和分析请求摄取量至关重要。获取方式此事件是根据 SRM:Request 表单中记录的创建时间戳和初始状态（例如“已提交”）推断出来的。捕获当状态为“Submitted”时，在 `SRM:Request` 表单中识别新服务请求 ID 的创建 timestamp。事件类型 inferred
	服务请求已解决	服务请求的履行已完成，且解决方案已传达给申请人。请求等待最终确认，或将在设定时间后自动关闭。
为何重要标志着服务交付周期结束的关键里程碑。它是衡量解决时间和 SLA 达标率的主要终点。获取方式根据 `SRM:Request` 表单状态变更为“Resolved”或“Completed”推断。捕获 SRM:Request“状态”字段更改为“已解决”或“已完成”的更新事件时间戳。事件类型 inferred
	请求已分配	服务请求已分配给负责完成工作的特定处理人员或团队。这标志着分流阶段的结束。
为何重要此里程碑对于衡量分流时间和分析坐席工作负载至关重要。频繁的重新分配可能表明路由问题或技能差距。获取方式此事件可以从 SRM:Request 或相关履行应用程序表单（例如 WOI:WorkOrder）上的“分配组”或“受派人”字段的审核日志中显式捕获。捕获审核日志中的时间戳，显示首次在“受派人”字段中设置非空值的时间。事件类型 explicit
	向用户索取信息	处理人员需要申请人提供额外信息才能继续工作。此时请求通常处于“挂起”状态。
为何重要此活动对于计算“外部信息等待时间”至关重要，有助于识别请求因信息不完整而停滞的频率。获取方式根据 `SRM:Request` 表单状态变更为“Pending”且状态原因为“Customer Hold”或“Awaiting Information”推断。捕获状态变更为“挂起”并结合特定状态原因的时间戳。事件类型 inferred
	方案已实施	技术人员已完成履行服务请求所需的技术工作。该请求现在可以由用户确认，然后正式解决。
为何重要此活动将技术完成与正式解决分开，有助于识别工作完成与用户确认之间的任何延迟。获取方式在父级 SRM:Request 标记为“已解决”之前，这可以从后端履行工单的状态变更（例如工作单状态变更为“已完成”）中推断出来。捕获与 SRM:Request 关联的后端工单（工作单、事件等）被标记为完成的时间戳。事件类型 inferred
	用户已确认解决方案	申请人已主动确认服务交付满意且请求已解决。这通常会触发请求的最终关闭。
为何重要提供客户满意度的明确指标，并正式结束服务交互。它将流程解决与客户验收环节区分开来。获取方式当用户通过门户或电子邮件确认时，此事件可能会记录在 SRM:Request 工作日志或活动备注中。它并不总是一个离散的状态。捕获扫描工作日志 (SRM:WorkInfo) 以查找指示用户确认或调查完成的特定条目。事件类型 explicit
	申请已批准	服务请求已获得相关方正式批准，履行流程得以继续。此事件通常紧随“待审批”状态之后。
为何重要标志着审批子流程的结束，是追踪审批耗时及其对整体解决时间影响的关键里程碑。获取方式根据 `SRM:Request` 表单中状态从“Waiting Approval”变更为随后的状态（如“Planning”或“In Progress”）推断。审批决定本身记录在相关的审批表单中。捕获在获得批准决定后，状态从“等待审批”迁出的时间戳。事件类型 inferred
	请求审核中	服务台正在对服务请求进行初步审查和分流，以确定其性质、优先级和适当的履行团队。这通常体现为请求记录中的状态变更。
为何重要追踪此活动有助于衡量分流效率，并识别从提交到分配之间的延迟，这对于“平均分流时间”KPI 至关重要。获取方式根据 `SRM:Request` 表单状态变更为“In Review”或“Planning”等值推断。捕获 SRM:Request“状态”字段更改为“审核中”的更新事件时间戳。事件类型 inferred
	请求已恢复	服务请求已脱离挂起或等待状态（通常在用户提供所需信息后）。处理人员恢复了该请求的工作。
为何重要标志着等待期的结束，从而能够精确衡量外部等待时间及其对 SLA 合规性的影响。获取方式当 `SRM:Request` 的状态从“Pending”变回“In Progress”时推断。捕获 SRM:Request“状态”字段从“挂起”更改为“处理中”的更新事件时间戳。事件类型 inferred
	请求已拒绝	服务请求在审批阶段被拒绝。这是一个终止状态，在履行开始前停止流程。
为何重要分析被拒绝的请求可以揭示请求理由、资格标准或审批政策中存在的问题。获取方式根据 `SRM:Request` 表单状态变更为“Rejected”推断。捕获 SRM:Request“状态”字段更改为“已拒绝”的更新事件时间戳。事件类型 inferred
	请求待审批	服务请求已提交给指定的审批人或审批组，在履行开始前需等待决定。这是涉及成本或访问权限的请求中的常见步骤。
为何重要此活动隔离了与审批相关的延迟，从而能够分析审批周期时间并识别审批链中的瓶颈。获取方式根据 `SRM:Request` 表单状态变更为“Waiting Approval”等值推断。捕获 SRM:Request“状态”字段更改为“等待审批”的更新事件时间戳。事件类型 inferred

推荐可选

提取指南

如何从 BMC Helix ITSM 获取数据

步骤

访问 Smart Reporting：登录您的 BMC Helix ITSM 环境。导航到报表部分并启动 Smart Reporting。根据版本不同，它可能被标记为“Reports”或“Smart Reporting”。
创建新报表：在 Smart Reporting 界面中，选择创建新报表的选项。类型选择“Report”。
选择 data 源和视图：系统将提示您选择 data 源。选择您的主 AR System data 源。在视图方面，搜索并选择“Service Request”视图，该视图通常基于 SRM:Request 表单。
添加额外表单（关联）：为了捕获全生命周期，必须将 SRM:Request 主表单与相关表单关联。使用“Data”选项卡并关联以下内容：
- SRM:WorkInfo（基于 SR ID+ = Request Number）以获取交付活动和工作日志详情。
- AP:Signature（基于 Request = SRInstanceID）以获取审批相关 event，如审批通过和拒绝。您可能需要为此创建自定义关联。
定义报表列：将所需字段从关联表单拖放到“Columns”区域。包括 SRM:Request 中的 Request Number、Submit Date、Status、Description、Priority、Assigned To 和 Assigned Group 等字段，以及来自关联表单的相关字段。
为活动创建计算字段：此方法的核心是创建一系列计算字段来表示每个活动的 timestamp。转到“Data”选项卡，为每个活动新建计算字段。例如：
- Submitted Timestamp：直接使用 Submit Date 字段。
- Approval Timestamp：使用 AP:Signature 表单中的 Signature Date。
- Work In Progress Timestamp：使用按 Request Number 分组的 SRM:WorkInfo 中的 MIN(Submit Date)。
为联合构建报表结构：Smart Reporting 没有像 SQL 那样的简单“UNION ALL”按钮。为此，您需要创建一个报表并使用高级函数或子查询来透视 data。常用技术是创建多个计算列，每列对应一个活动的 timestamp。随后，您需要在最终导出时对这些列进行格式化，将列转换为每个活动的单独行。
应用过滤器：为限制 data 范围并提高性能，请为报表添加过滤器。至少应按 SRM:Request 表单的 Submit Date 进行过滤以选择特定日期范围。如果是多租户环境，还需添加“Company”过滤器。
运行并预览 data：运行报表以确保 data 拉取正确。检查关联是否正确、列是否已填充，以及计算字段是否返回了预期的 timestamp。
导出报表：报表验证无误后导出 data。选择 CSV 或 Microsoft Excel 格式，这些格式便于导入 Process Mining 工具。
最终 data 转换：导出后，您必须将 data 从宽格式（每个服务请求一行，包含多个 timestamp 列）转换为长格式（每个活动一行）。使用脚本（如 Python、PowerShell）或 Excel Power Query 等工具，将 timestamp 列逆透视为两列：ActivityName 和 EventStartTime。这一步对于构建所需的 event log 结构至关重要。

配置

前提条件：您必须拥有 BMC Helix ITSM 的报表权限账号，特别是能够在 Smart Reporting 中创建和运行报表的权限。此外，您还需要具备读取 SRM:Request、SRM:WorkInfo 和 AP:Signature 表单 data 的权限。
核心表单：报表通过关联以下核心表单构建：
- SRM:Request：包含服务请求主要详情的主表单。
- SRM:WorkInfo：包含工作日志条目，用于获取交付活动详情。
- AP:Signature：包含审批记录，对于追踪审批相关活动至关重要。
日期范围过滤：请务必在 SRM:Request.Submit Date 字段上应用日期范围过滤器。建议选择 3 到 6 个月的 data 范围，以平衡样本代表性与报表性能。
重要过滤器：除日期范围外，还需按 Company 进行过滤，以隔离特定业务实体的 data。您可能还需要过滤掉与流程分析无关的特定请求类型或状态（如“Draft”）。
性能注意事项：跨大日期范围关联多个表单的报表生成速度可能较慢。对于大容量 data，强烈建议将报表安排在非高峰时段运行。如果出现超时，请考虑将提取任务拆分为按月进行的小块。

a 查询示例 config

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

步骤

前提条件：确保您拥有数据库客户端（如 DBeaver、SQL Server Management Studio 或 Oracle SQL Developer）以及 BMC Helix AR System 数据库的只读凭据。
连接数据库：使用数据库客户端建立与 AR System 数据库服务器的连接。
准备查询：将本文档“Query”部分提供的完整 SQL 查询复制到数据库客户端的查询编辑器中。
设置参数：在查询中找到占位符值。将 :start_date 和 :end_date 替换为您想要提取的日期范围（例如 '2023-01-01' 和 '2023-12-31'）。如果适用，将 :company_name 替换为您要过滤的特定公司名称。
执行查询：运行修改后的 SQL 查询。根据日期范围和系统规模，这可能需要几分钟时间。
查看结果：查询完成后，将显示包含 event log 的结果集。简要检查 data 以确保其填充正确，且包含预期的列和活动。
处理 timestamp：验证所有 timestamp 列（特别是 EventStartTime、EventEndTime 和 LastDataUpdate）是否格式一致，如 'YYYY-MM-DD HH:MI:SS'。如果数据库返回的格式不同，请相应调整查询中的 TO_CHAR 或 CONVERT 函数。
导出 data：使用数据库客户端的导出功能将完整结果集保存为 CSV 文件。选择 UTF-8 编码以确保兼容性。
准备上传：为文件命名，例如 servicerequest_eventlog.csv。现在即可将该文件上传至 ProcessMind 平台。

配置

数据库凭据：需要 AR System 数据库的只读用户账号。这可以防止意外修改 data 并符合安全最佳实践。
日期范围过滤：查询包含 :start_date 和 :end_date 占位符。为了管理查询性能和 data 量，设置一个具体且合理的日期范围（通常为 3 到 12 个月的 data）至关重要。过滤条件应用于服务请求的 Submit_Date。
公司过滤器：包含占位符 :company_name 以过滤特定运营公司的请求。如果您需要提取所有公司的 data，可以删除 AND req.Company = :company_name 这一行，或将其设置为通配符（如果支持）。
状态值：查询使用标准的 BMC Helix ITSM 状态整数值（例如：Submitted = 0，In Review = 1 等）。您的系统可能具有自定义状态或不同的整数映射。请根据系统的 SYS:Status 表单或 Developer Studio 验证这些值，并视情况调整查询中的 WHERE 子句。
性能建议：直接对 SRM_Request 及其审计日志等大表进行数据库查询可能会耗费大量资源。请将提取任务安排在非高峰时段，以尽量减少对系统性能的影响。

a 查询示例 sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

步骤

前提条件：确保系统中已安装 Python 3.6 或更高版本。在终端或命令提示符中运行 pip install requests 安装必要的 requests 库。
获取 API 凭据：在 BMC Helix ITSM 中创建或获取专用服务账号的凭据。该账号至少需要具有 SRM:Request 表单及其对应审计日志表单（通常名为 SRM:Request_AuditLog 或类似名称）的只读权限。记录您的用户名、密码以及 BMC Helix 实例的 base URL（例如 https://[your-company].bmc.com）。
配置 Python 脚本：将提供的 Python 脚本复制到文件中（例如 extract_servicerequests.py）。编辑脚本并填充顶部的占位符变量：BASE_URL、USERNAME、PASSWORD 和 AUDIT_FORM_NAME。调整 STATUS_ACTIVITY_MAP 字典，以匹配组织服务请求 workflow 中使用的特定状态值。
设置提取时段：修改脚本中的 START_DATE 和 END_DATE 变量。这将根据服务请求提交日期定义提取时间窗口。初步测试时，建议使用较小的日期范围（如一天）。
执行脚本：从终端运行命令 python extract_servicerequests.py。脚本将首先向 API 发起身份验证以获取 token。
初始 data 获取：脚本查询 SRM:Request 表单以检索在指定日期范围内创建的所有服务请求列表。此步骤将收集 case ID 以及优先级、服务类型等关联静态属性。
获取 event 历史记录：脚本迭代上一步获得的每个服务请求 ID。对于每个 ID，它会向配置的审计日志表单发起第二次 API 调用，以拉取该特定请求的状态变更详细历史记录。
将 data 转换为 event log：对于审计日志中的每条记录，脚本使用 STATUS_ACTIVITY_MAP 将状态变更映射为标准活动名称。它为每个映射的活动创建一行数据，包括服务请求 ID、活动名称以及变更 timestamp。
生成 Submitted event：脚本还会为每个请求创建初始的“Service Request Submitted”活动，使用来自 SRM:Request 主表单的 Submit Date。
导出为 CSV：处理完所有服务请求及其历史记录后，脚本会将生成的行合并到单个列表中，并写入名为 servicerequest_event_log.csv 的 CSV 文件。该文件已格式化完成，可直接上传至 Process Mining 工具。

配置

API 端点：脚本主要使用两个 API 端点。身份验证通过 api/jwt/login 处理。data 查询分别针对 arsys/v1/entry/SRM:Request（获取 case 列表）和 arsys/v1/entry/[AUDIT_FORM_NAME]（获取 event 历史记录）。
服务账号权限：需要一个具有 SRM:Request 表单和系统审计日志表单读取权限的专用服务账号。使用服务账号对于安全性和可追溯性至关重要。
日期范围过滤：脚本配置为根据 Submit Date 过滤服务请求。建议分批提取 data（例如每次 3-6 个月），以确保性能稳定。
状态到活动映射：脚本中的 STATUS_ACTIVITY_MAP 字典是转换逻辑的核心。必须根据您组织的自定义状态仔细配置，并将其映射到所需的活动名称。workflow 中未包含在映射表中的任何状态都将被忽略。
审计日志表单：脚本捕获详细活动的能力完全取决于可查询的审计日志。您必须在环境中找到存储服务请求状态变更历史的正确表单名称，并相应更新 AUDIT_FORM_NAME 变量。
分页处理：脚本自动处理 API 分页以检索所有记录。API 调用中的 limit 参数设置为每次请求检索 1000 条记录，以平衡性能和内存占用。

a 查询示例 python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

if __name__ == class="hl-string">"__main__":
    main()

您的服务请求管理数据模板

您的服务请求管理数据模板

服务请求管理属性

服务请求管理活动

提取指南

针对服务请求的 BMC Helix ITSM Smart Reporting

步骤

配置

a 查询示例 config

对 AR System 数据库表进行直接 SQL 查询

步骤

配置

a 查询示例 sql

通过 BMC Helix REST API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

准备好开始了吗？

释放效率：立即优化服务请求管理

您的服务请求管理数据模板

您的服务请求管理数据模板

服务请求管理属性

服务请求管理活动

提取指南

针对服务请求的 BMC Helix ITSM Smart Reporting

步骤

配置

a 查询示例 config

对 AR System 数据库表进行直接 SQL 查询

步骤

配置

a 查询示例 sql

通过 BMC Helix REST API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

释放效率：立即优化服务请求管理