L'API TrackTik dispose de tous les points de terminaison et de webhooks dont vous avez besoin pour un déclenchement bidirectionnel signale -> répartition mobile -> flux de travail -> flux de résolution.
Dans l'écosystème TrackTik, les entités de données centrales pour un flux de déclenchements et répartitions mobiles basé sur une caméra sont les suivantes :
- Client Sites (a kind of Account, the physical location that needs a guard dispatched to)
- Types de tâches (types de travail, une sorte de catégorisation de haut niveau de la raison de l'envoi)
- Modèles de rapport (information historique essentielle pour l'agent et pour enrichir les métadonnées du répartition mobile)
- Répartitions mobiles (Dispatches)
- Notes sur les répartitions mobiles (notes ad hoc supplémentaires et facultatives pour le répartiteur et l'agent)
- Flux de travail (modèles qui définissent les étapes à exécuter lors d'un répartition mobile)
- Instances de flux de travail (instances d'un modèle de flux de travail, une par répartition mobile)
- Journaux des instances de flux de travail (les journaux de l'exécution ds instances de flux de travail : assigné-> en route -> arrivé au location du site client -> terminé)
De votre système vers TrackTik
Dans le diagramme ci-dessous, vous voyez un flux unidirectionnel à partir d'un mécanisme de déclenchement d'incident basé sur une caméra qui crée ensuite des répartitions mobiles dans l'application Trackforce au moyen de son API.
Chaque portail Web TrackTik a des données différentes
Lorsque vous planifiez une architecture pour déployer votre intégration sur plusieurs portails TrackTik différents (domaines), vous devez prendre en compte dans vos stratégies de recherche, de mappage des données et des identifiants que chaque portail a une base de données différente. Donc il y aura des configurations différentes et des identifiants uniques (comme les ID des répartitions mobiles, des sites de clients, des modèles de rapport, etc.)
Un portail TrackTik peut permettre la personnalisation du champ clients.customId, alors que d'autres ne la sont pas.
Une équipe administrative d'un portail TrackTik peut être d'accord pour qu'une intégration ait ses propres modèles de rapport, tandis qu'une autre exigera que vous ajoutiez des champs supplémentaires à ceux qu'elle possède déjà.
Un portail TrackTik peut avoir une arborescence régionale de 5 nœuds avant que les sites de clients soient assis. Vous devez donc planifier l'UX de votre solution aura besoin de gérer une arborescence régionale et comment il offrira un outil de sélection des sites de clients. Une autre instance peut également n'avoir aucune région.
Certains portails TrackTik peuvent avoir des dizaines de milliers de sites de clients. Comment votre interface utilisateur va-t-elle gérer cela? Quel type de mécanisme de recherche allez-vous utiliser?
Un portail TrackTik peut avoir 60 modèles de rapport, ou 600. Votre solution et son interface utilisateur seront-ils évolutives?
Heureusement, il n'est pas nécessaire de tout cartographier à l'avance ni de créer un trop grand nombre de treillis. Il existe un moyen de découvrir le paysage et d'atteindre dynamiquement les minimums dont vous avez besoin. Nous en parlerons plus tard.
Conditions préalables des données et du mappage
Pour utiliser pleinement l'API pour une intégration basée sur les répartitions mobiles avec n'importe quel portail TrackTik, vous devrez être en mesure de vérifier l'existence des éléments suivants (et pour certains, les mapper) :
- Des sites de clients (parfois appelés "compte") (API /clients) existent.
- Les types de travail (API /task-types) existent
- Un modèle de rapport existe pour la répartition mobile (API /report-templates), et un modèle de rapport a 1:plusieurs enfants de champs de modèle de rapport (API /report-template-fields).
- Un flux de travail existe (API /workflows), et lorsqu'une répartition mobile est créée, c'est le modèle utilisé pour créer des Instances de flux de travail (API /workflow-instances), et les étapes des instances de flux de travail qui sont exécutées par un agent pendant une répartition mobile créeront des journaux d'instances de flux de travail (API /workflow-instance-logs).
- OPTIONNEL pour l'analyse : une catégorie d'incident (API /report-flags) existe.
Contexte régional
Presque tout dans un portail Web TrackTik sera lié à une région, soit directement (comme un type de travail), soit en tant que parent de quelque chose (comme un site de client qui se trouve à plusieurs niveaux dans une arborescence régionale, y compris un parent de multi-site avec des sous-sites).
Lors de la conception de votre solution, vous devez déterminer et éventuellement coordonner si les sites de clients cibles vers lesquels les répartitions mobiles sont effectués se trouvent tous dans la même région ou n'importe où dans l'arborescence régionale du portail Web.
Voici les éléments parents immédiats de vos conditions préalables en matière de données et de mappage, afin d'en prendre connaissance et de pouvoir les filtrer par région :
- Type de travail aka type de tâche (appartient à une région, mais peut être défini comme global pour l'application Web/application mobile)
- Modèle de rapport (peut appartenir à une région, mais peut être défini comme global pour l'application Web/application mobile)
- Champ du modèle de rapport (appartient à un modèle de rapport)
- Site de client (appartient à une région et éventuellement à un multi-site).
- Flux de travail (peut appartenir à un type de travail aka type de tâche)
Voici une comparaison entre une structure régionale complexe (à gauche) et une structure régionale simple (à droite) :
NB : Les modèles de rapport peuvent être autonomes ou utilisés à des fins multiples, comme pour les types de travail. Ces modèles de rapports polyvalents sont indiqués en gris.
When navigating records in the API, you will typically be able to know which item is "parent" to another when there is a "region", "client" or "account" key in the response. E.g. a /clients record has a "region" key. A /task-types record has a "region" key.
L'approche idéale pour la découverte des identifiants pour faire du mapping
Once you've negotiated the Regional scope during the Business Analysis phase of your approach, you will find that you can start with the Job Types/task-types and derive the most important relationships and data dependencies for creating Dispatches.
Par exemple La portée régionale est "all/any", ce qui signifie qu'il n'y a pas de filtrage pour les régions.
- Obtain a list of task-types in full, or based on a naming convention the Business layer might provide you:
GET /task-types
OR with filter
GET /task-types?name:contains=pattern OR GET /task-types?customId:contains=pattern
- Each of the records in the responses of #1 will have the ID of the Report Template. You can get the IDs of the report-template-fields by iterating through those:
GET /report-templates/{id}?include=reportFields
- If the Business layer has told you to expect Report Templates that have a field for an Incident Category (report-flags), then you can get the ID of the report-flag within the reportFields JSON sub-object from step #2, or if they give you a name of a particular report-flag, you can look up its ID directly:
GET /report-flags?name:contains=name_of_flag
- Si vous avez l'intention de mapper la liste des sites de clients dans le portail TrackTik, vous obtiendrez cette liste comme dans les exemples suivants :
GET /clients
OU avec une convention de nommage :
GET /clients?name:contains=pattern OU GET /clients?customId:contains=pattern
NB : Votre solution n'aura pas besoin de récupérer une liste de flux de travail. Lorsqu'une répartition mobile est créé, une Instance de flux de travail est créée, et vous serez plus intéressé par l'évolution du flux, les données se trouvant dans /workflow-instance-logs . L'infrastructure en nuage de TrackTik peut vous les envoyer au moyen de la méthode POST à un point de terminaison API/webhook que vous contrôlez. Nous y reviendrons plus tard.
After all the above, if your solution is based on a list of predetermined ID numbers or it searches dynamically with patterns, you'll still meet all the data dependencies required to create Dispatch Tasks.
Opportunités de mappage de champs
Lorsque deux systèmes communiquent entre eux, ils doivent mutuellement connaître leurs identifiants afin de pouvoir effectuer les correspondances et les appariements nécessaires. Grâce à la gestion architecturale du domaine, vous vous sentirez poussé à mettre vos identifiants/clés étrangères dans l'application TrackTik, mais à ce jour, les possibilités ne sont pas idéales. De nombreuses entités de données ont un champ appelé "customId" qui peut être utilisé pour mapper vos identifiants, mais ces champs sont modifiables par l'application Web et les administrateurs peuvent les modifier si leur formation ou l'attention qu'ils y portent ne sont pas adéquates. De nombreux partenariats et intégrations passés les ont utilisés avec succès, mais il ne s'agit pas de champs protégés.
Clés primaires : id
La première chose à savoir est que toute entité de données accessible au moyen de l'API avec une clé "id" est la clé primaire de la base de données. Elle est donc unique et immuable. Vous pouvez compter sur eux.
Mais n'oubliez pas que chaque application Web TrackTik possède sa propre base de données, et qu'elles seront donc différentes d'une instance à l'autre. Il peut donc être utile de prendre en compte les domaines de l'application Web. Si vous intégrez une entreprise.staffr.net et une entreprise2.staffr.ca, l'élément employee.id=12 d'un site Web ne sera pas la même personne que celle du site Web suivant.
Types de tâches
Les types de tâches ont une valeur "id", ainsi qu'une valeur "name" et "prefix" (prefix fonctionne comme un customId, un code de chaîne). Vous pouvez analyser les besoins de l'entreprise par rapport à la meilleure approche et négocier avec l'administrateur du site Web TrackTik au sujet des conventions de dénomination et si vous pouvez dédier l'identifiant de votre solution à "type d'événement que la caméra a détecté" au champ task-types.customId.
Modèles de rapport
Les modèles de rapport ont une valeur "id", ainsi qu'une valeur "name" et "customId". Comme précédemment, analysez les besoins d'affaire, ce qui est utilisé et ce que vous pouvez utiliser pour votre solution, y compris les discussions habituelles sur les conventions de dénomination. Ce point est moins important, car si vous découvrez les enregistrements depuis les types de tâches jusqu'aux modèles de rapport associés, il existe déjà une relation descendante 1:1 avec les types de tâches.
Sites de clients, régions et comptes (les clients et les régions sont des types de comptes; des vues de comptes)
Pour les clients et les régions, vous disposez de "id", "company", ou "name", mais customId est moins disponible. Les valeurs customId de ces entités sont généralement déjà utilisées ou ne sont pas modifiables par l'utilisateur si l'application Web TrackTik a été configurée pour les gérer elle-même.
Il existe des arbres régionaux, mais il n'est pas nécessaire de les mapper dans la plupart des solutions. Une répartition mobile est lié à un site de client en tant que 1:1, et ses exigences en matière de données de type de tâche et de rapport sont 1:1, et chacune d'entre elles est 1:1 avec une région. Mais vérifiez les besoins d'affaire si vous devez construire une interface utilisateur avec une sélection régionale, et pour valider la façon dont les données seront organisées dans le portail TrackTik.
Création d'une répartition mobile
Vous pouvez voir que le premier appel à l'API consiste à créer une répartition mobile comme suit :
POST /dispatch-tasks
{
"customId": "200019810",
"priority": "URGENT",
"client":50,
"report": {
"reportTemplate": 28,
"account": 50,
"geoLocation": {"latitude" : 45.508, "longitude" : -73.56},
"reportFields": [
{"field": 29, "value": "12:30"},
{"field": 31, "value": "Something undesirable has occurred"},
{"field": 30, "value": "Interior Patrol"}
]
},
"startedOn": "20220331122600",
"taskType": 9,
"locationType": "ACCOUNT_ADDRESS"
}NB : Dans l'exemple ci-dessus, le champ "geoLocation" a été ajouté en tant que donnée supplémentaire facultative (montrant que les champs du schéma du point de terminaison /reports sont autorisés, mais qu'ils ne sont pas obligatoires).
Dans la charge utile ci-dessus, vous pouvez voir les index d'entiers pointant vers les dépendances mentionnées précédemment :
Données de base
- Site de client 50 (/clients/50)
- priorité URGENT (une énumération, voir la documentation sur les spécifications de l'API)
- CustomId est ce que vous voulez, comme l'identifiant unique que vous souhaitez utiliser dans votre système intégré.
- startedOn est un datetime serial de yyyymmddhhiiss (NB : standard ISO, où i représente les minutes)
- taskType 9 (/task-types/9)
- locationType ACCOUNT_ADDRESS (une énumération, voir la documentation sur la spécification de l'API)
Rapport sur la répartition mobile (information sur la valeur commerciale)
- Modèle de rapport 28 (/report-templates/28)
- Compte (répétition de l'inscription du site de client, donc /clients/50)
- Liste de champs du modèle de rapport 28 avec 1 valeur pour chacun (/report-template-fields?reportTemplate=28)
En savoir plus sur les modèles de rapport et leurs champs
L'application TrackTik Suite d'opérations de gardiennage dispose d'une section Paramètres et d'une section Modèles de rapport permettant de créer ou de modifier des modèles de rapport afin de répondre à nos besoins d'affaires de collecter d'information initiale à associer à une répartition mobile. Le modèle de rapport avec l'ID 28 a été mentionné juste au-dessus. Voyons cela de plus près :
GET /report-templates/28
{
"name": "Mobile Patrol Report",
"details": "Used to record the details of a completed Mobile Patrol task",
"tag": "",
"adminOnly": false,
"id": 28,
"defaultLanguage": "EN_US",
"translatable": true
}Les données semblent peu nombreuses et ne mentionnent pas la liste des champs, car il s'agit uniquement des métadonnées du modèle de rapport. Les champs peuvent être vus à partir d'un point de terminaison différent :
GET /report-template-fields?reportTemplate=28
{
"reportTemplate": 28,
"parent": {
"type": "report-templates",
"object": 28
},
"id": 29,
==> "label": "Arrival Time:",
"name": "f_29",
==> "type": "TIME",
"required": false,
"adminOnly": false,
"displayOrder": 100,
"extra": "",
"isDispatcherField": false,
"fieldTag": "",
"confidential": false
},
{
"reportTemplate": 28,
"parent": {
"type": "report-templates",
"object": 28
},
"id": 30,
==> "label": "Activity Performed:",
"name": "f_30",
==> "type": "LIST_MULTIPLE",
"required": false,
"adminOnly": false,
"displayOrder": 98,
"extra": "Interior Patrol\nExterior Patrol\nStationary Post\nLocation Inspection",
"list": [
"Interior Patrol",
"Exterior Patrol",
"Stationary Post",
"Location Inspection"
],
"listItems": [
==> "Interior Patrol",
"Exterior Patrol",
"Stationary Post",
"Location Inspection"
],
"isDispatcherField": false,
"fieldTag": "",
"confidential": false
}
...etc.
Dans la réponse JSON ci-dessus, nous voyons deux champs (parmi plusieurs non montrés) définis dans le modèle de rapport. Le premier est de type TIME avec l'étiquette/le message "Heure d'arrivée", et le second est une liste déroulante (de type LIST_MULTIPLE) permettant de choisir une valeur dans une liste avec l'étiquette/le message "Activité réalisée".
La clé "value" dans la section Dispatch Task Report serait une valeur temporelle (hh:ii) pour le premier champ, et la chaîne "Interior Patrol" (si elle est choisie) serait la valeur pour le second.
Vous devriez consulter d'autres champs de modèle de rapport dans les enregistrements de votre portail Web pour voir les autres types possibles et vous familiariser avec eux.
Flux de travail
Lorsque vous créez une répartition mobile, une instance de son flux de travail (si un flux de travail est configuré pour le type de tâche) est également créée. L'instance de flux de travail créée peut être consultée en tant que liste de relations de la répartition mobile :
GET /dispatch-tasks/653?include=workflowInstance
{
"customId": "2024-12-13-15-37",
"taskType": 3,
"priority": "URGENT",
"priorityRating": 2,
"taskInstructions": "",
"scheduled": "NOW",
"startedOn": "2024-12-13T20:31:00+00:00",
"startDateTime": "2024-12-13T20:31:00+00:00",
"endedOn": null,
"endDateTime": null,
"plannedDurationInMinutes": null,
"reminderInMinutes": null,
"reminderAt": null,
"alarmOrganization": null,
"client": 687,
"account": 687,
"priceTier": null,
"status": "OPEN",
"active": "ACTIVE",
"assignedUser": null,
"assignedGroup": null,
"assignedGroupResource": null,
"assignedVendor": null,
"reportTemplate": 28,
"report": 6180,
"location": 78,
"locationType": "ACCOUNT_ADDRESS",
"closedOn": null,
"parentDispatchTask": null,
"alarm": null,
"id": 653,
==> "workflowInstance": {
"currentStatus": 11,
"workflow": 2,
"modifiedOn": "2024-12-13T20:39:52+00:00",
"startedOn": "2024-12-13T20:39:52+00:00",
"dispatchTask": 653,
==> "id": 590
}
}
L'instance de flux de travail dont l'ID est 590 dans l'exemple de charge utile ci-dessus est l'ID à conserver pour pouvoir suivre le parcours de la répartition mobile à travers les étapes de son instance de flux de travail.
Ces étapes sont accessibles comme suit :
GET /workflow-instance-logs?workflowInstance=590&include=status
{
"user": 1002,
"timeZone": "America/New_York",
"createdOn": "2024-12-13T16:01:14+00:00",
"workflowInstance": 590,
"id": 2181,
"status": {
"name": "New Alarm",
"tag": "New Alarm",
"workflow": 2,
"formatBackgroundColor": "Black",
"formatTextColor": "WHITE",
"warningThresholdInMinutes": 1,
"alertThresholdInMinutes": 5,
"id": 11
}
},
{
"user": 1002,
"timeZone": "America/New_York",
"createdOn": "2024-12-13T16:04:36+00:00",
"workflowInstance": 590,
"id": 2182,
"status": {
"name": "Assigned",
"tag": "Assigned",
"workflow": 27,
"formatBackgroundColor": "red",
"formatTextColor": "black",
"warningThresholdInMinutes": 1,
"alertThresholdInMinutes": 5,
"id": 12
}
}
Ce passage par Répartition mobile -> Instance de flux de travail-> Journaux d'instance de flux de travail est important à comprendre lorsque vous décidez d'utiliser l'API pour faire avancer un flux de travail à travers des transitions supplémentaires (si vous avez besoin de le faire de manière procédurale plutôt que sous forme de tâches manuelles effectuées par les agents et les administrateurs), et/ou si vous avez l'intention de faire des appels vers votre système en utilisant un webhook — plus d'information à ce sujet plus tard dans la section intitulée De TrackTik vers votre système.
Création de flux de travail et de transitions
Les flux de travail sont la séquence des étapes possibles qu'un agent assigné à une répartition mobile suivra (en partie ou en totalité). L'application Web TrackTik offre une approche basée sur une interface graphique facile à utiliser pour les créer, mais elles peuvent également être créées à l'aide de l'API.
Avancer les flux de travail
Normalement, ce sont les administrateurs et les agents qui font avancer les étapes d'un flux de travail jusqu'à sa fin (anticipée ou complète), mais les transitions et les étapes du flux de travail peuvent également être déclenchées par l'API.
De TrackTik vers votre système
Jusqu'à présent, nous avons révisé le flux d'information et les étapes d'exécution qui font progresser les processus commerciaux gérés à partir du logiciel TrackTik et à l'intérieur de celui-ci. Mais pour que votre système participe au processus APRÈS la création d'une répartition mobile (ou d'une autre étape), vous devez être en mesure de suivre l'évolution d'une répartition ou d'une réponse, ce qui se fait en recevant des données de TrackTik.
TrackTik peut envoyer de l'information à une API webhook que vous définissez et contrôlez, en tant que fonctionnalité inhérente à votre système ou à votre logiciel intermédiaire que vous écrivez vous-même (à la main, service en nuage, quelle que soit votre architecture préférée). Quelle que soit la solution utilisée par votre système, il doit avoir un webhook basé sur l'API REST et pouvant recevoir des méthodes POST avec des charges utiles JSON.
Le service TrackTik qui effectue des appels POST/call-out à votre webhook de l'API REST s'appelle Events Subscriptions (abonnements aux événements). Un point de terminaison API dédié permet de configurer ces appels en termes d'identifiant et de secret du client, de notifications par courrier électronique, de déclencheurs, de filtres, de mise en forme de la charge utile et de mécanisme de relance.
Consultez le guide d'abonnement aux événements ( https://support.tracktik.com/hc/en-us/articles/24446820229911-Events-Subscriptions-aka-Call-outs-Webhooks ) pour vous familiariser avec toutes ses capacités avant de poursuivre avec le reste de ce guide.
Deux stratégies
Lorsque vous créez une répartition mobile, que son type de tâche crée une instance du flux de travail qui lui est assigné et que vous souhaitez capturer des données relatives au parcours des étapes suivies par le flux de travail dans votre propre système sous la forme d'un appel à votre webhook, vous devez prendre une décision en matière de stratégie de mise en œuvre :
(A) I want to have a separate Events Subscription for each Workflow Instance, making sure to create the subscription myself, collect its data like the Dispatch Task and Workflow Instance and Workflow Instance Logs by using a filter on Dispatch Task and Workflow Instance IDs, until the Workflow Instance completes its journey, and then retire/halt the Events Subscription.
Ou
(B) I want to subscribe to ALL Workflow Instance lots via a single Events Subscription, and I'll aggregate data in my system on the Dispatch Task ID, Workflow Instance ID and Workflow Instance Logs IDs."
La plupart de nos partenaires qui configurent un abonnement à des événements ne veulent pas avoir à créer ou à retirer des abonnements à des événements à plusieurs reprises, car la complexité de l'administration et de la récupération est beaucoup plus grande en raison du grand nombre d'abonnements différents.
Almost everyone chooses approach (B), and it's also what we recommend.
Meilleure stratégie : s'abonner une fois, capturer tout, agréger dans son propre système
Pour souscrire à tous les journaux d'instances de flux de travail et relier la répartition mobile et son instance de flux de travail dans votre système, vous devez surveiller les déclencheurs créés et mis à jour.
Un exemple de configuration que vous pouvez POSTER au point de terminaison /events-subscriptions est présenté ci-dessous :
{
"customId": "WFI-ANY",
"name": "Steps progression of any Workflow Instance",
"events": [
"entity:workflow-instance-logs:created",
"entity:workflow-instance-logs:updated"
],
"entityResponse": {
"include": [
"status",
"user",
"workflowInstance"
]
},
"contextFilters": {
"filters": [
{
"tag": "context.*",
"includeChildren": true
}
]
},
"url": "https://webhook.site/fd152...",
"failureEmail": "fd152...@email.webhook.site",
"secretHeaderName" : "TrackTik-subscription-secret-without-spaces",
"secret" : "B2C6011...."
}
Les "qui déclenchent un appel à mon système" sont les suivants :
"events": [ "entity:workflow-instance-logs:created", "entity:workflow-instance-logs:updated" ]
Et l'objet include sert simplement à ajouter des détails (au moyen de 3 listes de relations, comme des sous-requêtes jointes) à la charge utile pour inclure plus d'information qui ne sont pas fournies par défaut.
context.region.* indique à l'abonnement de communiquer tous les événements qui se produisent dans toutes les régions, sinon * serait la valeur region.id pour limiter les appels aux seuls événements de cette région.
includeChildren permet d'indiquer à l'abonnement de se déclencher également pour tous les événements concernant les régions enfants dans son contexte parental.
customId et name sont des champs descriptifs que vous pouvez définir.
url est l'adresse de votre webhook/écouteur.
failureEmail est l'adresse à laquelle les messages d'erreur doivent être envoyés.
secretHeaderName et secret servent à l'authentification avec votre webhook.
Pour plus de détails sur la configuration de l'abonnement aux événements, reportez-vous au guide autonome mentionné plus haut.
OPTIONNEL :
- Si vous souhaitez surveiller les mises à jour de la répartition mobile parente, vous pouvez créer un deuxième abonnement aux événements pour entity:dispatch-tasks:updated, ou l'inclure en tant que liste de relations dans l'abonnement aux journaux de l'instance de flux de travail en ajoutant une autre ligne au tableau includes en utilisant un membre point comme workflowInstance.dispatchTask.
Problèmes courants et solutions
Vous avez des difficultés à récupérer la liste des types de tâches ou des modèles de rapports.
Cela signifie que vous avez appliqué un filtre régional qui omet ce dont vous avez besoin, ou que les données avec lesquelles vous travaillez n'ont pas été organisées (au moyen des contextes régionaux) de la manière attendue par votre solution.
Discutez les régions auxquelles appartiennent les dépendances de données avec la couche d'affaires, avec les administrateurs qui configurent le portail TrackTik.
Vous devez fournir plus d'information dans le rapport sur les répartitions mobiles que le modèle de rapport permet.
Tout d'abord, vous saurez exactement combien de champs vous avez et leurs numéros d'identification en demandant aux responsables d'entreprise de vous indiquer les types de tâches à utiliser, qui contiennent des données listant la connexion 1:1 à un modèle de rapport. Et comme il est décrit plus haut dans ce guide, vous pouvez consulter le nombre total de champs et leurs types de données avec :
GET /report-templates/{id}?include=reportFields
Vous pouvez travailler avec la couche d'affaires et les administrateurs du portail TrackTik pour étendre les modèles actuels afin d'accueillir plus de données, ou ils peuvent vous aider à mettre en place un nouveau modèle de rapport qui est plus dédié à votre solution.