Skip to content

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)

  • [ ]
Edited by Jonas Gröger