Symptoms

MA tries to register a person using facade, in particular:

  • facade.RegisterPersonAndWaitForDetailsInCaseOfDuplicates
  • facade.GetDuplicatesAndWaitForDetailsInCaseOfDuplicates 
  • facade.GetDuplicates


No details of potential duplicates are found within the timeout defined.

Note, that the symptoms are similar yet different from a situation when your requests for person details does not time-out but returns an empty string instead. That situation is well described in this article. In our case MA does not seem to respond at all.


Potential reasons

Listener of other MA is down


It often happens, especially in Beta, that listeners of other MAs are not working. If Connect ID identifies a potential duplicate in such an MA, our code will send the request for details via Service Bus but they will never come. The method will wait timeout seconds and return without duplicates.


Solution

If you have a working contact with another MA, you may ask them to start their listener. The best solution, however, will be to try to register a person for which there is a potential duplicate in your own MA. The request for details will still go via Service Bus but it will be your own MA - whose listener is obviously working - to deliver the details.



NRS and listener do not have a shared memory/storage


If both your listener and listener of another MA are alive and kicking, the possible reason has to do with the fact that the system did not recognize that a return message from another MA is an answer to a particular request for details. In other words, your system is unable to correlate a return message (with person details) with the original message (when you asked for details). In order for this correlation to work, an ID of the request message (so-called Correlation ID) needs to be stored and later retrieved by our code. By default, this is done in the memory (.Net and JAVA only) and you don't need to code anything.


Two most known reasons for the lack of shared storage are:

a) hosting Listener in the cloud (e.g. as Azure WebJob)
b) having multiple instances of your NRS system (and in effect: multiple instances of SDK)


In those cases, there is no memory shared. When the listener receives the message it saves it in memory (by default) under the certain Correlation ID. At the same time code of the SDK (method: facade.RegisterPersonAndWaitForDetailsInCaseOfDuplicates) keeps checking its memory for the appearance of a message with a given Correlation ID - the message never arrives to this memory though, because it was saved in the listener's memory.


Note that this problem will materialize for any MA that you ask for details - including yours.


Solution
The solution to this problem is well described in 3.1.8 [Optional] Advanced listener configuration of the SDK documentation. In essence, we will ask you to provide simple shared storage and we provide interfaces for 2 methods to implement saving and getting information to/from this storage.

You may also look at the attachment to this article (https://support.id.ma.services/support/solutions/articles/7000021207-integration-with-fifa-connect-id-general-overview), which shows, in a visual way, how the architecture of international duplicate detection is implemented.


You have a 2nd listener running in the background


Occasionally a developer would forget about a test listener and leave it working in the background. With some bad luck that could result with 2 listeners trying to access the very same queue. From the perspective of a developer it would look as if some messages were reaching him and some not - without any specific pattern.

The reason is of course the other listener trying to download and process messages delivered to the queue.


Solution

Stop the other listener.


Your listener is not configured to work all the time


Your listener needs to work 24/7. Let's see what can happen if you e.g. stop your listener after processing a single message (or after a minute):

* let's assume that during your testing you will send a number of messages to your listener (e.g. 100)

* since the listener is not operating all the time, some of those messages will stay in a queue

* if you now run it again in order to work on some other tests (e.g. see if your respond with person details), it will first work on the messages in the queue


In the end you will not be getting person details (current test) because your listener will be busy working on other messages (previous tests). To you it will look like the other MA (e.g. your MA) is not responding with person details.


Solution

Make your listener work 24/7. If you can't, make sure that before running any new tests your listener runs long enough to process all messages from your queue.