FIFA Connect ID Service delivers three versions of the SDK for integration, one for each of the following technologies:

  • .NET
  • Java
  • PHP
As a result, if you want to integrate with Connect ID, the best way by far is to use any of these libraries. They can be downloaded from Connect ID SDK folder. Full documentation for integration is available as part of the package for each technology. The step-by-step article guiding you through the integration process is here.


Directly including SDK will, however, only work for MAs whose NRS is written in one of the aforementioned technologies. This article explains the recommended integration approach for NRSes developed in other technologies (e.g. Python or Ruby). We will first describe at length a single recommended solution and towards the end discuss some alternatives. 

Recommended approach - custom proxy application

Note: for the sake of clarity we assume that MA's native technology is Python (both the examples and recommendation still stand for languages other than Python).


The most effective integration choice will be via a custom proxy application. It requires a minimum effort, time and cost on the MA side when compared to alternatives. It is also the simplest one to implement which makes it less error prone.


The first decision MA needs to take is to pick one of the technologies that they are most comfortable with (out of .NET, Java and PHP). For the sake of examples let's assume they picked Java. With this assumption we will have a solution consisting of the following elements:

  1. NRS written in Python
  2. Connect ID SDK (Java)
  3. Proxy application (Java)


 


Components A and B already exist. MA's only job when compared to the standard integration model will be to develop component C. Proxy application needs to have the following functions:

  • Communicate to NRS in a technology agnostic way
  • Communicate to Connect Id using native SDK methods

The MA should choose technology they want to use for communication between NRS and the proxy application. It has to be implementable across the technologies used by NRS system and a proxy application, or technology agnostic. MA should consider the scenarios in which Member Association queries Connect ID but there are also some scenarios that requires MA to provide information (e.g. implementation of IPersonalDetailsProvider as per SDK documentation).
For the sake of examples let's assume that MA picked REST API as the communication technology.

To summarize, in our example: 

  • Proxy application is a web application that exposes REST API for the MA's NRS
  • Proxy application translates API methods into native SDK methods
  • Proxy application implements IPersonalDetailsProvider


As you can see the proxy component does not need to contain any business logic - it simply acts as an adapter allowing MA's NRS to indirectly call methods from SDK.


As an example let's choose quite a complex, yet a very frequent scenario of a person registration. First we will briefly show what a standard, Java-based MA, would need to do and then explain in details what is required of our Python-based MA. In the example we will assume that the technology decision 


Java-based MA needs to:

  • create an application that utilizes Connect Id SDK (taking into consideration certificate used for securing communication and a service bus listener) as per step-by-step instruction 
  • [in Java] instantiate PersonData object containing both person information (first name, last name, date of birth) and information about registration (e.g. active football professional registration in a given MA)
  • [in Java] call registerPersonAndWaitForDetailsInCaseOfDuplicates method, passing PersonData object as a parameter
  • [in Java] handle the method's output (new FIFA_ID or potential duplicates)


Python-based MA  needs to:

  • [in Java] create a web based application that exposes a REST API and utilizes Connect Id SDK (taking into consideration certificate used for securing communication and a service bus listener) as per step-by-step instruction 
  • [in Java] implement an API endpoint (ex: RegisterPersonAndWaitForDetailsInCaseOfDuplicatesPost) that would deserialize PersonDataDto object from request body, map the object to PersonData that is required by SDK method registerPersonAndWaitForDetailsInCaseOfDuplicates and calls the method
  • [in Python] instantiate PersonDataDto object containing both person information (first name, last name, date of birth) and information about registration (e.g. active football professional registration in a given MA)
  • [in Python] serialize PersonDataDto object to allow the API call
  • [in Python] call a method RegisterPersonAndWaitForDetailsInCaseOfDuplicatesPost 
  • [in Python] handle the method's output (new FIFA_ID or potential duplicates)



Note that the same way that we don't ask MAs to implement all methods from our SDK, the proxy application does not need to translate every available method. Instead we recommend going through a step-by-step instruction and implementing methods one by one, whenever they are needed for a given business scenario.

Alternative solutions

We believe that a solution described in the previous chapter is most effective and should be the first choice for every MA with a system based on technology other than .NET, Java or PHP. To provide a full picture, however, we will also list a couple of alternative integration approaches.


Proxy application without API

One of the MAs implemented a solution which is very similar to the recommended one. Instead of exposing a REST API from their proxy application, however, they communicate with their NRS via a shared database. This solution has been fully implemented and works in Production.


Programming languages converters

Instead of developing a proxy application, MA could choose one of the available language converters to dynamically access an SDK of their choice. For example a Python based MA could use Py4J to access Java SDK or Python for .NET allowing to use .NET SDK. Note that this approach, although theoretically possible, hasn't been implemented by any of the MAs.


Use Connect ID API directly

Connect ID Service exposes a REST API layer. All methods called by our SDKs use this API under the hood. MA implementing a direct API access would need to solve a lot of challenges, e.g.:

  • implement integration with Azure Active Directory (authentication & authorization)
  • implement encryption/decryption of messages in Service Bus

  • implement person registration (single operation in SDK but multiple operations without it)

  • etc.


This solution is therefore not recommended (more information and arguments concerning this scenario can be found here). Like the one above, it hasn't been implemented by any of the MAs.

If, despite the recommendation, a Client chooses to pursue the direct integration with API, they will find the following resource useful as it includes the code snippets: Direct API integration (proof of concept).


Summary

There is a clear recommendation on how to integrate with Connect ID Service using a technology other than .NET, Java or PHP. If you are not convinced whether the proxy solution would work for you, we encourage you to open a ticket in this Support Portal - we will be able to provide additional information and/or technical help. We would also be happy to help you make a couple of first steps.

Other useful resources: