Ce guide a été conçu pour vous faciliter l’intégration du service FIFA Connect ID. Il comporte cinq étapes correspondant à des niveaux d’intégration : plus l’étape est élevée, plus l’intégration est près d’être finalisée.

Avant de commencer l’intégration, il est recommandé de lire cet article, qui décrit les concepts fondamentaux du service Connect ID. Ce n’est pas obligatoire mais cela vous aidera à comprendre les raisons pour lesquelles nous vous demandons de réaliser certaines étapes.

En cas de problème, n’hésitez pas à nous contacter via notre page d’aide (Support Portal – voir ci-dessous) et à consulter les questions fréquemment posées. Vu le nombre d’associations membres concernées, il y a de fortes chances que quelqu’un d’autre soit déjà passé par là !

Remarque : lorsque les instructions ci-dessous évoquent une documentation SDK [principale], il s’agit d’un fichier HTML contenant le pack SDK zippé que nous vous demandons de télécharger à l’étape n°1. Son nom peut varier en fonction de la technologie et de la version du pack. À l’heure actuelle, la documentation se trouve dans les fichiers suivants :

  • fifa-connectid-sdk-php-6.1.html
  • fifa-connectid-sdk-net-6.1.html
  • fifa-connectid-sdk-java-6.2.html

 

Étape n°1 – Fondamentaux

Ce chapitre présente ce qu’il convient de faire avant de commencer à intégrer votre solution à Connect ID. Il faut obtenir les identifiants, télécharger les bibliothèques et les enregistrer au sein de votre solution. Une fois cette étape terminée, vous êtes prêt à commencer l’intégration et à dérouler le premier scénario d’enregistrement d’une personne.

 

  1. Rendez-vous sur Support Portal (https://support.id.ma.services/support/home) et appuyez sur « New support ticket ».
  2. Demandez des identifiants pour l’environnement bêta à l’équipe Connect ID. Indiquez le nom de votre association membre.
  3. Les identifiants vous sont envoyés par courriel sous la forme de valeurs ClientID et SecretKey. Vous devez ensuite ajouter ces valeurs dans le code source, ce qui permettra à Connect ID de vérifier votre identité et vos autorisations.
  4. Vous recevrez également un nouveau nom d’utilisateur et un mot de passe, que vous utiliserez ultérieurement pour accéder à notre système (Admin Console) à des fins de dépannage et de signalement de problèmes. Par exemple, si vous avez utilisé un SDK pour enregistrer un joueur, vous devez probablement vous rendre sur Admin Console pour confirmer son enregistrement.
  5. Vous pouvez utiliser les mêmes nom d’utilisateur et mot de passe que dans le point 4 pour accéder au système DevTools, qui vous permet de suivre la progression de votre intégration.
  6. Téléchargez la dernière version du SDK depuis le Support Portal (https://support.id.ma.services/support/solutions/7000001343). Choisissez la version correspondant à votre technologie (.NET, Java, PHP).
  7. Décompressez le SDK (téléchargé comme fichier zip).
  8. Ouvrez le fichier fifa-connectservicebus-certificates-generation.html et suivez les instructions indiquées qu’il contient. Vous pourrez ainsi générer votre clé publique et votre clé privée, qui serviront à chiffrer les communications directes avec d’autres associations membres via Service Bus.
  9. Référencez les bibliothèques de Connect ID dans votre solution. La liste des bibliothèques à référencer se trouve dans le chapitre 2. Paramétrage de la documentation SDK (Setup).

 

Étape n°2 – Enregistrement forcé d’une personne

Cette étape a pour objectif de vérifier que vous pouvez vous authentifier sur Connect ID et y déposer des informations à partir de votre système, deux éléments indispensables à l’enregistrement d’une personne. Lors de cette étape, nous allons dérouler le scénario le plus simple et partir du principe que le service Connect ID ne trouve aucun doublon potentiel. Pour faire en sorte que le Connect ID ignore les doublons, vous allez utiliser l’option enregistrement forcé plutôt que l’enregistrement standard.

 

Veuillez noter qu’aux étapes n°2, 3 et 4, vous utilisez uniquement la catégorie RegistrationFacade. Celle-ci permet de simplifier l’intégration car elle propose des procédures faciles à utiliser qui dissimulent toute la complexité technique de Connect ID. Vous n’êtes pas supposé utiliser la catégorie FifaConnectIDClient décrite au chapitre 3.2 de la documentation SDK (Using FIFA Connect ID Client).

  1. Rendez-vous dans la documentation SDK et suivez les instructions décrites au chapitre 3.1.1 (Get FIFA identifier of your organisation and client credentials). La catégorie RegistrationFacade doit connaître l’emplacement de votre clé privée. Elle en aura besoin à l’étape n°3, lorsque nous traiterons des dossiers dont l’enregistrement est impossible en raison de la présence de doublons. Dans notre cas particulier (enregistrement forcé), nous n’avons pas besoin d’utiliser la clé privée mais le constructeur de RegistrationFacade la demandera.
  2. Suivez les instructions du chapitre 3.1.2 pour créer RegistrationFacade. Veuillez noter que vous utilisez des identifiants déjà générés, notamment ClientID, SecretKey et PrivateKey [emplacement].
  3. Passez au chapitre 3.1.5 (Register a new person) et créez un objet PersonData, comme décrit dans le premier extrait de code.
  4. Passez l’objet de votre personne à la méthode RegistrationFacade.ForceRegisterPerson(...). N’oubliez pas que cette étape consiste à enregistrer une personne sans passer par la vérification de doublons. Vous n’êtes donc pas obligé d’utiliser la méthode RegistrationFacade.RegisterPersonAndWaitForDetailsInCaseOfDuplicates(...), décrite dans l’extrait de code au chapitre 3.1.5.
  5. Rendez-vous dans Admin Console https://fci-adminconsole-beta.azurewebsites.net/ et sélectionnez Audit Trail. Si votre enregistrement a réussi, vous verrez apparaître votre dossier tout en haut.
  6. Nous partons du principe que vous avez pensé à sauvegarder l’identifiant FIFA d’une personne nouvellement enregistrée dans votre Football Management System. Dans le cas contraire, veuillez le faire car nous en aurons besoin à l’étape n°4 de ce guide.
  7. Remarque : consignez les détails de la personne que vous avez enregistrée. À l’étape n°4, nous allons vous demander d’enregistrer la même personne, mais cette fois sans enregistrement forcé.

 

Une fois la première personne enregistrée, nous passons à la gestion des doublons internationaux. Cette activité comporte deux étapes. Vous allez tout d’abord mettre en place un service chargé de répondre aux associations membres demandant les détails d’une personne à votre système. Ensuite, vous apprendrez vous-même à demander les détails d’une personne et à interpréter les réponses envoyées par d’autres associations membres.

 

Étape n°3 – Partager les détails d’une personne avec d’autres associations membres

L’étape n°3 décrit comment partager les détails d’une personne avec d’autres associations membres. Ceci permet d’éviter l’enregistrement de doublons.

 

À l’étape n°4, vous apprendrez comment demander aux autres associations membres des informations concernant des doublons potentiels de votre dossier. Pour commencer sur le sujet des doublons, nous allons vous demander de mettre en place un service qui répondra aux demandes d’information de joueurs émises par d’autres associations membres. Cette fonctionnalité répond aux besoins du scénario d’enregistrement d’une personne le plus important. Imaginez que l’association membre X essaie d’enregistrer une personne. Connect ID l’informe de la présence d’un doublon potentiel. L’association membre en question ne reçoit pas de données personnelles car leur stockage n’est pas prévu dans Connect ID. En revanche, il lui est indiqué que le doublon potentiel provient de votre association membre et qu’il correspond à un certain identifiant FIFA.

Dans cette situation, l’association membre X vous adresse via Service Bus un message chiffré de type request-for-person-details. Nous allons désormais vous montrer comment reconnaître ce genre de message et y répondre. 

 

Le bon côté de cet outil, c’est qu’il facilite les échanges avec les autres associations membres. Le SDK se charge du chiffrement des messages échangés sur la plateforme. Il comprend également qu’un message est arrivé et qu’il s’agit d’une request-for-person-details. Vous devez alors procéder comme suit :

  • Exécutez un code personnalisé (interface PersonDetailsProvider), qui recherche les informations de la personne correspondant à l’identifiant FIFA reçu comme paramètre PersonDetailsRequest sur votre propre Football Management System et les renvoie. Bien qu’il s’agisse d’un message XML, vous n’avez pas à vous préoccuper des problèmes de format car le SDK comporte un outil (PersonLocalXmlSerializer) qui transforme automatiquement votre objet PersonLocal en XML. Vous trouverez de plus amples informations sur le fournisseur d’informations de personnes et sur la gestion du format XML au chapitre 3.1.3 (Setup Service Bus listener).
    • Vous vous demandez peut-être quelles informations vous devez renvoyer à une association membre vous adressant une demande de ce genre. En fait, nous nous conformons à la norme FIFA Data Standard, qui, pour faciliter les choses, contient les informations requises par le constructeur PersonLocal : nom de famille, sexe, nationalité, date de naissance, pays de naissance, lieu de naissance, langue et pays. Lors de l’installation finale, nous vous recommandons de fournir davantage d’informations (par exemple, l’historique du joueur) mais, pour l’instant, vous pouvez vous en tenir aux données obligatoires. Veuillez noter que les champs susmentionnés sont obligatoires. Vous devez donc les renseigner lors de chaque demande d’informations d’une personne. Vérifiez si votre base de données contient des enregistrements incomplets pour pouvoir définir une solution alternative (ex. : vous pouvez éventuellement indiquer « inconnu » s’il manque le lieu de naissance).
  • Lancez votre listener d’arrière-plan pour pouvoir échanger des messages avec les autres associations membres. La configuration du listener dépend de la technologie que vous utilisez. Les technologies .NET et Java sont multithread, contrairement à PHP, qui a donc besoin d’une couche supplémentaire pour partager des données entre le listener et l’application web/le script d’enregistrement. Vous trouverez dans la documentation SDK (3.1.3) une description détaillée vous expliquant comment démarrer le listener selon votre technologie.

 

Si vous avez appliqué les mesures ci-dessus, vous devez désormais disposer d’un listener actif prêt à recevoir des demandes d’informations de la part d’autres associations membres. Vous aurez besoin de faire un peu plus de codage pour vérifier son bon fonctionnement (l’étape n°4 décrit comment faire). Nous vous suggérons donc de nous contacter dès maintenant. Indiquez-nous l’identifiant FIFA d’une personne enregistrée à l’étape n°2 et nous vérifierons grâce à notre outil interne si votre système nous envoie les informations de la personne.

Votre solution est désormais capable :

  • d’enregistrer de façon forcée une personne ;
  • d’envoyer les informations d’une personne à une association membre cherchant à déterminer si une personne en cours d’enregistrement est un doublon d’une personne de votre Football Management System.

Le dernier élément du scénario d’enregistrement d’une personne consiste à apprendre à demander à une autre association membre les informations d’une personne et à en interpréter la réponse.

 

Étape n°4 – Comprendre les informations de doublons potentiels

L’étape n°4 va vous permettre de dérouler la fin du scénario d’enregistrement d’une personne. Vous allez apprendre à gérer les doublons potentiels lors de l’enregistrement et à récupérer les informations d’une personne fournies par d’autres associations membres.

 

Souvenez-vous, à l’étape n°2, vous avez créé un objet PersonData et vous l’avez soumis à la procédure RegistrationFacade.ForceRegisterPerson(...). Celle-ci peut être utilisée dans le système Production, mais seulement dans certaines circonstances : lorsque vous savez déjà que la personne que vous êtes sur le point d’enregistrer ne présente aucun véritable doublon. Mais comment distinguer un véritable doublon d’un faux positif ? Le processus complet d’enregistrement d’une personne est le suivant (vous trouverez ci-après une description rapide ; les étapes techniques spécifiques sont indiquées par la suite) :

  • Une fois l’objet PersonData créé, au lieu de forcer l’enregistrement comme dans l’étape n°2, vous devez essayer de l’enregistrer avec la procédure RegistrationFacade.RegisterPersonAndWaitForDetailsInCaseOfDuplicates(...).
  • Cette méthode contacte en arrière-plan Connect ID, vérifie la présence de doublons et, le cas échéant, télécharge les informations de base vers le client/SDK.
  • Toujours avec cette procédure, notre code envoie des messages chiffrés via Service Bus à toutes les associations membres ayant des doublons potentiels pour leur demander les informations complètes de la personne.
  • La procédure se termine lorsque toutes les réponses ont été reçues (ou, au plus tard, dans le délai défini en secondes en tant que paramètre timeout) et renvoie un ensemble de doublons potentiels comportant les informations personnelles envoyées par les autres associations membres.
  • Maintenant que vous disposez des données personnelles des doublons potentiels, vous pouvez les afficher sur le Football Management System de sorte que l’utilisateur puisse décider si la personne à enregistrer présente des doublons ou non (vous trouverez tous les détails dans l’article Building user interface for duplicate resolution).
  • Les mesures à prendre en fonction de cette décision dépendent des processus professionnels (également décrits ici), mais ne vous préoccupez pas de cela pour l’instant. Il vous suffit de comprendre que si tous les doublons sont en réalité des faux positifs, vous devez forcer l’enregistrement (comme à l’étape n°2) et que si un véritable doublon a été trouvé, vous devez utiliser son identifiant FIFA (et potentiellement lancer un processus de transfert).

Veuillez noter que la catégorie RegistrationFacade vous évite toutes les difficultés liées à la vérification des doublons et à l’obtention des informations de la part d’autres associations membres. C’est pour cette raison que nous avons nommé cette catégorie de la sorte.

 

Si vous vous demandez encore pourquoi il faut recourir au mécanisme de communication de Service Bus pour un simple enregistrement de personne, n’oubliez pas que le service d’identifiant ne stocke pas les données personnelles. Si, pour statuer sur les doublons, l’utilisateur ne comptait que sur les informations de Connect ID, il serait rarement en mesure de prendre la bonne décision. Il verrait par exemple les informations suivantes : « La personne que vous essayez d’enregistrer semble être le doublon d’un joueur amateur, de sexe masculin, né en France le 23/04/1978. Le taux de correspondance des noms est de 0,6. » Nous ne serions même pas en mesure d’afficher le nom complet d’un doublon potentiel et encore moins la photo ou l’historique de la personne !

Il y a encore autre chose à savoir avant de passer au déroulement de ce scénario. Vous y avez peut-être déjà pensé : « que se passe-t-il si la personne que j’essaie d’enregistrer ne présente pas de doublon international mais un doublon local/national ? ». « Dois-je lancer une nouvelle procédure pour vérifier la présence de doublons locaux puis de doublons internationaux sur Connect ID ? »

Alors, bonne nouvelle : non, pas du tout ! Nous utilisons exactement le même mécanisme pour vérifier les doublons locaux et internationaux. Relisez la description ci-dessus. Est-il indiqué que le système contactera toutes les associations membres sauf la vôtre ? Non, fort heureusement. Si le service d’identifiant trouve un doublon au sein de votre association membre, votre client/SDK s’auto-envoie un message via Service Bus, exécute PersonDetailsProvider (que vous avez utilisé à l’étape n°3) et renvoie les informations de la personne. En fin de compte, votre utilisateur visualise également les informations fournies par votre propre Football Management System. C’est vrai que le système implique beaucoup de va-et-vient et qu’on pourrait abréger. Sauf que pour ce faire, vous devez lancer une procédure distincte de gestion des doublons locaux et nous ne souhaitons pas que vous perdiez du temps avec ceci. Au lieu de cela, nous avons accru la puissance de Service Bus afin qu’il puisse gérer toutes les communications requises.

Après cette introduction plutôt longue, vous êtes désormais prêt à passer à la partie technique. Comme précédemment (pour les doublons nationaux et internationaux), nous allons vous présenter plusieurs scénarios.

 

Scénario 1 – Obtenir les informations de doublons figurant dans votre propre base de données (doublons nationaux)

  • Vous avez déjà enregistré une personne à l’étape n°2 de ce guide. Vous allez désormais prendre les données de cette personne et essayer de l’enregistrer à nouveau. Cette fois, en revanche, vous allez utiliser la procédure RegistrationFacade.RegisterPersonAndWaitForDetailsInCaseOfDuplicates(...) au lieu de RegistrationFacade.ForceRegisterPerson(...). Cette opération est bien décrite dans le chapitre 3.1.5 de la documentation SDK (Register a new person). Étant donné que la personne est déjà enregistrée dans la base de données de la FIFA, il n’est pas possible de l’enregistrer à nouveau (si l’enregistrement n’est pas forcé). La requête renvoie donc un code d’erreur 409 HTTP (conflit). N’oubliez pas, cependant, que tout cela se produit en arrière-plan. Lorsque le code 409 est renvoyé en interne, le SDK adresse automatiquement des demandes d’informations de personne à toutes les associations membres ayant des doublons potentiels dans leur base de données locale. Dans ce cas précis, votre SDK s’auto-envoie la requête et y répond (parce que la personne est enregistrée dans votre système).
  • Consultez l’extrait de code du chapitre 3.1.5. Dans la chaîne duplicateWithDetails.PersonDetails, vous trouverez une réponse au format XML générée et renvoyée par votre PersonDetailsProvider. Lorsque vous ouvrez le document XML, vous voyez qu’il contient les mêmes données que celles définies à l’aide de la catégorie PersonLocal à l’étape n°3.

 

Si vous en êtes arrivé là, c’est que votre installation réagit correctement avec les informations de la personne. Nous l’avons vérifié à la fin de l’étape n°3 sur notre outil, mais vous en avez désormais la preuve concrète.

 

Scénario 2 – Obtenir les informations de doublons en provenance d’autres associations membres (doublons internationaux)

  • En gros, les étapes à suivre ici sont très similaires à celles du scénario 1. En revanche, on va utiliser ici les données de personnes enregistrées par d’autres associations membres dans l’environnement bêta au lieu de vos propres données. Vous trouverez ci-dessous la liste de ces personnes. Vous pouvez dérouler ce scénario pour quelques-unes d’entre elles ou pour l’intégralité, puis comparer le nombre de doublons affichés.
  • Dans ce cas, vous devez suivre les instructions décrites au chapitre 3.1.5 (Register a new person). En quelques mots, vous devez créer un objet PersonType et le remplir avec les données d’une personne de la liste.
  • L’exécution de RegistrationFacade.RegisterPersonAndWaitForDetailsInCaseOfDuplicates(...) renvoie désormais également un code d’erreur 409 en interne mais, cette fois, votre exécution de PersonDetailsProvider n’est pas déclenchée. Vous obtenez une réponse XML de la part d’autres associations membres, celles qui détiennent les informations de la personne que vous souhaitez enregistrer. Vous vous souvenez de la catégorie PersonLocalXmlSerializer que vous avez utilisée à l’étape n°3 ? Vous pouvez vous servir du même outil pour créer une occurrence de PersonLocal à partir d’une chaîne XML brute (vous trouverez de plus amples détails concernant ceci au chapitre 3.1.9 (Deserialize XML with person details) de la documentation SDK). Vous pouvez utiliser le XML avec les informations de la personne ou le désérialiser en tant qu’objet PersonLocal. Tout dépend de vos préférences et de votre contexte.

 

Scénario 3 – Comprendre les enregistrements créés dans mon association membre par d’autres systèmes

Si, au cours de la mise en place, vous remarquez que la propriété RequestRecipientOrganisationSystemId sous PersonDuplicateWithDetails est remplie, rendez-vous à la section Concepts avancés pour en savoir plus sur les enregistrements créés par des systèmes externes. 

Liste des personnes test enregistrées dans l’environnement bêta :

  • Tres Bruno, 29 avril 1989
  • Yacine Adli, 29 juillet 2000
  • Nabil Alioui, 18 février 1999
  • Danilo Cataldi, 6 août 1994

 

Veuillez noter que cette liste était valable au moment de rédiger le présent article. Si vous ne parvenez pas à recevoir les informations des personnes susmentionnées (autrement dit, si vous recevez une chaîne vide au lieu d’un document XML), veuillez nous en informer pour que nous puissions effectuer une vérification et vous fournir d’autres noms.

Si vous êtes arrivé à ce stade et que vous avez réussi à dérouler les étapes n°1 à n°4, félicitations ! Il vous reste un peu de travail à faire, mais vous avez assimilé les concepts les plus importants. Votre solution devrait désormais être capable :

  • d’enregistrer une personne, de recevoir un identifiant FIFA et de le sauvegarder dans votre Football Management System ;
  • d’enregistrer une personne et, en cas de doublons, de demander les informations à d’autres associations membres, d’obtenir les informations et de les comprendre :
  • de forcer l’enregistrement d’une personne ;
  • d’envoyer les informations d’un joueur depuis votre Football Management System en réponse à la requête d’autres associations membres.

 

Du point de vue du système :

  • vous êtes intégré au service Connect ID ;
  • vous êtes intégré au Service Bus de Connect ID et vous êtes en mesure d’utiliser l’infrastructure de clé publique/privée pour échanger des messages avec d’autres « utilisateurs » du Service Bus.

 

L’étape n°5 décrit les éléments que vous n’avez pas encore mis en place.

 

Étape n°5 – Concepts avancés

 

La dernière étape vous explique comment mettre en œuvre les opérations restantes, notamment :

  • Mise à jour d’une personne
  • Enregistrement d’un club
  • Enregistrement d’installations
  • Processus de transfert

Elle explique également comment fournir des informations supplémentaires lorsque vous partagez les données d’une personne avec d’autres associations membres.

 

Le présent chapitre renvoie à trois ressources complémentaires, les listes de contrôle. Elles vous servent à vérifier que vous avez bien suivi toutes les opérations nécessaires à l’intégration de Connect ID. À des fins pratiques, vous trouverez ci-dessous les liens, mais veuillez noter qu’ils se trouvent également dans les parties concernées :

Veuillez noter qu’un nouvel outil a été mis à disposition en octobre 2019 pour aider les associations membres à réaliser une auto-évaluation de leur progression. Vous pouvez utiliser les mêmes identifiants que pour Admin Console. L’outil est accessible sur cette page.

Mettre à jour les informations de profil d’une personne

Il est possible de modifier ou de mettre à jour les informations d’une personne que vous avez enregistrée à l’étape n°3. Plusieurs options sont possibles :

  • Mettre à jour une personne
  • Ajouter des enregistrements
  • Mettre à jour les enregistrements
  • Fusionner des personnes

 

La procédure UpdatePerson donne la possibilité de mettre à jour le nom, la date de naissance ou le sexe d’une personne. Vous avez alors besoin d’au moins un des éléments mentionnés. Vous pouvez mettre à jour les trois éléments à la fois ou n’en choisir qu’un (par exemple, la date de naissance) et donner une valeur nulle aux autres. N’oubliez pas que ce genre d’opération peut potentiellement entraîner l’apparition de doublons. Pour dérouler un tel scénario, suivez les instructions du chapitre 3.1.6 de la documentation SDK :

  1. Créez et forcez l’enregistrement de deux personnes avec des informations différentes.
  2. Utilisez la procédure UpdatePersonAndWaitForDetailsInCaseOfDuplicates pour mettre à jour les informations de la personne enregistrée en deuxième avec celles de la personne enregistrée en premier (noms, date de naissance et sexe). Vous devriez obtenir un ou plusieurs doublons potentiels à la fin de l’opération.
  3. Vous pouvez à présent retenter la même opération (UpdatePersonAndWaitForDetailsInCaseOfDuplicates) avec des données différentes. Essayez par exemple de mettre à jour une seule valeur. Si vous mettez à jour les noms, essayez d’utiliser autant de valeurs uniques que possible. Ensuite, vous pouvez tester le scénario « mise à jour des informations de la personne sans obtenir de doublons ».

 

Comme vous l’avez peut-être déjà remarqué, il est techniquement possible d’enregistrer une personne sans enregistrement. Un tel cas, bien qu’il soit autorisé, est inutile d’un point de vue professionnel (puisque la personne n’est affectée à aucune association membre). En revanche,
 il est facile de modifier une personne enregistrée de la sorte en ajoutant des enregistrements : 

  1. Commencez par enregistrer une personne sans enregistrement. Vous pouvez suivre le chapitre 3.1.5 mais n’oubliez pas d’ignorer la partie où PlayerRegistrationType est créé et rattaché à la liste d’enregistrements.
  2. À la suite de cette opération, vous obtenez un identifiant FIFA unique pour la personne enregistrée. À ce moment-là, vous pouvez vous connecter à Admin Console (https://fci-adminconsole-beta.azurewebsites.net/) et vérifier que vous pouvez voir cette personne et qu’aucun enregistrement ne lui est affecté.
  3. Passez désormais au chapitre 3.2.7 (et à son sous-chapitre 3.2.7.1, en particulier). À l’aide de l’identifiant FIFA que vous venez d’obtenir et de l’identifiant de votre association membre (organisationId), vous pouvez désormais créer l’instance PlayerRegistrationType et l’affecter à AddRegistrationsRequestType.
  4. Vous êtes alors prêt à envoyer la requête. En voyant l’extrait de code du chapitre 3.2.7.1, vous vous demandez sans doute ce qu’est le client et comment l’obtenir facilement. Comme indiqué à l’étape n°2, nous n’allons pas créer l’instance FifaConnectIDClient séparément. Vous pouvez l’obtenir à partir de RegistrationFacade en déclenchant la propriété ConnectIdClient (ou via la procédure getConnectIdClient, selon la technologie utilisée).
  5. Il vous suffit maintenant de lancer la procédure AddRegistrations, d’attendre une réponse puis de vérifier votre personne dans Admin Console (le mieux étant de passer par la fonctionnalité Audit Trail).

 

Rendons les choses encore plus compliquées en essayant de mettre à jour l’enregistrement d’une personne :

  1. Comme à l’étape précédente, nous avons ajouté PlayerRegistrationType à notre personne. Veuillez réaliser la même opération. Cette fois, cependant, ajoutez un autre type d’enregistrement (vous avez le choix parmi les options suivantes : MatchOfficialRegistrationType, OrganisationOfficialRegistrationType et TeamOfficialRegistrationType). 
  2. Lorsque vous êtes prêt, rendez-vous sur Admin Console et assurez-vous de voir deux enregistrements sur la page de la personne.
  3. Passez au chapitre 3.2.7.2 et essayez de mettre à jour un seul enregistrement pour cette personne. Essayez par exemple de modifier le statut de l’enregistrement du joueur.

 

À un moment donné, lorsque vous utilisez le SDK de Connect ID, vous allez peut-être avoir besoin de fusionner deux personnes enregistrées (primaire et secondaire). Pour rappel, il n’est pas possible de supprimer une personne de la base de données. Si une même personne a été enregistrée deux fois, la seule action possible consiste donc à fusionner les dossiers. D’un point de vue technique, ce processus plutôt facile peut être effectué tout simplement à l’aide de la procédure MergePersons (voir chapitre 3.2.5). À la suite de cette opération :

  • dans Admin Console, vous verrez (dans les pages informations de la personne et Audit Trail) qu’une personne secondaire a été fusionnée avec une personne primaire ;
  • aucun enregistrement n’est déplacé/copié, donc les deux personnes gardent les mêmes enregistrements qu’avant la fusion ;
  • tous les enregistrements conservent leur statut actuel ;
  • GetPerson renvoie une FifaPersonMergedException lors d’une requête d’identifiant de personne secondaire.


 Si vous avez suivi le guide étape par étape jusqu’à maintenant, vous devriez être en mesure de réaliser toutes les opérations sur les personnes dont vous avez besoin pour l’intégration au service FIFA Connect ID.
 Veuillez vous reporter à cet article, qui comporte une liste de contrôle des opérations que chaque Football Management System devrait pouvoir réaliser.
 

Enregistrement d'un club

La base de données du service FIFA Connect ID est prête à stocker les clubs de toutes les associations membres. Chaque club reçoit un identifiant FIFA unique après l’enregistrement. Veuillez noter que :

  • chaque enregistrement de personne est exclusivement lié à une association membre (nous ne conservons pas les relations entre les personnes et les clubs).
  • Dans la mesure du possible, veuillez utiliser l’identifiant du club lorsque vous renvoyez un XML avec les informations d’une personne (c’est ainsi que l’on peut lier l’enregistrement à l’identifiant du club). Rendez-vous au chapitre 3.1.3.1 de la documentation SDK pour savoir comment préparer les données pour la sérialisation XML.

 

Passons désormais à l’utilisation du SDK pour l’enregistrement d’un club : 

  • Tout comme lorsque vous ajoutez des enregistrements à une personne, vous devez récupérer FifaConnectIDClient dans RegistrationFacade. 
  • Passez ensuite au chapitre 4.1, qui explique comment construire et exécuter la requête du processus d’enregistrement. 
  • Chaque type d’organisation impose la saisie de champs différents lors de l’enregistrement. Lors de l’enregistrement d’un club, vous devrez fournir les propriétés suivantes : Status, InternationalName, LocalName, LocalLanguage, LocalCountry, OrganisationNature, ParentOrganisationFIFAId et OfficialAddress.
  • Les autres champs sont facultatifs mais nous recommandons de les remplir également dans la mesure du possible (pour qu’ils puissent être utilisés par l’algorithme de déduplication du club).

 

Pour effectuer les étapes susmentionnées, nous partons du principe qu’aucun doublon n’a été trouvé lors de l’enregistrement.
 Si un doublon est trouvé, vous recevez une FifaDuplicatedOrganisationFoundException comportant les détails du doublon potentiel.

Si vous estimez qu’il s’agit d’un faux positif, vous pouvez utiliser le paramètre facultatif pour forcer l’enregistrement de l’organisation.

 

Tout comme pour les personnes, il est possible de mettre à jour ou de fusionner les clubs/organisations. Vous trouverez toutes les informations nécessaires concernant ces opérations aux chapitres 4.3 et 4.4.

 

Tout comme pour les personnes, nous avons préparé une liste de contrôle pour les organisations. Vous la trouverez ici.

 

Enregistrement d’installations

La base de données de Connect ID peut également stocker des Installations (par exemple, un stade).
 Vous pouvez enregistrer une installation, qui sera associée à l’organisation indiquée (association nationale ou tout autre type d’organisation).

 Voici les étapes à suivre pour enregistrer une installation :

  • Tout comme pour les personnes et les organisations, nous utilisons FifaConnectIdClient de RegistrationFacade.
  • Le chapitre 5.1 comporte un bloc de code expliquant comment créer et exécuter la requête. 
  • Les champs obligatoires pour les installations sont les suivants : Status, LocalName, LocalLanguage, LocalCountry, OrganisationFifaId, OfficialAddress.
  • Tout comme pour les organisations, nous vous recommandons d’indiquer les champs non obligatoires pour qu’ils puissent être utilisés par l’algorithme de déduplication de l’installation.

 

Tout comme pour les organisations, en cas de détection de faux positifs, vous pouvez utiliser le paramètre facultatif pour forcer l’enregistrement de l’installation.

 

Une fois l’enregistrement de l’installation terminé, vous pouvez en modifier les données. Le chapitre 5.3 vous explique comment y parvenir.

 Contrairement aux personnes et aux organisations, les installations ne peuvent pas être fusionnées/défusionnées.

 Pour finir, voici une liste de contrôle pour les installations.

 

Partage d’un passeport de joueur complet avec d’autres associations membres

À l’étape n°3, nous vous avons demandé de créer la fonctionnalité permettant de partager les informations d’un joueur avec d’autres associations membres. Cela permet aux autres associations membres de résoudre les doublons internationaux. À l’étape n°3, seule la bonne configuration du processus importait, donc nous vous avons demandé de saisir uniquement les informations obligatoires dans le message.

Nous vous recommandons à présent de fournir autant d’informations que possible sur le joueur, dans les limites de la norme FIFA Data Standard, bien entendu. Il ne vous manque certainement qu’une seule partie, intitulée <PlayerRegistration>. Nous vous demandons de répertorier tout l’historique des enregistrements du joueur que vous connaissez. Si vous ne connaissez pas son parcours, vous devez au moins indiquer son enregistrement actuel auprès de votre association membre.

La dernière chose à expliquer est le champ OrganisationFIFAId. Sa valeur doit être :

  • dans l’idéal, l’identifiant FIFA du club pour lequel le joueur évolue/a évolué (n’oubliez pas que nous pouvons avoir affaire à des enregistrements historiques également) ;
  • si vous ne le connaissez pas, au moins l’identifiant FIFA de l’association membre pour laquelle le joueur évolue/a évolué.

 

Envoyer plus que les informations obligatoires dans une réponse à une demande d’informations de personne

 

Comme décrit à l’étape n°3 du présent guide, vous devez remplir un certain nombre de champs obligatoires lorsque vous répondez à une demande d’informations d’une personne. Rendez-vous au chapitre 3.1.3.1 de la documentation SDK pour voir comment définir ces valeurs dans la technologie que vous utilisez. En gros, vous devez créer et modifier l’objet PersonLocal, qui est ensuite sérialisé directement dans un document XML. Nous vous encourageons à ouvrir cette catégorie (PersonLocal) et à l’explorer afin de comprendre ce que vous pouvez en tirer. Vous trouverez également ci-dessous la liste des champs non obligatoires :

  • LocalFirstName (chaîne)
  • LocalBirthName (chaîne)
  • Photo (vous trouverez les instructions expliquant comment créer un tel objet au chapitre 3.1.3.1)
  • LocalPersonName (liste de noms de personnes localisés)
  • NationalIdentifier (liste d’identifiants de personnes nationaux uniques, comme le numéro de sécurité sociale, le numéro de passeport ou l’identifiant fiscal)
  • PlayerRegistration (liste)
  • TeamOfficialRegistration (liste)
  • MatchOfficialRegistration (liste)
  • OrganisationOfficialRegistration (liste)
  • PersonFIFAId (chaîne)
  • InternationalFirstName (chaîne)
  • InternationalLastName (chaîne)
  • RegionOfBirth (chaîne)
  • LocalSystemMAId (chaîne, identifiant provenant de votre base de données locale)

 

Chaque type d’enregistrement (Player, TeamOfficial, etc.) contient uniquement des champs obligatoires. Cela signifie (selon votre technologie) que pour créer une instance de ces enregistrements, vous devez simplement répondre aux besoins du constructeur ou utiliser toutes les méthodes de mutateur possibles.

 

Joueurs enregistrés par des systèmes externes (SystemID)

Pour en savoir plus sur ce scénario, veuillez consulter l’article suivant : System ID explained.

Veuillez noter que certains des exemples mentionnés à l’étape n°4 ont été enregistrés par un système externe. Nous vous recommandons de réaliser des tests afin de pouvoir faire la différence entre un doublon enregistré par une association membre et un doublon enregistré par un système externe.

 

Transferts / prise en charge d’un joueur existant

Cet article devenant extrêmement long, nous avons décidé de décrire les transferts dans un autre article.