The archiving system at Norges Bank generates a respons and sends it to us as a new message using the same conversation id. This is the theory as to why we're getting incomming messages from Norges Bank.
Conclusion: We should not have alarms on this, as it is a bug outside our systems (people should not send messages in the first place). The sender will also get "failed message" in theri end.
Additional Information
The API might already have support for filtering on incomming or outgoing messages.
API doc
Acceptance Criterias
[x] No alarm when we find receipts with message timeout status on incomming messages
[x] Issues with messages being sent still trigger alarms
Testing
This is a little tricky to test. The hope is that we can check for new LEVETID_UTLØPT receipts and cross check with the type of message as well as the time of alarms. A regression test would mean that we still correctly generate alarms for issues with messages we're sending. Is this something we can trigger?
Description
The archiving system at Norges Bank generates a respons and sends it to us as a new message using the same conversation id. This is the theory as to why we're getting incomming messages from Norges Bank.
Conclusion: We should not have alarms on this, as it is a bug outside our systems (people should not send messages in the first place). The sender will also get "failed message" in theri end.
Additional Information
The API might already have support for filtering on incomming or outgoing messages. API doc
Acceptance Criterias
Testing
This is a little tricky to test. The hope is that we can check for new LEVETID_UTLØPT receipts and cross check with the type of message as well as the time of alarms. A regression test would mean that we still correctly generate alarms for issues with messages we're sending. Is this something we can trigger?