|
Heart Informatisering B.V.
|
 |
« on: December 04, 2014, 02:53:52 pm » |
|
Met ingang van 05-03-2018 is de inhoud van dit topic komen te vervallen!
M.i.v. deze Releasenote wijzigt de procedure voor het uitvoeren van een Upgrade voor gebruikers die ADS (Advantage Database Server) als onderliggende databaseengine gebruiken.
Met ADS zijn we in staat om binnen Profit tabellen aan te sturen die de grootte van 2 GB kunnen overschrijden. ADS biedt ook de mogelijkheid om midden op de dag, terwijl alle gebruikers aan het werk zijn, een backup te maken; zo kunnen we bijv. ieder uur een differentiele backup maken waarin alleen de wijzigingen van het laatste uur worden gebackupped (t.o.v. de laatste backup).
Profit in kombinatie met ADS is momenteel nog in een beginfase. E.e.a. is opgezet als een soort hybride systeem waarbij het mogelijk is om per (netwerk) tabel ervoor te kiezen deze over te zetten naar ADS danwel nog even in VFP te houden.
Willen we overigens volledig gebruik kunnen maken van een differentiele backup, dan geldt dat zoiets alleen werkt als we met <i>alle </i> tabellen over zijn naar ADS, immers als we hebben niets aan het kunnen terughalen van een Verkooprderregelbestand van een uur geleden, als we voor het Verkooporderbestand zelf terug moeten naar de backup van gisteren.
Het doel is dan ook om zo snel mogelijk met alle tabellen over te kunnen naar ADS. M.i.v. deze Releasenote is dat in principe al mogelijk, met uitzondering van tabel LOPR; hier moeten we eerst nog even een probleempje oplossen.
Overigens betekent dit niet meteen dat we alle tabellen nu meteen in ADS moeten definieren, er zal immers eerst uitvoerig getest moeten worden. In de Testbestanden was het al mogelijk om alle tabellen als ADS te definieren, en die Testbestanden zijn erg belangrijk gedurende het testproces.
Merk op dat als we met een tabel over gaan naar ADS, de data van de VFP tabel moet worden overgeheveld naar de ADS Server, en alle gebruikers daarna moeten weten dat de tabel voortaan uit ADS gelezen moet worden. Dit vereist dat alle gebruikers opnieuw moeten opstarten. Tijdens de upload zelf moeten alle gebruikers uit Profit zijn. Konkreet zal het eropneerkomen dat iedereen uit Profit moet zijn als we een tabel gaan uploaden naar ADS.
De overgang met een tabel naar ADS dient eerst in de Testbestanden uitvoerig getest te worden alvorens de betreffende tabel in de Produktiebestanden naar ADS te uploaden. Profit kent duizenden funkties die veelal nog in diverse kombinaties uitgevoerd kunnen worden, en iedere klant werkt anders dan de ander. Niet alles is op voorhand even goed te testen.
Het is derhalve van groot belang uw kritieke bedrijfsprocessen eerst in de Testbestanden te testen alvorens de tabel in de Produktiebestanden te uploaden. Dit, om te voorkomen dat u buiten de werktijden van Heart om een tabel gaat uploaden, en pas dan konstateert dat we voor tabel nog net even niet helemaal klaar waren. Uiteraard geldt dat zodra de fout direkt gekonstateerd wordt, we de tabel altijd weer uit ADS kunnen verwijderen, waarna (na opnieuw opstarten) als vanzelf de VFP tabel weer aktief zal worden, maar, als we inmiddels al veel data hebben ingevoerd, wordt dit lastig, want we zullen een inconsistent systeem krijgen.
Met de Upgrade gaat er ook iets drastisch veranderen.
In VFP werken we met 'normale' tabellen, die we te pas en te onpas kunnen openen. In ADS zou zoiets in theorie ook mogelijk zijn mits we met zgn. Free Tables zouden werken. Maar, differentieel backuppen zou dan niet mogelijk zijn, en dat is toch een van de 'musts', immers, als er iets fout gaat, willen we niet een dag voor niets gewerkt hebben.
In ADS geldt dat er een Data Dictionary de set met tabellen beheert. Voor de Testbestanden en de Produktiebestanden hebben we separate Data Dictionaries tot onze beschikking, ieder met zijn eigen tabellen. Zie ook http://ha1.heartprofit.nl/profit/index.php?topic=26395.0
Zo'n tabel weet van zichzelf in welke Data Dictionary ze is opgenomen, en, een tabel kan <i>niet </i> aan twee Data Dictionary's gekoppeld worden. Voor de meeste tabellen kan dit geen kwaad, immers die hebben we toch al gescheiden voor Test- en Produktie. Een aantal tabellen (Systeemtabellen) hebben we echter maar in 1 versie, die voor Test- gelijk is aan Produktie. Zo ook de Gebruikersgegevens (APUS) zijn voor Test- en Produktie gelijk.
In ADS kan dat niet meer, immers we kunnen het gebruikersbestand niet in twee Data Dictionary's opnemen. M.i.v. heden worden die tabellen (zodra ze in ADS worden opgenomen) dubbel uitgevoerd (SYTF voor de Testbestanden, en SYPF voor de Produktiebestanden).
In een Profitsessie connecten we aan 1 Data Dictionary: HP_TEST.ADD of HP_PROD.ADD. We hoeven nu alleen maar aan te geven welke tabel we nodig hebben, en de Data Dictionary regelt wel waar die tabel en haar indexen staan. Of, zoals in een SQL Query, SELECT * FROM LOAR zou voldoende zijn om alle gegevens uit de artikeltabel te lezen, de Data Dictionary weet wel waar de file LOAR zich bevindt.
Van belang is dat de database voor de Testbestanden nu kompleet gescheiden is van de database in de Produktiebestanden (ok, op zich geldt dit pas zodra we met onze Systeembestanden over zijn naar ADS), maar dat is het uiteindelijke doel: alle tabellen in ADS.
Ongeacht of we nu met <b>Profit-Base-Test</b> werken of niet (bij de aanwezigheid van die module hebben we in de Testbestanden ook een andere set programmatuur, en kunnen we eerst alle nieuwe funktionaliteit in de Testbestanden testen alvorens we de Upgrade in Produktie uitvoeren), er zijn een aantal Systeembestanden die voorheen 1x van data voorzien werd wat nu 2x zal moeten gebeuren.
Het meest duidelijke voorbeeld zal dan "de Releasenotes" zijn, welke Systeemtabellen maar 1x werden gevuld zodra de Upgrade werd uitgevoerd, en daarna waren ze meteen voor Test- en Produktie bekend.
Als we Profit-Base-Test hadden en de Upgrade in Test hadden uitgevoerd, waren de nieuwe Releeasenotes in Produktie al bekend, terwijl de Produktieomgeving op zich nog met de oude set programmatuur werkte. Zo slecht is het dus niet dat dit nu formeel gescheiden is; gekombineerde Systeemtabellen had ook nadelen.
Als we geen Profit-Base-Test hadden, was er maar 1 set van de programmatuur, en kon het op zich geen kwaad. De Upgrade werd als eerste uitgevoerd in de Produktiebestanden (de Releasenotes waren daarna in Produktie- en Test bekend) en daarna hoefde alleen nog een Database Upgrade te worden uitgevoerd in Test.
In de nieuwe opzet geldt dat de Systeemdatabase voor Test- en Produktie gescheiden zijn. We <i>moeten </i> twee keer die Releasenotes 'inlezen', anders hebben we die maar in 1 van de 2 datasets.
In theorie lijkt de oplossing eenvoudig: kopieer dat dan gewoon door.
Dat lijkt simpel, maar, in SQL kunnen we niet zomaar een INSERT INTO SYUG SELECT * FROM SYUG doen, immers, we hebben nu twee tabellen die hetzelfde heten, en hoe geven we aan dat die ene tabel uit een andere Data Dictionary gelezen moet worden?
De meest eenvoudige oplossing lijkt dat we in ADS de Upgrade gewoon twee keer moeten opstarten. In beide bestandensets een keer.
Hierbij zal de Upgradeprogrammatuur zelf 'weten' of Profit-Base-Test aanwezig is, en afhankelijk daarvan iets anders werken.
<b>Geen Profit-Base-Test</b>
In de oude situatie moesten we de Upgrade uitvoeren in de Produktiebestanden. De nieuwe structures werden gekopieerd, de nieuwe tijdelijke bestanden werden op het systeem geplaatst, de Database Upgrade vond plaats (in die Produktiebestanden) en de programmatuur werd gekopieerd. Als de Upgrade klaar was werden er mogelijk nog wat konversies uitgevoerd, moesten we omschakelen naar de Testbestanden, en moesten we daar nog een Database Upgrade uitvoeren. Nogmaals de programmatuur kopieren was niet aan de orde, immers, we hebben maar 1 set van de programmatuur.
In de nieuwe situatie zullen we de Ugrade in Produktie moeten uitvoeren. Als we klaar zijn met de Upgrade, doen we geen Database Upgrade in de Testbestanden, maar moeten we de Upgrade nogmaals opstarten in de Testbestanden!
Nb: Merk op dat als we nog niet over zijn met onze Systeemtabellen naar ADS dit tot een waarschuwing "Deze Upgrade is al eens uitgevoerd, weet U het zeker?" zal leiden. Deze melding kunnen we dan gewoon negeren. Het kan immers ook geen kwaad om diezelfde programmatuur nogmaals te kopieren.
De Upgradeprogrammatuur zal nu moeten weten dat als we de Upgrade in de Testbestanden doen, terwijl er maar 1 set programmatuur bestaat, we die programmatuur niet nogmaals gaan kopieren. Hetzelfde geldt bijv. voor de Helptekst, die ook niet meerdere malen gekopieerd hoeft te worden.
<b>Let op:</b> Het is dus wel van wezenlijk belang dat de Upgrade in dit geval eerst in Produktie wordt uitgevoerd, en daarna pas in Test!
<b>Wel Profit-Base-Test</b>
De procedure zal nagenoeg hetzelfde zijn als hierboven; we zullen de Upgrade in beide bestandensets moeten uitvoeren, echter, omdat we met deze module in Test- en Produktie een eigen set programmatuur hebben, zal in deze versie de programmatuur de tweede keer ook gekopieerd moeten worden.
Dan is er nog een belangrijk verschil: we hebben <b>Profit-Base-Test</b> natuurlijk om de Upgrade eerst te kunnen testen in de Testomgeving. In tegenstelling tot geen Profit-Base-Test, waar we de Upgrade als eerste op zullen starten in de Produktiebestanden, doen we dat bij aanwezigheid van Profit-Base-Test eerst in de Testbestanden!
Het enige nadeel van deze methode is, dat we voorheen een Upgrade konden doen in Test, deze daar een week laten staan, om vervolgens pas de Upgrade over te zetten naar Produktie. In die week konden dan allerlei problemen worden opgelost, handmatig naar Test worden overgezonden, en het geheel werd in een keer overgezet naar Produktie.
Nu de Upgrade opnieuw moet worden uitgevoerd in Produktie, bevat deze niet de handmatig overgestuurde aanpassingen die hebben plaatsgevonden in de periode dat de Upgrade pending was.
Vooralsnog lijkt dit niet zo'n onoverkomelijk probleem. Als dit al eens optreedt, weten we natuurlijk wat er gewijzigd is. En, als we dat niet willen hoeven te weten, kunnen we altijd nog iets verzinnen dat de Upgrade die in Produktie uitgevoerd moet gaan worden 'gegenereerd wordt' vanuit de Testbestanden, immers, die bevat alles.
Als u niet met de ADS versie werkt, is dit verhaal niet van toepassing Werkt u wel met de ADS versie dan geldt dat vanaf nu de Upgrade in beide bestandensets een keer moet worden uitgevoerd.
Bij Profit-Base-Test eerst in de Testomgeving, en daarna in Produktie. Zonder Profit-Base-Test juist eerst in Produktie, en daarna in Test.| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz | | SYUGHKUV | Upgrade Heart -> Klant | 02-07-2014 | 04-12-2014 | | SYUGPGGN | Genereren Upgradeset | 04-12-2014 | 05-12-2014 | | SYUGTPUV | Uitvoeren Upgrade Test -> Prod | 02-07-2014 | 04-12-2014 |
|
