-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overgangsløsning #74
Comments
Samspill mellom Altinn2 og Altinn 3, f.eks. for å frikople migreringsløpet for mottaker vs. avsender |
@CWO79 @erikhag1 som avtalt legger jeg inn kommentar her rundt de alternativene vi diskuterte. Edit; Etter @CWO79 sin kommentar la jeg til nytt pkt A, resten rykket da ned. En generell utfordring er å få alle eksisterende brukere av formidlingstjenesten over på ny plattform innen eksisterende Altinn 2 plattform skal skrus av. Listet i anbefalt rekkefølge; Alternativ "A" Begge løsninger i parallell, isolert fra hverandre.
Alternativ "B" Begge løsninger i parallell med Bro/Synkronisering på tvers
Alternativ C: "Fasade"-løsning.
Alternativ D: "Emulert Altinn 2"-løsning.
|
Hei
Jeg savner et alternativ som handler om at vi kjører Altinn 2 og Altinn 3 i parallell, uten å lage overgangs api (altså noen av de alternativene du ha skissert opp)
Så kan vi heller bruke ressurser mer hensiktsmessig på å hjelpe tjenesteeier over på nytt API.
Enig?
Fra: Ragnar Fatland ***@***.***>
Sendt: torsdag 21. september 2023 19:31
Til: Altinn/altinn-broker ***@***.***>
Kopi: Wold, Camilla Marie Røsholm ***@***.***>; Mention ***@***.***>
Emne: Re: [Altinn/altinn-broker] Kunne fortsette å kjøre på eksisterende versjon av løsningen i en overgangsperiode (Issue #74)
[ Ekstern e-post ]
@CWO79<https://github.com/CWO79> @erikhag1<https://github.com/erikhag1> som avtalt legger jeg inn kommentar her rundt de alternativene vi diskuterte.
Uansett tilnærming er det fare for at det fører til at implementering av ny versjon blir nedprioritert.
Her ser jeg få tilnærminger som ikke gir for mye overhead.
Listet i anbefalt rekkefølge;
Alternativ "A" Bro/Synkronisering
* Man bygger den nye løsningen i separat infrastruktur, men med nok fellestrekk i prosessen til at man kan kjøre en forsendelse via enten A2 eller A3.
* Batch-Sync-jobb som kjører på Altinn 2-plattformen som synkroniserer forsendelser mellom A2 og A3.
* Eget API-endepunkt hostet i A3 som Kun Sync-jobb benytter; IP-Filtrert, dedikert båndbredde.
* Det må være en mapping mellom A2-formidlingstjenester og A3-formidlingstjenester der synk skal være mulig.
* Ingen nye brukere tillates på A2-formidlingstjenester.
* Når en forsendelse opprettes eller endres i en av løsningene, synkroniseres endringen på tvers.¨
* Data lagres begge steder.
Ulemper er duplisering av data, og noe tidsforsinkelse før hendelser reflekteres på annen plattform.
Man kan bruke regelsett slik at man kun tillater dette for enkelte formidlingstjenester/avsendere/mottakere for å redusere unødvendig dobbelt-lagring.
Dette vil gjøre det mulig for en miks av brukere på både gammel og ny versjon av tjenesten, noe som kan gjøre det lettere å planlegge migrering siden man ikke må ta "hard switch".
B: "Fasade"-løsning.
* Krever som Alt A at ny prosess i stor grad kan kjøres som gammel.
* Altinn 2 API'ene reduseres til fasader/skall som kun kaller videre til Altinn 3 API.
* Autentisering/Autorisasjon kan være utfordring; man må nok fremdeles benytte A2 sin stack videre, spesielt for de systembrukere og autentiseringsmetodene som ikke støttes i A3.
C: "Emulert"-løsning.
Bare aktuell dersom man må støtte A2-APIene etter at A2 er tatt ut av drift:
* Det bygges et API som benytter A2-kontraktene, men som er bygd på toppen av A3-stacken og hostes i cloud.
* Vil kreve en del merarbeid for dra ut nødvendige A2 autensiering/autorisasjons-komponenter og hoste disse sammen i cloud
-
Reply to this email directly, view it on GitHub<#74 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5N7QGKMFGGAYEEW2A6HQLDX3R2TTANCNFSM6AAAAAA4AQTWEY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Hva med A3 api som kjører mot A2 backend frem til trafikk er flyttet og så foreta svitsj på backend tjeneste for tjeneste @RagnarFatland-Avanade ? Så litt som alt. A uten at en tjeneste må kjøre på 2 backends samtidig? Ser for meg at vi da kan skaffe oss noe frihet mtp. hvordan vi bygger A3 løsning, samtidig som det kan fungere for A2 i en overgangsperiode. (løses med felter i kallet). Vil gjerne at dere utdyper og tegner ut litt pr alternativ med fordeler og ulemper og reflekterer litt på workload for oss, brukerne. |
Tittel på denne epic-en er kanskje også litt misvisende. Tror beskrivelsene av alternativene bør inn her: #134 |
@leogasnier jeg kan sette opp det alternativet du nevner, men gitt at tidslinjen vår i stor grad er styrt av at RRR i A3 må bli klart, så vil vi mest sannsynlig bli ferdige med mesteparten av A3-stacken før vi kan begynne å kjøre reell trafikk gjennom de APIene, så da tjener vi ikke så mye på å bruke A2 backend. Motsatt retning av at A2 benytter A3 backen har jeg skissert som alternativ, men det er selvfølgelig nyanser i hvordan disse alternativene kan implementeres. På generelt basis tror jeg det er best å unngå å endre for mye på A2-løsningen, man har gjort mye der gjennom årene for å tweake Formidlingstjenesten, så derfor tenkte jeg at vi beholdt separasjon så mye som mulig. Men jeg tar ny runde og strukturerer om og tester ut mot andre folk før jeg legger det inn i #134. |
Det er #74 som er epic og #134 som er god-first-issue
Fra: leogasnier ***@***.***>
Sendt: fredag 22. september 2023 14:28
Til: Altinn/altinn-broker ***@***.***>
Kopi: Wold, Camilla Marie Røsholm ***@***.***>; Mention ***@***.***>
Emne: Re: [Altinn/altinn-broker] Kunne fortsette å kjøre på eksisterende versjon av løsningen i en overgangsperiode (Issue #74)
[ Ekstern e-post ]
Tittel på denne epic-en er kanskje også litt misvisende. Tror beskrivelsene av alternativene bør inn her: #134<#134>
-
Reply to this email directly, view it on GitHub<#74 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5N7QGJUSUGHSOLGHHLEUEDX3V73JANCNFSM6AAAAAA4AQTWEY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Users view
Title: Kunne fortsette å kjøre på eksistende versjon av løsningen i en overgangsperiode
User role(s): Kunde
Users value statement(s):
Ved å ha muligheten til å fortsette å kjøre på den eksisterende versjonen av løsningen i en overgangsperiode, sikrer vi en smidig migrering uten å forstyrre daglig drift. Dette reduserer risiko for driftsavbrudd, gir teamene tid til å tilpasse seg nye funksjoner og endringer, og sikrer at kvaliteten på våre tjenester forblir konstant mens vi beveger oss mot en oppdatert og forbedret teknologisk plattform.
Vendors view
Description
High level features (capabilities):
Additional information
TBD
User stories
Work items
Item attributes
Note: Automatically updated properties, not intended for change by you;)
Issue type: epic
Concept no: 15
Stage: Migration
ArchiConceptID: id-4639432829714218a9ce0da3cfba4850
GithubIssueID: I_kwDOIwEQMM5vYMsd
The text was updated successfully, but these errors were encountered: