altinn / altinn-eformidling Goto Github PK

Description

Altinn have a single eFormidling integration point using DigDir "credentials". We want the integration point being used by Apps in Altinn to be separated from the DigDir hierarchy.

Additional Information

No response

Description

Team Platform wants to make the altinn-platform repository private. Automated tests needs to be moved here.

This includes the code and the workflow.

Additional Information

No response

Tasks

No response

Acceptance Criterias

• No remaining code or workflows in the altinn-platform repository
• Failures are correctly reported to slack on the alerts channels

Description

Turn off the TT02 tests for failed shipments.

Tasks

• Re-work test scripts
• QA
• Manual verification

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update slackapi/slack-github-action action to v1.27.0

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

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

• No alarm when we find receipts with message timeout status on incomming messages
• 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

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.

1. Subscribe for events where an instance enters the waiting step.
2. Download data and create a shipment for eFormidling.
3. Store a status in a database
4. Queue a polling job to look for receipts from eFormidling.
5. Handle the receipt(s): Update instance and status based on receipt.
   1. Automatically end the waiting step. "process/next"
   2. Automatically complete the instance. "process/next"
   3. 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"
6. 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.

Conclusion

No response

On hold. Not sure if the eFormidling client code used by the Apps belong here or not.

Description

Code related to the eFormidling client currently located in the altinn-studio repository should be moved into its new home.

Try to retain as the commit history.

Additional Information

No response

Tasks

No response

Acceptance Criterias

No response