> Amélioration continue des processus > Gestion des problèmes > Jira Service Management > Modèle de données

Votre template de données de gestion des problèmes

Jira Service Management

Attributs de gestion des problèmes (21) Activités de gestion des problèmes (14) Guides d'extraction (2)

Votre template de données de gestion des problèmes

Ce template sert de feuille de route complète pour l'analyse de vos workflows de gestion des services IT en identifiant les points de données essentiels et les jalons de processus au sein de Jira Service Management. Il offre une vue d'ensemble structurée des attributs et activités nécessaires pour obtenir une visibilité totale sur la manière dont votre équipe gère les problèmes sous-jacents et l'analyse des causes premières. Utilisez ces directives pour rationaliser votre collecte de données et vous assurer que vos initiatives de process mining génèrent des insights exploitables.

Attributs recommandés pour une analyse approfondie
Jalons de processus à capturer dans votre journal d'événements
Guide technique pour l'extraction de données

Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de gestion des problèmes

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre cycle de vie de gestion des problèmes.

5 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Description
	Activité ActivityName	L'action spécifique ou le changement de statut qui s'est produit pour l'enregistrement de problème.
Description Cet attribut capture le nom de l'événement ou de la transition d'état se produisant au sein du cycle de vie de gestion des problèmes. Les exemples incluent 'Problème enregistré', 'Statut changé en En investigation', ou 'Cause première identifiée'. Il est essentiel pour cartographier le flux de processus et identifier la séquence des étapes prises pour résoudre un problème. En process mining, ces activités forment les nœuds de la carte de processus. Pourquoi c'est important Définit les étapes de la cartographie des processus et permet l'analyse des variantes de processus. Où obtenir Jira Changelog (Historique) ou transitions de statut de problème Exemples Enregistrement de problème crééEnquête initiéeCause profonde identifiéeSolution de contournement mise à jourEnregistrement de problème clos
	Dernière mise à jour des données LastDataUpdate	L'horodatage de l'extraction ou de la dernière actualisation des données.
Description Indique la dernière synchronisation de l'ensemble de données (dataset) avec l'environnement Jira Service Management en direct. Cela garantit que les analystes comprennent la fraîcheur des données. Il est utilisé pour valider que l'analyse reflète l'état le plus actuel du processus et pour identifier les problèmes potentiels de latence des données. Pourquoi c'est important Assure la fraîcheur des données et aide à la confiance dans les résultats de l'analyse. Où obtenir ETL Timestamp Exemples 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Enregistrement de problème ProblemKey	L'identifiant unique attribué à l'enregistrement de problème dans Jira Service Management.
Description Cet attribut sert d'identifiant central de cas pour l'analyse de process mining. Il représente la clé unique (par exemple, PM-1001) générée par Jira Service Management lors de la création d'un nouvel enregistrement de problème. Il est utilisé pour regrouper toutes les activités, changements de statut et mises à jour liés en une seule instance de processus de bout en bout. L'analyse de cet attribut permet la visualisation du cycle de vie complet d'un problème, de la détection initiale à la clôture finale, en passant par l'investigation. Pourquoi c'est important C'est la clé fondamentale requise pour reconstruire le flux de processus et suivre des enregistrements de problèmes spécifiques. Où obtenir Table des problèmes, champ 'Clé' ou 'Clé du problème' Exemples PM-1023PM-4099PRB-3321PM-5001
	Système source SourceSystem	Le nom du système d'où proviennent les données.
Description Identifie le système logiciel à partir duquel les données du processus ont été extraites. Dans ce contexte, la valeur est constamment 'Jira Service Management'. Cet attribut est particulièrement utile dans les environnements multi-systèmes pour distinguer les sources de données, bien que pour cette vue spécifique, il serve principalement d'identifiant statique pour la lignée des données. Pourquoi c'est important Fournit le contexte de l'origine des données, en particulier lors de la fusion avec d'autres données de gestion des services informatiques. Où obtenir Configuration codée en dur ou système Exemples Jira Service ManagementJira CloudJSM-Prod
	Timestamp EventTimestamp	La date et l'heure exactes de l'activité.
Description Cet attribut enregistre le moment précis où une activité a eu lieu. Il est utilisé pour séquencer les événements chronologiquement et calculer les durées entre les étapes. Des horodatages précis sont essentiels pour calculer les temps de cycle, tels que le temps entre 'Problème enregistré' et 'Cause première identifiée', et pour analyser le débit au fil du temps. Pourquoi c'est important Permet le calcul de tous les KPI basés sur le temps et le bon ordre des événements. Où obtenir Date de création du Jira Changelog ou date de création du problème Exemples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Catégorie de Cause Racine RootCauseCategory	La classification de la cause sous-jacente du problème.
Description Catégorise la défaillance technique ou de processus qui a causé le problème, telle que « Bug logiciel », « Erreur humaine » ou « Défaillance matérielle ». Il s'agit souvent d'un champ personnalisé dans Jira Service Management. Cet attribut soutient le dashboard « Distribution des catégories de causes profondes », permettant des décisions stratégiques sur les investissements en infrastructure ou en formation pour prévenir les récurrences. Pourquoi c'est important Clé pour identifier les problèmes systémiques et orienter les mesures préventives. Où obtenir Champ personnalisé 'Cause profonde' ou 'Catégorie de cause profonde' Exemples Bogue logicielErreur de configurationProblème de capacitéProblème fournisseur
	Groupe de support assigné SupportGroup	L'équipe technique ou le groupe actuellement affecté à l'investigation du problème.
Description Identifie l'équipe spécifique responsable de l'enregistrement de problème au moment de l'événement. Dans Jira Service Management, cela est souvent mappé à 'Composant' ou à un champ personnalisé comme 'Groupe de support'. Cet attribut est vital pour le dashboard « Goulots d'étranglement des transferts entre groupes de support », permettant aux analystes de visualiser comment les problèmes se déplacent entre les équipes et où ils restent le plus longtemps. Pourquoi c'est important Essentiel pour le process mining organisationnel et l'identification des frictions inter-équipes. Où obtenir Champ 'Composant' du problème ou champ personnalisé 'Groupe de support' Exemples Administration de Bases de `Données`Opérations réseauSupport applicatif niveau 2
	Priorité Priority	Le niveau de criticité attribué à l'enregistrement de problème.
Description Indique l'urgence et l'impact du problème, allant typiquement de « Faible » à « Critique ». Ce champ est utilisé pour segmenter l'analyse et s'assurer que les problèmes de haute priorité sont résolus dans les objectifs SLA. L'analyse de cet attribut aide dans le dashboard « Conformité SLA et Tendances des Objectifs » à vérifier si les risques métier critiques sont correctement priorisés. Pourquoi c'est important Permet la segmentation de la performance des processus par criticité métier. Où obtenir Champ 'Priorité' du problème Exemples La plus élevéeÉlevéMoyenFaible
	Résumé du problème ProblemSummary	La description textuelle courte ou le titre de l'enregistrement de problème.
Description Contient le résumé principal (headline) de l'enregistrement de problème. Bien que principalement basé sur du texte, il fournit un contexte aux analystes qui examinent les cas individuels au sein de l'outil de process mining. Il permet la recherche par mots-clés et l'analyse qualitative des types de problèmes enregistrés. Pourquoi c'est important Fournit un contexte lisible par l'homme pour l'identifiant de cas. Où obtenir Champ 'Résumé' du problème Exemples Délai d'attente de connexion à la base de données dans la région UEPic de latence du service de messagerieFile d'attente de traitement des commandes bloquée
	Utilisateur UserKey	L'identifiant unique ou le nom de l'utilisateur qui a effectué l'activité.
Description Capture l'identité de la personne ou du compte système responsable de l'exécution de l'activité spécifique. Il peut s'agir de l'« Assigné » mettant à jour l'enregistrement ou de l'« Auteur » d'un changement de statut. Ces données sont utilisées pour analyser l'utilisation des ressources, identifier les goulots d'étranglement (bottlenecks) de transfert entre les utilisateurs et garantir la responsabilité au sein du processus de gestion des problèmes. Pourquoi c'est important Critique pour l'analyse des transferts, de la ségrégation des tâches et de la charge de travail des ressources. Où obtenir Champ 'auteur' de Jira dans le journal des modifications ou champ 'assigné' sur le problème Exemples j.smithsystem_automationm.doe
	Code de Résolution ResolutionCode	Le code indiquant comment le problème a été résolu.
Description Spécifie l'issue finale de l'enregistrement de problème, telle que 'Corrigé', 'Ne sera pas corrigé', 'Doublon' ou 'Non reproductible'. Ceci est utilisé pour filtrer les problèmes résolus avec succès de ceux fermés pour des raisons administratives, garantissant que les calculs de KPI comme le 'Temps moyen jusqu'à la cause première' sont précis. Pourquoi c'est important Distingue les correctifs efficaces des clôtures administratives. Où obtenir Champ 'Résolution' du problème Exemples TerminéRefuséDoublonImpossible de reproduire
	Date de création CreatedDate	La date de création de l'enregistrement de problème.
Description L'horodatage lorsque le problème a été enregistré pour la première fois dans le système. Bien que l'horodatage d'événement gère le timing des activités, cet attribut spécifique est souvent utilisé pour un filtrage de haut niveau (par exemple, 'Montrez-moi tous les problèmes créés au T1'). Il sert de point d'ancrage pour l'analyse du vieillissement. Pourquoi c'est important Date de référence pour l'analyse de l'ancienneté et du volume d'admission. Où obtenir Champ 'Créé' du problème Exemples 2023-01-012023-06-15
	Déclarant ReporterName	L'utilisateur qui a initialement enregistré le problème.
Description Identifie l'individu qui a créé l'enregistrement de problème. C'est distinct de l'assigné. L'analyse des reporters aide à comprendre où les problèmes sont détectés (par exemple, Agents du Service Desk vs Administrateurs Système). Cela ajoute du contexte à l'analyse « Proactif vs Réactif ». Pourquoi c'est important Identifie la source d'admission des problèmes. Où obtenir Champ 'Reporter' du problème Exemples monitoring_servicehelpdesk_leadnetwork_admin
	Demande de changement liée LinkedChangeRequest	L'identifiant de la demande de changement liée à ce problème.
Description Stocke l'ID de la demande de changement (RFC) créée pour implémenter le correctif permanent. Ce lien est vital pour le dashboard 'Délai d'initiation de la demande de changement'. Il connecte le processus de gestion des problèmes à la gestion du changement, permettant une analyse inter-processus. Pourquoi c'est important Connecte l'investigation à la remédiation dans le processus de gestion des changements. Où obtenir Liens de problème où le type est 'est résolu par' ou similaire Exemples CR-404CHG-1099CR-5512
	Durée de l'investigation InvestigationDuration	Temps écoulé entre l'enregistrement du problème et l'identification de la cause première.
Description Calcule la durée entre la création de l'enregistrement de problème et l'horodatage de l'activité « Cause profonde identifiée ». C'est la métrique principale pour le dashboard « Analyse du temps de cycle d'investigation ». Cela aide les managers à identifier les problèmes complexes qui ont bloqué l'équipe ou le manque de ressources dans la phase de diagnostic. Pourquoi c'est important Métrique principale de l'efficacité de la phase d'analyse des causes premières. Où obtenir Calculé à partir des horodatages d'événement Exemples 48 heures5 jours30 minutes
	Est rouvert IsReopened	Indicateur signalant si le problème a été rouvert après sa clôture.
Description Un indicateur booléen (flag) défini à vrai si l'enregistrement de problème est passé d'un état fermé à un état ouvert. Ceci soutient l'« Analyse du taux de réouverture des problèmes ». Des taux de réouverture élevés indiquent des problèmes de qualité avec les correctifs permanents ou des procédures de vérification insuffisantes. Pourquoi c'est important Indicateur de qualité de l'efficacité des correctifs. Où obtenir Dérivé des transitions de statut Exemples truefaux
	Nombre d'incidents liés LinkedIncidentCount	Le nombre d'incidents liés à cet enregistrement de problème.
Description Un décompte des tickets d'incidents associés à l'enregistrement de problème. Cet attribut quantifie l'impact du problème sur la base d'utilisateurs. Il est utilisé dans l'indicateur clé de performance (KPI) « Profondeur du lien Incident-Problème » pour prioriser les problèmes qui génèrent le plus grand volume de tickets de support. Pourquoi c'est important Quantifie l'impact métier basé sur le volume d'incidents. Où obtenir Nombre de liens dans la table 'issuelinks' où le type est 'Problème/Incident' Exemples 011550
	Revue post-implémentation effectuée ReviewStatus	Indique si une revue post-implémentation (PIR) a été effectuée.
Description Vérifie si l'activité ou l'indicateur 'Revue post-implémentation' est présent sur le cas. Ceci est essentiel pour le dashboard 'Conformité de la Revue post-implémentation'. Il garantit que l'organisation respecte les exigences de gouvernance pour l'amélioration continue. Pourquoi c'est important Métrique de conformité pour l'apprentissage organisationnel. Où obtenir Champ personnalisé 'Statut PIR' ou existence de l'activité 'PIR' Exemples TerminéEn attenteNon requis
	Solution de contournement disponible WorkaroundDetails	Indique si une solution de contournement a été documentée pour le problème.
Description Capture si un texte de solution de contournement temporaire existe ou a été publié. Cela permet à l'organisation de suivre la « Vitesse de publication de la solution de contournement ». L'analyse de ce champ aide à déterminer la rapidité avec laquelle l'équipe peut restaurer la stabilité du service, même avant qu'un correctif permanent ne soit trouvé. Pourquoi c'est important Clé pour mesurer la rapidité du soulagement provisoire fourni à l'entreprise. Où obtenir Champ personnalisé 'Solution de contournement' Exemples Redémarrer le serviceVider le cache du navigateurAucun fourni
	Source de détection DetectionSource	Comment le problème a été identifié (par exemple, Proactif, Réactif).
Description Indique l'origine de l'identification du problème. Les valeurs courantes incluent « Surveillance proactive », « Incident du Service Desk » ou « Notification du fournisseur ». Cet attribut est utilisé dans le dashboard « Identification proactive vs réactive » pour mesurer la maturité du processus de gestion des problèmes. Pourquoi c'est important Mesure la maturité des processus et l'efficacité des systèmes de surveillance. Où obtenir Champ personnalisé 'Source' ou 'Source de détection' Exemples Surveillance proactiveEscalade d'incidentNotification fournisseur
	Statut de violation SLA SlaBreachStatus	Indique si l'enregistrement de problème a dépassé son accord de niveau de service (SLA).
Description Un champ booléen ou de statut indiquant si le temps de résolution a dépassé l'objectif convenu. Cela est utile pour le dashboard « Conformité SLA et Tendances des Objectifs ». Il met en évidence les cas qui exposent l'organisation à des risques de conformité ou à des pénalités. Pourquoi c'est important Critique pour la conformité et le suivi des performances. Où obtenir Logique du champ SLA de Jira Service Management Exemples AtteintDépasséMis en Pause

Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Ce sont les étapes de processus et les jalons clés à capturer dans votre journal d'événements pour une découverte précise de vos workflows de résolution.

8 Recommandé 6 Facultatif

	Activité	Description
	Affecté au Groupe de Support	L'affectation de l'enregistrement de problème à une équipe technique ou à un groupe de support spécifique. Ceci est suivi via les changements apportés au champ personnalisé 'Support Group' ou au champ 'Assignee' si les groupes ne sont pas utilisés.
Pourquoi c'est important Critique pour analyser les transferts et les goulots d'étranglement (bottlenecks) entre les équipes. Des taux de transfert élevés peuvent indiquer des inefficacités de routage. Où obtenir Historique du problème Jira : Le champ 'Groupe de support' ou 'Assigné' a changé Capture Enregistré lorsque le champ d'assignation change Type d'événement explicit
	Cause profonde identifiée	Le point où la cause sous-jacente est formellement enregistrée. Ceci est déduit d'un changement de statut vers 'Cause première identifiée' ou du remplissage du champ 'Cause première'.
Pourquoi c'est important Une étape majeure qui met fin à la phase d'enquête. Essentiel pour le calcul du « Temps moyen de découverte de la cause profonde ». Où obtenir Historique du problème Jira : Le statut est passé à 'Cause profonde identifiée' OU le champ 'Cause profonde' a été rempli Capture Comparer le champ de statut ou vérifier le remplissage du champ Type d'événement inferred
	Enquête initiée	La transition du statut du problème vers un état d'investigation active (par exemple, 'Sous investigation' ou 'En cours'). Cela marque le début de la phase de travail active.
Pourquoi c'est important Déclenche le chronomètre pour le temps de cycle d'investigation. Aide à distinguer le temps d'attente du backlog de l'analyse active réelle. Où obtenir Historique du problème Jira : Le statut est passé à 'Sous investigation' ou 'En cours' Capture Comparer les mises à jour des champs de statut Type d'événement inferred
	Enregistrement de problème clos	La clôture finale du cycle de vie du problème. Capturée explicitement lorsque le statut passe à 'Fermé'.
Pourquoi c'est important La fin définitive de l'instance de processus. Nécessaire pour le calcul du temps de cycle total et des taux de clôture. Où obtenir Historique du problème Jira : Le statut est passé à 'Fermé' Capture Enregistré lorsque le statut passe à 'Fermé' Type d'événement explicit
	Enregistrement de problème créé	L'événement initial où le ticket de problème est créé dans le système. Ceci est explicitement capturé dans l'historique du ticket comme l'horodatage de création.
Pourquoi c'est important Marque le début du cycle de vie de la gestion des problèmes et permet l'analyse des volumes. Essentiel pour calculer le débit et les taux d'admission. Où obtenir Table de problème Jira : Horodatage de la date de création ou Onglet Historique : Événement de création de problème Capture Enregistré lorsque la transaction de création de problème est validée Type d'événement explicit
	Incident lié au problème	L'action de lier un ticket d'incident connexe à l'enregistrement de problème. Ceci est capturé dans la table des liens de tickets ou l'historique.
Pourquoi c'est important Détermine l'impact et la portée du problème. Essentiel pour le KPI « Profondeur du lien Incident-Problème » et pour la priorisation basée sur l'impact métier. Où obtenir Liens de problème Jira : Lien créé avec le type 'cause' ou 'est lié à' Capture Enregistré lorsqu'un lien de problème est créé Type d'événement explicit
	Résolution vérifiée	La confirmation que le correctif a effectivement résolu le problème. Déduit d'une transition de statut vers 'Résolu' ou un état 'Vérifié' spécifique.
Pourquoi c'est important Porte de qualité garantissant le bon fonctionnement du correctif. Des retards ici indiquent des goulots d'étranglement dans les tests ou l'acceptation utilisateur. Où obtenir Historique du problème Jira : Le statut est passé à 'Résolu' ou 'Vérifié' Capture Comparer les mises à jour des champs de statut Type d'événement inferred
	Solution de contournement mise à jour	Le remplissage ou la mise à jour du champ texte 'Solution de contournement'. Cet événement indique qu'un correctif temporaire a été documenté.
Pourquoi c'est important Mesure la rapidité de la fourniture d'une solution provisoire à l'entreprise. Critique pour le KPI « Délai de disponibilité de la solution de contournement ». Où obtenir Historique du problème Jira : Le champ 'Solution de contournement' a changé (non nul) Capture Enregistré lorsque le champ 'Solution de contournement' est modifié Type d'événement explicit
	Correctif permanent appliqué	La transition indiquant que la solution a été implémentée. Ceci est généralement déduit d'un changement de statut vers 'Implémentation' ou 'Corrigé'.
Pourquoi c'est important Marque la fin du travail de remédiation technique. Utilisé pour mesurer le temps de cycle d'implémentation. Où obtenir Historique du problème Jira : Le statut est passé à 'Implémenté', 'Vérification en attente' ou 'Corrigé' Capture Comparer les mises à jour des champs de statut Type d'événement inferred
	Demande de changement liée	La liaison d'une demande de changement (RFC) à l'enregistrement de problème. Cela indique l'initiation du processus de correctif permanent.
Pourquoi c'est important Mesure le délai entre l'identification de la cause et le début de la remédiation. Soutient le KPI « Délai de transition de la gestion des changements ». Où obtenir Liens de problème Jira : Lien créé avec le type 'est corrigé par' ou lié au type de problème 'Changement' Capture Enregistré lorsqu'un lien vers un type de problème 'Changement' est créé Type d'événement explicit
	Priorité du problème modifiée	Une mise à jour du champ 'Priorité' de l'enregistrement de problème. Ceci est capturé en surveillant l'onglet d'historique pour les changements du champ 'Priorité'.
Pourquoi c'est important Indique une escalade ou une désescalade du problème. L'analyse de ceci aide à identifier la précision du triage initial et l'ancienneté des arriérés à haute priorité. Où obtenir Historique du problème Jira : Le champ 'Priorité' est passé de l'ancienne valeur à la nouvelle valeur Capture Enregistré lorsque le champ 'Priorité' est mis à jour Type d'événement explicit
	Problème rouvert	La transition d'un problème d'un statut 'Résolu' ou 'Fermé' vers un statut actif. Indique un correctif échoué ou une résolution rejetée.
Pourquoi c'est important Une métrique de qualité primaire. Des taux de réouverture élevés indiquent une analyse des causes profondes ou des tests inefficaces. Où obtenir Historique du problème Jira : Le statut est passé de 'Fermé'/'Résolu' à 'Ouvert'/'En cours' Capture Comparer la séquence des champs de statut Type d'événement inferred
	Revue post-implémentation	L'exécution d'une revue après l'application du correctif. Capturée via un changement de statut vers 'En revue' ou des mises à jour des champs spécifiques au PIR.
Pourquoi c'est important Activité de conformité garantissant la capture des leçons apprises. Soutient l'analyse de « Conformité des revues post-implémentation ». Où obtenir Historique du problème Jira : Le statut est passé à 'En revue' OU le champ 'Notes PIR' a été mis à jour Capture Comparer le champ de statut ou les mises à jour du champ PIR Type d'événement inferred
	SLA Non Respecté	Un événement indiquant que le temps de résolution du problème a dépassé l'accord de niveau de service (SLA) défini. Ceci est calculé en comparant la date cible du SLA avec la date de résolution.
Pourquoi c'est important Critique pour les rapports de conformité. Aide à identifier les priorités ou catégories qui manquent le plus souvent leurs objectifs. Où obtenir Journaux SLA de Jira Service Management : 'Temps de résolution' > Cible, ou calculé Capture Déduire des données du champ SLA ou comparer la Date d'échéance à la Date de résolution Type d'événement calculated

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données depuis Jira Service Management

Étapes

Connectez-vous à votre instance Jira Service Management à l'aide d'un navigateur web avec un compte disposant des permissions 'Parcourir les projets' pour le projet de gestion des problèmes.
Naviguez vers la barre de menu supérieure et sélectionnez 'Filtres', puis cliquez sur 'Recherche avancée de problèmes' pour ouvrir le navigateur de problèmes (Issue Navigator).
Passez le mode de recherche à JQL (Jira Query Language) plutôt qu'à 'Basic' si ce n'est pas déjà fait.
Saisissez la chaîne de requête JQL spécifique fournie dans la section 'Requête' ci-dessous pour isoler les enregistrements de problèmes (par exemple, project = 'Problem Management'). Assurez-vous que la plage de temps est appropriée pour les limites d'exportation du système.
Cliquez sur le bouton 'Rechercher' pour vérifier que la liste des problèmes renvoie les enregistrements de problèmes attendus.
Localisez le bouton 'Exporter' dans le coin supérieur droit de l'interface du navigateur de problèmes.
Sélectionnez 'Exporter XML' dans le menu déroulant. Ne sélectionnez pas CSV, car l'exportation CSV standard ne fournit que des données d'état actuel et ne contient pas les journaux de modifications historiques requis pour le process mining.
Enregistrez le fichier XML généré (par exemple, jira_export.xml) dans un répertoire local accessible par votre environnement de traitement.
Préparez l'environnement Python en installant la bibliothèque requise 'pandas' si elle n'est pas déjà présente.
Exécutez le script Python fourni dans la section 'Requête', en vous assurant que la variable de chemin de fichier correspond à l'emplacement de votre fichier XML enregistré.
Le script analyse la structure RSS/XML, extrayant l'horodatage 'Created', les entrées 'History' pour les changements de statut/priorité/assignation, et les 'Issue Links' pour les incidents connexes.
Le script calcule les violations de SLA en comparant les dates de résolution aux dates d'échéance et génère un journal d'événements CSV formaté, prêt pour ProcessMind.

Configuration

Format d'exportation: Doit utiliser l'exportation XML (RSS), et non CSV. Le format XML contient les balises <history> et <issuelinks>, essentielles pour la reconstruction du flux de processus.
Limite de lignes: Les exportations standard de Jira sont souvent limitées à 1 000 problèmes par exportation. Pour les ensembles de données plus volumineux, vous devez paginer l'extraction en ajustant la plage de dates JQL (par exemple, created >= '2023-01-01' AND created < '2023-02-01') et en effectuant plusieurs exportations.
Filtre JQL: Assurez-vous que la clé project correspond à l'identifiant de votre projet de gestion des problèmes spécifique (par exemple, PROB, PM).
Fuseau horaire du système: Vérifiez que le profil utilisateur effectuant l'exportation correspond au fuseau horaire du système pour garantir la cohérence des horodatages.
Permissions des champs: L'utilisateur doit avoir la permission de visualiser l'historique des changements et les problèmes liés pour capturer les transitions et les liens d'incidents.
Champs personnalisés: Si 'Root Cause' ou 'Workaround' sont des champs personnalisés, assurez-vous que la logique de correspondance des noms de champs du script s'aligne avec les noms de champs spécifiques de votre instance Jira.

a Exemple de requête config

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Étapes

Configuration des prérequis: Assurez-vous d'avoir Python 3.x installé, ainsi que les bibliothèques requests et pandas. Vous aurez besoin d'un compte Jira Service Management avec des permissions de lecture pour le projet pertinent. Pour Jira Cloud, générez un jeton API via les paramètres de votre compte Atlassian. Pour Data Center, générez un jeton d'accès personnel (PAT).
Identifier les IDs des champs personnalisés: Jira Service Management utilise des IDs dynamiques pour les champs personnalisés (par exemple, customfield_10012 pour le groupe de support ou le SLA). Avant d'exécuter l'extraction principale, utilisez un navigateur ou Postman pour interroger un problème spécifique (/rest/api/2/issue/[ISSUE-KEY]) afin d'identifier les IDs de champ spécifiques pour 'Support Group', 'Workaround', 'Root Cause' et vos champs SLA.
Configurer le script: Ouvrez le script Python fourni et mettez à jour le dictionnaire CONFIG. Remplacez l'URL, l'email de l'utilisateur et le jeton API. Mettez à jour le dictionnaire FIELD_MAPPING avec les noms ou IDs de champs personnalisés réels que vous avez identifiés à l'étape 2. Mettez à jour le JQL_QUERY pour cibler votre projet spécifique (par exemple, project = PM AND issuetype = Problem).
Définir les mappages de statut: Dans le dictionnaire STATUS_MAPPING du script, mappez vos statuts de workflow Jira spécifiques (par exemple, 'Under Investigation', 'Implementing', 'Resolved') aux noms d'activités standard de ProcessMind (par exemple, 'Investigation Started', 'Permanent Fix Applied').
Exécuter l'extraction: Exécutez le script via un terminal ou un IDE. Le script utilise l'API de recherche Jira avec expand=changelog pour récupérer l'état actuel et l'historique complet de chaque modification de champ.
Logique de traitement: Le script itère sur chaque problème. Il crée d'abord un événement 'Problem Record Created' (Enregistrement de problème créé) à partir de l'horodatage de création. Il analyse ensuite l'historique du journal des modifications (changelog). Pour chaque élément d'historique, il vérifie si le champ modifié correspond à notre liste d'intérêt (Statut, Priorité, Lien, etc.) et génère une ligne d'événement correspondante.
Gestion des SLA: Le script tente d'identifier les violations de SLA en recherchant les changements dans les champs personnalisés liés aux SLA ou les transitions de statut explicitement nommées 'Breached'. Ajustez la logique dans la fonction _parse_sla_breach si votre système utilise une automatisation spécifique pour signaler les violations.
Transformation des données: Le script aplatit la structure JSON imbriquée en un DataFrame Pandas tabulaire. Les horodatages sont convertis au format ISO 8601.
Exportation: L'ensemble de données final est exporté vers un fichier CSV nommé jira_problem_event_log.csv. Ouvrez ce fichier pour vérifier que les en-têtes de colonne correspondent aux exigences de ProcessMind.
Télécharger vers ProcessMind: Importez le fichier CSV dans ProcessMind. Mappez ProblemKey comme ID de Cas, ActivityName comme Activité, et EventTimestamp comme Horodatage.

Configuration

API Endpoint: Utilise /rest/api/2/search (compatible avec les versions Cloud et la plupart des versions Data Center). L'API v3 est également supportée, mais la v2 est généralement plus sûre pour une large compatibilité.
Pagination: Le script implémente la pagination à l'aide de startAt et maxResults pour gérer efficacement de grands ensembles de données. La taille de lot par défaut est fixée à 50.
Extension du journal des modifications (Changelog Expansion): Le paramètre expand=changelog est essentiel. Sans cela, seul l'état actuel est renvoyé, et l'historique/le flux de processus est perdu.
Filtrage JQL: La requête filtre par issuetype = Problem. Il est fortement recommandé d'ajouter un filtre de plage de dates (par exemple, created >= -180d) pour limiter le volume de données lors des tests initiaux.
Authentification: Prend en charge l'authentification de base (Email + Token) pour le Cloud. Pour Data Center, modifiez les en-têtes pour utiliser des jetons Bearer.
Mappage des champs: Une configuration critique est requise. Les noms de champs internes de Jira pour 'Status' et 'Priority' sont standard, mais 'Support Group', 'Root Cause' et 'SLA' sont presque toujours des champs personnalisés avec des identifiants uniques (par exemple, customfield_12345).

a Exemple de requête python

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

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        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"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

Votre template de données de gestion des problèmes

Votre template de données de gestion des problèmes

Attributs de gestion des problèmes

Activités de gestion des problèmes

Guides d'extraction

Exportation du Navigateur de problèmes de Jira Service Management

Étapes

Configuration

a Exemple de requête config

Extraction Python via l'API REST Jira avec Changelog

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimisez votre flux de gestion des problèmes dès aujourd'hui

Votre template de données de gestion des problèmes

Votre template de données de gestion des problèmes

Attributs de gestion des problèmes

Activités de gestion des problèmes

Guides d'extraction

Exportation du Navigateur de problèmes de Jira Service Management

Étapes

Configuration

a Exemple de requête config

Extraction Python via l'API REST Jira avec Changelog

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez votre flux de gestion des problèmes dès aujourd'hui