VISIE - Oracle Gebruikersclub Holland

Migratie APEX 3.2. naar 4.1Voor het manipuleren van gegevens vanuit de user interface(Figuur 2) wordt gebruik gemaakt van bovenstaande views waarbijdoor middel van IO-triggers de afhandeling in de databaseplaatsvindt.• je kunt gefaseerd migreren per gebruiker èn applicatie;• een fallback scenario is eenvoudig omdat de oude versie noggewoon beschikbaar is.Deze aanpak is echter niet mogelijk omdat je niet twee APEXversiesin één Database-instance actief kunt hebben. Dit komtdoordat bepaalde objecten in het SYS-schema met public synonymswerken.Figuur 1: Tonen van gegevensFiguur 2: Manipuleren van gegevensWaarom migreren?Afgezien van het feit dat je om bij te blijven zo af en toe mee moetmet de nieuwe releases, zijn ook nieuwe functionaliteiten een redenom naar APEX 4 te willen migreren. Voor Centraal Boekhuiszijn dat vooral de nieuwe features zoals Dynamic Actions,jQuery-mogelijkheden en Plug-ins.Projectaanpak en RisicomanagementOver het algemeen worden bij Centraal Boekhuis grote projectenof migraties zoveel mogelijk gefaseerd in productie genomen omhet risico zo klein mogelijk te houden. Er wordt dan een klankbordgroepgeformeerd van klanten die hieraan willen meewerken.Deze klanten zullen op de nieuwe omgeving gaan werken. Erwordt dan een constructie gemaakt om gemakkelijk te kunnenswitchen tussen de oude omgeving en de nieuwe omgeving.Om de risico’s op verstoringen zo klein mogelijk te houden, willenwe dus het liefst per applicatie per gebruiker migreren. Daarvoormoeten dan in één Database-instance twee installaties vanAPEX komen: één voor 3.x en één voor 4.1. Dan zouden we pergebruiker kunnen aangeven met welke versie er wordt gewerkt.De voordelen hiervan zijn evident:Big BangEen alternatief scenario zou zijn om een nieuwe instance te makenvoor APEX 4.1 en deze naast de 3.x versie te draaien. Dan kunje met behulp van synonyms over een Databaselink connectennaar de applicatie objecten. Hiervoor is niet gekozen uit kostenoverweging.Dit moet dan worden geregeld voor alle instances opde development-, test- en productieomgeving. Onze inschattingwas dat de kosten die hiermee gemoeid zijn niet opwegen tegende risico’s van de migratie.Voor het APEX migratieproject heeft Centraal Boekhuis dus gekozenom met een “Big Bang” in productie te gaan.Er is dus per Database-instance gemigreerd, voor meerdere applicatiestegelijk. De 16 applicaties zijn verdeeld over vier Databaseinstances. Er is bewust gekozen voor een specifieke volgorde omde kans op verstoringen bij klanten zoveel mogelijk te voorkomen.Eerst zijn de interne applicaties gemigreerd, pas daarna de applicatiesvoor de Boekhandels en Uitgevers.RollbackOmdat er altijd risico’s zijn, willen we weten of we terug kunnen.Het is niet acceptabel dat onze externe systemen niet beschikbaarzijn. Het primaire proces van de klanten komt dan in gevaar endat is onbespreekbaar; het is eigenlijk ondenkbaar dat CB Onlineniet beschikbaar is. Er wordt daarom per instance een uitgebreidrollback-draaiboek opgesteld om eventuele grote verstoringen opproductie te kunnen tackelen. Deze rollback-draaiboeken zijnook daadwerkelijk geoefend op een speciale testomgeving.Externe ondersteuningHoewel Centraal Boekhuis zelf voldoende expertise in huis heeftom deze APEX-migratie uit te voeren hebben we toch hulp gezochtbij de leverancier O2U. Zij hebben in 2009 het grootste deel vande migratie van J2EE naar APEX uitgevoerd. Zij kennen dus onzeomgeving en hebben al ervaring met (de migratie naar) APEX 4.O2U heeft aangegeven waar je bij een migratie op moet letten enheeft tevens een opleiding verzorgd voor de APEX-ontwikkelaars.Zij waren dus nauw bij de voorbereiding en de opleiding betrokkenen stonden voor ons paraat bij de daadwerkelijke migraties.ScrumteamVoor de uitvoering van dit project was er een ‘scrumteam’ beschikbaarvoor de periode van drie weken (één sprint). Alle ap-OGh Visie27