This article describes why & how to use the functionality of sending person details via the Service Bus - part of the Connect ID infrastructure. Sending (and receiving) person details is available for every user (e.g. MA) of the Service Bus since October 2022.



Also see:
- Custom messaging through Connect Service Bus for technical information on how to send custom messages over the Service Bus.


Why to use the functionality

One of the FIFA Connect ID Service goals has been to avoid data duplication. This was one of the reasons to introduce a worldwide unique FIFA_ID and develop duplicate detection algorithms available for any registration system.

With almost all systems/parties being connected to the same infrastructure (the Connect ID Service Bus), it is now possible to utilise another great benefit: data transfer automation. In the ideal scenario it should no longer be necessary to manually key in basic data of any existing person (i.e. of any person with a FIFA_ID). In other words: if a person is registered somewhere, it can be easily registered anywhere.

In many scenarios this has already been possible since the introduction of the Connect ID in 2016. If you are a Member Association (MA) trying to register a person that has already been registered elsewhere, Connect ID will spot a duplicate and you will receive details of that person (including photo) in the form of a Service Bus message (message type: person-details). If your National Registration System (NRS) allows it, you can reuse the data sent by another MA instead of filling in the data manually.

The previous scenario is a "pull" one as you are able to pull someone's data from another system and re-use it in your own. However, due to data protection, there are limitations: you can only pull data of a FIFA_ID that you discovered as a potential duplicate of your own [potential] record.

We can also easily imagine a "push" scenario. For example, in a given MA we may have a system for hosting national club tournaments (Competition Management System or CMS). Traditionally, all players would be manually registered in such a system. But if we connect it to a Service Bus, it should be possible to send the data of all players from an NRS to a CMS automatically, without anyone needing to enter it manually.

Of course we can bring this scenario to a higher level, imagining a Confederation or even a world wide tournament.


How to use it

Whether we are talking about a national tournament or a world wide event, all that is needed is an implementation of a single method from the Connect ID SDK. Let's see how to go about it.

Let's build on the example mentioned above. There are two systems: NRS and CMS. NRS "wants" to send a couple of hundred players taking part in the national tournament to CMS. Of course there is no point in re-registering those players manually in CMS. Assuming that both systems use the Connect ID SDK, the following should be done:

  1. Parties need to agree the name of a message type they are going to use. Each message sent over the Service Bus has a type. An example name might be 'send-player-for-tournament'.
  2. NRS needs to include calling of the PersonLocalSender.Send(...) in their business process. The goal is to somehow initiate sending of a person(s). The method takes the following parameters:
    1. personLocal object - there go details of a person being sent. This is exactly the same class defined by a FIFA Data Standard that is used in other places, e.g. when replying to another MA's request for person details.
    2. recipient - this is a unique identifier of a recipient (System ID). Every system knows their identifier as they receive it along with credentials to use the Connect ID SDK. For a Member Association the standard is to provide their FIFA_ID, e.g. 105C79D would be a unique identifier of a Norwegian NRS. For systems other than NRS-es, identifier may contain an additional part, e.g. 105C3ZB_TMS is a unique identifier of a TMS system. To summarize: NRS needs to know the CMS'es identifier.
    3. message type - explained above
  3. CMS needs to implement a message handler, i.e. the code that will be executed when a message is read by their listener. The idea is exactly the same as in the scenario when you are expected to reply with PersonDetails. In that scenario your handler is supposed to get data for a given FIFA_ID from your NRS. In this scenario your handler will probably need to register a person in the local DB.
  4. CMS needs to register a newly created handler and remember to use the proper - previously agreed - message type.

All the code snippets for the points above are available in the Connect ID SDK Documentation.

How to keep your records up-to-date

Supposing that our example CMS received a couple of hundred players, a valid question would be: how does it keep those players' data up-to-date? If in your scenario keeping records up-to-date is important, you have to do the following:

  • inform Connect ID that you are a so called data holder of a given FIFA_ID (do it for all FIFA_IDs)
  • subscribe for the notifications about changes to persons' data


If you perform the steps above, Connect ID will know to send you notifications if e.g. two players are merged. More on this topic, including the detailed instructions can be found in the following two articles: https://support.id.ma.services/support/solutions/articles/7000073835-data-holders-explained and https://support.id.ma.services/support/solutions/articles/7000069673-connect-id-notifications.