ABIS to queue - handling invalid messages

Developer
1

Hi,
I have a clarification on message handling in ABIS from the message queue.
As part of ABIS spec here it specifies the response failure reason code 4 owing to ‘invalid request structure’. I am not sure, how can this error be generated?
Since, the message can be either Text or Bytes and if while parsing the message, there is an error, then there is no way to send back any context in response queue such as id, requestid, etc. The only way to respond such message is put it in dead letter queue (DLQ)
So, is there a DLQ configured where such invalid messages can be put?
Do let me know if my understanding is incorrect and if so, it will be great if you can give an example of how to handle such invalid messages without such messages being redelivered by active mq.

Thanks,
Srinath

2

Hi @srinathv

I have asked my tech lead to guide you on DLQ configuration and whether there is a way to handle invalid messages without such messages being redelivered by active mq.

@sowmya695 @Monobikash Look into this and guide him on how this can be done.

Best Regards,
Team MOSIP

3

Hi @srinathv ,

Thanks for your query. When a request structure is invalid and abis system does not understand, it will return with error code 4. While responding abis will always send back request id. You are correct when you say during parsing if error occurred then it might send error code 4. If json has request id (ideally it should) and other fields are missing then it can be read from json and sent back in the response so that there is context. But if the message does not have any relevant information and abis returns back with error code 4 without context then it will be logged in regproc as well and abis table status will be updated properly. Manual intervention would be required to debug what is going wrong. I don’t understand purpose of sending in DLQ as the response from ABIS will be consumed by regproc and status will be updated in DB.

4

Thanks @Monobikash :+1:

The context for my question is specifically when the request ID is not extractable since the processing from message queue throws exception on Text or Byte type message. In such cases, there is no way to extract the request ID as the conversion to a DTO such as this:

public class MessageDTO {
private String id;
private String version;
private String requestId;
private String requestTime;
private String referenceId;
private String referenceURL;
}
Will fail! Then there is no way on the ABIS side to post a response to this message.

And for such a scenario, the typical construct is to push it to DLQ so that it doesn’t get redelivered & get reprocessed.

This is the reason I wanted to clarify.

Thanks,
Srinath

5

Hi Srinath,

Ideally that should not happen as regproc will make sure the request id is present. But in case id is missing there is no way to trace. Thanks for bringing it up. This scenario is not handled as we make sure request is valid.
But we should consider DLQ scenario you have mentioned.

6

G8! :+1:

I will leave it as ‘shouldn’t come here with a severe error’ assuming no message will come without id for now.

Thanks,
Srinath

1 Like