eFormidling is an asynchronous system. It will accept requests on to a queue and generate a receipt after some time. The time will wary a lot from a few milliseconds to up to 24 hours. One submission will eventually get many receipts for different steps, but the most important one would probably be a confirmation of delivery.
This asynchronicity is not handled by the current client implemetation used by Apps. They will show the user a receipt of success before knowing how the submission actually went.
In scope
The channel currently being used is KS SvarInn. Another channel that has been wanted is DPV.
Question:
Should we allow apps that display success despite not actually knowing for sure whether the shipment succeeded or not?
The apps currently in development jumps directly to the receipt page once the user has submitted the data. This gives the impression of success. For other apps we rely on the application owner to take action. The responsibility is shifted over to them or somone they have hired to handle new instances.
The eFormidling integration is sneaking in a mechanism similar to what we have in Altinn 2 where Altinn is responsible for the sending of data untill confirmed received by the recipient.
Analysis:
How should Altinn ensure that the shipment is actually delivered? If eFormidling/KS SvarInn continue to refuse our shipment, how do we handle it? When KS has taken responsibility for a shipment they guarantee delivery and will eventually use print and mail it if necessary.
An alternative is to force apps that use eFormidling to have a waiting step in the process. The app will not indicate success unless we have successfully delivered the data through eFormidling. If all attempts to send the data fails, the user is informed and will need to try again later or contact their municipality in a different way.
Out of scope
No response
Additional Information
No response
Analysis
It's difficult to see Altinn implementing a printing and mailing system, but having apps that can wait for a successful submission sounds like a fun project.
The idea behind a waiting step comes from the SKD apps with feedback steps. We copy the idea and create a system that can check for receipts in eFormidling and automatically update the instance once the submission has gone through.
This is going to involve new infrastructure with Azure Functions, Storage Queues and a database to persist statuses. Alot of it is already implemented in our reference implenetation for application owners.
We remove the eFormidling client from the Apps. The integration is moved to a new system that can handle the process.
Subscribe for events where an instance enters the waiting step.
Download data and create a shipment for eFormidling.
Store a status in a database
Queue a polling job to look for receipts from eFormidling.
Handle the receipt(s): Update instance and status based on receipt.
Automatically end the waiting step. "process/next"
Automatically complete the instance. "process/next"
Automatically set the instance as complete on behalf of application owner. (This will allow actual delete once the user wants the instance deleted.) "instance/complete"
The feedback step as a polling mechanism we can copy. Once the instance has been updated it will automatically show the receipt page if the user still have the browser window open.
Description
eFormidling is an asynchronous system. It will accept requests on to a queue and generate a receipt after some time. The time will wary a lot from a few milliseconds to up to 24 hours. One submission will eventually get many receipts for different steps, but the most important one would probably be a confirmation of delivery.
This asynchronicity is not handled by the current client implemetation used by Apps. They will show the user a receipt of success before knowing how the submission actually went.
In scope
The channel currently being used is KS SvarInn. Another channel that has been wanted is DPV.
Question: Should we allow apps that display success despite not actually knowing for sure whether the shipment succeeded or not?
The apps currently in development jumps directly to the receipt page once the user has submitted the data. This gives the impression of success. For other apps we rely on the application owner to take action. The responsibility is shifted over to them or somone they have hired to handle new instances.
The eFormidling integration is sneaking in a mechanism similar to what we have in Altinn 2 where Altinn is responsible for the sending of data untill confirmed received by the recipient.
Analysis: How should Altinn ensure that the shipment is actually delivered? If eFormidling/KS SvarInn continue to refuse our shipment, how do we handle it? When KS has taken responsibility for a shipment they guarantee delivery and will eventually use print and mail it if necessary.
An alternative is to force apps that use eFormidling to have a waiting step in the process. The app will not indicate success unless we have successfully delivered the data through eFormidling. If all attempts to send the data fails, the user is informed and will need to try again later or contact their municipality in a different way.
Out of scope
No response
Additional Information
No response
Analysis
It's difficult to see Altinn implementing a printing and mailing system, but having apps that can wait for a successful submission sounds like a fun project.
The idea behind a waiting step comes from the SKD apps with feedback steps. We copy the idea and create a system that can check for receipts in eFormidling and automatically update the instance once the submission has gone through.
This is going to involve new infrastructure with Azure Functions, Storage Queues and a database to persist statuses. Alot of it is already implemented in our reference implenetation for application owners.
We remove the eFormidling client from the Apps. The integration is moved to a new system that can handle the process.
Conclusion
No response