Eén van mijn BI collega’s had onlangs via de Service Desk een speciaal verzoek geplaatst. Hij wilde iedere avond om 22.00 uur geautomatiseerd enkele bestanden vanaf productielocatie A kopiëren naar acceptatieserver B en productieserver C.
In eerste instantie had ik bedacht dit op te lossen via Windows geplande taken op server B en C. Na nog eens wat beter na te hebben gedacht, kwam ik tot de conclusie dat dit ook een mooi klusje zou zijn voor onze Cloverleaf server. We hebben immers al een mooie site draaien waarop meerdere van dit soort koppelingen actief zijn.
Op deze manier heb je in één oogopslag al die bestandskoppelingen bij elkaar…netjes en overzichtelijk.
Voorbereiding
De productielocatie A is een gedeelde map op een van onze fileservers. Hierin plaatst BI de bronbestanden die ze op hun DataWareHouse servers (acceptatie en productie) gebruiken voor de ETL’s. Denk hierbij aan csv bestanden van zo’n 80 en 90MB die dagelijks aangevuld en gewijzigd worden.
Het account waaronder het Cloverleaf proces draait moet leesrechten hebben in productielocatie A.
Op Server B is een gedeelde map aangemaakt waar de csv bestanden naar toe gekopieerd moeten worden.
Het account waaronder het Cloverleaf proces draait moet schrijfrechten hebben in de gedeelde map op Server B en C.
Dan kunnen we het nu eindelijk over de configuratie van de koppeling gaan hebben.
De gebruikte namen zijn niet belangrijk, elke instantie heeft vermoedelijk ook haar eigen naamconventies.
Het draait meer om de configuratie.
Inbound Thread
De Encoding is op binary gezet. De inhoud van het bestand wordt dan niet aangepast tijdens de overdracht.
De recovery database wordt niet gebruikt. Op deze manier hoeven (grote) bestanden niet helemaal door de engine te gaan. We behalen daarmee behoorlijk wat performancewinst.
De fileset-local configuratie ziet er als volgt uit:
De opgegeven Directory moet natuurlijk bereikbaar zijn.
Omdat we alleen om 22.00 uur de bestanden willen kopiëren, kiezen we voor Use advanced scheduling.
.
De belangrijkste instelling is het Deletion proc nodelete_fslocal.
Het bronbestand bij een fileset-local wordt na verwerking standaard verwijderd. Om meerdere redenen willen we dat dit nu juist niet gebeurd. Om dat te voorkomen geven we een Deletion proc op.
De inhoud van deze proc is simpel:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
proc nodelete_fslocal { args } { global HciConnName ;# Name of thread keylget args MODE mode ;# Fetch mode set ctx "" ; keylget args CONTEXT ctx ;# Fetch tps caller context set uargs {} ; keylget args ARGS uargs ;# Fetch user-supplied args set debug 0 ; ;# Fetch user argument DEBUG and catch {keylget uargs DEBUG debug} ;# assume uargs is a keyed list set module "nondelete_fslocal/$HciConnName/$ctx" ;# Use this before every echo/puts, ;# it describes where the text came from set dispList {} ;# Nothing to return switch -exact -- $mode { start { # Perform special init functions # N.B.: there may or may not be a MSGID key in args if { $debug } { puts stdout "$module: Starting in debug mode..." } } run { # 'run' mode always has a MSGID; fetch and process it keylget args MSGID mh msgset $mh "" lappend dispList "CONTINUE $mh" } time { # Timer-based processing # N.B.: there may or may not be a MSGID key in args } shutdown { # Doing some clean-up work } default { error "Unknown mode '$mode' in $module" } } return $dispList } |
De ingelezen bestanden worden …
Outbound Thread
De route tussen beide threads is een eenvoudige _HCI_static_route__ raw.
Zo simpel is het dus om de Cloverleaf te gebruiken als doorgeefluik van bestanden.
