Hi,
Nein, das war auch bei der Impressed-Lösung so nicht umgesetzt. Warum? Weil so ein Preflight dauernd kann, weil bspw. in Switch gerade noch 1.000 Jobs vor dem konkreten Prüfjob kommen, etc.
Die Impressed-Lösung hat die Daten entgegengenommen und mit Metadaten versehen in Switch geworfen. Dort wurde der Rest mit Switch-Bordmitteln abgefeiert und am Ende der User per eMail (ebenfalls Switch-Bordmittel) informiert, daß die Daten geprüft wurden, was das Ergebnis ist und unter welchem Link das/die Prüfergebnisse einsehbar waren (bzw. kann man aus Switch heraus auch Prüfberichte als Attachments an eMails anhängen lassen)
Mit WebShare ist ein Upload der zu prüfenden Daten möglich. Da die User sich am WebShare-Server authentifizieren müssen und dabei auch ein Set an Stammdaten abgerufen wird, ist die Übergabe dieser Daten an Switch ebenfalls möglich -- wenngleich nicht mit Bordmitteln, da muß man ein klein wenig skripten (lassen). D.h. aus WebShare heraus kommt man ganz simpel Richtung Switch, die Metadaten (Profil und Kontaktdaten des Users) würden dabei von einem Webshare-Skript als XML-"Sidecar"-Datei der bzw. den zu prüfenden XML-Dateien mitgegeben.
Ab da wäre das dann alles Switch-Bordmittel, d.h. die weitere Verarbeitung als auch Benachrichtigung des Users, wenn der Preflight fertig ist, funktionieren solo aus Switch heraus. Die geprüfte Datei kann im Erfolgsfall dann bereits in weitere Workflows geroutet werden, im Fehler- oder Warnungsfall zurückgehalten werden und die Prüfreports dem Anwender zur Verfügung gestellt werden (bspw. indem sie einfach in den Webshare-Sharepoint kopiert werden oder aber als Attachment an die Benachrichtigungs-Mail getackert werden -- auch in Switch parametrisierbar bzgl. Größte der Attachments)
Man erwirbt bei Helios nur die Preflight-Komponente. Soweit ich weiß gibt es aber ein vergünstigtes Upgrade auf die Vollversion des pdfToolbox Server (bzw. der CLI-Version, denn die Server-Version mit GUI gibt es ja nur für MacOS X und Windows -- und Helios bedient ja alle Unix-Plattformen mit einer Version)
Es kommt -- wie immer -- drauf an. Wenn die Helios-Server-Plattform bspw. MacOS X ist, man bei Callas die Toolbox hat "aufsperren" lassen (die Version, die Helios mitliefert, ist zwar auf Prüffunktionalität beschränkt. Aber es reicht ein anderer Lizenz-Code und man hat quasi die Vollversion an Bord) und PowerSwitch auf dem selben Rechner einsetzt, dann könnte man für die Toolbox nun auch die normalen Switch-Konfiguratoren einsetzen.
So ein Setup würde ich mir aber dreimal durch den Kopf gehen lassen, speziell da auch dabei ein paar Fallstricke lauern (bspw. dürfte Switch keinesfalls lokal auf die Helios-Volumes zugreifen sondern über einen loopback-AFP-Mount und das wiederum geht nur, wenn man Helios dazu bringt, AFP unter einem anderen als dem Standard-Port anzubieten). Zumal ist sowas auch unter Performance-Gesichtspunkten sehr genau zu prüfen, ob man sich das antun will.
Setzt man auf den unixoiden Helios-Plattformen die pdfToolbox ein und will diese "per GUI" nutzen (bspw. aus Switch heraus) und Switch-Server und Helios-Server laufen auf unterschiedlichen Servern, dann wird's kompliziert. Es ist möglich aber nur mit Zusatzprodukten (bspw. unserem k-switch, das eine Brücke zwischen Helios und PowerSwitch schlägt,
und ein wenig Skripting, um eine flexible Ansteuerung der Toolbox hinzubekommen.
Da bist Du nicht allein
Nein, neben den im Thread schon genannten Varianten würde bei der Variante, die pdfToolbox auf dem Helios-Server laufen zu lassen und durch einen separaten PowerSwitch-Server ansteuern zu lassen, initial noch Skripting hinzukommen, um eine flexible Ansteuerung der pdfToolbox hinzubekommen. D.h. einmalig Programmieraufwand, der dann alle Eventualitäten abdeckt. Der Rest ist "Herumklicken in Switch" und Befüllen der Flows (bspw. per WebShare, um Externe anzubinden).
Aber: Für sowas braucht es natürlich einerseits irgendein Bindeglied zwischen PowerSwitch und Helios (bspw. k-switch). Und andererseits ist dieses "Herumklicken in Switch" etwas verharmlosend. Denn gerade, wenn man Switch effizient nutzen will, stellt man schnell fest, daß auch dort wieder Skripting zum Einsatz kommt (bspw. weil man an Grenzen stößt und die Übergabe von Parametern an externe Tools, wenn kein nativer Konfigurator vorhanden ist, nur noch über Skriptausdrücke sauber abzuwickeln ist. D.h. dann kommt man um ein wenig (Java-)Skript-Code in Switch nicht herum.
Läßt sich vielleicht in einem kurzen Telefonat klären.
Gruss,
Thomas