Task der das macht, in eine eigene executable auslagern und die mittels cronjobs steuern.
Danke auch dir für das Feedback! Was mir daran nicht gefällt, ist wieder ein zusätzlicher administrativer Aufwand (klar, der ist erstmals überschaubar, aber dennoch blöd, wenn man es dann z.B. mal vergisst) und eine zusätzliche Abhängigkeit zu einem zweiten Programm für eine Aufgabe, die eigentlich intern laufen könnte. Aber drüber nachgedacht hatte ich da auch schon.
Interessant, wie unterschiedlich man solche Aufgaben betrachten kann.
Anhand der Aufgabenstellung habe ich jetzt nichts entdecken können, dass die Aufgabe so "schwierig" oder besonders macht (fachlich), dass sie von Deinem Server erledigt werden muss, im Gegenteil.
Hole 1x pro Tag eine Datei von einem (anderen) Server.
Ich sehe auch keine "zusätzliche Abhängigkeit". Denn der Vorschlag von Phoenix ist mit Bordmitteln(Betriebssystem) problemlos zu erledigen, vollkommen transparent und mit wenigen Handgriffen auf neue Anforderungen adaptierbar. Diese Systeme funktionieren seit Jahrzehnten so zuverlässig, erprobt und transparent, wie man es selbst nur schwerlich hinbekommt.
Und der Administrator ist (meistens) leichter verfügbar, als der Entwickler, was m.E. eine deutlich geringere Abhängigkeit (des Systems) ist. Auch wenn Delphi "alles kann", es gibt zunächst nie einen Grund, Dinge für die man fachlich kein Spezialprogramm braucht, mit einem solchen zu erledigen. (Der einzige Grund wäre, gezielt Abhängigkeiten schaffen zu wollen).
Ist also Morgen die Anforderung plötzlich 2 Dateien zu holen statt eine, oder 2x am Tag eine oder oder, dann muss der Entwickler ran. Ein separates Skript mit
OS Scheduler wäre in ein paar Minuten vom Admin umgestellt, ebenso geänderte Quellserver, gesperrte, verlorene Accounts, nicht mehr verfügbare oder geänderte Transferprotokolle, firewall Änderungen .. <nach Belieben erweiterbar>
Zuletzt ist ein Scheduled Task (oder Cronjob) mit einer so unauffälligen Aufgabe einer Dateiübertragung 1/Tag via
OS Werkzeug ein vollkommen transparenter und angemessen prominenter Vorgang auch aus Sicherheits - und Monitoring Perspektive.
Zu allerletzt hat man so ein Plus an Flexibilität, das nicht nur den Betreiber freuen wird. Die Strategie, die sich darin zeigt wird mehr und mehr auch in großen Unternehmen eingesetzt.
Jetzt aber wirklich als letztes
Ein Server ist ein Server und er soll immer laufen. Muss ein Server wegen der geänderten Anforderung bspw. nicht 1x pro Tag sondern 2x (oder was auch immer) erstens umprogrammiert und zweitens, gestoppt, ausgetauscht und neu gestartet werden, so ist das in mehrfacher Hinsicht ein Service Ausfall, der in keinem guten Verhältnis zum Nutzen steht. (Es ist schon ein paar Jahre her, aber ich habe irgendwann mal in irgendwelchen Windows Release Notes gelesen, dass mehr 90 Gründe für einen Reboot beseitigt wurden. Es klang trotz trockener Sprache etwas stolz - ihr versteht was ich meine)
Mag sein, dass das hier alles nicht zutrifft, weil sich das System in einer komfortablen Nische befindet, aber es hat mich gejuckt, es mal so aufzuführen. War ja ne Konzeptfrage.