BiDiKo: Document `notify-reply` event when receiving system has become aware of reply

Business requirements

• Onlineservice operators require proof that a Fachverfahren has received knowledge of a Submission...
  • ...in order to protect agains false claims that the Fachverfahren has lost submissions
• Fachverfahrens operators require proof that an Onlineservice has received knowledge of a Reply...
  • in order to protect agains false claims that the Onlineservice has lost replies
• We require proof that an Onlineservice has received knowledge of a Reply...
  • ...in order to protect agains false claims that FIT-Connect has lost the Reply and false claims that FIT-Connect did not inform the Onlineservice about the Reply
• We require proof that a Fachverfahren has received knowledge of a Submission...
  • ...in order to protect agains false claims that FIT-Connect has lost the Submission and false claims that FIT-Connect did not inform the Fachverfahren about the Submission
• All parties require proof over which mechanism (callback or polling) the recipient has received knowledge of the Submission/Reply in order to further debug the (false) claims.

Technical requirements

With the event notify-reply, the zustelldienst documents that the receiving system has become aware of the reply. How this was done is documented with the entry notifyType:

• notifyType = polling: When replies are retrieved or listed (only for the 1st call, since not every access should be logged)
• notifyType = callback: When callback is triggered by the zustelldienst. The implementation is equivalent to notify-submission.

Akzeptanzkriterien

1. Write notify-reply of type callback event when callback succeeded after submitting a reply.
2. Write notify-reply of type polling event when GET /replies was called.
3. Write max. one notify-reply event for every notify-type (polling|callback).

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

• [ ]