TiC Narrow Casting Pull structuur uitleg en settings Let op! Deze settings zijn voor ervaren beheerders en/of System Integrators van TiC Narrow Casting. Aangezien dit een functionele wijziging is van het reeds geïmplementeerde softwarepakket raden wij aan eerst goed na te gaan of deze wijzigingen voor u van toepassing zijn om de structuur van TiC te veranderen van de huidige Push structuur naar de Pull structuur. Voor ondersteuning (telefonisch, remote support of ondersteuning op lokatie) rekenen wij een uurtarief of per 15 minuten supportkosten door via uw dealer. Voor meer informatie bel TiC Narrow Casting op +31 (0) 78-6811420
(Alleen bestemd voor Systeembeheerders ) Algemeen Vanaf TNC versie 1.7 is het mogelijk om zowel via push (vanuit de manager naar de client, bestaande methode) als via pull (vanuit de client geïnitieerd, nieuwe methode) de clients bij te werken. Dit document geeft inzicht in de aanpassingen die gedaan zijn in TNC om de pull strategie te ondersteunen. Verschillende typen clients Voorheen bestond er één type client in TNC, de normale client. In de nieuwe versie zijn daar twee typen bijgekomen. Vanaf de nieuwe versie zijn er de volgende soorten clients: Normale client Een normale client is een client zoals die voorheen altijd werkte. Elke normale client staat voor een fysieke client die via TNC gebruikt kan worden. -
Kanaal Een kanaal is bedoeld om content en tickerregels op te plannen, ten behoeven van de clients die via de pull strategie bijgewerkt worden. Een kanaal staat niet voor een fysieke client.
-
Administratieve clients Een administratieve client is een client die fysiek bestaat, maar via de pull strategie bijgewerkt wordt. Op een administratieve client kan niet gepland worden, maar deze is bedoeld om de client te kunnen configureren (rs-232 apparatuur, clientprofielen, nummerprofielen, etc)
Werking van het bijwerken via de pull strategie Het idee van de pull strategie is dat de client zelf periodiek gaat kijken of er nieuwe content, instellingen of software beschikbaar is en deze indien nodig toepast. Om dit te bereiken is er een centrale plaats nodig die altijd te benaderen is. Dit is een FTP server. Als er vanuit de manager ‘bijwerken’ gekozen wordt voor iets wat via de pull strategie werkt, het niet naar de clients gestuurd, maar op de FTP server geplaatst. De clients maken periodiek verbinding met de FTP server om daar te bekijken of er iets bijgewerkt moet worden.
Aanpassingen in de TNC Manager instellingen In de instellingen van de TNC Manager is een nieuwe tabblad beschikbaar ‘Pull strategie’. Hierin kan aangegeven worden hoe de centrale FTP server benaderd moet worden. Aanpassingen in het clientprofiel In het cliëntprofiel zijn de volgende aanpassingen gedaan: Configureren van de pull strategie In het tabblad ‘Pull strategie’ in het clientprofiel kan ingevuld worden hoe de client de FTP server moet benaderen. -
Gepland bijwerken Het was al mogelijk om acties te plannen (herstarten en content opschonen). Daar is een actie bijgekomen, ‘updaten via pull strategie’. Verder was het eerst alleen mogelijk om een actie één keer per week, of één keer per dag te laten draaien. Nu is het ook mogelijk om een actie om een bepaald aantal minuten te laten draaien.
Installatie van een pull strategie client Een pull strategie client moet op de bekende manier de basis installatie krijgen, zoals dat ook met normale clients gebeurd. Vervolgens moet er in de TNC Manager het volgende gedaan worden: Ga naar optie ‘Clients & groepen’ Maak een administratieve client aan, i.p.v. een normale client. En configureer de client in de TNC Manager zoals dat met een normale client ook gedaan moet worden. Zorg ervoor dat de pull strategie correct geconfigureerd is in het clientprofiel. Ga naar tabblad ‘Installeren & updaten clients’ Kies links bovenin ‘Modus: Push naar administratieve clients’ Installeer de laatst beschikbare software versie Ga naar tabblad ‘Groepen & Clients’ Ga naar de nieuwe administratieve client en klik met de rechtermuisknop op de client en kies ‘Client profiel bijwerken (push naar administratieve client)’. De client is nu gereed om te werken via de pull strategie. Bijwerk procedure via de pull strategie Volgorde van bijwerken via de pull strategie Het bijwerken door de client wordt in de volgende volgorde gedaan: 1. Bijwerken van het clientprofiel indien er een nieuwe beschikbaar is 2. Nagaan of er nieuwe cliëntsoftware geïnstalleerd moet worden en eventueel installeren 3. Bijwerken van contentitems indien er een nieuwe beschikbaar zijn 4. Bijwerken van de ticker indien er nieuwe vulling beschikbaar is.
Let op: Als er in het clientprofiel aangegeven is dat de pull strategie gebruikt moet worden, maar er geen actie(s) gepland zijn om de update uit te voeren, zal de client automatisch elk uur gaan bijwerken via de pull strategie. Clientprofiel controle Voor de clientprofielen die via de pull strategie opgehaald worden, wordt een extra controle gedaan. In het nieuwe clientprofiel staan namelijk mogelijk nieuwe FTP gegevens waar de client in het vervolg naar toe moet gaan om bij te werken. Daarom zal de client eerst controleren of de FTP gegevens wel correct zijn (er wordt getest of die FTP server te bereiken is), als dat niet het geval is zal het hele clientprofiel genegeerd worden. Als het nieuwe clientprofiel niet geaccepteerd wordt, zal de client elke minuut opnieuw proberen bij te werken om een correct clientprofiel binnen te halen. Als het nieuwe clientprofiel niet geaccepteerd wordt zal er bij stap 1 van het bijwerken (zie hierboven) gestopt worden.
Logging Van de update via de pull strategie worden door de clients logbestanden op de FTP server geplaatst. Via de TNC Manager in het scherm ‘Clients & groepen’, tabblad ‘Client log inzicht’ kunnen deze bestanden van de FTP server opgehaald worden en in de TNC Manager opgeslagen worden. Als dit enige tijd niet gedaan wordt, zullen de TNC Clients er zelf voor zorgen dat oude logbestanden van de FTP Server afgehaald worden. Locking Zowel de TNC Manager als de TNC Client maken gebruik van dezelfde mappen op de FTP server. Om er voor te zorgen dat de manager en de client niet tegelijk elkaars bestanden bewerken wordt er gebruik gemaakt van en locking-mechanisme. In de locking directory op de FTP server (zie ook ‘opbouw van FTP mappen’) wordt er een bestand aangemaakt waarmee bijvoorbeeld aangegeven wordt dat een manager bezig is met het bijwerken van client gegevens. In het lock bestand staat ook hoe lang de lock nog geldig is. Zodra de manager klaar is, zal hij het bestand weer verwijderen. Als de client zichzelf gaat bijwerken op het moment dat de manager ook bezig is, zal de client moeten wachten totdat de manager klaar is. Uiteraard geldt dit andersom ook. Belangrijk is om de clients niet te vaak bij te laten werken. Stel dat bij alle clients ingesteld is dat ze elke 5 minuten moeten bijwerken en dat er 100 clients zijn. Dat betekent dus dat er door de clients zo vaak bijgewerkt wordt dat de manager een behoorlijke kans loopt heel lang op zijn lock te moeten wachten. Als de manager of client vastloopt tijdens het bijwerken zal hij zijn lock zelf niet weggooien. Daarom verloopt elke lock na een bepaalde tijd. Deze tijd is opgeslagen in het lock bestand. Tijd afhankelijkheid Voor zowel de clients als de manager is het heel belangrijk dat de tijd op de pc’s correct loopt. Stel dat de manager zijn content/planning update, dan worden de nieuwe bestanden geplaatst en een bestand waarin staat wanneer dit geplaatst is. In dat bestand staat de datum/tijd van de manager, van het moment dat er bijgewerkt werd. De client gaat vervolgens bijwerken en vergelijkt de laatste tijd waarop de client bijgewerkt heeft, met het bestand wat de manager geplaatst heeft. Op basis daarvan gaat de client wel of niet bijwerken. Melding van software versie van de client Elke keer dat de client bijwerkt via de pull strategie plaatst deze een bestand op de FTP server waarin staat welke clientversie de client geïnstalleerd heeft. Op die manier kan in de manager weergegeven worden welke clientversie de administratieve clients hebben. Op het moment dat de client van bijvoorbeeld versie 1.6 naar versie 1.7 geupdate moet worden, gebeurd er het volgende: 1. Vanuit de manager installeert iemand de nieuwe versie (de clientsoftware wordt op de FTP server geplaatst) 2. De client gaat zichzelf updaten en meldt zijn oude versie (1.6) 3. De client ziet dat hij een nieuwe versie moet installeren en doet dat. Uit deze stappen blijkt dat de client pas bij de volgende keer updaten meldt dat hij versie 1.7 geïnstalleerd heeft staan.
