Interface de l'API Text de CA SDM

Cet article contient les rubriques suivantes :
casm173
Cet article contient les rubriques suivantes :
Présentation de l'API de texte
L'
API de texte
est une interface qui permet d'utiliser des entrées de texte pour créer et mettre à jour des objets dans la base de données CA SDM, tels que les demandes client, les demandes, les contacts et les actifs. Elle permet d'affecter des valeurs à la plupart des champs accessibles aux utilisateurs.
CA SDM nécessite que toutes les entrées soient au format UTF-8 afin d'éviter une corruption des données. L'utilitaire pdm_unconv permet de convertir les données d'un jeu de caractères local en UTF-8, et inversement.
Vous pouvez accéder à l'API de texte à l'aide des interfaces suivantes :
  • Ligne de commande
  • Courriel
Vous pouvez substituer les services Web à l'API de texte pour l'intégration interapplication.
Interface de ligne de commande
Utilisez la commande
pdm_text_cmd
pour activer l'interface de ligne de commande de l'API de texte. Vous pouvez alors indiquer des informations, telles que la table à traiter et l'opération à exécuter, en utilisant des paramètres à la commande pdm_text_cmd.
L'entrée effectuée dans l'API de texte est transmise à la commande pdm_text_cmd sous la forme d'un fichier d'entrée ou directement depuis STDIN.
Lors du transfert des paramètres à partir de l'invite de commande, utilisez Ctrl+Z dans Windows et Ctrl+D dans POSIX.
Vous ne pouvez pas utiliser d'apostrophes ou de guillemets droits comme paramètres pour les commandes bop_cmd et pdm_text_nxd.
Format d'entrée
L'entrée dans l'API de texte est spécifiée selon les méthodes suivantes :
  • Dans l'interface de ligne de commande, l'entrée est généralement insérée dans un fichier texte transmis à la commande
    pdm_text_cmd
    .
  • Dans l'interface de messagerie électronique, l'entrée est insérée dans le texte du courriel. Indiquez une expression régulière pour rechercher les identificateurs d'objet cible.
Formatez l'entrée de l'API de texte de la même façon, quelle que soit l'interface vous utilisez.
Le format de base pour les entrées est le suivant :
%keyword=value
ou
%PROPERTY={{property_label}}value
Le comportement normal des commandes de l'API de texte implique les exceptions suivantes, où la dernière commande à apparaître sur deux ou plusieurs commandes en conflit est prioritaire :
  • Lorsqu'un message contient plusieurs artefacts d'ID de ticket valides correspondant à la chaîne de filtrage de la règle de la boîte aux lettres, ou plusieurs commandes d'ID de ticket d'API de texte, la première commande rencontrée est celle qui sera utilisée. En outre, un artefact d'ID de ticket, qui est identifié en utilisant la chaîne de filtrage de la règle de la boîte aux lettres, remplace toute commande d'ID de ticket d'API de texte, quelle que soit la commande qui apparaît en premier.
  • Lorsqu'un message contient plusieurs commandes API de texte de commentaire de journal, tous les commentaires sont publiés, bien que l'ordre dans lequel ils apparaissent dans le journal d'activité de ticket puisse varier.
Tous les artefacts d'ID de ticket qui correspondent au filtrage, valides ou pas et les commandes d'ID de ticket d'API de texte dans le message, applicables ou pas, appliquées ou pas, sont commentés avant la publication du message. Les artefacts d'ID de ticket identifiés à travers les filtrages de la règle de la boîte aux lettres apparaissent sous la forme -((...))-. Les signes de pourcentage figurant en tête (%) dans les commandes d'ID de ticket d'API de texte sont convertis en deux parenthèses ouvrantes ((, et deux parenthèses fermantes)) suivent la commande. Si une commande d'ID de ticket d'API de texte apparaît après une autre commande d'API de texte avec un commentaire de journal (%LOG=…), la commande d'ID de ticket d'API de texte commentée est effectuée dans un commentaire de journal séparé.
Le commentaire de journal est la seule commande de l'API Texte qui puisse apparaître plusieurs fois dans un message et être appliquée à chaque occurrence. Pour toute autre commande, l'API de texte utilise uniquement la dernière occurrence car des occurrences multiples d'autres commandes entrent en conflit les unes avec les autres. Des commandes de commentaire de journal multiples publient des messages de commentaire de journal séparés sur le ticket et pas nécessairement dans un ordre spécifique.
De plus, si une commande d'ID de ticket d'API de texte apparaît dans le message au début du message ou en entre deux autres commandes d'API de texte, elle est convertie en commentaire de journal. Si la commande précédente est un commentaire de journal (%LOG=…) ou une description de mise à jour (%DESCRIPTION=…), elle est ajoutée à cette commande, au lieu d'être convertie en commentaire de journal distinct.
Utilisation des mots clés par l'API de texte
Vous pouvez utiliser deux types de mots clés comme entrées de l'API de texte.
  • Définitions dans la rubrique [KEYWORDS] du fichier
    text_api.cfg
    : ce type est un groupe de mots clés directement associés aux champs des différentes tables que vous pouvez mettre à jour. Par exemple, la plupart des champs du formulaire Détail de la demande client sont définis dans la section [KEYWORDS]. Ces mots-clés vous permettent de définir des valeurs pour les champs de l'enregistrement que vous mettez à jour ou que vous créez. Par exemple, la ligne ci-dessous définit la priorité de la demande client à 5 :
    %PRIORITY=5
    La section [KEYWORDS] du fichier
    text_api.cfg
    répertorie tous les mots clés. Vous pouvez définir d'autres mots clés, par exemple pour autoriser l'accès de l'API de texte aux champs que vous avez ajoutés lors de la personnalisation de votre schéma de base de données.
  • Les mots clés spéciaux suivants sont toujours définis de la façon suivante, indépendamment du contenu du fichier
    text_api.cfg
    :
Mot clé
Description
ASSET
Utilisé pour attacher un élément à un ticket (valide pour les demandes, les demandes client et les demandes de changement). La valeur indiquée est le nom de l'élément, qui doit déjà exister. Vous pouvez indiquer ce mot-clé plusieurs fois, du fait que plusieurs éléments peuvent être attachés à un ticket.
ATTACHMENT
Utilisé au niveau interne par l'interface de messagerie électronique pour ajouter des pièces jointes électroniques à un ticket.
DESCRIPTION
Spécifie la valeur à utiliser pour le champ de description du ticket. Ce mot-clé est supposé si l'entrée est envoyée à l'API de texte sans mot-clé explicite. Ce mot clé est appliqué automatiquement par l'interface de lecture du courrier entrant lorsque le message ne commence pas par un mot clé mais contient un artefact d'ID de ticket ou mot clé.
Vous pouvez changer la manière dont le mot-clé DESCRIPTION est traité pour les mises à jour utilisant l'entrée suivante dans la rubrique [OPTIONS] du fichier text_api.cfg :
UPDATE_DESC_IS_LOG
Si cette option est définie à YES, la valeur est utilisée pour créer un commentaire de journal. Si la valeur est définie à NO, elle remplace le contenu du champ de description existant.
FROM_EMAILFROM_EMAIL_OVERRIDE
Ces mots-clés sont utilisés par l'interface de messagerie électronique pour établir une correspondance avec le champ Adresse électronique de l'enregistrement ca_contact. Il est également utilisé comme log_agent pour le ticket. S’ils sont tous deux renseignés, FROM_EMAIL est ignoré.
FROM_EMAIL est automatiquement défini par l'interface de lecture du courrier entrant avec l'adresse de l'expéditeur du message.
FROM_PERSID
Utilisé par l'interface de ligne de commande pour définir le log_agent d'une opération (par exemple, si un enregistrement ca_contact ne contient pas d'ID d'utilisateur). Ce mot clé est transféré automatiquement par pdm_text_cmd si le paramètre -p est spécifié
.
La valeur est mise en correspondance avec le champ persistent_id d'un enregistrement ca_contact.
FROM_USERID
Utilisé uniquement dans l'interface de ligne de commande pour définir le log_agent d'une opération. Ce mot clé est transféré automatiquement par
pdm_text_cmd
si le paramètre -u est spécifié. La valeur est mise en correspondance avec le champ ID utilisateur d'un contact.
LOG
Utilisé pour créer une entrée de journal (valide pour les demandes, les demandes de changement, les demandes client et les contacts). Ce mot clé est appliqué automatiquement par l'interface de lecture du courrier entrant lorsque le message ne commence pas par un mot clé mais contient au choix un artefact d'ID de ticket, un mot clé ou un mot clé DESCRIPTION.
PROPERTY
Utilisé pour définir la valeur d'une propriété (valide uniquement pour les demandes, les demandes de changement et les demandes client). A la différence d'autres mots-clés qui sont suivis du signe égal et d'une valeur, la syntaxe du mot-clé PROPERTY doit inclure l'étiquette de propriété, comme suit :
PROPERTY={{property_label}}valeur
Vous devez entrer l'étiquette de propriété
property_label
telle qu'elle figure dans la base de données.
SEARCH
Utilisé uniquement dans l'interface de ligne de commande pour fournir la liste des mots clés qui seront utilisés dans une requête pour mettre à jour plusieurs tickets pour un actif. La valeur est une liste de mots-clés utilisés dans la recherche.
Conventions de saisie des mots clés
Les conventions suivantes s'appliquent au formatage de saisie des mots clés :
  • Préfixez tous les mots clés (y compris PROPERTY) avec un signe de pourcentage (%). Le signe de pourcentage doit être dans la position un de la colonne. Si la première ligne non vide de l'entrée n'a pas de signe de pourcentage au début de la ligne,
    %DESCRIPTION= ou %LOG=
    est utilisé comme préfixe pour les données entrantes, selon si un artefact d'ID de ticket ou mot clé a été trouvé. Si
    %DESCRIPTION est défini
    , le contenu du message jusqu'au premier mot clé est publié comme description du ticket. Si
    %LOG= est défini
    , le contenu du message jusqu'au premier mot clé est publié en tant que commentaire de journal.
  • N'insérez pas d'espace entre le signe % et le mot clé, ni entre le mot clé et le signe égal (=).
  • Ne placez pas les valeurs entre guillemets. Toutes les données situées après le signe = sont supposées être la valeur.
  • Les mots clés ne distinguent pas les majuscules et les minuscules.
  • Si l'entrée inclut des mots clé dupliqués, le dernier mot clé est utilisé ; autrement, l'ordre dans lequel vous spécifiez les paires de mot clé/valeur n'a aucune importance.
  • Entrez les valeurs de mot-clé comme vous le feriez pour le champ correspondant dans l'interface Web. Par exemple, pour indiquer un type de contact Analyste, entrez
    %CONTACT_TYPE=Analyste
    , même si, dans la base de données, cette valeur est stockée sous la forme d'un nombre entier. Le mot clé
    CONTACT_TYPE
    est défini dans
    text_api.cfg
    , de sorte qu'il convertit la valeur spécifiée de manière à ce qu'elle corresponde à la valeur stockée.
    La sensibilité ou non à la casse dépend du SGBD sous-jacent.
  • Les données de la chaîne peuvent s’étendre sur plusieurs lignes.
Formater un courriel pour mettre à jour un ticket
Un utilisateur peut formater un courriel pour créer ou mettre à jour un ticket.
Pour formater un courriel afin de créer ou de mettre à jour un ticket, utilisez les champs suivants :
  • A
    Spécifie le nom de la boîte aux lettres affectée au contact CA SDM défini comme utilisateur à forts privilèges.
  • De
    Spécifie l'expéditeur du courriel. Cette personne doit être définie dans la table
    ca_contact
    , sauf si l'option
    Autoriser l'accès anonyme
    est spécifiée dans la règle de la boîte aux lettres applicable.
    L'adresse de l'expéditeur fait généralement partie de la configuration de votre programme de messagerie et ne se définit pas en général au niveau du message.
  • Pièces jointes
    Joint les documents et les autres fichiers au courriel pour envoyer des pièces jointes à l'API de texte.
  • Objet
    Fait correspondre des mots clé dans une chaîne de filtrage de la règle de la boîte aux lettres, particulièrement lors de la création d'un ticket.
  • Corps
    Spécifie le corps du message à l'aide de l'API de texte. Vous pouvez spécifier le mot clé
    ISSUE_ID
    ,
    REQUEST_ID
    ou
    CHANGE_ID
    , selon le type de ticket afin de créer ou de mettre à jour un ticket.
Délimiteurs de début et de fin des courriels
Certaines interfaces de système de messagerie ajoutent des informations au début ou à la fin du message (par exemple, codage MIME), qui peuvent nuire au fonctionnement de l'interface .
Si votre interface de messagerie électronique ajoute des informations, vous pouvez utiliser les délimiteurs suivants :
startrequest et endrequest. L'interface de messagerie électronique ignore les informations qui sont spécifiées avant et après ces deux balises.
La fonctionnalité MailEater de CA SDM prend désormais en charge les courriels entrants aux formats HTML et RTF.
Exemple : Utilisation des délimiteurs start-request et end-request
"start-request" message_body "end-request"
Utilisation des artefacts par l'API de texte
L'API de texte traite l'objet ou le corps des notifications par courriel. Les règles de la boîte aux lettres vous permettent d'identifier des artefacts et des valeurs utilisés par l'API de texte. Par exemple, vous pouvez définir la règle pour les incidents comme l'incident:{{object_id}} afin de détecter l'incident:1234 qui se traduit par %INCIDENT_ID=1234 pour l'API de texte. 1234 est le ref_num pour l'incident. Parce que l'artefact doit être unique dans le courriel et facile à trouver, vous pouvez rendre l'artefact plus distinctif comme %Incident:{{object_id}}%.
Faites suivre le mot clé {{object_id}} d'un caractère qui ne soit pas une lettre, un numéro, une virgule, une barre oblique (/), le signe plus (+) ou égal (=) parce que ces caractères peuvent apparaître dans un artefact. Dans le cas contraire, les caractères qui suivent l'artefact peuvent être mal interprétés comme faisant partie de la valeur de l'artefact ou un caractère dans la valeur de l'artefact peut être interprété à tort comme un caractère qui suit la valeur.
L'interface de lecture du courrier entrant permet d'effectuer les opérations suivantes :
  1. Elle recherche l'artefact dans un courriel (comme Incident:1234) qui correspond au ticket approprié ou à un autre objet pris en charge par l'API de texte.
  2. Convertit l'artefact en jeton de l'API de texte (comme %INCIDENT_ID=1234).
  3. L'interface de lecture du courrier entrant soumet le message portant une indication à l'API de texte. L'API de texte traite le courriel, applique le texte, les commandes ou les deux qu'il contient sur le ticket approprié et génère un courriel de réponse automatique indiquant si le message qu'il a reçu a été correctement appliqué. Selon les actions effectuées, un courriel de notification est envoyé également pour indiquer certains événements spécifiques, comme la création d'un ticket.
Configuration des réponses de notification pour mettre à jour des tickets
Le démon de l'API text (pdm_text_nxd) crée et met à jour des tickets avec des informations en provenance d'interfaces externes, comme la ligne de commande et le courriel. Vous pouvez configurer la messagerie à utiliser l'API text pour que les utilisateurs (contacts) puissent mettre à jour des tickets en répondant à des notifications par courriel. Le texte de la réponse est ajouté comme une activité de commentaire de journal au ticket.
Pour configurer des réponses de notification afin de mettre à jour des tickets, procédez comme suit :
  1. Définissez la méthode de notification que le contact utilise sur pdm_mail -T
    reply_email_address
    ou pdm_mail -F
    reply_email_address
    La méthode
    reply_email_address
    spécifie l'adresse entrante pour la boîte aux lettres. Lorsque le contact clique sur répondre dans un courriel, cette adresse est renseignée à partir de l'adresse de réponse ou de l'adresse de l'expéditeur du message auquel il répond.
    -T définit l'adresse de réponse. -F définit l'adresse de l'expéditeur, qui est utilisée comme l'adresse de réponse si une adresse distincte n'est pas spécifiée.
    Certains programmes de messagerie ne respectent pas ou ne peuvent pas respecter l'adresse de réponse.
  2. Créez ou mettez à jour une règle de la boîte aux lettres en utilisant un mot clé de l'API de texte.
    Les artefacts définis par l'utilisateur dans les filtres de la règle de la boîte aux lettres remplacent les mots clés de l'API de texte suivants :
Objet
Mot clé de l'API de texte
Identificateur
Incident
%INCIDENT_ID
Ref_Num
Problème
%PROBLEM_ID
Ref_Num
Demande
%REQUEST_ID
Ref_Num
Chg_ref_num
%CHANGE_ID
Chg_ref_num
Demande client
%ISSUE_ID
Ref_Num
  1. Créez ou mettez à jour une expression de notification qui correspond à la règle.
  2. Créez ou mettez à jour un modèle de message qui utilise l'expression de notification.
  3. Mettez à jour la règle de la boîte aux lettres que vous avez créée à l'étape 2 pour spécifier le modèle de message que vous avez créé ou mis à jour à l'étape 4.
Après la réception de la notification par l'utilisateur et la réponse apportée par celui-ci, les actions suivantes se produisent :
  1. Lorsque la chaîne de filtrage est trouvée, le mot clé de l'ID du ticket et la valeur correspondants indiqués, le cas échéant par l'espace réservé, sont ajoutés au message.
  2. Si un artefact d'ID de ticket correspondant est trouvé, le ticket correspondant est mis à jour, avec au choix, un commentaire de journal, une nouvelle description, ou d'autres valeurs conformément au texte, aux mots clés et aux commandes dans le message.
  3. Si un artefact d'ID de ticket correspondant n'est pas trouvé, un ticket est créé avec une description et d'autres paramètres, conformément au texte, aux mots clés et aux commandes dans le message.
Exemple de définition d'une réponse à une notification d'incident
Cet exemple montre comment définir une réponse à une notification d'incident.
Pour définir une réponse à une notification d'incident, procédez comme suit :
  1. Créez une règle de boîte aux lettres en utilisant les champs et les valeurs suivants :
    • Filtre : contenu du corps
    • Chaîne de filtre : %Incident:{{object_id}}%
    • Ignorer la casse : Oui
    • Action : mettre à jour un objet
    • Objet Action : incident
  2. Créez une expression de notification qui inclut la règle suivante :
    • Symbole : réponse à un incident
    • Code : IncidentReply
    • Actif : actif
    • Description : Commentaires qui incorporent la réponse pour un incident, un problème ou une demande.
    • Expression : Pour ajouter un commentaire à votre @{call_req_id.type.sym}, répondez simplement à ce courrier ou incluez la ligne ci-dessous (sur une ligne séparée) :
      %Incident:{call_req_id.ref_num}%
      Ignorez le préfixe call_req_id dans le texte de réponse automatique de la règle de boîte aux lettres. Ce préfixe applique un contexte dans lequel se trouvent déjà le texte de la règle de boîte aux lettres, et un tel changement de contexte n'est pas valide lorsqu'une action est déjà en cours dans ce contexte.
  3. Créez ou actualisez un modèle de message qui utilise l'expression de notification comme suit :
    • Corps du message de la notification
      This is a simple notification. @{notification_phrase[IncidentURL1].phrase}
  4. Actualisez la règle de boîte aux lettres que vous avez créée à l'étape 1 pour spécifier le modèle de message que vous avez créé à l'étape 3, comme suit :
    Modèle de message :
    nom de règle de boîte aux lettres
Mise à jour d'un exemple de ticket par un utilisateur
L'exemple suivant montre comment un utilisateur final (John Smith) répond à une notification par courrier électronique pour mettre à jour un ticket d'incident.
Le corps ou l'objet du courriel inclut l'identificateur d'objet. L'espace réservé {{object_id}} dans la chaîne de filtrage indique l'identificateur d'objet.
  1. Une notification est envoyée à John Smith et inclut les instructions suivantes :
    In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself). %Incident:1234%
  2. John Smith répond à la notification de la façon suivante :
    This is my response...
  3. L'interface de lecture du courrier entrant reçoit la version de texte suivante du courriel de John Smith :
    This is my response... From: Service Desk Sent: Wednesday, September 18, 2009 10:22 AM To: Smith, John Subject: Simple Notification This is a simple notification. In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself). %Incident:1234%
  4. L'interface de lecture du courrier entrant traite les règles dans l'ordre et trouve l'artefact %Incident :1234% :
    This is my response... From: Service Desk Sent: Wednesday, September 18, 2009 10:22 AM To: Smith, John Subject: Simple Notification This is a simple notification. In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself). %INCIDENT_ID=1234
  5. L'interface de lecture du courrier entrant ajoute les mots clé de l'API de texte et la valeur {{object_id}} à une instruction %INCIDENT_ID= et laisse un marqueur où la valeur de {{object_id}} a été trouvée. Le texte suivant affiche les données qui sont envoyées à l'API de texte. Le texte en gras affiche les valeurs ajoutées par l'interface de lecture du courrier entrant.
    %LOG=This is my response...
    From: Service Desk
    Sent: Wednesday, September 18, 2009 10:22 AM
    To: Smith, John
    Subject: Simple Notification
    This is a simple notification.
    In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself).
    %Incident:-((...))-%
    %INCIDENT_ID=1234
  6. L'API de texte ajoute un commentaire de journal pour l'Incident 1234.
Méthodes de conversion de mot clé
De nombreux mots-clés définis dans le fichier text_api.cfg sont associés à une méthode de conversion de la valeur indiquée en une valeur appropriée pour le stockage dans la base de données. Cette fonction permet aux utilisateurs de préciser les valeurs qu'ils souhaitent dans l'interface Web, sans avoir à connaître l'implémentation sous-jacente.
Le fichier de configuration comporte plusieurs exemples de ce type de définition de mot clé, notamment ISSUE.PRIORITY et CONTACT.CONTACT_TYPE. Si vous devez définir d'autres mots clés (par exemple, pour permettre l'accès de l'API de texte aux champs que vous avez ajoutés lors de la personnalisation de votre schéma de base de données), vous pouvez utiliser l'une des méthodes prédéfinies ci-dessous :
Méthode
Type de sortie
lookup_actbool
INTEGER
lookup_asset_by_name
UUID
lookup_asset_by_persid
UUID
lookup_chg_category
STRING
lookup_chg_status
STRING
lookup_cnt_by_email
UUID
lookup_cnt_by_last_first_middle
UUID
lookup_cnt_by_logonid
UUID
lookup_cnt_by_persid
UUID
lookup_cnt_meth
INTEGER
lookup_cnt_type
INTEGER
lookup_company
UUID
lookup_cr_status
STRING
lookup_cr_template
STRING
lookup_domain
INTEGER
lookup_grc
INTEGER
lookup_group
UUID
lookup_impact
INTEGER
lookup_iss_category
STRING
lookup_iss_status
STRING
lookup_loc
UUID
lookup_mfr_model
UUID
lookup_nr_family
INTEGER
lookup_org
UUID
lookup_person_contacting
INTEGER
lookup_position
INTEGER
lookup_priority
INTEGER
lookup_prob_category
STRING
lookup_product
INTEGER
lookup_resource_status
INTEGER
lookup_service_lvl
STRING
lookup_severity
INTEGER
lookup_state
INTEGER
lookup_timezone
STRING
lookup_type_of_contact
INTEGER
lookup_urgency
INTEGER
lookup_workshift
STRING
Si la valeur que vous devez convertir n'est rencontrée par aucune de ces méthodes prédéfinies, vous devez écrire une méthode personnalisée. La méthode doit utiliser une valeur de type chaîne (STRING) comme entrée et renvoyer une valeur (INTEGER, STRING ou UUID) comme sortie. "Renvoyer une valeur -1 (ou "-1") pour indiquer qu'il n'a pas été possible de déterminer la valeur qui n'est donc pas définie. "Pour l'UUID, renvoyer "(uuid) NULL".
Par exemple, vous pouvez développer une méthode pour convertir un ID d'utilisateur en une référence de la table ca_contact. La valeur entrée, par exemple Administrateur, est transmise à la méthode, qui renvoie l'ID de la table ca_contact pour l'ID d'utilisateur Administrateur.
La manière dont vous définissez les mots-clés dans le fichier de configuration permet de définir plusieurs mappages de mots-clés pour le même champ, notamment diverses méthodes de conversion en fonction de la valeur spécifiée. Par exemple, la personne assignée peut avoir plusieurs mappages de mots-clés différents pour indiquer la manière de définir sa valeur en fonction des différentes valeurs entrées. Une entrée peut être l'ID d'utilisateur, une autre le nom, le prénom ou le deuxième prénom, et une troisième l'ID ca_contact réel (par exemple, 793ED69B4E87A545BD8E911834D829FC). Chaque mot-clé est mappé sur une autre méthode de conversion, à l'exception de la dernière qui ne nécessite pas de conversion.