This article explains the concept and usage of a System ID. It may be important for you in 2 cases which are described separately:
- you are a standard (primary) system provider for a Member Association and you are about to implement a deduplication screen (e.g. as described here)
- you are a system provider for a Member Association but a registration system already exists (i.e. your system comes 2nd)
In other words: you either need to register persons and mark them by your System ID or you want to successfully recognize records registered like that.
Deduplication of person records registered by/with a System ID
Players from non-onboarded MAs (without Connect ID integration) who take part in some FIFA competitions are still registered and receive FIFA_IDs. This is done by non-MA systems (we'll refer to them as "external systems") and such records are marked with a System ID attribute while still pointing to the correct MA.
Later, when their MA decides to integrate and register them, they will inevitably appear as potential duplicates (they have been registered already after all). The case might be confusing for a human operator because a 100% duplicate will pop up pointing to the MA itself. This case is very rare (almost an exception) but possible and your Football Management System should know how to handle this situation. Examples below explain how to determine whether the duplicate has a System ID or it is a national duplicate.
Here are questions you may ask at some stage of integration during duplicates resolution.
"How to take over a player, that has been registered by an external system (with System ID)? "
- To take over a player you need to send UpdateRegistrations request passing oldRegistrations and newRegistrations parameters. Inside newRegistrations SystemId should be left empty. As a result, SystemId will be erased from the registration. Your MA will from now on be responsible to answer with person details.
"How to check that the record comes from a non-MA system (with System ID)?"
- If registration was not successful and duplicates were returned you can see from where duplicates came from by looking at:
|DeduplicationResult -> PersonDuplicateWithDetails -> RequestRecipientOrganisationId||Id of MA a player plays in|
|DeduplicationResult -> PersonDuplicateWithDetails -> RequestRecipientOrganisationSystemId||SystemID|
Specifically looking at RequestRecipientOrganisationSystemId gives the information whether an external system registered a person. It says for example "105c3zb_csrs". If analyzing a duplicate from a system that is not a Stakeholder Registration System field RequestRecipientOrganisationId might be confusing as it does not mean the actual recipient of a Details Request message. It holds information about the MA that player plays in and not the actual recipient of the message (if speaking about a person registered by an external system). For the end-user to see whether a duplicate comes from an external system, you have to expose that information in the UI.
"How do I tell a difference between such a record and the record that has been registered a minute before from my own DB?"
- When you register a person and then it will be returned in process of resolving internal duplicates the following fields will indicate the difference:
|DeduplicationResult -> PersonDuplicateWithDetails -> RequestRecipientOrganisationId||Id of MA registering a player|
|DeduplicationResult -> PersonDuplicateWithDetails -> RequestRecipientOrganisationSystemId||null|
RequestRecipientOrganisationSystemId will be null when registered by an MA (you) in a standard way.
Secondary system provider for a Member Association
By default, all registrations are stored in a single national registration system. It is however possible to connect additional system(s) to FIFA Connect ID service. As an example we may consider the [main] national registration system being responsible for Amateur players only and an additional, external system – for Professionals. In such a setup it is important that Connect ID is able to properly route requests for player details sent by other MAs via Service Bus.
In order for this routing to work correctly, an external system, for each of registrations it manages (professional ones), must provide its unique identifier (System ID).
System ID should be set for each registration by using SystemId property. Use the value you received from the Connect ID Support Team. See below example:
var organisationId = "105C8LX";
var systemId = "105C8LX_SystemName";
var newPlayerRegistration = new PlayerRegistrationType();
newPlayerRegistration.Level = "Pro";
newPlayerRegistration.Discipline = "Football";
newPlayerRegistration.RegistrationNature = "Registration";
newPlayerRegistration.Status = "Active";
newPlayerRegistration.OrganisationFIFAId = organisationId;
newPlayerRegistration.SystemId = systemId; // The system identifier is created and passed along with the access credentials.
There is no need of setting SystemId if registration is added by a default/primary registration system. In this case the <null> value should be used.
In connection to the topic of this article we highly recommend to read more about transfer / taking over an existing player here: https://support.id.ma.services/support/solutions/articles/7000052312-transfer-taking-over-an-existing-player