Anzeigentransfer

SchalterStandardWerteBeschreibungAnmerkung

AnzeigenTransfer.Protokoll_Pfad

-PfadangabeVerzeichnis der Protokolldateien des Anzeigentransfers
AnzeigenTransfer.Batch_Pfad-PfadangabeVerzeichnis der Batchdateien für den Anzeigentransfer
AnzeigenTransfer.XmlVorgabePfad-PfadangabeVerzeichnis für die Vorgabedateien des Anzeigentransfers
AnzeigenTransfer.ExtAuftragImportVorgabeFile-FileangabeVorgabedatei für den Anzeigen-XML-Import (bpauftragimport)
AnzeigenTransfer.AuftragImport_XML_Pfad-PfadangabePollingverzeichnis für den BPAuftragimport, wo Anzeigen-XML-Dateien abgeholt werden
AnzeigenTransfer.BPAnzeigeVorgabeFile-FileangabeVorgabedatei für den Anstrich-XML-Export (bpanstrichexport)
AnzeigenTransfer.BPAnstrichExportPfad-PfadangabeVerzeichnis, wo Anstrich-XMLs vom BPAnstrichExport abgelegt werden
AnzeigenTransfer.EpsSourcePath-PfadangabeVerzeichnis, 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-PfadangabeVerzeichnis, wo Anzeigen-XMLs für die Redaktion abgelegt werden, wenn ein Motivupdate passiert ist
AnzeigenTransfer.ExtOrderUnknownRubricFailed00 = aus (default), 1 = einWenn 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 µmGibt die Toleranz zwischen den im Anzeigen-XML angegeben und im Motiv übermittelten Maße an.

AnzeigenTransfer.ExtMotifDisableColorCheck

00 = aus (default), 1 = einUnterdrueckt die Farbpruefung beim externen Motivimport
AnzeigenTransfer.TransferRepeatCount30

Anzahl
(default = 30)

Wiederholrate für die Transferversuche bei Fehlern beim Anzeigentransfer (BPAnzEpsPoller, MotifUpdater, Motivtransfer an Redaktion)
AnzeigenTransfer.TransferWaitTime1Sekunden
(default = 1)
Wartezeit in Sek. zw. den Anzeigentransfer-Wiederholversuchen

Anstrich-Export

Allgemein

Vgl. auch Knowledge-Base Blattplanung

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.

Durch einen Fehler in der View, sind momentan alle Anzeigen ohne Platzierung in der aktuellen DB und alle Füller für den Poller "unsichtbar". Das Zielsystem bekommt damit das Deplatzieren bereits angestrichener Anzeigen nicht zur Kenntnis.

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, 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 (Warnung) 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


ParameterBedeutung
-ustartet als Poller fuer "unique Anzeigen"
-pstartet als Poller fuer "P5" (benoetigt AdvBPInterface.dll)
-tstartet als Poller fuer Fremdsystem; // third-party system
-d=nnnn: Wartezeit zwischen DB-Pollingaktionen in Sekunden (default: 5s)
-vzeigt zusätzliche Informationen zur Laufzeit
-ignoreColorError

unterdrueckt Farbfehler zw. Auftrag und Produktion

-?diese Hilfe

Status in der Anstrich-Tabelle

Status (Bitmaske)Bedeutung
0unplatziert (ehemals platziert, nie belichtet)
1platziert
2belichtet
4geändert (nach Belichtung)

Ein Verschieben der Anzeige auf einer bereits belichteten Seite führt nicht zu Status-Bit 4, nur das Verschieben auf eine andere Seite. Ebenso wird es gesetzt, wenn die Anzeige deplatziert oder erneut platziert wird und in der Anstrich-Tabelle bereits mit Status-Bit 2 enthalten ist. Belichten beseitigt das Status-Bit 4 wieder.

Testatfeld der Anzeigen

Testat (Bitmaske)Bedeutung

VAL_TESTAT_BP_ANZEIGE_NOT_DEFINED

0
VAL_TESTAT_BP_ANZEIGE_ANGELEGT 1
VAL_TESTAT_BP_ANZEIGE_VORPLANUNG 2
VAL_TESTAT_BP_ANZEIGE_PLATZHALTER 4
VAL_TESTAT_BP_ANZEIGE_ABGESPALTEN 8
VAL_TESTAT_BP_ANZEIGE_AKTUALISIERT 16
VAL_TESTAT_BP_ANZEIGE_BELICHTET 32
VAL_TESTAT_BP_ANZEIGE_NICHT_PLANBAR 64
ehemals: VAL_TESTAT_BP_ANZEIGE_STORNIERT 128
VAL_TESTAT_BP_ANZEIGE_EPS_EXPORTIERT 256
VAL_TESTAT_BP_ANZEIGE_EXPORTIERT 512
VAL_TESTAT_BP_ANZEIGE_HAT_CLIPPFAD 1024
VAL_TESTAT_BP_ANZEIGE_EXPORT_CLIPPFAD 2048
VAL_TESTAT_BP_POSITIONIERUNG_DECORATOR_CHANGED 4096

In der aktuellen DB platzierte Anzeigen mit bestimmten Testaten werden für die View explizit ausgefiltert: 2 (vor Korrektur, advantage Platzhalter), 4, 64 (Motiv gelöscht). Für unplatzierte Anzeigen wirkt dieser Filter nicht.