Analyze: Need for forward compatiblity for agency systems

[TheTechArch]

Description
We need to analyze the need for forward compatibility for agency systems.

https://docs.altinn.studio/development/analysis/api/agency/

Input from pilot SSB
They are currently receiving the data in their system through SOAP and would like this to also be possible in "tjeneste 3.0"

Tasks

• Identify all relevant agency APIs
• Analyze if any of them need to support forward compatibility.

[altinnadmin]

The agency systems in general needs to be able to do the following:

Functional need	Altinn 2	Altinn 3
Receive data	Download queue, SOAP web services or batch	Platform REST API + feed
Prefill data	SOAP web service or batch	App REST API for instantiation or call API from app
Create an instance	SOAP web service or subscription file (abo batch)	App REST API for instantiation

@GGunnar My impression is that the feedback we've got from the pilots and various other service owners is that they'd prefer to use the new Altinn 3 APIs instead of the old stuff. Is that correct?

[altinnadmin]

There are some major positive effects if agency systems can use the new REST APIs instead of developing forward compatibility in Altinn 2:

• We avoid adding (and forever being stuck with) dependencies on Intermediary and BizTalk
• Modern integration patterns that scale and does not require setup is "enforced" and will be the default
• Maskinporten and OAuth2 can be used instead of username / password
• Simpler and more maintainable architecture
• Reduces scope for MVP significantly
• Instantiation and "prefill" will be a testable part of apps instead of part of the platform.
• "Special needs" for integration (if any) can be served at a later stage using apps and the flexibility in the architecture

If @GGunnar can confirm the assumption about the feedback from our service owners I think we should close this issue. If anybody disagrees, now is the time to speak up :)

[GGunnar]

Our feedback so far from service owners are that forward compability is not a requirement, therefore closing this issue.