MA tries to register a person using facade, in particular:
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.
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.
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:
Note that this problem will materialize for any MA that you ask for details - including yours.
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.
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.
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.