|
Title: Separate SQL Replikatie Servers voor Test- en Produktiebestanden Post by: Heart Informatisering B.V. on November 14, 2018, 03:16:29 pm M.i.v. deze Releasenote is er een nieuwe Systeemparameter opgenomen: "Separate SQL Replikatie Server voor Test- en Produktiebestanden J/N".
De vraagstelling van deze rubriek doet wellicht meer vermoeden dan waar ze daadwerkelijk wordt gebruikt, maar, strikt genomen zorgt deze rubriek er voor dat Repliceren in de Testbestanden gebeurd naar databases met namen LO, AD, PK, NT en SY in plaats van LOTF, ADTF, PKTF, NTTF en SYTF. De rubriek heeft dus alles te maken met "Repliceren". Allereerst een klein beetje uitleg, omdat in het verleden genomen (mogelijk niet logische beslissingen) toe te lichten. Repliceren naar een SQL Server gebeurt meestal alleen vanuit de Produktiebestanden. Aangezien alle Tabellen op disk per Applikatiekode worden opgeslagen, is er ook in SQL voor gekozen om "per Applikatiekode" een Database aan te maken: LO, AD, PK, NT en SY. Nb: Merk op dat we er in ADS juist voor hebben gekozen om ALLE tabellen op te nemen in één Database, immers, daarmee hebben we alle data als één consistent geheel bij elkaar, en kunnen we bijv. ook SQL Queries maken die Logistieke- en Financiële tabellen met elkaar kombineren. In SQL er hier (destijds) niet voor gekozen. Pas veel later is bedacht dat Profit standaard ook met Testbestanden wordt uitgerust, en dat het helemaal niet zo gek is om ook vanuit die Testbestanden te kunnen willen repliceren. De databasenamen hadden dus eigenlijk LOPF/LOTF, ADPF/ADTF etc. moeten heten. Bij het aanmaken van een nieuwe SQL Database, kunnen we aangeven of we dit voor Test- en Produktie gescheiden willen doen, of niet. Kiezen we voor Ja, dan worden er Databases met de namen LOPF/LOTF, ADPF/ADTF etc. aangemaakt, kiezen we voor Nee, dan wordt het LO, AD, PK, NT, SY. De LOPF/LOTF situatie behoeft verder weinig aandacht; het zal voor iedereen duidelijk zijn dat de Verkooporders uit de Produktiebestanden in LOPF terecht komen, terwijl de orders uit de Testbestanden in LOTF terecht komen. Bij een indeling LO, AD, PK, NT, SY zal het uitgangspunt zijn dat deze Databases worden gevuld met de data vanuit de Produktiebestanden. Is de replikatie tóch aktief in de Testbestanden, dan zullen deze Transakties NIET worden verwerkt, simpelweg omdat er geen SQL Database is waar ze naar gerepliceerd kan worden. Per heden is hier een 3e situatie bij gekomen. Een bestaande klant repliceert al jaren enkel en alleen vanuit de Produktiebestanden, naar Databases in de vorm LO, AD, PK, NT en SY. Zij wil nu ook vanuit Test gaan repliceren. Op zich is dit geen probleem, immers, dit kán gewoon. Natuurlijk, de bestaande indeling moet eenmalig worden omgezet van een LO,AD etc. naar een LOPF/LOTF, ADPF/ADTF etc. indeling, maar als dat gebeurt is, werkt het op zich al. Tóch is er een reden om het anders te willen hebben... Als we in SQL een Query willen uitvoeren, dan zullen we (een eventuele ConnectionString naar de SQL Server even daargelaten) een Database moeten selekteren en kunnen we onze SQL Statements uitvoeren. Dus bijvoorbeeld: USE LO; SELECT * FROM LOAR WHERE LOSU_SID = '<bedrijf>' Bedenk dat we nu honderden SQL Queries hebben voor allerlei doelen. Queries die iedere gebruiker de afgelopen jaren voor zichzelf ontwikkeld hebben, en op verschillende werkstations rondzweven. Als we nu onze Database anders gaan noemen (LOPF in plaats van LO), dan zullen we overal al dit soort Queries moeten gaan aanpassen! Als oplossing, maar mede om de SQL Server niet onnodig te belasten, is bedacht een 2e SQL Server in te zetten speciaal voor de Replikatie vanuit de Testbestanden. Omdat Profit-Base-Test is geïmplementeerd, kan de Produktieomgeving al zodanig worden ingericht dat ze naar een andere SQL Server verwijst dan de Testomgeving. Zonder dat er verder enige aanpassing nodig zou zijn, zouden we de SQL Server in de Produktieomgeving kunnen laten werken met Databases LO,AD, etc. terwijl we in de Testomgeving de boel inrichten als LOTF,ADTF etc. Ook hier geldt nu dat dit niet wenselijk is, omdat "de honderden zelf gemaakte Queries eerst omgebouwd moeten worden naar de andere Database namen" willen ze blijven werken. We willen nu in de Testbestanden eenzelfde SQL Database aan sturen als in de Produktiebestanden, waarbij we er op moeten vertrouwen dat er 'kwa inrichting' in Test- een andere SQL Server is gekoppeld dan in Produktie. Middels deze Systeemparameter geven we dat aan. Als de systeemparameter aan staat, moet er in de Testbestanden feitelijk hetzelfde gebeuren als wat er nu in Produktie reeds gebeurt. Hier hoort dus ook bij dat Profit in Test de Transakties gewoon gaat verwerken, en deze niet 'laat vervallen' omdat (zoals nu) de SQL Database niet is ingericht naar LOPF/LOTF. Ook triggert het aktiveren van de parameter dat Profit niet meer in de NCONFIG.HRT en CONFIG.HRT op zoek gaat naar settings: SQLSERVER=ON SQLSRV=<SQL Server> SQLUID=<Userid> SQLPWD=<Password> maar dat deze settings gescheiden worden voor Test- en Produktie; dus, één setje voor de Testbestanden: SQL_TEST_SERVER=ON SQL_TEST_SRV=<SQL Server> SQL_TEST_UID=<Userid> SQL_TEST_PWD=<Password> én een eigen setje voor de Produktiebestanden: SQL_PROD_SERVER=ON SQL_PROD_SRV=<SQL Server> SQL_PROD_UID=<Userid> SQL_PROD_PWD=<Password> Deze funktionaliteit is enkel beschikbaar bij aanwezigheid van de ADS versie van Heart-Profit én Profit-Base-Test. ADS is vereist omdat we in de ADS versie ook in de Testbestanden over een eigen set Systeemparameters beschikken, en settings in die Testbestanden dus ook op de afwijkende SQL Server kunnen worden ingesteld. Merk op dat omdat we twee separate bestandensets hebben met een eigen Systeem omgeving, we deze parameter in beide bestandensets op "Ja" zullen moeten zetten. Doen we dit in Test wel, maar in Produktie niet, dan kan e.e.a. toch werken, alleen zal Produktie naar de SQL* variabelen kijken, en niet naar de SQL_PROD_*. Op die manier kan probleemloos een Upgrade in Test worden gedaan, terwijl alles in Produktie niet direkt fout loopt omdat daar nog niets anders is ingericht.
|