> 持续流程改进 > 服务请求管理 > Jira Service Management > 数据模板

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

Jira Service Management

← 返回改进指南

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

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

此模板提供了一种结构化方法，用于收集分析服务请求流程所需的核心数据。它概述了要收集的关键属性、要追踪的核心活动，并提供了如何从系统中提取这些信息的指导。利用此资源简化您的数据准备工作，并获得对业务运营的更深层次见解。

全面分析的推荐属性
用于流程发现的关键跟踪活动
Jira Service Management数据导出指引

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

下载模板

服务请求管理属性

这些是推荐包含在事件日志中的数据字段，用于全面的服务请求管理分析。

5 必填 5 推荐 10 可选

	名称	描述
	开始时间 EventTime	特定活动或事件发生的精确日期和时间。
描述开始时间或事件时间戳（timestamp）记录了活动发生的准确时刻。这是任何 Process Mining 分析的关键组成部分，因为它为整个流程提供了时间维度上的上下文。此时间戳用于按顺序排列事件、计算活动间的时长、衡量 case 总周期时间，并根据 SLA 等时间目标分析流程绩效。如果没有准确的时间戳，就无法理解流程流向、识别延迟或衡量效率。为何重要此时间戳（timestamp）对于排列事件顺序、计算时长和周期时间以及识别流程瓶颈至关重要。获取方式这是与 Jira 问题变更日志中每个状态转换关联的时间戳（timestamp）。问题创建时间是“创建”字段。示例 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	服务请求 ID ServiceRequestId	每个服务请求的唯一标识符，作为所有相关事件的主键。
描述服务请求 ID（在 Jira 中通常称为 Issue Key）唯一标识由用户或系统提交的每个服务请求。它是连接所有后续事件的核心主线，从初始登记到最终关闭，支持对每个服务请求的旅程进行完整的端到端分析。在 Process Mining 中，此 ID 对于 case 关联至关重要。它确保每个活动、状态变更和时间戳（timestamp）都能准确关联到所属的特定请求，从而形成连贯的流程实例用于分析。为何重要此 ID 是基础的 case 标识符，它将所有相关活动连接成一个完整的端到端流程流，从而使流程分析成为可能。获取方式这是 Jira Service Management 中问题的“key”字段。示例 SR-2023-001IT-45892HELP-105
	活动 ActivityName	服务请求生命周期中发生的特定事件或任务的名称。
描述此属性描述了服务请求在某一时间点发生的具体操作或状态转换。示例包括“请求已创建”、“请求已分派”、“解决方案已实施”和“请求已关闭”。分析这些活动的顺序和频率是 Process Mining 的核心。它支持流程图的可视化、瓶颈识别以及对标准工作流偏差的检测，这对于理解流程效率和合规性至关重要。为何重要它定义了流程中的步骤，从而实现流程图的可视化，并支持对 Workflow 模式和偏差的分析。获取方式通常源自 Jira 问题的“状态”转换历史记录。问题变更日志中状态字段的每个条目都代表一项活动。示例请求已分拨信息已请求方案已实施服务请求已关闭
	最后数据更新 LastDataUpdate	指示源系统数据上次刷新时间的时间戳。
描述此属性记录了从 Jira Service Management 进行最近一次数据提取的日期和时间。它为分析的时效性以及仪表板和 KPI 中包含的数据提供了关键背景。在任何分析中，了解数据的实时性对于做出明智决策都至关重要。此时间戳（timestamp）有助于用户了解他们看到的是实时信息还是过去某一时间点的快照，这会影响发现结果的相关性。为何重要指示 data 的新鲜度，确保分析基于最新信息。获取方式这是由数据提取工具或脚本在运行结束时生成并存储的元数据字段。示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	源系统 SourceSystem	提取服务请求数据的源系统。
描述此属性标识了数据的来源，在本例中为 Jira Service Management。虽然在分析单一来源的数据时这似乎微不足道，但在合并来自多个系统的流程数据时，它就变得至关重要。在分析中，它有助于追踪数据血缘并确保数据质量。它还支持对可能跨越或与不同软件平台交互的流程进行过滤和比较。为何重要识别 data 来源，这对于数据治理以及合并来自多个企业系统的流程 data 至关重要。获取方式这通常是在 data 提取和 transformation 过程中添加的静态值，用于标记 dataset 的来源。示例 Jira Service ManagementJiraSM
	SLA 到期日期 SlaDueDate	根据 SLA 规定，服务请求应被解决的目标日期和时间。
描述 SLA 截止日期是一个计算得出的时间戳（timestamp），代表解决请求的期限。它由请求的优先级、类型以及 Jira Service Management 中配置的特定服务级别协议 (SLA) 政策决定。此属性是“服务请求 SLA 绩效”仪表板和“SLA 达成率”KPI 的基础。通过将实际解决时间与此截止日期进行对比，系统可以确定每个请求是按时完成、延迟完成，还是存在违反 SLA 的风险。为何重要这是衡量绩效的基准。它直接支持 SLA 合规性的计算，并有助于确定工作的优先级。获取方式 SLA 信息由 Jira Service Management 管理，可通过 API 访问，通常存储在动态更新的自定义字段中。示例 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	受理人 Assignee	当前被指派处理该服务请求的用户或代理。
描述经办人是负责下一步操作或解决服务请求的个人。在请求的生命周期中，随着请求在不同代理或团队之间交接，该属性的值可能会多次更改。此属性对于工作负载分析、绩效衡量和资源管理至关重要。它支持按代理过滤流程，比较个人间的解决时间，并识别可能导致瓶颈的培训需求或工作负载不平衡。为何重要此属性对于分析代理工作负载、衡量个人绩效以及了解资源分配至关重要。获取方式这对应于 Jira 问题上的“经办人”字段。示例爱丽丝·约翰逊鲍勃·威廉姆斯未分配
	请求优先级 RequestPriority	分配给服务请求的优先级，如低、中、高或紧急。
描述请求优先级反映了服务请求的紧急程度和业务影响。此分类决定了处理请求的顺序，并通常规定了目标解决时间和 SLA。在流程分析中，优先级是细分流程的关键维度。通过对比不同优先级水平的周期时间（cycle times）和 SLA 达成率，可以确保高优先级请求确实得到了更快的处理并达标。这有助于验证优先级排序系统的有效性。为何重要支持分层分析，确保高优先级请求得到更快速处理，并满足更严格的服务水平。获取方式这对应于 Jira 问题上的“优先级”字段。示例最高高中低
	请求状态 RequestStatus	服务请求在其生命周期中的当前状态。
描述此属性代表服务请求的当前状态，例如“开启”、“处理中”、“等待客户”或“已解决”。它提供了请求在任何给定时间的快照。虽然活动日志提供了历史流向，但当前状态对于分析待办工作量和识别停滞项非常有用。例如，分析可以集中在处于“等待供应商”状态时间异常长的请求上，从而突出外部依赖和延迟。为何重要提供每个 case 的当前快照，支持对在办工作的分析，并识别停滞或陈旧的请求。获取方式这是 Jira 问题上的“状态”字段。示例未结进行中等待客户已解决
	请求类型 RequestType	服务请求的分类，例如“访问请求”或“硬件问题”。
描述请求类型根据其性质对服务请求进行分类。这是分析的基础维度，因为不同类型的请求通常具有不同的解决流程、SLA 和资源需求。通过按请求类型细分流程分析，组织可以针对特定工作流进行优化。例如，“密码重置”请求的瓶颈与“新服务器配置”请求的瓶颈截然不同。此属性对于构建“按类别划分的解决质量”等仪表板至关重要。为何重要此属性对于跨不同类别的服务请求比较流程、工作负载和绩效至关重要。获取方式这通常对应于 Jira 中的“问题类型”字段或 Jira Service Management 中的自定义“请求类型”字段。示例申请新账号获取 IT 帮助新员工入职
	SLA 状态 SlaState	指示服务请求是达成、违反还是处于既定的 SLA 范围内。
描述 SLA 状态是一个计算属性，根据服务请求在 SLA 截止日期前的表现对其进行分类。可能的值包括“已达标”、“已违规”或“进行中”。它通过对比解决时间戳（timestamp）与“SlaDueDate”来确定。这是“服务请求 SLA 绩效”仪表板的核心属性，用于计算“SLA 达成率”KPI。它提供清晰直观的服务级别合规视图，对于报表统计、合同管理和维护服务质量至关重要。为何重要提供 SLA 绩效的清晰且即时的指标，这是衡量服务质量和合同合规性的关键标准。获取方式在数据转换期间计算。如果解决时间早于 `SlaDueDate`，则状态为“已达成”；否则为“已违规”。示例已达成已超期进行中
	个案周期时间 (Case Cycle Time) CaseCycleTime	从服务请求创建到最终关闭所经历的总时长。
描述个案周期时间（Case Cycle Time）是一个衡量服务请求生命周期总时长的计算指标。它通常计算为“服务请求已关闭” timestamp 与“服务请求已创建” timestamp 之间的差值。这是 Process Mining 中最重要的 KPI 之一，直接支持“平均服务请求周期时间” KPI 和“服务请求端到端周期时间” Dashboard。它提供了对整体流程效率和客户等待时间的高层级衡量。为何重要这是衡量整体流程效率和端到端客户体验的主要 KPI。获取方式在数据转换期间计算，方法是从每个 case 的最终关闭 timestamp 中减去创建 timestamp。示例 864003600007200
	供应商参与时长 VendorEngagementDuration	服务请求等待外部供应商处理的总时间。
描述这是一个计算指标，汇总了服务请求处于“由外部供应商处理”状态的总时间。其计算方法是找出“供应商参与开始”和“供应商参与结束”活动之间的时长，如果单个 case 中多次出现，则将这些时长相加。此属性对于“外部供应商参与延迟”仪表板和“平均外部供应商耗时”KPI 至关重要。它有助于量化第三方依赖导致的延迟，这对于管理供应商关系和设定现实的客户预期非常关键。为何重要隔离并量化由外部依赖导致的延迟，为管理供应商绩效和改进预测提供 data。获取方式在数据转换期间计算，方法是测量“供应商协作开始”与“供应商协作结束”事件之间的时间。示例 172800604800259200
	分拣到分派的时间 TriageToAssignmentTime	请求从分拣到分派给代理之间的时间间隔。
描述这是一个计算得出的时长指标，用于衡量服务请求初始处理和路由阶段的效率。它的计算方式是“请求已分派”活动与“请求已分拣”活动之间的时间差。此指标是“平均分拣到分派时间”KPI 和“分拣与分派效率”仪表板的基础。此处时长较长可能表明服务台的接收流程存在瓶颈，例如分拣人员不足或在确定正确的分派团队时存在延迟。为何重要衡量请求处理关键初始步骤的效率，突出工作正式开始前的延迟。获取方式在数据转换期间计算，方法是从“请求已指派”事件的 timestamp 中减去“请求已分流”事件的 timestamp。示例 3009001800
	报告人 Reporter	最初创建或报告服务请求的用户。
描述报告人是提交服务请求的个人，通常是终端用户或客户。此属性标识了启动流程的相关方。在分析中，报告人可用于了解不同用户、部门或客户群体的请求模式。它有助于回答诸如“哪些部门提交的请求最多？”或“特定用户是否反复面临相同问题？”等问题。这些信息对于主动的问题管理和改进用户培训非常有价值。为何重要识别请求发起者，支持按用户、部门或客户分析请求量和类型。获取方式这对应于 Jira 问题上的“报告人”字段。示例查尔斯·达尔文玛丽·居里艾萨克·牛顿
	指派团队 AssignedTeam	负责处理服务请求的团队或小组。
描述此属性指定了分配给请求的团队，这通常是比单个经办人更高一级的分组。这对于分析团队级别的绩效非常有用，例如比较一线支持团队与网络运营团队。该维度对于“代理工作负载和解决指标”等仪表板至关重要。它支持在团队级别聚合绩效指标，有助于进行公平比较并了解不同团队对整体服务交付流程的贡献。为何重要支持在团队或部门层级进行绩效分析和工作负载平衡，而不仅仅针对单个坐席。获取方式这可能是 Jira 中的自定义字段（例如“团队”），也可能源自经办人的用户配置文件属性。示例 IT 支持 - 一线基础设施团队应用支持
	是否重新打开 IsReopened	一个布尔标记，用于指示服务请求在解决后是否被重新打开。
描述此计算属性是一个真/假 (true/false) 标志，如果请求的工作流包含“请求已重新开启”活动，则设置为 true。它是通过分析每个 case 的活动顺序得出的。此标志对于计算“服务请求重开率”KPI 以及支持“重开服务请求量”仪表板至关重要。高重开率是首次解决质量不佳的有力指标，会导致重复劳动并降低客户满意度。分析哪些类型的请求或解决结果与此标志相关联，可以精准定位改进领域。为何重要直接衡量返工和初次解决质量，这是流程有效性和客户满意度的关键指标。获取方式在数据转换期间计算，方法是检查一个 case 的活动序列中在“已解决”流转之后是否包含“重新打开”流转。示例 truefalse
	渠道 Channel	用于创建服务请求的提交方式，如电子邮件、门户或 API。
描述渠道属性识别服务请求进入系统的方式。Jira Service Management 中的常见渠道包括客户门户、电子邮件或由代理直接创建。按渠道分析流程对于理解用户行为和优化服务交付非常重要。它可以揭示来自某些渠道的请求是否需要更长的时间来解决或需要更多澄清，从而可能表明需要改进门户表单或电子邮件解析规则。这为“服务请求吞吐量趋势”仪表板提供了数据支持。为何重要有助于分析提交渠道是否会影响解决时间、请求清晰度或整体流程效率。获取方式此信息可通过 Jira Service Management 中的“请求渠道类型”字段获取。它可能需要特定的 API 访问权限或存储在自定义字段中。示例 portalemailapi
	组织机构 Organization	报告人所属的客户组织或内部部门。
描述此属性将报告人分为不同的组织或部门。Jira Service Management 具有内置的“组织”功能，允许代理管理来自多个客户或内部团队的请求。按组织进行分析可提供有价值的业务背景。它可以帮助识别哪些客户或部门消耗了最多的支持资源，特定群体是否遇到了重复发生的问题，以及不同业务单元的 SLA 达成情况是否保持一致。为何重要便于按客户或内部部门分析服务需求和绩效，提供关键业务洞察。获取方式此数据来自 Jira Service Management 中与服务请求关联的“组织”字段。示例 Acme Corporation财务部Global Tech Inc.
	解决 Resolution	已解决服务请求的最终结果或结论。
描述解决结果字段指明了服务请求关闭的原因。常见值包括“已完成”、“不予处理”、“重复”或“无法重现”。它提供了除“已解决”或“已关闭”状态之外的详细结案信息。分析解决结果有助于理解交付质量和结果性质。例如，大量的“重复”结果可能暗示请求提交流程存在问题，而追踪哪些结果导致请求重新开启，则可以发现无效的解决方案。为何重要提供关于请求结果的背景信息，有助于分析解决质量并识别请求关闭原因的趋势。获取方式这对应于 Jira 问题上的“解决结果”字段，通常在问题转换为“已完成”状态类别时设置。示例已完成暂不处理重复已修复

必填推荐可选

服务请求管理活动

为确保流程发现与优化的准确性，建议在事件日志中记录以下关键步骤和里程碑。

5 推荐 8 可选

	活动	描述
	已提出解决方案	在许多服务台 Workflow 中，这是一个独特的步骤，即向请求者提供解决方案以供其审批。当事务状态变更为“待客户接受”或“等待确认”等状态时，即可推断出此活动。
为何重要此活动分离出了提供解决方案后等待客户反馈的时间，有助于将其与内部工作时间区分开来。获取方式从事务历史中推断，在状态变更为指示方案正等待客户验证时的 timestamp 采集。捕获识别状态变更为“待客户接受”或等效状态的 timestamp。事件类型 inferred
	服务请求已关闭	代表服务请求的最终行政关闭，通常在“已解决”状态维持一段时间后自动发生。这是 Jira 中问题生命周期的终点。
为何重要这是流程的最终结束事件。可以分析“已解决”和“已关闭”之间的时间，以了解行政开销或自动关闭政策。获取方式从事务历史中推断。该 timestamp 对应于最后一次状态变更为“已关闭”或等效终止状态。捕获识别最后一次变更为“已关闭”状态的 timestamp。事件类型 inferred
	服务请求已创建	此活动标志着服务请求生命周期的开始，即用户通过门户、电子邮件或其他渠道正式提交请求。当在 Jira 中创建“服务请求”类型的新问题时，系统会明确捕获此事件并记录创建时间戳（timestamp）。
为何重要这是流程的主要开始事件。它对于计算整体周期时间以及理解请求量和到达模式至关重要。获取方式这是问题历史表（issue history table）中捕获的明确事件。活动时间戳（timestamp）是 Jira 问题上的“创建”字段。捕获使用来自“问题”表或历史记录的问题创建时间戳（timestamp）。事件类型 explicit
	服务请求已解决	标志着请求被视为已交付且方案已记录的官方时间点。当事务首次进入“完成”类别的状态时，Jira 会填充“解决日期”字段。
为何重要这是流程的主要结束里程碑，对于计算解决时间和 SLA 达成率至关重要。它标志着主动工作的结束。获取方式这是一个明确的事件。时间戳（timestamp）是 Jira 问题中“解决日期”字段的值，该值在首次转换为“已完成”类别状态时设置。捕获使用 Jira 问题中的“解决日期”字段。此字段是自动填充的。事件类型 explicit
	请求已分配	当服务请求分派给特定的代理或团队进行解决时，就会发生此活动。Jira 会明确追踪“经办人”字段的变更，并为分派操作提供清晰的时间戳（timestamp）。
为何重要这是衡量“分拣到分派时间”和代理工作负载分布的关键里程碑。它标志着从排队到主动处理的转变。获取方式通过查看事务历史中“经办人”字段首次被设置或从“未分配”变更的实例来采集。捕获使用问题历史记录中第一次“经办人”字段变更的时间戳（timestamp）。事件类型 explicit
	供应商参与已开始	此活动表示服务请求已升级到外部供应商或第三方，或者需要其采取行动。这是通过问题转换到“等待供应商”或“第三方处理中”等状态来推断的。
为何重要追踪供应商参与情况对于识别内部服务台直接控制之外的外部依赖和延迟至关重要。获取方式从事务历史中推断。该 timestamp 对应于事务状态变更为指定的“供应商”状态的时间。捕获识别“状态”字段变更为“等待供应商”等类似值时的 timestamp。事件类型 inferred
	供应商参与已结束	代表外部供应商完成操作并将服务请求退回内部团队的时刻。这通常在问题移出“等待供应商”状态时推断得出。
为何重要测量供应商协作的时长有助于管理供应商绩效，并了解外部各方对整体解决时间的影响。获取方式从事务历史中推断。该 timestamp 对应于事务状态从“供应商”状态变回“进行中”状态的时间。捕获识别“状态”字段从“供应商”状态变回“活跃”状态时的 timestamp。事件类型 inferred
	信息已请求	标志着坐席需要向请求者获取更多信息才能继续处理的时间点。通常通过事务流转到“等待客户”或“待输入”等状态来推断。
为何重要频繁或漫长的“请求信息”循环可能表明初始提交内容不清晰或沟通效率低下，这是延迟的一个主要来源。获取方式从事务历史中推断。该 timestamp 对应于事务状态变更为“等待客户”或等效状态的时间。捕获识别“状态”字段变更为指示流程正在等待客户的值时的 timestamp。事件类型 inferred
	提供信息	当请求者提供了必要信息，允许坐席恢复工作时发生。当事务移出“等待客户”状态时（通常由请求者添加评论触发），即可推断出此活动。
为何重要此活动完成了与客户的“请求-响应”循环。请求信息与接收信息之间的时间是流程等待时间的关键组成部分。获取方式从事务历史中推断。该 timestamp 对应于事务状态从“等待客户”变回“进行中”状态的时间。捕获识别“状态”字段从“等待”状态变回“活跃”状态时的 timestamp。事件类型 inferred
	方案已实施	指示坐席已执行必要操作或开发出解决方案来处理服务请求。这通常通过状态变更为“待评审”或直接变为“已解决”来推断。
为何重要此里程碑标志着核心解决工作的完成。导致此活动发生之前的时间通常代表流程中主要的正向增值部分。获取方式从事务历史中推断，对应于状态变更为“已解决”、“待接受”或类似预关闭状态的 timestamp。捕获识别“状态”字段变更为指示工作已完成的值时的 timestamp。事件类型 inferred
	解决已确认	当请求者正式接受建议的方案时发生，通常会触发自动流转到“已解决”状态。此事件通常由此状态变更推断得出。
为何重要此里程碑验证了解决方案的有效性，并作为停止 SLA 计时的触发器。它有助于衡量客户确认修复所需的时间。获取方式从事务历史中推断。该 timestamp 对应于状态从“待客户接受”变更为“已解决”或“已关闭”。捕获识别状态从“待客户接受”变更为“已解决”或“已关闭”状态的 timestamp。事件类型 inferred
	请求已分拨	代表服务请求的初步评估，在此阶段确定其优先级、类别和影响。此活动通常通过状态变化来推断，例如从“新建”移至“处理中”或特定的“已分拣”状态。
为何重要分析分流时间有助于评估初始请求处理流程的效率。此处的延迟会显著影响整体解决时间和 SLA 达成率。获取方式通过识别状态从初始的“新建”或“开启”状态变更为“进行中”等活跃状态的首次 timestamp，从事务历史中推断得出。捕获根据项目的 Workflow，识别从“新建”或等效初始状态开始的首次状态变更。事件类型 inferred
	请求已重新打开	此活动记录了之前已解决的服务请求返回活动状态的情况。它是通过状态从已解决或已关闭状态变回开启或处理中状态来推断的。
为何重要追踪重新开启的请求对于衡量解决质量和首次解决率至关重要。高重开率表明解决方案无效或问题反复出现。获取方式通过识别状态从“已解决”或“已关闭”类别流转到“开启”或“进行中”类别，从事务历史中推断得出。捕获查找从“完成”状态类别到“待办”或“进行中”状态类别的状态变更。事件类型 inferred

推荐可选

提取指南

如何从Jira Service Management获取数据

步骤

Login 您的 Jira Service Management 实例并导航至主菜单。
选择筛选器，然后选择高级事务搜索。这将打开“事务导航器”，您可以在此处构建查询。
在搜索栏中，输入“查询”部分提供的 JQL (Jira Query Language) 查询，以筛选出您想要分析的特定服务请求。根据需要调整项目键值和日期范围。
点击搜索按钮执行查询。检查返回的事务列表，确保数据集正确无误。
在搜索结果页面的右上角，点击导出图标（通常是一个带箭头的方框）。
从下拉菜单中选择 XML。使用 XML 至关重要，因为标准的 CSV 导出不包含生成完整事件日志所需的详细变更历史 data。
将下载的 XML 文件保存到您的本地系统。该文件包含查询出的所有事务，且每条事务的 data 中都嵌入了完整的变更历史。
由于导出的 XML 不是事件日志格式，因此需要进行后期处理。使用脚本（例如 Python、Powershell 或其他语言）来解析该 XML 文件。
脚本必须遍历文件中的每条事务，并根据创建时间戳创建一个“服务请求已创建”事件。然后，脚本必须解析每条事务的变更日志 (changelog)，识别映射到所需活动的“状态 (status)”和“经办人 (assignee)”字段变更。对于识别出的每项变更，都必须生成一个新行。
脚本应将这些 data 转换为扁平的 CSV 文件，并为 ServiceRequestId、ActivityName、EventTime 以及所有其他必需和推荐的属性创建列。
脚本的最终输出即为事件日志。保存此 CSV 文件并准备将其 Upload 至 Process Mining 工具。

配置

JQL 项目筛选器：使用 project = "[您的 JSM 项目键值]" 来定位特定的服务管理项目。请将占位符替换为您的项目键值，例如 'JSM' 或 'HELPDESK'。
JQL 事务类型筛选器：使用 issuetype = "Service Request" 或您配置中用于服务请求的具体事务类型名称。
日期范围：强烈建议筛选特定时间段以控制导出文件的大小。使用类似 created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD" 的子句。通常 3 到 6 个月的数据是一个不错的起点。
导出格式：您必须选择 XML 进行导出。CSV 格式不包含创建事件日志所需的变更日志 data。
Jira 权限：执行导出的用户必须拥有指定 Jira 项目的“浏览项目”权限，才能查看并导出事务。
数据量：Jira 的默认 UI 导出通常每次限制为 1000 条事务。如果您的查询返回更多结果，必须通过缩小每次导出的日期范围来分批导出数据。

a 查询示例 config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

步骤

获取数据库访问权限：获取 Jira 实例后端 SQL 数据库的只读凭据和连接详情（主机名、端口、数据库名称）。这通常需要数据库管理员或 IT 部门的协助。
识别 Jira Schema：使用 DBeaver、SQuirreL SQL 或 SQL Server Management Studio 等 SQL 客户端连接到数据库。熟悉关键表：jiraissue（核心事务 data）、changegroup（变更历史）、changeitem（每项变更的详情）、project（项目详情）、issuetype（事务类型）和 priority（优先级）。
定位自定义字段 ID：RequestType 和 SlaDueDate 等属性通常是自定义字段。通过查询 customfield 表来识别它们的 ID：SELECT id, cfname FROM customfield WHERE cfname IN ('[您的请求类型字段名称]', '[您的 SLA 字段名称]');。记下这些 ID 以备在主查询中使用。
自定义 SQL 查询：将提供的 SQL 脚本复制到您的 SQL 客户端中。您必须仔细地将所有用方括号括起来的占位符替换为 Jira 配置中的实际值，包括项目键值、事务类型名称、状态名称和自定义字段 ID。
设置日期范围：在查询初始的 issue_base 部分找到 WHERE i.created >= '[YYYY-MM-DD]' 子句。修改日期以定义数据提取的时间窗口。
执行查询：运行修改后的 SQL 脚本。该查询适用于 PostgreSQL、SQL Server 和 MySQL 等常见 SQL 数据库。在大型 Jira 实例上，执行可能需要几分钟时间。
核对结果：查询完成后，简要检查输出，确保返回了数据行，且 ServiceRequestId、ActivityName 和 EventTime 等列已按预期填充。
导出数据：将 SQL 客户端中的完整结果集导出为 CSV 文件。为文件起一个描述性的名称，例如 jira_servicerequest_eventlog.csv。
准备 Upload：打开 CSV 文件，验证列标题是否与要求的属性名称完全一致（例如 ServiceRequestId、ActivityName、EventTime）。确保文件以 UTF-8 编码保存，以兼容 ProcessMind。

配置

前提条件：需要对 Jira 生产数据库或从库数据库拥有直接的只读访问权限，仅有标准应用程序访问权限是不够的。此外，您还需深入了解特定 Service Desk 项目的 Workflow，包括状态、事务类型和自定义字段的准确名称。
关键查询筛选器：必须配置查询以锁定正确的数据集。请密切关注以下 WHERE 子句：
- p.pkey IN ('[您的项目键值]')：这是最重要的筛选器，将数据限制在一个或多个特定的 Jira Service Management 项目中。
- it.pname = '[您的服务请求事务类型]'：确保您只提取服务请求，而非故障 (Incident)、问题 (Problem) 或其他事务类型。
- i.created >= '[YYYY-MM-DD]'：设置提取的开始日期。对于首次分析，建议选取最近 3 到 6 个月的数据范围。
Workflow 状态映射：事件日志的准确性完全取决于查询中 Jira 状态名称的正确映射。您必须将 [Status for Triage]、[Waiting for Customer Status] 和 [Resolved Status] 等占位符替换为您特定 Workflow 中使用的实际名称。
性能注意事项：直接在大型活跃的 Jira 数据库上执行此查询可能会消耗大量资源，并可能影响用户的应用程序性能。强烈建议在只读副本数据库上运行提取，或在非高峰时段进行。

a 查询示例 sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

步骤

前提条件与设置：确保您的系统已安装 Python 3.6 或更高版本。在终端运行以下命令安装必要的 Python 库：pip install requests pandas。
生成 Jira API 令牌：Login 您的 Jira Cloud 账号。导航至个人资料 Settings，选择“账号设置”，进入“安全”选项卡并创建一个 API 令牌。安全地复制此令牌，它将用于身份验证。
识别自定义字段 ID：诸如“请求类型”或“SLA 截止日期”等许多 Jira 属性都是自定义字段。要查找它们的 ID，请导航至“设置”>“事务”>“自定义字段”。搜索所需字段，点击省略号“...”>“查看字段信息”。ID 将显示在 URL 中（例如 customFieldId=10021）。记下这些 ID 以配置脚本。
配置 Python 脚本：在文本编辑器中打开提供的 Python 脚本。填写文件顶部的配置变量，包括 JIRA_URL、JIRA_EMAIL、JIRA_API_TOKEN、用于筛选服务请求的 jql_query，以及上一步识别出的 CUSTOM_FIELD_IDS。
将 Jira 状态映射到活动：仔细检查脚本中的 STATUS_ACTIVITY_MAP 字典。您必须更新此映射以匹配您的特定 Jira Service Management Workflow。键（Key）应为 Jira 状态的准确名称（例如 'Waiting for customer'），值（Value）应为事件日志所需的对应活动名称（例如 'Information Requested'）。
执行提取脚本：打开终端或命令提示符，进入保存脚本的目录，运行命令：python jira_extraction_script.py。脚本将连接到 Jira API，获取事务 data，进行处理并在控制台打印进度更新。
核对输出文件：脚本运行完成后，会在同一目录下生成一个名为 jira_event_log.csv 的 CSV 文件。在电子表格软件中打开此文件核对内容，确保所有列都已存在并按预期填充。
准备 ProcessMind Upload：确保 CSV 文件中的列标题完全符合要求：ServiceRequestId、ActivityName、EventTime、SourceSystem、LastDataUpdate、Assignee、RequestPriority、RequestStatus、RequestType 和 SlaDueDate。现在，该文件即可 Upload 至 ProcessMind。

配置

Jira Authentication：该脚本需要您的 Jira 域名 URL、Jira 账号关联的电子邮件地址，以及用于安全访问的个人 API 令牌。
JQL 查询 (jql_query)：这是数据提取的核心筛选器。准确定义 JQL 查询对于选取正确的事务至关重要。我们建议通过 project、issuetype 以及使用 createdDate 设置特定日期范围来控制数据量（例如：project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'）。
状态到活动的映射 (STATUS_ACTIVITY_MAP)：该字典对于将 Jira 状态变更准确转换为有意义的流程活动至关重要。您必须根据组织的特定 Jira Workflow 自定义此映射。任何未包含在此映射中的状态都将被忽略。
自定义字段 ID (CUSTOM_FIELD_IDS)：若要从“请求类型”或“SLA 截止日期”等自定义字段提取数据，您必须提供其唯一的系统 ID（例如 customfield_10021）。必须正确配置这些 ID 才能填充相关属性。
日期范围与性能：对于首次提取，建议将 JQL 日期范围设置为 3 到 6 个月，以确保性能可控。由于 API 分页和频率限制，提取数年的数据可能会非常缓慢。

a 查询示例 python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

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

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

服务请求管理属性

服务请求管理活动

提取指南

Jira Service Management 内置 CSV/XML 导出

步骤

配置

a 查询示例 config

针对 Jira Server/Data Center 的直接数据库查询

步骤

配置

a 查询示例 sql

通过 Jira Cloud REST API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

准备好开始了吗？

立即优化 Jira 服务请求管理

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

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

服务请求管理属性

服务请求管理活动

提取指南

Jira Service Management 内置 CSV/XML 导出

步骤

配置

a 查询示例 config

针对 Jira Server/Data Center 的直接数据库查询

步骤

配置

a 查询示例 sql

通过 Jira Cloud REST API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

立即优化 Jira 服务请求管理