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

服务请求管理数据模板

BMC Helix ITSM

← 返回改进指南

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

服务请求管理数据模板

此模板概述了服务请求管理流程需要收集的关键数据属性和需要跟踪的主要活动，并提供从BMC Helix ITSM高效提取数据的实用指南。借助此资源，您可以简化数据准备工作，并有把握地启动流程挖掘项目。

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

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

下载模板

服务请求管理属性

这些数据字段对于构建完整的事件日志至关重要，可用于深入分析您的服务请求管理流程。

5 必填 6 建议填写 9 选填

	名称	说明
	开始时间 EventStartTime	表示某项活动或事件开始时间的时间戳。
说明此属性记录活动开始的准确日期和时间。日志中的每个事件，从初始提交到最终关闭，都必须有开始时间，以确定流程的时间顺序。此时间戳对于所有基于时间的流程挖掘分析都至关重要。它用于计算周期时间、活动时长、步骤间等待时间以及SLA达成情况，帮助发现瓶颈并分析流程绩效随时间的变化。重要性开始时间确定了事件的先后顺序，是计算流程时长、发现延误和了解流程时间线的基础。获取途径对应于“SRM:Request”表单相关审计日志或状态历史表中的时间戳字段，例如初始事件的“Submit Date”。示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	服务请求ID ServiceRequestId	每个服务请求的唯一标识符，也是跟踪整个生命周期的主键。
说明服务请求ID用于唯一标识用户或系统提交的每个服务请求。它是串联后续所有事件的主线，从初始登记到最终关闭，支持对每个服务请求的完整端到端过程进行分析。在流程挖掘中，此ID对于重建每个案例的活动顺序至关重要。工具可据此将“提交服务请求”“请求已分派”和“服务请求已关闭”等相关事件归入同一个流程实例，为所有流程分析奠定基础。重要性这是基本的案例标识符。没有它，就无法追踪服务请求的端到端过程，也无法发现和分析流程。获取途径在BMC Helix ITSM的“SRM:Request”表单中，通常对应“InstanceId”或“Request Number”字段。示例 SR000010572931SR000010572932SR000010572933
	活动 ActivityName	服务请求生命周期中某个时间点发生的具体事件或任务的名称。
说明此属性描述服务请求流程中的具体步骤或状态变更，例如“请求审核中”“履行处理中”或“服务请求已解决”。每项活动都代表服务请求端到端过程中的一个事件。分析活动的顺序和频率是流程挖掘的核心。通过分析，您可以发现流程图、识别瓶颈并分析流程变体。了解发生了哪些活动、顺序如何以及发生频率，对于优化流程至关重要。重要性活动是流程图的基本组成部分。跟踪活动有助于可视化和分析流程，揭示工作的实际执行方式。获取途径通常根据“SRM:Request”表单中的“Status”和“Status Reason”字段，或相关履行应用日志（例如Incident、Work Order）中的变更推导得出。示例请求等待批准履行处理中服务请求已解决服务请求已关闭
	数据上次更新时间 LastDataUpdate	从源系统上次刷新此流程数据时的时间戳。
说明此属性表示最近一次从BMC Helix ITSM提取数据的日期和时间。它能让用户了解所分析数据的新旧程度，以及分析涵盖的时间范围。这是流程挖掘仪表板或分析中至关重要的元数据属性。它可以帮助用户判断洞察基于近实时数据还是历史快照，从而评估所得结论的有效性和相关性。重要性此属性能让用户了解数据的时效性，这对于根据当前可用的流程绩效信息做出决策至关重要。获取途径此时间戳在数据提取和加载过程中生成并添加。示例 2024-05-21T08:00:00Z
	源系统 SourceSystem	标识数据提取自哪个系统。
说明此属性用于标明流程数据的来源。在此视图中，该值固定为“BMC Helix ITSM”，表示所有服务请求相关事件均来自此系统。在集成多个系统的环境中，此字段对于了解数据沿袭和按来源划分数据至关重要。尤其是在合并不同平台的数据时，它有助于确保信息清晰且可追溯。重要性此属性提供数据来源背景，对于多系统环境中的数据治理、追溯和故障排查十分重要。获取途径这是在数据提取和转换过程中添加的固定值，并非BMC Helix ITSM本身的字段。示例 BMC Helix ITSM
	优先级 Priority	分配给服务请求的优先级，用于表示其业务影响和紧急程度。
说明优先级决定请求的处理顺序和速度。常见值包括“严重”“高”“中”和“低”。通常根据请求对业务的影响和紧急程度综合确定优先级。按优先级分析有助于评估高优先级请求是否比低优先级请求处理得更快。优先级也是处理时间和SLA合规仪表板中的关键维度，有助于确保资源合理分配给最紧要的业务需求。重要性此属性有助于评估流程是否正确安排工作优先级，以及不同业务影响级别的请求是否达到预期服务水平。获取途径这是“SRM:Request”表单中的“Priority”字段。示例严重高中低
	已分派代理 AssignedAgent	当前负责处理服务请求的个人用户。
说明此属性用于标识在特定时间负责处理请求的IT专员或支持人员。单个请求在整个生命周期中该字段发生变化，通常表示请求已转交或重新分配。此属性对于分析专员绩效和工作量至关重要。您可以据此跟踪每位专员处理的请求数量、平均解决时间和重新分配频率，为资源管理和培训机会识别提供依据。重要性跟踪负责处理请求的专员，有助于分析工作交接、衡量个人绩效，并了解支持团队的工作量分布。获取途径对应于与服务请求关联的履行记录（例如工单、事件）中的“Assignee”或“Assigned To”字段。示例 Bob SmithAlice JohnsonCharlie Brown
	服务类型 ServiceType	用户申请的服务类别或类型。
说明服务类型用于对请求性质进行分类，例如“申请新软件”“重置密码”或“新员工入职”。这是筛选和细分流程数据的基本维度。在流程分析中，此属性用于比较不同类型请求的处理绩效，帮助回答“哪些服务类型处理时间最长？”或“哪些服务类型返工最多？”等问题。它对于处理时间和SLA合规仪表板至关重要。重要性此属性可用于细分服务请求、比较流程、发现特定类型的问题，并有针对性地开展优化。获取途径此数据通常位于“SRM:Request”表单的“Title”字段或分类字段中，根据服务目录中所选的服务生成。示例新硬件申请软件访问权限申请VPN访问配置
	结束时间 EventEndTime	表示某项活动或事件完成时间的时间戳。
说明结束时间标志着活动完成。ITSM系统中的许多活动是即时状态变更，但有些活动会持续一段时间。记录结束时间可以准确计算这类活动的时长。分析时，结束时间与开始时间结合使用，用于计算各项活动的处理时间。这有助于定位流程中具体哪些任务耗时最多，而不仅仅是步骤之间的等待时间。重要性此属性可用于计算活动处理时间，对于发现低效步骤和了解资源耗时所在至关重要。获取途径此值可以推导得出。对于同一案例，某项活动的结束时间通常就是下一项顺序活动的开始时间。对于最后一项活动，则使用解决或关闭时间戳。示例 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	请求状态 RequestStatus	事件发生时服务请求的状态，例如“处理中”“待处理”或“已关闭”。
说明此属性记录服务请求在生命周期不同阶段的状态，为每项活动提供背景信息，也常用于推导“活动”属性。按状态分析有助于了解请求在“等待客户”或“等待审批”等状态下花费的时间。这对于发现外部依赖或内部队列造成的瓶颈和延误至关重要，也能直接支持瓶颈识别仪表板。重要性此属性呈现请求在特定时点的状态，便于分析请求处于等待状态和主动处理状态的时长，是识别瓶颈的关键。获取途径这是“SRM:Request”表单中的“Status”字段。历史值可在审计日志中查找。示例规划中处理中待处理已解决已关闭
	负责团队 AssignedTeam	当前负责处理服务请求的支持组或团队。
说明此属性用于标识负责处理请求的职能组，例如“服务台”“网络团队”或“数据库管理”。该字段发生变化，表示请求的处理责任已转交给其他团队。按负责团队分析，有助于发现团队层面的瓶颈、分析团队间的交接情况，并评估不同支持组的效率。此属性是“请求返工与重新分配”和“分流效率”仪表板的关键数据，可揭示工作在组织内的流转方式。重要性此属性有助于分析不同职能组之间的流程，发现路由效率问题并衡量团队绩效。获取途径对应于与服务请求关联的履行记录（例如工单、事件）中的“Assigned Group”字段。示例服务台基础设施支持二线应用支持
	SLA目标日期 SlaTargetDate	根据服务级别协议（SLA），预期完成服务请求解决的日期和时间。
说明 SLA目标日期是一个计算得出的时间戳，表示完成服务请求的截止时间。该日期由服务协议规则确定，通常会考虑请求的优先级和类型等因素。此属性是“SLA合规概览”仪表板的基础数据，可作为衡量实际解决时间的基准。将最终解决活动的“EventEndTime”与目标日期进行比较，即可判断是否履行了服务承诺。重要性此属性是衡量服务绩效是否达到承诺的主要基准，对于SLA合规监控和报告至关重要。获取途径此日期由服务级别管理（SLM）模块计算并存储，可在与服务请求关联的SLM表单中找到。示例 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	交接次数 HandoffCount	服务请求在不同专员或团队之间重新分配的总次数。
说明此计算指标统计单个服务请求的“AssignedAgent”或“AssignedTeam”发生变化的次数。交接次数过多可能意味着流程分散、首次联系未能解决问题，或路由效率低下。此属性是“每个请求的平均专员交接次数”KPI的计算依据，也用于“请求返工与重新分配”仪表板。分析交接次数较多的案例，有助于发现改进分流、加强培训或简化解决流程的机会，从而减少延误并提升客户满意度。重要性此属性用于衡量流程分散程度和沟通成本。交接次数较多通常与解决时间较长、流程效率较低有关。获取途径此计算指标根据每个唯一服务请求ID对应的“AssignedAgent”或“AssignedTeam”属性中的不同值数量得出。示例 0135
	关闭代码 CloseCode	用于说明服务请求最终结果或关闭原因的代码。
说明关闭代码为服务请求的解决结果提供标准化分类，例如“由服务台解决”“用户取消”或“重复请求”。分析关闭代码有助于了解请求的常见结果。例如，用户取消的请求数量较多，可能意味着流程耗时过长；重复请求较多，则可能反映系统或沟通方面的问题。此属性支持“解决类别准确性”仪表板。重要性此属性以结构化数据记录请求结果，便于分析解决成效，以及请求未完成或被取消的原因。获取途径此信息通常位于与服务请求关联的履行工单中的“Resolution”或“Closure Code”字段。示例已成功用户取消不再需要自动解决
	提交渠道 SubmissionChannel	提交服务请求所使用的方式或渠道。
说明此属性记录服务请求的发起方式，例如通过自助服务门户、电子邮件、致电服务台或自动系统警报提交。不同渠道可能对应不同的流程变体和解决时间。按提交渠道分析流程，有助于发现特定受理方式中的低效环节或最佳实践。例如，通过自助服务门户提交的请求，初始数据质量可能更高，因此解决速度更快；电子邮件提交的请求则可能需要更多人工分流。重要性此属性有助于了解受理方式如何影响流程效率、数据质量和整体周期时间，从而针对特定渠道采取改进措施。获取途径通常可根据“SRM:Request”表单或关联履行工单中的“Client Type”或“Reported Source”等字段推断。示例自助服务门户电子邮件电话系统生成
	是否已升级 IsEscalated	用于标记服务请求是否已升级的布尔值。
说明如果服务请求经过职能升级或层级升级，此标记将设为true。请求进展不如预期、即将违反SLA，或需要更高层级的审批或处理时，通常会进行升级。此属性是“请求升级效率分析”仪表板的关键数据。您可以筛选并分析已升级请求的流程路径，了解触发升级的原因、升级后解决所需的时间，以及升级流程的成效。重要性此属性可筛选并分析需要升级的请求，帮助您发现标准流程中的薄弱环节，或复杂问题的触发因素。获取途径此属性通常并非来自单一字段，而是通过检查审计日志中的特定升级活动，或检查是否存在符合升级规则的优先级或负责人变更来推导。示例 truefalse
	是否返工 IsRework	用于标记服务请求是否经历返工（例如退回到之前阶段）的布尔值。
说明此标记用于识别流程中出现循环或返工的服务请求。例如，请求从“履行处理中”退回到“请求审核中”，即可视为返工。具体定义取决于业务流程逻辑。此属性直接支持“请求返工与重新分配分析”仪表板和“请求返工率”KPI。您可以据此量化返工频率并分析常见原因，例如初始评估有误或信息不完整，从而发现流程低效之处。重要性此属性通过标记偏离“理想路径”的案例来量化流程低效情况，帮助您查找流程循环和重复工作的根本原因。获取途径此属性根据事件日志中的活动顺序计算得出，需要通过逻辑判断流程是否出现回退。示例 truefalse
	是否违反SLA IsSlaBreached	用于标记服务请求是否在SLA目标日期之后才解决的布尔值。
说明如果服务请求的最终解决时间戳晚于“SLA目标日期”，此计算标记将设为true。它以简单的二元结果记录每个请求的SLA绩效。此属性是“SLA合规概览”仪表板和“SLA达标率”KPI的重要数据。您可以汇总此属性，轻松计算整体达标率；也可以筛选并比较违反SLA与符合SLA的请求的流程特征，从而查找SLA未达标的根本原因。重要性此属性将时间戳比较结果转换为简单的布尔值，简化SLA绩效分析，便于衡量和展示合规率。获取途径这是一个计算字段，逻辑为：IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false。示例 truefalse
	解决类别 ResolutionCategory	用于对解决请求所采用的方案进行分类。
说明此属性以结构化方式记录请求的解决方式，例如“软件修复”“用户培训”或“数据更正”。与简单的关闭代码相比，它能更具体地说明解决方案的性质。此属性是“解决类别准确性”仪表板的重要数据，可与最初的服务类型进行比较，以检查分类是否一致。分析解决类别有助于识别问题趋势，并为主动问题管理提供依据。例如，若许多请求通过用户培训解决，便可据此采取相应措施。重要性此属性有助于了解解决方案的性质，识别重复问题的趋势，以及主动管理问题或开展用户培训的机会。获取途径此信息属于履行工单中的运营和产品分类字段，字段名称通常为“Resolution Category”。示例账户管理硬件故障软件升级信息已提供
	请求人部门 RequestorDepartment	提交请求的用户所属业务部门或单位。
说明此属性用于标识服务请求人的组织部门，例如“财务”“人力资源”或“IT”。此信息通常来自系统中的用户档案。按部门细分流程分析，有助于识别各部门的需求、请求模式，以及有针对性的培训或服务改进机会。您可以借此了解“财务部门的请求是否等待时间更长？”等问题。重要性此属性支持按业务单元分析服务使用情况和流程绩效，有助于发现部门特有的问题或趋势。获取途径此信息通常从“SRM:Request”表单中“Requested For”用户的关联档案获取。示例财务销售人力资源信息技术

必填建议填写选填

服务请求管理活动

为准确发现和可视化流程，请在事件日志中记录这些关键步骤和里程碑。

6 建议填写 8 选填

	活动	说明
	履行处理中	已分派的代理或团队开始实际处理服务请求，表明请求已从队列进入主动处理状态。
重要性此节点标志着创造价值的履行工作开始。分析此阶段的耗时，有助于了解资源生产率和履行工作的复杂程度。获取途径根据SRM:Request表单中的状态变更推断，状态变为“In Progress”时即表示开始处理。采集 SRM:Request的“Status”字段变为“In Progress”时，对应更新事件的时间戳。事件类型 inferred
	提交服务请求	此活动表示用户创建并提交新的服务请求。当SRM:Request表单中创建一条初始状态通常为“Submitted”的新记录时，即可记录此活动。
重要性这是每个服务请求案例的起点，对于衡量整个生命周期时长和分析请求量至关重要。获取途径根据SRM:Request表单记录的创建时间戳和初始状态（例如“Submitted”）推断此事件。采集在SRM:Request表单中，找到状态为“Submitted”的新服务请求ID及其创建时间戳。事件类型 inferred
	服务请求已关闭	服务请求已正式关闭，并转为只读归档状态。此操作发生在请求解决且确认期结束之后。
重要性此活动代表流程的最终结束。“Resolved”到“Closed”之间的耗时可揭示关闭流程中的低效之处。获取途径根据SRM:Request表单中的最终状态变更推断，状态变为“Closed”时即表示请求已关闭。采集 SRM:Request的“Status”字段变为“Closed”时，对应更新事件的时间戳。事件类型 inferred
	服务请求已取消	履行完成前，请求人或服务台撤回了服务请求。这是请求的终止状态。
重要性跟踪取消情况有助于发现相关规律，例如用户提交了错误请求或不再需要相关服务，从而为改进服务目录提供依据。获取途径根据SRM:Request表单中的状态变更推断，状态变为“Canceled”时即表示请求已取消。采集 SRM:Request的“Status”字段变为“Canceled”时，对应更新事件的时间戳。事件类型 inferred
	服务请求已解决	服务请求已完成履行，解决结果也已告知请求人。请求等待最终确认，或将在设定期限后自动关闭。
重要性此关键节点标志着服务交付周期结束，是衡量处理时间和SLA达成率的主要终点。获取途径根据SRM:Request表单中的状态变更推断，状态变为“Resolved”或“Completed”时即表示请求已解决。采集 SRM:Request的“Status”字段变为“Resolved”或“Completed”时，对应更新事件的时间戳。事件类型 inferred
	请求已分派	服务请求已分派给负责完成工作的具体履行代理或团队。这标志着分流阶段结束。
重要性此节点对于衡量分流时间和分析代理工作量至关重要。频繁重新分派可能表明路由存在问题或技能不足。获取途径可以直接从SRM:Request或相关履行应用表单（例如WOI:WorkOrder）中“Assigned Group”或“Assignee”字段的审计日志记录此事件。采集审计日志中首次为“Assignee”字段设置非空值时的时间戳。事件类型 explicit
	向用户索取信息	履行代理需要请求人提供更多信息才能继续处理。此时请求通常会进入“Pending”状态。
重要性此活动对于计算“外部信息等待时间”至关重要，可用于了解请求因信息不完整而停滞的频率。获取途径根据SRM:Request表单中的状态变更推断：状态变为“Pending”，且状态原因是“Customer Hold”或“Awaiting Information”等。采集状态变为“Pending”并同时设置特定状态原因时的时间戳。事件类型 inferred
	用户确认解决结果	请求人主动确认服务已妥善交付且请求已解决。这通常会触发请求的最终关闭。
重要性此活动清晰反映客户满意度，并正式结束服务交互。它将流程解决与客户接受结果区分开来。获取途径用户通过门户或电子邮件确认后，相关事件可能记录在SRM:Request工作日志或活动备注中，但不一定对应单独的状态。采集检查工作日志（SRM:WorkInfo），查找表明用户已确认或已完成调查的具体记录。事件类型 explicit
	解决方案已实施	代理已完成履行服务请求所需的技术工作。正式解决请求前，还需请用户确认。
重要性此活动将技术工作完成与正式解决区分开来，有助于发现工作完成后到用户确认前的延误。获取途径可以根据后端履行工单的状态变更推断此活动，例如在上级SRM:Request标记为“Resolved”之前，工单状态已变为“Completed”。采集与SRM:Request关联的后端工单（Work Order、Incident等）标记为完成时的时间戳。事件类型 inferred
	请求审核中	服务台正在对服务请求进行初步审核和分流，以确定请求性质、优先级及适当的履行团队。通常可通过请求记录中的状态变更识别此活动。
重要性跟踪此活动有助于衡量分流效率，并发现提交到分派之间的延误。这对于计算“平均分流时间”KPI至关重要。获取途径根据SRM:Request表单中的状态变更推断，例如状态变为“In Review”或“Planning”。采集 SRM:Request的“Status”字段变为“In Review”时，对应更新事件的时间戳。事件类型 inferred
	请求已批准	服务请求已由所需审批方正式批准，可以继续履行流程。此事件通常发生在状态为“Waiting for Approval”之后。
重要性此事件标志着审批子流程结束，是跟踪审批耗时及其对整体处理时间影响的重要节点。获取途径根据SRM:Request表单中的状态变更推断：状态从“Waiting Approval”变为“Planning”或“In Progress”等后续状态。审批决定本身记录在相关审批表单中。采集审批通过后，状态从“Waiting Approval”变更时的时间戳。事件类型 inferred
	请求已拒绝	服务请求在审批阶段被拒绝。这是终止状态，流程会在履行开始前停止。
重要性分析被拒绝的请求，有助于发现请求理由、资格标准或审批政策方面的问题。获取途径根据SRM:Request表单中的状态变更推断，状态变为“Rejected”时即表示请求已拒绝。采集 SRM:Request的“Status”字段变为“Rejected”时，对应更新事件的时间戳。事件类型 inferred
	请求恢复处理	服务请求已退出待处理或等待状态，通常是因为用户已提供所需信息。履行代理恢复处理请求。
重要性此节点标志着等待期结束，可用于准确衡量外部等待时间及其对SLA达成率的影响。获取途径 SRM:Request的状态从“Pending”变回“In Progress”时，即可推断此事件。采集 SRM:Request的“Status”字段从“Pending”变为“In Progress”时，对应更新事件的时间戳。事件类型 inferred
	请求等待批准	服务请求已提交给指定审批人或审批组，等待其决定后才能开始履行。涉及费用或访问权限的请求通常需要经过此步骤。
重要性此活动可单独呈现审批相关的延误，便于分析审批周期时间并定位审批链中的瓶颈。获取途径根据SRM:Request表单中的状态变更推断，例如状态变为“Waiting Approval”。采集 SRM:Request的“Status”字段变为“Waiting Approval”时，对应更新事件的时间戳。事件类型 inferred

建议填写选填

数据提取指南

如何从BMC Helix ITSM获取数据

步骤

访问智能报表：登录BMC Helix ITSM环境。进入报表部分并启动智能报表。根据版本不同，该功能可能标记为“报表”或“智能报表”。
创建新报表：进入智能报表界面后，选择创建新报表，并将类型设为“报表”。
选择数据源和视图：系统会提示您选择数据源。选择主要的AR System数据源。在视图中搜索并选择服务请求视图，该视图通常基于SRM:Request表单。
添加其他表单（联接）：要覆盖完整生命周期，需将主表单SRM:Request与相关表单联接。使用“数据”选项卡进行联接：
- SRM:WorkInfo（按SR ID+=Request Number联接），获取请求处理活动和工作日志详情。
- AP:Signature（按Request=SRInstanceID联接），获取审批和拒绝等审批相关事件。您可能需要自定义联接。
定义报表列：将联接表单中的所需字段拖放到“列”区域。其中包括SRM:Request中的Request Number、Submit Date、状态、说明、Priority、Assigned To和Assigned Group，以及联接表单中的相关字段。
为活动创建计算字段：此方法的核心是创建一系列计算字段，以表示各项活动的时间戳。进入“数据”选项卡，为每项活动创建一个计算字段。例如：
- 提交时间戳：直接使用Submit Date字段。
- 审批时间戳：使用AP:Signature表单中的Signature Date。
- 处理中时间戳：使用SRM:WorkInfo中按Request Number分组的MIN(Submit Date)。
整理报表以合并数据：Smart Reporting没有类似SQL的简单“UNION ALL”按钮。要实现这一点，您需要创建单个报表，并使用高级函数或子查询转换数据。常见做法是为每项活动的时间戳创建多个计算列，然后在最终导出时，将这些列转换为每项活动各占一行的格式。
应用筛选器：为限制数据范围并提升性能，请为报表添加筛选器。至少应按SRM:Request表单中的Submit Date筛选特定日期范围。如果您使用多租户环境，也请按“Company”筛选。
运行并预览数据：运行报表，确认数据提取正确。检查联接是否正确、列是否已填充，以及计算字段是否返回预期的时间戳。
导出报表：验证报表后，导出数据。选择CSV或Microsoft Excel格式，便于后续处理并导入流程挖掘工具。
转换最终数据：导出后，需将宽格式数据（每个服务请求一行，包含多个时间戳列）转换为长格式数据（每项活动一行）。使用脚本（如Python、PowerShell）或Excel Power Query等工具，将时间戳列取消透视为两列：ActivityName和EventStartTime。此步骤对于构建所需的事件日志结构至关重要。

配置

前提条件：您需要拥有BMC Helix ITSM报表权限的用户账号，具体来说，需要能够在Smart Reporting中创建和运行报表。您还需要读取SRM:Request、SRM:WorkInfo和AP:Signature表单数据的权限。
关键表单：报表通过关联以下核心表单构建：
- SRM:Request：包含服务请求主要详情的主表单。
- SRM:WorkInfo：包含工作日志条目，用于推导履行活动。
- AP:Signature：包含审批记录，是跟踪审批相关活动的必要数据。
日期范围筛选：始终根据SRM:Request.Submit Date字段设置日期范围筛选。建议使用3至6个月的数据，在获取有代表性的样本与报表性能之间取得平衡。
重要筛选条件：除日期范围外，还应按Company筛选，以便单独查看特定业务实体的数据。您也可以排除与流程分析无关的特定请求类型或状态，例如“草稿”。
性能注意事项：跨较长日期范围关联多个表单的报表可能生成缓慢。数据量较大时，强烈建议安排在非高峰时段运行。如果发生超时，可考虑按月分批提取数据。

查询示例 sql

/*
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数据库服务器。
准备查询：将本文档“查询”部分提供的完整SQL查询复制到数据库客户端的查询编辑器中。
设置参数：找到查询中的占位值。将:start_date和:end_date替换为所需的数据提取日期范围，例如2023-01-01和2023-12-31。如需筛选特定公司，请将:company_name替换为相应公司名称。
执行查询：运行修改后的SQL查询。根据日期范围和系统规模，查询可能需要几分钟才能完成。
检查结果：查询完成后，系统会显示包含事件日志的结果集。请简要检查数据是否已正确填充，并包含预期的列和活动。
处理时间戳：确认所有时间戳列，尤其是EventStartTime、EventEndTime和LastDataUpdate，均采用一致的格式，例如YYYY-MM-DD HH:MI:SS。如果数据库返回的格式不同，请相应调整查询中的TO_CHAR或CONVERT函数。
导出数据：使用数据库客户端的导出功能，将完整结果集保存为CSV文件。请选择UTF-8编码以确保兼容性。
准备上传：为文件命名，例如servicerequest_eventlog.csv。现在即可将此文件上传到ProcessMind平台。

配置

数据库凭据：需要用于AR System数据库的只读用户账号，以防止意外修改数据，并遵循安全最佳实践。
日期范围筛选：查询中包含:start_date和:end_date占位符。请务必设置明确且合理的日期范围，通常为3至12个月的数据，以控制查询性能和数据量。筛选条件应用于服务请求的Submit_Date字段。
公司筛选：查询中包含:company_name占位符，用于筛选特定运营公司的请求。如需提取所有公司的数据，可删除AND req.Company = :company_name这一行，或在系统支持时将其设为通配符。
状态值：查询使用BMC Helix ITSM的标准状态整数值（例如，已提交=0，审核中=1等）。您的系统可能使用自定义状态或不同的整数映射。请在系统的SYS:Status表单或Developer Studio中核实这些值，并根据需要调整查询中的WHERE子句。
性能：直接查询SRM_Request等大型表及其审计日志可能占用大量资源。请安排在非高峰时段提取数据，以尽量减少对系统性能的影响。

查询示例 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，安装用于发起HTTP API调用的requests库。
获取API凭据：在BMC Helix ITSM中创建或获取专用服务账号的凭据。该账号至少需要对SRM:Request表单及对应审计日志表单（通常命名为SRM:Request_AuditLog或类似名称）拥有只读权限。记录用户名、密码以及BMC Helix实例的基础URL（例如https://[your-company].bmc.com）。
配置Python脚本：将提供的Python脚本复制到文件中，例如extract_servicerequests.py。编辑脚本，填写顶部的占位变量：BASE_URL、USERNAME、PASSWORD和AUDIT_FORM_NAME。调整STATUS_ACTIVITY_MAP字典，使其与您所在组织服务请求工作流使用的具体状态值相符。
设置提取时间段：修改脚本中的START_DATE和END_DATE变量，以定义根据服务请求提交日期提取数据的时间范围。首次测试时，请使用较短的时间范围，例如一天。
运行脚本：在终端中运行命令python extract_servicerequests.py。脚本会先通过API进行身份验证并获取令牌。
首次获取数据：脚本会查询SRM:Request表单，获取指定日期范围内创建的所有服务请求。此步骤会收集案例ID以及优先级、服务类型等相关静态属性。
获取事件历史记录：脚本会遍历上一步获取的每个服务请求ID，并针对每个ID调用配置的审计日志表单，提取该请求的详细状态变更历史。
将数据转换为事件日志：对于审计日志中的每条记录，脚本会使用STATUS_ACTIVITY_MAP将状态变更映射为标准活动名称，并为每项映射活动创建一行数据，其中包括服务请求ID、活动名称和变更时间戳。
生成提交事件：脚本还会为每个请求创建初始的“服务请求已提交”活动，并使用主SRM:Request表单中的Submit Date作为时间戳。
导出为CSV：处理完所有服务请求及其历史记录后，脚本会将生成的数据行汇总到一个列表中，并写入名为servicerequest_event_log.csv的CSV文件。该文件已完成格式整理，可上传到流程挖掘工具。

配置

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

查询示例 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()

准备好开始了吗？

使用此模板简化数据收集，稳步开启流程挖掘之旅。立即开始优化服务请求管理！

返回改进指南

下载模板

提升效率：立即优化服务请求管理

实现70%的自动化，消除处理延迟，让用户满意。

开始免费试用

无需信用卡，几分钟即可开始。

服务请求管理数据模板

服务请求管理数据模板

服务请求管理属性

服务请求管理活动

数据提取指南

BMC Helix ITSM服务请求智能报表

步骤

配置

查询示例 sql

直接查询AR System数据库表

步骤

配置

查询示例 sql

通过BMC Helix REST API使用Python脚本提取数据

步骤

配置

查询示例 python

准备好开始了吗？

提升效率：立即优化服务请求管理