...
| Schalter | Standard | Werte | Beschreibung | Anmerkung |
|---|---|---|---|---|
AnzeigenTransfer.Protokoll_Pfad | - | Pfadangabe | Verzeichnis der Protokolldateien des Anzeigentransfers | |
| AnzeigenTransfer.Batch_Pfad | - | Pfadangabe | Verzeichnis der Batchdateien für den Anzeigentransfer | |
| AnzeigenTransfer.XmlVorgabePfad | - | Pfadangabe | Verzeichnis für die Vorgabedateien des Anzeigentransfers | |
| AnzeigenTransfer.ExtAuftragImportVorgabeFile | - | Fileangabe | Vorgabedatei für den Anzeigen-XML-Import (bpauftragimport) | |
| AnzeigenTransfer.AuftragImport_XML_Pfad | - | Pfadangabe | Pollingverzeichnis für den BPAuftragimport, wo Anzeigen-XML-Dateien abgeholt werden | |
| AnzeigenTransfer.BPAnzeigeVorgabeFile | - | Fileangabe | Vorgabedatei für den Anstrich-XML-Export (bpanstrichexport) | |
| AnzeigenTransfer.BPAnstrichExportPfad | - | Pfadangabe | Verzeichnis, wo Anstrich-XMLs vom BPAnstrichExport abgelegt werden | |
| AnzeigenTransfer.EpsSourcePath | - | Pfadangabe | Verzeichnis, wo der BPAuftragimport auch EPS/PDF-Motive erwartet, es muss zwingend eine XML-Datei bei jedem Motivimport vorliegen | (veraltet - MotivUpdater-Modul im Winpoller2 benutzen) |
| AnzeigenTransfer.XmlExportUpdatePath | - | Pfadangabe | Verzeichnis, wo Anzeigen-XMLs für die Redaktion abgelegt werden, wenn ein Motivupdate passiert ist | |
| AnzeigenTransfer.ExtOrderUnknownRubricFailed | 0 | 0 = aus (default), 1 = ein | Wenn der Config-Schalter aktiviert ist, wird der Rubrikenbaum aus der im Import-XML angegeben Rubrik aufgebaut. Die Rubrik muss in der BP existieren! | |
AnzeigenTransfer.ExtMotifTolerance | - | Integerangabe in µm | Gibt die Toleranz zwischen den im Anzeigen-XML angegeben und im Motiv übermittelten Maße an. | |
AnzeigenTransfer.ExtMotifDisableColorCheck | 0 | 0 = aus (default), 1 = ein | Unterdrueckt die Farbpruefung beim externen Motivimport | |
| AnzeigenTransfer.TransferRepeatCount | 30 | Anzahl | Wiederholrate für die Transferversuche bei Fehlern beim Anzeigentransfer (BPAnzEpsPoller, MotifUpdater, Motivtransfer an Redaktion) | |
| AnzeigenTransfer.TransferWaitTime | 1 | Sekunden (default = 1) | Wartezeit in Sek. zw. den Anzeigentransfer-Wiederholversuchen |
Anstrich-Export
Allgemein
Vgl. auch /wiki/spaces/CON/pages/221087000
Der "Anzeigenlieferant" soll eine Rückmeldung über die Produktion seiner Anzeigen bekommen. Dazu werden beim Speichern nach verschiedenen Aktionen (platzieren, belichten, deplatzieren) Anstrichdaten in eine entsprechende DB-Tabelle (blattp.Anstrichtransfer) geschrieben bzw. dort aktualisiert (Pollstatus wieder auf 0). Die Daten können durch den Anstrich-Poller auf verschiedene Art und Weise an das Anzeigensystem übergeben werden (DB, XML). Bei erfolgreicher Übergabe wechselt der Pollstatus auf 2. Da nicht bei jeder Aktion die benötigten Daten korrekt zur Verfügung stehen um in die DB geschrieben zu werden, greift der Poller statt auf die Anstrich-Tabelle auf eine entsprechende View (blattp.VANSTRICHTRANSFER) zu - in der View wird über die Platzierung der Anzeige bis auf die Schemagruppe ge"Joint" (vgl.
DNT OP #6576828: Anstrichdaten unvollständig). Die View ist sehr ressourcenintensiv und beschäftigt den Datenbankserver stark - obwohl im Ergebnis meist festgestellt wird, dass nichts zu tun ist.
...
Ein weiterer Fehler führt dazu, dass deplatzierte Anzeigen mit falschem Status in der Anstrich-Tabelle stehen (3 - wenn sie ohne Termin für die konkrete Ausgabe trotzdem dort platziert und belichtet und erst danach wieder deplatziert wurden).
Mit CONS-53 werden nun auch Füller vom BPAnstrichExport erfasst. Als Testbemerkung (s. CONS-69) wird folgendes festgehalten: Wenn der Füller auf einer DMS platziert ist (z. B. 7 Ausgaben), wird beim Belichten der DMS nur ein Anstrichtransfer-Datensatz geschrieben und entsprechend die Verwendung in FUELLERATTRIB.REALERSCHEINANZ um einen Zähler hochgesetzt. Für eine in gleicher Weise platzierte Anzeige wird für jede beteiligte Ausgabe ein Transfer-Datensatz geschrieben, hier also 7 Stück. Prinzipiell ist das nicht korrekt, es müssten auch für DMS-platzierte Füller mehrere Anstrichtransfer-Datensätze geschrieben werden (entsprechend einer Zählung pro beteiligter Seite). Da die Füllverwendung aber bislang gar nicht geschrieben wurde und auch von keinem Verlag ausgewertet wird, belassen wird soll die Funktionsweise erst einmal so belassen werden.
Die Intention zur Behandlung der Füller im VL-System scheint nicht ganz klar - der Poller prüft die Datensätze gegen den aktuellen Zähler und die zugeordneten Ausgaben, um zu entscheiden, ob er etwas schreibt oder nicht. Ggf. zählt er den Zähler hoch und schreibt PTermin- und KTermin-Datensätze (die in der Auftragsbearbeitung nicht sichtbar sind und offenbar nur bei EPLAT für den Export vorgesehen waren - vgl. OP unten). Eigentlich sollte es m.E. (Rene Bretschneider) so funktionieren: Die Blattplanung schreibt bei der Belichtung Füller-Datensätze zu den tatsächlichen Platzierungen (egal ob die Ausgaben "gültig" waren oder nicht und auch mit Beachtung von Durchläufern), der Poller schreibt bedingungslos 
die Termin-Datensätze und Inkrementiert den Zähler. In der Blattplanung werden dann nur Füller angeboten, deren Zähler das Maximum noch nicht erreicht hat oder deren Maximum durch "-1" nicht zu beachten ist.
Korrespondierende OPs zu diesem Thema:
EPL OP #6302817: placemente data for filler - Anstrichtransfer für Füller (BP -> ANZ)
PLT OP #6705116: DEV: Füller - Max Erscheinungen auf 999 begrenzt
Kommandozeilen-Parameter beim Anstrich-Poller BPAnstrichExport.exe
...