Met ingang van heden is de registratiewijze van Transaktionele Bestanden (module Profit-Transact) drastisch aangepast. Funktioneel was er in het oude ontwerp vast veel meer mogelijk, alleen dit werkte niet, of we snapten het niet, feit is dat e.e.a. regelmatig tot fouten leidde, en alleen wij konden wijzigingen aanbrengen in de status van transaktionele bestanden door rechtstreeks in de database te wijzigen. Ook trad met enige regelmaat een fout "Transaktiestatus Bestand xxxx gewijzigd; Verdere verwerking niet mogelijk", waarbij "Reorganiseren" dit probleem zou moeten verhelpen, doch wat niet het geval was. Per heden werkt alles een stuk eenvoudiger, en moet de gebruiker zelf zijn/haar eigen wijzigingen kunnen aanbrengen.
Navolgend een beschrijving van de funktionele wijzigingen:
Nieuwe tabellen zijn nu standaard Transaktioneel
Bij de nieuwe opzet is het uitgangspunt dat we niet voor niets over de module
Profit-Transact beschikken; een tabel is vanaf heden dan ook standaard Transaktioneel, totdat anders wordt aangegeven. Konkreet geldt dit voor alle nieuwe tabellen die met een Upgrade worden meegezonden. Voor alle tabellen die reeds op uw systeem aanwezig zijn zullen al definities gemaakt kunnen zijn die bepalen of een tabel wel/niet transaktioneel moet zijn. Tijdens de eerste Upgrade na vandaag zal middels een run worden bepaald welke van de huidige tabellen transaktioneel is, en welke niet, en wordt deze instelling bewaard.
Hoewel normaliter niet nodig, is het mogelijk om deze run nog een keer uit te kunnen voeren, middels optie #1 van menu 9-5-7.
Nb: Indien U nog niet over de module
Profit-Transact beschikt, maar op enig moment hier wel naar overstapt, kan dit ook daadwerkelijk funktioneel worden toegepast. Immers, indien de module op het systeem wordt gezet, en de run is nog niet opgestart, dan zijn er geen definities van welke bestanden wel/niet transaktioneel zijn. Zouden we dan meteen alle bestanden reorganiseren, dan worden deze als vanzelf allemaal transaktioneel (immers, een bestand is standaard transaktioneel, tot anders aangegeven). Zouden we ná implementatie van de module éérst de run opstarten, dan wordt van alle bestanden geregistreerd dat ze niet-transaktioneel zijn, en zal daarna reorganiseren ertoe leiden dat ze nog steeds niet transaktioneel zijn.
Wijzigen Transaktionele status bestand
Via optie #2 van bovenstaand menu kan een overzicht worden opgevraagd van alle (netwerk) bestanden met hun huidige Transaktionele status.
In dit overzicht worden alle bestanden vermeldt die in de SQL Database worden opgenomen (LO, AD, PK, NT, SY); Tijdelijke Bestanden komen hierin niet voor.
Per bestand wordt aangegeven vanaf welke datum de betreffende status geldig is, en door wie ze het laatst is gewijzigd (en wanneer).
Omdat bij optie #1 de hele lijst helemaal opnieuw wordt opgebouwd, gaat ook deze informatie dan verloren. Na opnieuw opbouwen zal de wijzigingsdatum-/tijd gelijk worden gesteld aan het tijdstip waarop de run werd uitgevoerd.
Middels Funktietoets F4 kan de Transaktionele Status voor een bestand worden Aangezet;
middels Funktietoets F6 kan de Transaktionele Status voor een bestand worden Uitgezet.
Zowel voor het Aan- danwel Uitzetten van de Transaktionele Status zal het betreffende bestand moeten worden gereorganiseerd, wat automatisch gebeurd zodra een van deze twee toetsen wordt gebruikt. Aan-/Uitzetten is dan ook alleen mogelijk indien het bestand voor alleengebruik geopend kan worden (ofwel, niemand mag de betreffende tabel in gebruik hebben).
Het Aanzetten van de transaktionele status van een bestand gaat gepaard met het opnieuw uploaden van dat bestand naar de SQL Server. Immers, vanaf het moment dat de tabel transaktioneel wordt, zullen alle mutaties op deze tabel als Transaktie beschikbaar worden gesteld, en voor het geval er data gewijzigd wordt, moet die data al wel beschikbaar zijn in de SQL Database. Het uploaden naar de SQL Database is overigens alleen mogelijk indien uw werkstation zodanig is ingericht dat er een verbinding kan worden gemaakt met die SQL Database. Uploaden (en daarmee het transaktioneel maken van een bestand) hoeft (dus) niet op ieder werkstation beschikbaar te zijn.
Zowel het Aan- alsmede het Uitzetten van de transaktionele status van een bestand, zal alle eventueel nog openstaande Transakties voor dat bestand verwijderen. Het wijzigen van de transaktionele status, en de daaraan gekoppelde verplichte reorganisatie, zal derhalve niet fout kunnen lopen op de melding "Reorganiseren niet toegestaan, er zijn niet verwerkte Transakties gevonden". Merk op dat als we vinden dat een tabel niet meer Transaktioneel hoeft te zijn, we de eventueel nog openstaande Transakties mogen verwijderen, immers, als we vinden dat de SQL tabel niet meer bijgewerkt hoeft te worden d.m.v. Transakties, dan mogen de Transakties die nu mogelijk nog open staan voor deze tabel ook wel komen te vervallen. Andersom: met dat we stellen dat als we een tabel transaktioneel maken en we verplichten dat deze tabel opnieuw geupload wordt naar de SQL Database, zal de huidige status daarmee al aktueel zijn in die SQL Database, en kunnen de nog openstaande Transakties eveneens komen te vervallen.
Aan-/Uitzetten Transaktieverwerking v/e Bedrijf
Middels menuoptie #3 kan worden aangegeven of een
Bedrijf wel/niet Transaktioneel is.
Met deze optie kunnen we ervoor zorgen dat als we binnen Profit de administratie voeren van 5 bedrijven, slechts één of twéé hiervan moeten leiden tot Transakties die leiden tot het bijwerken van de SQL Database. Eigenlijk een instelling die puur is bedoeld omwille van performance redenen, en waarmee we kunnen instellen dat als we met bepaalde bedrijven toch niets doen in de SQL Database, de mutaties uit deze bedrijven ook niet tot Transakties hoeven te leidden t.b.v. het bijwerken van die SQL Database.
Nb: Deze methode is 1:1 overgenomen uit de oude werkwijze. Hierbij plaats ik nog wel even een paar kanttekeningen:
Ten eerste zie ik het nut niet van de instelbare "Ingangsdatum-/tijd". Feitelijk staat deze ons toe om te stellen dat alle gegevens uit het aktieve Bedrijf vanaf morgenmiddag 14:15 transaktioneel moeten worden. Ah, dus vanaf morgenmiddag 14:15 zal een wijziging van een Artikel worden bijgewerkt op de SQL Server, echter, één probleem: de SQL Database bevat nog helemaal geen gegevens van dit Bedrijf, dus waarom pas "vanaf morgenmiddag 14:15" ? en niet "vanaf nu?".
Datzelfde geldt ook voor het uitzetten. Waarom zouden we daarmee willen wachten, en waarom niet "per nu"?
Een tweede kanttekening plaats ik bij het feit dat het Transaktioneel zijn van een Bedrijf wordt bepaald bij het opstarten van Profit. Zodra een bedrijf kwa transaktionele status wordt gewijzigd, impliceert dit dat alle gebruikers verplicht opnieuw Profit moeten opstarten om deze aanpassing te laten ingaan.
Resumerend zie ik wel degelijk het nut ervan in om transakties genereren in bepaalde bedrijven uit te kunnen schakelen, maar in praktijk zal het er m.i. op neer komen dat dit "in een weekend" gebeurt, en vervolgens gekombineerd wordt met het opnieuw uploaden van alle data uit dit bedrijf naar de SQL Database, opdat het vervolgens van kracht kan worden nadat iedereen Profit weer opnieuw opstart. Vooralsnog is er aan déze werkwijze niets gewijzigd.
Herstellen indexfout verwerking Replikatie
Om dan maar meteen de andere twee funkties van dit menu ook even te beschrijven...
Optie #4 is een bijzondere optie, die als het goed is nooit nodig is. Toch hebben we in praktijk een aantal keer meegemaakt dat er een verknald record in de tabel met te verwerken Transakties zit. Resultaat hiervan is dat de Replikatie hangt, en niet verder gaat met het verwerken van transakties. Het gevolg hiervan is dat alle navolgende ontstane Transakties niet verwerkt worden, met bijv. als gevolg dat een klant die een order plaatst op een webshop (en welke via EDI binnenkomt), deze order niet kan terugvinden op de webshop (immers, de transakties die ontstaan uit het Toevoegen van die Verkooporder worden niet verwerkt in de SQL Database).
Tot nu toe moesten wij in zo'n geval inbellen om de eerst volgende, nog niet verwerkte Transaktie te manipuleren, opdat deze weer opnieuw in de index werd opgenomen. Deze manipulatie is per heden opgenomen in een separate funktie, opdat de gebruiker deze zelf kan uitvoeren, zonder inmenging van Heart.
Deze Funktie vereist expliciete Autorisatie.
Verwerking Replikatie
Menuoptie #5 betreft het proces waarbij de Transakties worden repliceerd naar de SQL Database.
Aan dit proces is verder niets gewijzigd.
Migratie Data naar SQL Database
Een laatste Funktie waarin van alles is aangepast, betreft de Migratie van Data naar de SQL Database; ofwel, de Funktie die gebruikt wordt om tabellen te kunnen oploaden naar de SQL Database. Per saldo is er een aanzienlijke performance verbetering geboekt.
Opgave meerdere Applikatiekodes werkte niet Hoewel de eerste rubriek vroeg om de Applikatiekodes van de te uploaden bestanden, was het niet mogelijk om meerdere Applikatiekodes ineens te uploaden naar de SQL Database. De te uploaden data werd voorbereid in een separate LOPF,ADPF,PKPF,NTPF,SYPF directory in de opgegeven werkdirectory, en per directory werd een Batchfile gegenereerd met daarin de opdrachten op de in die directory voorbereidde data te uploaden naar de SQL Database. Na het voorbewerken van de te uploaden data werd er echter maar één Batchfile uitgevoerd; de laatste. Ofwel, bij het Uploaden van LO,AD,PK,NT en SY tegelijk, werd alleen SY daadwerkelijk geupload.
Alleengebruik (Exclusief openen)Alvorens de data uit een tabel wordt geupload naar de SQL, werd de te uploaden dataset voorbereid in de opgegeven werkdirectory. Bij het maken van deze subset werd een tabel nimmer geopend voor alleengebruik. Dit, terwijl als de tabel wél geopend zou worden voor alleengebruik, het maken van de subset véle malen sneller zou verlopen. Ervanuitgaande dat het uploaden van een tabel naar de SQL Database toch zo goed als nooit gebeurd terwijl er nog gebruikers in het systeem zitten, is het openen voor alleengebruik per heden instelbaar geworden, met "Ja" als defaultwaarde. De enige situatie waarin je dit zou kunnen willen doen zónder alleengebruik is m.i. als je bijv. een tabel wilt uploaden, waarvan je wéér dat er niet in gemuteerd wordt (bijv. omdat het pauze is), maar de tabel niet op alle werkstations is vrijgegeven. Voor deze situatie kan de rubriek alsnog op Nee worden gezet.
Merk op dat in de situatie Aan-/Uitzetten Transaktionele Verwerking v/e Bestand, dit bestand sowieso gereorganiseerd moet worden, en om die reden al voor alleengebruik geopend moet kunnen worden.
Alleen Transaktionele BestandenEen bestand wordt veelal Transaktioneel gedefinieerd omdat de data van die tabel benodigd is in de SQL Database, bijvoorbeeld omdat deze door een gekoppelde Webshop gebruikt wordt. Net zoveel bestanden (zo niet meer) doen we helemaal niets mee in de SQL Database, en er is dan ook geen reden om die bestanden Transaktioneel te definiëren. Stel nu eens voor dat er 2000 bestanden zijn in Profit, waarvan we er 200 Transaktioneel hebben gedefinieerd. Uitgaande van de # t/m ZZ selektie, en dat voor alle Applikaties, impliceerde dit dat we altijd 2000 bestanden opnieuw gingen uploaden naar de SQL Database, waar we er echter maar 200 nodig hebben.
En, aangezien het vnl. bestanden met zeer veel transakties zullen zijn die we niet transaktioneel willen hebben (zoals Batchboekingen, Oorspronkelijke Batchboekingen, of bijv. Boekingen) raakten we relatief veel tijd kwijt aan het uploaden van DBF'fen waar we vervolgens niets mee deden in de SQL Database.
Met ingang van heden is er dan ook een rubriek toegevoegd waarmee we kunnen aangeven dat we alleen de tabellen willen uploaden die als Transaktioneel zijn gedefinieerd; standaard staat deze selektie aan.
Alleen Transaktionele BedrijvenNóg zo'n aanpassing, maar dan in de hoek van Transaktionele Bedrijven. Stel voor je dat we 5 Bedrijven administreren in Profit, met in ieder bedrijf 20.000 Artikel-/Verschijningen. In totaal hebben we dan 100.000 Artikel-/Verschijningen. Als we nu maar voor één van deze 5 Bedrijven een Webshop hebben, hoeven we in principe maar de data uit één van deze 5 bedrijven in de SQL Database te hebben; binnen Profit hebben we de mogelijkheid (zie eerdere uitleg) om die andere 4 Bedrijven niet transaktioneel te maken. Bij het uploaden werd echter de hele tabel geupload naar de SQL Server, ofwel 100.000 records, waar 20.000 voldoende is.
M.i.v. heden worden dan ook alleen maar de records geupload van bedrijven die als Transaktioneel zijn gedefinieerd.
Selektie bestand van 12 naar 4 positiesWaar alleen bestanden met een lengte van 4 posities ondersteund worden (geupload naar de SQL Database) bestond het filter op de te uploaden bestanden uit 12 characters. Kon niet veel kwaad, maar was slecht uit te leggen.
Zappen doelbestand geëlimineerdIn de oude versie was een rubriek opgenomen waarmee kon worden aangegeven dat de oude gegevens in de SQL Database eerst gezapped moesten worden alvorens de data opnieuw te uploaden. Deze rubriek is komen te vervallen, omdat ze alleen maar verkeerd gebruikt kon worden. Indien we een tabel in zijn geheel uploaden naar de SQL Database, dan zal (uiteraard) eerst de oude inhoud in de SQL Database moeten worden verwijderd. Gaan we slechts één bedrijf uploaden naar de SQL, dan mógen we niet eens de SQL Database eerst zappen (immers, dan zouden we de data uit de andere bedrijven kwijt zijn in de SQL Database).
Migratie GereedDe batchfile, waarmee de bulk-upload van de Profit tabellen naar de SQL Database werd verricht, werd (a.g.v. Windows) opgestart als separate taak. Resultaat was dat Profit inmiddels verder ging, en met de melding "Migratie Database Gereed" kwam, terwijl die migratie eigenlijk nog amper was opgestart. M.i.v. heden komt de melding "gereed" pas als het uploaden ook daadwerkelijk klaar is.
