FTP-siirtojen yleissuunnittelu ja organisointi osa 2

Transkriptio

1 FTP-siirtojen yleissuunnittelu ja organisointi osa 2 Jorma Kiiski, Manycom Software Oy Tämä artikkeli on jatkoa osalle 1, joka julkaistiin edellisessä Commentissa 1/2005. Kuten edellisessä osassa todettiin, tässä artikkelissa keskitytään FTP-siirtoympäristön yleissuunnitteluun ja organisointiin liittyviin kysymyksiin sovellusintegroinnin ja automatisoinnin näkökulmista. FTP-tekniikkaa käsitellään tilan puutteen vuoksi vain siltä osin, kuin se määrää reunaehdot yleissuunnittelulle. FTP-siirtoympäristön ja siirtojen yleissuunnittelun ja organisoinnin merkitys tulee selvästi esille, kun todetaan, että keskiverto yrityksellä on tyypillisesti 3-10 FTP-yhteyskumppania, joiden kanssa ajetaan päivittäin kymmenkunta tai jopa kymmeniä erilaisia FTP-siirtoja. Kun monet näistä siirroista ajetaan asiakaspalvelun nopeuttamiseksi tai muusta syystä useita, tai jopa useita kymmeniä kertoja päivässä, kasvaa päivittäisten FTP-yhteyksien määrä keskiverto yrityksessäkin helposti yli sadan. Tällaisessa ympäristössä manuaalinen operointi ei ole enää mahdollista tai ei ainakaan järkevää ja kustannustehokasta joten edessä on FTP-siirtotöiden sekä niihin välittömästi liittyvien tietomuunnosten ja muiden prosessien integrointi sovelluksiin, ja koko systemmin automatisointi. Kyseessä on yrityksen päivittäisten toimintojen kannalta varsin kriittinen ja kompleksinen ympäristö. Sen luotettava toiminta, ylläpidettävyys, poikkeustilanteiden tehokas käsittely ja joustavuus tuleville muutostarpeille vaatii huolellisen yleissuunnittelun. Tällainen yleissuunittelu, jossa mallinnetaan, vaikioidaan ja ohjeistetaan se, miten FTP-siirrot ja niihin liittyvät prosessit tulee hoitaa, on syytä tehdä riittävän ajoissa! Muutoin tuloksena on sellainen viidakko, josta on vaikea saada kokonaiskuvaa, ja jonka ylläpito sekä muutostarpeiden ja varsinkin poikkeustilanteiden hoito aiheuttavat jatkuvasti ongelmia. Tilanteen korjaamista jälkikäteen hankaloittaa usein se, että muutokset vaikuttavat usein myös vastakumppanin toimintaan. Osassa 1 esitettiin lista asioista, joita FTP-siirtoympäristön yleissuunnittelussa ja organisoinnissa tulisi mm. ottaa huomioon. Aloitetaan käsittelemällä ensin FTP-asiakas- ja FTP palvelintilassa tapahtuvia siirtotoimintoja. FTP-asiakas- ja FTP-palvelintoiminnot Kuten jo artikkelin osassa 1 todettiin, FTP:tä käytettäessä kommunikoidaan asiakas-palvelin-mallin mukaisesti, missä koko FTP-istunnon ajan toinen järjestelmä (yhteyden ottaja) on FTP-asiakas, joka suorittaa sisäänkirjauksen, ja tekee kaikki siirto- ja muut palvelupyynnöt FTP-palvelimelle, ja toinen järjestelmä on siis koko yhteyden ajan FTP-palvelin, joka vain suorittaa (tai hylkää) palvelupyynnöt, ja palauttaa sen mukaisen paluukoodin ja sanoman FTP-asiakkaalle. Todettiin myös, että FTP-asiakas- ja FTP-palvelinprosessit ovat toisistaan täysin erillisiä, ja siten samassakin OS/400- tai i5/os-loogisessa järjestelmässä (partitio) voidaan ajaa yhtä aikaa sekä FTPasiakas- että palvelintöitä, ja luonnollisesti useita samanaikaisesti. Myös saman loogisen järjestelmän sisällä voidaan ajaa FTP-asiakas-FTP-palvelin siirtoja sisäistä ns. loopback-yhteyttä tai esim. paikallisen LAN:n kautta kiertävää yhteyttä käyttäen. Tätä mahdollisuutta käytetäänkin varsin yleisesti mm. siirrettäessä ja konvertoitaessa tiedostoja eri tiedostojärjestelmien välillä. Onkin varsin yleistä, että järjestelmä kommunikoi samanaikaisesti joko yhden ja saman, tai useiden eri vastakumppaneiden kanssa ajaen sekä FTP-asiakas- että FTP-palvelintöitä. FTP-istunnon siirtotoiminnot FTP-asiakastilassa toimittaessa siirtotoimintoja ovat tiedoston lähetys (SEND, PUT, SUNIQUE), tiedoston tietueiden lähetys lisäämällä ne tulostiedoston tietueiden perään (APPEND), ja tiedoston nouto (RETRIEVE, GET). FTP-palvelintilassa toimittaessa siirtotoimintoja ovat tiedoston lähetys FTP-asiakkaan pyynnöstä ja tiedoston vastaanotto FTP-asiakkaan pyynnöstä. Manycom Software

2 Saman FTP-yhteysjakson eli istunnon aikana FTP-asiakas voi toki pyytää FTP-palvelimelta useammankin tiedoston siirtoa ja tarvittaessa molempiin suuntiin, eli siis sekä lähetystä että noutoa, ja missä tahansa järjestyksessä. FTP tuntee myös monen tiedoston lähetyksen (MPUT) ja noutamisen (MGET) yhdellä pyynnöllä käyttäen useaa määrättyä tai geneeristä tiedostonimiä (abc*). Erityisesti on syytä huomata, että FTP-asiakas voi sekä lähettää että noutaa tiedostoja, eli se pystyy siis siirtämään tiedostoja molempiin suuntiin: järjestelmästä ulos ja järjestelmään sisään. Tarvitaanko siis FTP-palvelimena toimimista lainkaan? Toisaalta, jos toimitaan FTP-palvelimena, FTP-asiaakkaat voivat sekä lähettää järjestelmään tiedostoja että noutaa järjestelmästä tiedostoja. Periaatteessa riittäisi siis, että toimitaan vain joko FTP-asiakkaana tai FTP-palvelimena, mutta riittääkö tämä käytännössä? Seuraavassa käsitellään tarkemmin mm. tätä kysymystä tarkastelemalla kunkin siirtotoiminnon erityispiirteitä siirtojen yleissuunnittelun kannalta. Koska FTP-asiakas- tai FTP-palvelintilassa toimiminen on luonteeltaan hyvin erilaisia, jaetaan siirtotoimintojen käsittely seuraavassa näiden tilojen mukaisesti. FTP-asiakastila: tiedoston lähetys Yleistä Kaikilla yrityksellä on yleensä tarve siirtää tuotamaansa dataa ja informaatiota tiedostoina toisiin yrityksiin toimimalla itse aktiivisena, siirron aloittavana ja suorittavana osapuolena. Tällöin siirtäminen tapahtuu lähettämällä FTP-asiakkaana toimien tiedostoja, jotka tyypillisesti sisältävät esim. laskuja, tilauksia, viranomaistietoa, tms., toisiin järjestelmiin. Lähettäminen vaatii siis toimimista FTP-asiakkaana, josta seuraa, että vastakumppanin on tällöin kyettävä ja suostuttava toimimaan FTP-palvelimena. Lähettämisellä on (vaihtoehtona sille, että toinen osapuoli noutaisi tiedoston) etunsa ja varjopuolensa. Merkittävin etu seuraa siitä, että sovellus, joka tuottaa tiedoston, tietää, minkä tiedoston se on tuottanut (tiedoston tunnistus) ja tietää milloin tiedosto on valmis lähetettäväksi. Näin se voi tarvittaessa välittömästi itse lähettää tai pyytää siirto-ohjelmistoa lähettämään tiedoston eteenpäin, jolloin on siis mahdollista välttää viiveiden syntyminen. Sovellus voi tietenkin myös suorittaa itse tai pyytää siirto-ohjelmistoa suorittamaan ajastetun eli viivästetyn lähetyksen. Lähettäminen on suoraviivaista ja luontaista myös siinä mielessä, että tiedoston tuotanut sovellus tietää, mitä aineistoa sen tuottama tiedosto sisältää ja mihin tiedosto on lähetettävä. Tämän seurauksena lähetyspää myös tietää, mitä muuta prosessointia ml. tietomuunnoksia tiedostolle on tehtävä paikallispäässä ennen siirtoa, mitä mahdollisia alustustoimenpiteitä etäpäässä on tehtävä ennen siirtoa, mitä asetuksia tarvitaan ennen siirtoa, miten tiedosto on lähetettävä (mekkikoodikonversiolla vai binäärisiirtona), millaisella tietueen pituudella etätiedosto luodaan jos luodaan, mitä siirron jälkeen on tehtävä etäpäässä ja paikallispäässä, jne. Sovellus myös tietää sen, kenen nimissä ja valtuuksilla tiedosto lähetetään, ja mitä hakemisto- ja lokimerkintöjä halutaan siirtotyöstä tehdä. Tiedoston luoneen sovelluksen tulee periaatteessa, mutta onneksi vain periaatteessa, tietää kaikki siirtoon ja siirtotyön ohjaamiseen ja suorittamiseen tarvittavat tekniset yksityiskohdat. Sovelluksen tekemistä helpottaa huomattavasti, jos käytössä on väliohjelmisto, tässä tapauksessa siirto-ohjelmisto, jonka etukäteen tehtyihin, siirron tekniset yksityiskohdat määrittäviin kokoonpanomäärityksiin sovellus voi API-rajapinnassa viitata. Siirto-ohjelmisto huolehtii sitten siirronaikaisista teknisistä yksityiskohdista. Lähettämisen varjopuoliin kuuluu mm. se, että lähettävän siirto-ohjelmiston on huolehdittava ja vastattava kaikista siirtotyön aikaisista toimenpiteistä ml. ongelmatilanteiden havaitseminen, automaattiset uudelleenyritykset, ym. Tämä edellyttää lähetysohjelmistolta melkoisia ominaisuuksia. Miksi siis toimia FTP-asiakkaana? Entäs jos toimittaisiinkin vain FTP-palvelimena, ja annettaisiin vastapuolen FTP-asiakkaan hoitaa ikävät ja vaativat siirtovelvollisuudet, eli annettaisiin siis lähettämisen sijasta vastapuolen noutaa tiedostot? Voisiko siitä olla muuta haittaa, kuin että altistamme järjestelmämme FTP-palvelimen kautta tapahtuville tietoturvaloukkauksille? Mikäli oma järjestelmä toimii vain FTP-palvelimena, ja syntynyt tieto pitäisi kuitenkin valmistuttuaan saada nopeasti siirretyksi eteenpäin, FTP-asiakas joutuisi käytännössä tiuhaan tahtiin pollaamaan eli kiertokyselemään tiedoston olomassaoloa eli siirtokelpoisuutta. Ylleensä tällainen kyselyväli asetetaan, Manycom Software

3 linja- ja laiteresurssien säästämiseksi pienimmilläänkin muutamaksi minuutiksi, mutta tyypillisesti kyselyväli on 15 minuuttia tai tunti tms. Tiedonkulkuun siis syntyy helposti vähintäänkin minuuttien viive, ja systeemiin turhaa prosesointia ja resurssien kulutusta kiertokyselystä johtuen. Minuuttien viive on useimpia siirtotarpeita ajatellen pieni, mutta voi esim. tilaustapahtumien tai kuittausten siirtämisessä olla joskus jopa liian suuri nykyisissä hektisissä liiketoimintaympäristöissä. Tähän sisältyy toinenkin ajatusvirhe. Harvoin yritys on kuitenkaan siinä asemassa, että voisi edellyttää toisen osapuolen toimivan juuri tietyllä tavalla. Ennemmin tai myöhemmin tulee vastaan tilanne, jossa toinen osapuoli onkin se, joka sanelee, miten toimitaan. Edellä esitetyt seikat jo yksin tuottavat sellaiseen johtopäätöksen, että yrityksen ei yleensä tulisi edes pyrkiä siihen, että se pitäytyy toimimaan pelkästään FTP-asiakkaan tai FTP-palvelimen roolissa, vaan yrityksen tulee varautua siihen, että pystyy toimimaan molemmissa rooleissa. Tällöin, kun esim. tilaus syntyy omassa järjestelmässä, se voidaan tarvittaessa vaikka heti, nykyisten nopeiden verkkojen aikakaudella parissa sekunnissa, siirtää toisen järjestelmän FTP-palvelimelle, ja kun toisessa järjestelmässä syntyy tiedosto, esim. edellä mainitun tilauksen tilausvahvistus, se voi FTPasiakkaana toimien lähettää välittömästi tiedoston oman yrityksemme FTP-palvelimelle. Näin tieto saadaan kulkemaan tarvittaessa molempiin suuntiin välittömästi ilman turhia viiveitä. Edellä kuvattu tilauksen siirto - prosessointi tilausvahvistuksen siirto -ketju voidaan, kun se automatisoidaan, toteuttaa FTP:llä tyypillisesti muutamassa sekunnissa olettaen, että palvelimen päässä tilausvahvistuksen tuottava prosessi herätetään heti tilauksen saavuttua, ja että sen käsittely ei kestä enempää kuin, sanokaamme sekunnin. Tässä mielessä FTP-automaatiolla voidaan päästä lähes tosiaikaiseen tiedonsiirtoon ja prosessointiin. Heti perään on huomautettava, että tällaiseen tapahtumatason toimintaan kannattaisi, ainakin silloin, kun tapahtumamäärä ovat suuria, ehdottomasti käyttää tosiaikaiseen tiedonsiirtoon tarkoitettuja väliohjelmistoja, eikä FTP:tä. Tällöin tilauksen siirto prosessointi - tilausvahvistuksen siirto -ketjun (eli yhden tilaustapahtuman) läpimenoaika on tyypillisesti vai sekunnin kymmenesosia, tai jopa vain sadasosia, ja systeemin kokonaiskuormitus on, kun tiedonsiirto toteutetaan oikein, vain murto-osan siitä, mitä FTP:llä toteutettaessa. Lähetykseen liittyviä haasteita ja ongelmia Lähettämiseen toki liittyy omat haasteensa ja potentiaaliset ongelmansa. Aina tiedostoa, esim. tilauksia, ei haluta lähettää tai ei voida lähettää heti, jolloin tarvitaan ajastettu eli viivästetty lähetys ominaisuus. Toisaalta, verkkoyhteys voi olla poikki tai katkeaa kesken yhteyden, tai FTP-palvelin ei ole päällä, tai paikallis- tai etäkomennon ajo keskeytyy, tiedoston uudelleen nimeämien epäonnistuu kun tulosnimen mukainen tiedosto onkin olemassa, tms. Siirtotyö voi epäonnistua hyvin monista eri syistä. Tällöin siirtoohjelmiston automaattiset uusintayritykset ominaisuus on tarpeen ja hyödyllinen, kunhan vastaanottajan sovelluksissa on huomioitu tällainen mahdollisuus. Jos tiedostoja lähetetään useisiin järjestelmiin satoja päivittäin, ei mene välttämättä montaakaan päivää, kun jokin siirto epäonnistuu. Jos automattisia uusintayrityksiä ei voida kyseisessä tapauksessa sallia, tulisi systeemissä ainakin olla hyvät tilatieto-, loki- ja hälytysominaisuudet, jotta tilanne pystytään nopeasti selvittämään ja hoitamaan hallitusti manuaalisilla uudelleenyrityksillä. Koska siirtotiedoston tuottanutta sovellusajoa ei aina edes voida ajaa uudelleen, olisi sovelluksen voitava tallettaa siirtopyyntö eli kaikki siirtotyöhön liittyvä informaatio esim. siirto-ohjelmiston siirtohakemistoon, josta haluttu siirtopyyntö sitten tulisi voida valita ja ajaa uudelleen. Jos automaattinen uusinta-ajo sallitaan siirtotyölle, se joudutaan aloitetaan käytännössä aina alusta, koska yhteyden muodostamisen jälkeen ensimmäinen siirtotyön vaihe, sisäänkirjautuminen, on FTP:ssä pakollinen, ja se määrää FTP-asiakkaalle mm. tiedostojärjestelmän, oletushakemiston, tiedostojen oletusnimeämiskäytännön, jne. Sovellukset, erityisesti FTP-palvelimen päässä, olisikin siis suunniteltava ja toteutettava niin, että ne sallivat siirtotyön kaikkien toimintojen suorituksen, ml. tiedostojen lähetyksen, useampaankin kertaan. Sovellusten tulisi siis pystyvät mukautumaan erilaisiin poikkeustilanteisiin. Muutoin automaattista uudelleenajoa ei voida tietenkään sallia siirtotyölle. Ajan mittaan saattaa mikä tahansa siirtotyöhön liittyvä parametritieto - lähettäjätiedot, vastaanottajatiedot, ajoitus, lähetystapa tai paikallis- tai etäprosessit - muuttua. Esim. oman tai etäjärjestelmän IP-osoitteen - Manycom Software

4 ja dns-nimenkin - muuttuminen on varsin yleistä. Jos kaikki tiedot on rautalankakoodattu sovelluksiin, joudutaan sovelluksia tavan takaa muuttamaan ja kääntämään, mikä tuo jäykkyyttä systeemiin, eikä aina onnistu niin nopeasti kuin olisi tarve. Kuten jo aikaisemmin todettiin, ei kaikkia teknisiä yksityiskohtia pitäisi eikä tarvitsekaan määritellä, jos sovellus käyttää FTP-siirto-ohjelmistoa, joka mahdollistaa teknisten tietojen talletuksen ja ylläpidon ohjelmiston kokoonpanomäärityksissä sovelluksen ulkopuolella. Itse lähetys meni hyvin, mutta... Lähetykseen liittyy myös seuraavat paikallis- ja etäpään perushaasteet : Paikallispää: Tiedoston lähetys FTP:llä tapahtuu siten, että paikallisen lähdetiedoston sisältö kopioidaan FTPpalvelimelle tulostiedostoon. Koska tietueita ei siirretä vaan kopioidaan, lähdetiedosto sisältöineen säilyy ja on olemassa edelleen siirron jälkeenkin. Kuinka voidaan siis olla varmoja siitä, että samaa lähdetiedostoa ei lähetetä useampaan kertaan esim. uusintalähetyksen yhteydessä silloin, kun palvelimen päässä oleva sovellus ei pysty paljastaman useampaan kertaan lähetettyä aineistoa? Tämä voisi aiheuttaa esim. tilauksen käsittelemisen useampana tilauksena, tai laskujen lähettämisen asiakkaalle useampaan kertaan (minkä asiakas todennäköisesti kyllä huomaa, mutta josta ei hirveästi tykkää)! Silloin, kun paikallistiedostoa ei oletettavasti enää onnistuneen siirron jälkeen tarvita esim. mahdollista uusintalähetystä varten, se tulisi voida automattisella mutta luotettavalla tavalla tarvittaessa tuhota paikallisjärjestelmästä, tai mieluummin uudelleennimetä tai siirtää toiseen hakemistoon. Jälkimmäistä kahta tapaa puoltaa se, että ennemmin tai myöhemmin palvelimen päässä onnistuneen siiron jälkeen tupeksitaan ja tuhotaan tulostiedosto. Lähdetiedostosta on siis aina hyvä säilyttää kopio kaiken varalta kuukauden päivät. Tätä puoltaa myös se, että joskus huomataan vasta kolmen viikon jälkeen myyntireskontrasta, että laskutusaineisto ei ole mennyt perille. Sitäpaitsi, muutenkin voi jälkikäteen tulla tarvetta tarkistaa, mitä aineistoa oikeasti tuli lähetettyä linjalle. Etäpää: Normaalin PUT-toiminnolla tehdyn lähetyksen oletuksena on, että jos tulostiedosto on jo olemassa, uusi data korvaa vanhan. Kuinka voidaan siis varmistua siitä, että silloin kun siirretään olemassa olevaan tulostiedostoon, edellisen lähetyskerran data on jo käsitelty? Muutenhan voidaan mahdollisesti menettää dataa niin, että se huomataan vasta liian myöhään, jos silloinkaan. Tähän ongelmaan ei liene muuta pätevää ratkaisua, kuin se, että dataa ei koskaan siirretä olemassa olevaan tulostiedostoon, eikä FTP-asiakkaan toimesta tuhota (DEL-toiminnolla) olemassa olevia etätiedostoja. Tulostiedoston nimenä tulisikin aina käyttää yksikäsitteistä nimeä liittämällä nimeen esim. aikaleima tai sarjanumero, ja siirron jälkeen sitten uudelleennimetään tulostiedosto sovelluksen tuntemalle nimelle. Tämä menettely on sinänsä ristiriidassa sen OS/400- ja i5/os-manuaaleissakin annetun suosituksen kanssa, että pitäisi aina siirtää olemassa olevaan tulostiedostoon. Suositus perustunee mm. siihen sinänsä pätevään ajatteluun, että (oletettavasti) palvelimen päässä tiedetään paremmin, minkä nimisen tiedoston tulee olla, ja millaisen sen rakenteen tulee olla, jotta se kelpaa sovelluksille. Tätä problematiikkaa selvitetään lisää vielä seuraavassa kappaleessa. Huom: On syytä huomata, että tämän ongelman ratkaisuksi tarkoitettu SUNIQUE (SEND UNIQUE) toiminto soveltuu lähinnä vain manuaalisesti operoituihin siirtoihin. Tällöin, jos FTP-palvelin huomaa, että tulostiedosto on jo olemassa, se luo tiedostolle automaattisesti uuden yksikäsitteisen nimen tietyn kaavan mukaan, ja saa täten aikaiseksi sen, että FTP-asiakas ei enää välttämättä tiedä (ellei visuaalisesti näe), minkä niminen tulostiedostosta tuli. Näin ollen tiedostoa ei voi, tai se on hankala ainakin automaattisesti uudelleennimetä, eikä toisaalta etäpään sovelluskaan tunne suoraan tiedoston uutta nimeä. Lähetys olemassa olevaan tulostiedostoon (sovellustiedostoon) Manycom Software

5 FTP:n lähetys-toiminnolle tyypillistä on se, että jos tulostiedosto on olemassa, FTP-palvelimen tulee FTPmääritysten mukaisesti ensin putsata tiedoston sisältö kokonaisuudessaan (tuhoamatta tiedostoa tai muuttamatta sen rakennetta), ja sitten lisätä tulostiedostoon lähdetiedoston tietueita sitä mukaan, kun se ottaa niitä vastaan linjalta. FTP-määritykset ottavat vain hyvin puutteellisesti kantaa siihen, miten FTP-asiakkaan tai FTP-palvelimen tulee tarkkaan ottaen toimia eri poikkeustilanteissa, esim. kun kyseessä on merkkipohjainen siirto, ja kun esim. lähdetiedoston tietueen pituus on suurempi kuin tulostiedoston, tai kun siirtoyhtyes katkeaa kesken tiedoston siirron. FTP-palvelin voi katkaista siirron siinä vaiheessa, kun havaitsee liian pitkän tietueen, tai voi jatkaa siirtoa hävittämällä ylimääräisen datan tietueen lopusta ilmoittamatta tästä mitään, tai palauttamalla korkeintaan varoituksen. Jos taas tiedoston siirto katkeaa kesken, tulostiedostoon jää yleensä ne tietueet, jotka FTPpalvelin on sinne kerinnyt lisätä. FTP-palvelimet, ml. OS/400- ja i5os-palvelimet, eivät siis yleensä tuhoa eli peruuta jo siirrettyjä tietueita. Varsinkin jälkimmäinen tilanne (yhteyden katkeaminen) voi olla ongelmallinen, koska tulostiedostoa (esim. tilausrivejä) käsittelevä sovellus ei välttämättä huomaa lainkaan sitä, että tietueita puuttuu. Puuttuvien tietueiden metsästäminen ja tilanteen korjaaminen sitten, kun ongelma päivien tai viikkojen jälkeen ehkä huomataan, voi olla hankalaa. Edellä esitetyn lisäksi on otettava huomioon myös se, että FTP-palvelimen päässä oleva sovellus, jos se on ohjelmoitu käsittelemään suoraan tulostiedostoa, pääsee yleensä käsiksi tulostiedostoon kesken siirron, koska FTP-palvelin ei yleensä varaa tiedostoa poissulkevasti. Näin on asian laita myös OS/400- ja i5/os-ftp-palvelinten kanssa. Useamman kerran onkin käytännössä nähty tilanne, että kun siirto on tapahtunut suoraan tulostiedostoon, jonka sovellus tuntee, sovellus on lukenut ja prosessoinut tulostiedoston tietueita nopeammin, kuin FTP-palvelin on kerinnyt uusia tietueita lisätä. Näin on syntynyt tilanne, jossa sovellus on kohdannut tiedoston loppumerkin (EOF, end-of-file), vaikka tiedostoon on vielä tulossa lisää tietueita, joten taas ollaan tilanteessa, jossa sovellus kuvittelee käsitelleensä tiedoston kaikki tietueet. Edellä kuvatut kaksi eri tiedon eheysongelmatilannetta, joissa tulostiedostoa käsittelevä sovellus tulee prosessoineeksi vain osan tietueista, voi estää ja ne on syytä estää. Tapoja on useita, joista seuraavassa esitetään kaksi. Kuinka varmistaa se, että tiedosto siirtyy eheänä etäsovellukselle tapa 1 Varmin tapa lienee se seuraava: Tiedosto lähetetään ensin toisella yksikäsitteisellä tulostiedostonimellä, jota palvelimen sovellukset eivät tunne, ja kun siirto on todettu onnistuneeksi, uudelleennimetään tiedosto edelleen yksikäsitteiselle, sovelluksen tuntemalle nimelle FTP-asiakkaan toimesta. Jos halutaan olla varmoja, että ei menetetä aikaisempaa, vielä käsittelemätöntä aineistoa, siirretään data siis aina uuteen, ainutkertaisella nimellä luotavaan tiedostoon. Näin sovellus ei pääse käsiksi mahdollisesti kesken jääneeseen tulostiedostoon, eikä se pääse käsiksi tiedostoon kesken siirron. Kun siirto on päättynyt onnistuneesti, minkä FTP-asiakaspää voi ja sen tulee tarkistaa FTP-palvelimen palauttamasta paluukoodista, FTP-asiakas uudelleennimeää tulostiedoston FTP:n RENAME-toiminnolla sovelluksen tuntemalle nimelle. Tästä seuraa kuitenkin uusi potentiaalinen ongelma, joka liittyy tiedoston uudelleennimeämiseen sekin voi epäonnistua, ja epäonnistuukin, jos tulostiedosto on jo olemassa. Tämä voidaan ratkaista siten, että tulostiedosto tuhotaan FTP-asiakkaan toimesta aina ennen uudelleennimeämistä, mikä tosin voi johtaa siihen, että menetetään dataa, jos sovellukset eivät ole vielä ehtineet käsitellä dataa. Suositus onkin, aikaisemmin jo esitetyn mukaisesti, että ei käytetä tätä menettelyä, eli että FTP-asiakas ei tuhoa etäpään tiedostoja. Kuinka siis välttää RENAME-operaation epäonnistuminen? Käytetään RENAME-operaation tulostiedoston nimenä jälleen ainutkertaista, esim. sarjanumerolla varustettua nimeä. Kuinka sovellus sitten löytää tiedoston, jonka nimi ei ole määrätty, vaan vaihtelee? Sovellus voidaan ja se tulisi rakentaa niin, että se etsii ko. hakemistosta ko. geneerisellä nimellä olevia tiedostoja, ja nimeää ne sitten uudelleen lopulliselle haluamalleen nimelle prosessoitavaksi. Manycom Software

6 RENAME-operaatiosta voidaan vielä mainita, että se on sinänsä nopea, ja ainutkertaiselle tulosnimelle nimettäessä varma toimenpide, koska käyttöjärjestelmän tiedostonhallinta ei päästä mitään sovellusta käsiksi tulostiedostoon ennen toimenpiteen päättymistä. Kuinka varmistaa se, että tiedosto siirtyy eheänä etäsovellukselle tapa 2 Tässä esitettävä tapa ei takaa sitä, että vain eheät siirtotiedostot pääsevät käsittelyyn siirron katkamisen yhteydessä, mutta varmistaa sen, että sovellus ei pääse käsiksi tiedostoon ennen aikojaan silloin, kun FTP-palvelin vielä lisää siihen tietueita. Kun etäsovellus haluaa käsitellä siirron tulostiedostoa, se voi yrittää varata tulostiedoston aina poissulkevasti käyttöönsä- eli yksin itselleen. Jos tiedosto on FTP-palvelimen käytössä, sovellus voi yrittää hetken päästä uudelleen. Jos sovellus saa varattua tiedoston, mutta siinä ei ole yhtään tietuetta, sovelluksen tulee poistua. Muutoin, jos siinä on tietueita, sovellus käsittelee tiedoston tietueet, ja tyhjentää sen ennen kuin vapauttaa tiedoston. Nyt FTP-palvelin voi taas lisätä tietueita, mutta vain, kun sovellus ei ole varannut tiedostoa. Tämän menettelyn huonona puolena voidaan pitää myös sitä, että FTP-palvelin ei välttämättä pääse käsiksi FTP-asiakkaan nimeämään tulostiedostoon, mikä aiheuttaa siirtopyynnön hylkäämisen. Siirrot ja siirtotiedostojen käsittely onkin tässä menettelyssä syytä ajoitaa niin, että ne eivät tapahdu yhtä aikaa. Tällaisessa tapauksessa, esim. kun siirto tapahtuu vain kerran päivässä tiettyyn aikaan, ja sovellus prosessoi datan selkeästi myöhemmin, tämä voi olla varsin toimiva menettely. Lähetys uuteen tulostiedostoon FTP-määritysten mukaisesti, mikäli FTP-asiakkaan antamaa tulostiedostoa ei ole olemassa, FTP-palvelin luo tiedoston mutta millaisena ja miten siirretty data viedään siihen? Lähtökohtaisesti FTP-palvelimet vastaanottavat datan ensin väliaikaiseen tiedostoon. Näin tekevät myös OS/400- ja i5/os-ftp-palvelimet. Kun esim. lähetetään kirjastotiedostosysteemiin, nämä palvelimet vastaanottavat datan ensin QTEMP-kirjastoon luomaansa väliaikaistiedostoon. Jos kyseessä on merkkikoodattu tekstimuotoinen siirto, FTP-palvelin etsii tulevasta datasta pisimmän tietueen (rivin). Jos siirto onnistui, FTP-palvelin luo sitten pyydetyn tulostiedoston, jonka tietueen pituus on kiinteänmittainen ja pisimmän rivin pituinen, ja kopioi sitten väliaikaistiedoston tietueet tulostiedostoon. Binäärisiirtojen lopputuloksia eri tilanteissa on selvitetty mm. osan 1 kirjallisuusviitteissä. Jos FTP-siirron aikana tapahtuu virhe, tulostiedostoa ei synny, ja FTP-asiakas saa paluutietona virhekoodin ja -sanoman. Tiedoston eheys on siis tässä tapauksessa hyvin turvattu. Yleisesti ottaen voidaan sanoa, että dataa uuteen tiedostoon siirrettäessä lopputulos riippuu täysin käyttöjärjestelmästä, tietodostojärjestelmästä, tiedostojärjestelmän hallintaohjelmistosta, FTPpalvelinohjelmistosta, sekä tietenkin näiden versiotasoista. FTP:tä koskevat RFC-määritykset ottavat vain ylimalkaisesti kantaa siihen, miten tiedostojärjestelmän tulisi eri tilanteissa toimia. Mitään yhtenäistä käytäntöä olisikin käytännössä mahdoton saavuttaa. Seuraavassa numerossa jatketaan tiedostojen noutamiseen liittyvän problematiikalla sekä FTPpalvelimen toimintojen käsittelyllä. Manycom Software