Tridion 2011 SP1 HR1 - Senden von Inhalten an SmartTarget / Fredhopper

7

Wir richten SmartTarget / Fredhopper in unserer Tridion 2011 SP1 HR1-Umgebung ein und haben einen Haken - daher die Frage!

  • CM ist korrekt konfiguriert und wir können den <SmartTarget addToFredhopper="true"/>Eintrag im Paket sehen, der an den Deployer gesendet wurde.
  • Die Protokollierung wird auf DEBUG-Ebene für den Deployer konfiguriert, und im Smarttarget-Protokoll wird ein Eintrag angezeigt:

2013-01-23 10: 46: 08,148 INFO FredhopperDeployerModule - Starten Sie die Bereitstellung des Transportpakets 'D: \ Tridion \ incoming \ Zip \ tcm_0-22268-66560.Content \' für Fredhopper.

  • Leider wird in Fredhopper nichts angezeigt - die Veröffentlichungswarteschlange bleibt in der Bereitstellungsphase fest, bis sie schließlich mit einem "Fehler beim Überschreiten der Abfrage" fehlschlägt.

Fredhopper ist auf einem anderen Server installiert, daher verwenden wir den SmartTarget-Webdienst (nicht J2EE & Tomcat) und haben dies in der Datei smarttarget_conf.xml konfiguriert:

Location>http://server:8080/SmartTargetDeploymentWebService/SmartTargetDeploymentWebService?wsdl</Location>

Eine schnelle Überprüfung dieser URL in einem Browser antwortet erfolgreich mit der WSDL. Wir haben den Dienst auch auf DEBUG-Ebene konfiguriert, aber es wird nie eine Protokolldatei geschrieben, was darauf hindeutet, dass der Bereitsteller niemals erfolgreich etwas an ihn sendet.

Damit:

  • Fredhopper installiert - Überprüfen
  • SmartTarget-Webdienst (Tomcat) - Überprüfen
  • Veröffentlichen - Überprüfen
  • Deployer - Richtig konfiguriert, aber anscheinend nicht in der Lage, den Webdienst zu erreichen?

Kann jemand Ratschläge zu den nächsten zu überprüfenden Schritten geben oder etwas Offensichtliches, das wir verpasst haben?

AKTUALISIEREN_

Zusätzliche Informationen aus dem Kernprotokoll - hier scheint onSuccess nicht ausgeführt werden zu können, was etwas verdächtig aussieht!

2013-01-23 14: 53: 12,094 INFO FredhopperDeployerModule - Starten Sie die Bereitstellung des Transportpakets 'D: \ Tridion \ incoming \ Zip \ tcm_0-22272-66560.Content \' für Fredhopper.

2013-01-23 14: 53: 12,109 DEBUG RMICacheChannelConnector - Broadcasting-Ereignis für Schlüssel beendet: 67: 17789: 17791

2013-01-23 14: 53: 12,250 ERROR DeployPipelineExecutor - onSuccess-Ereignis kann nicht in Phase ausgeführt werden: Bereitstellungs-Commit-Phase für Transaktion: tcm: 0-22272-66560

2013-01-23 14: 53: 12,250 DEBUG DeployPipelineExecutor - Überprüfen, ob die Transaktion abgeschlossen ist: tcm: 0-22272-66560 ist falsch

2013-01-23 14: 53: 12,250 INFO DeployPipelineExecutor - Ausführung der Bereitstellungspipeline für: tcm: 0-22272-66560 in 17722 ms abgeschlossen.

2013-01-23 14: 53: 12,250 INFO TransactionManager - Bereinigen des Bereitstellungspakets für die Transaktion: tcm: 0-22272-66560 und Typ: CONTENT

2013-01-23 14: 53: 12,265 INFO TransactionManager - Abgeschlossene Bearbeitung des Bereitstellungspakets: tcm: 0-22272-66560 mit Typ: CONTENT

2013-01-23 14: 53: 12,265 DEBUG QueueLocationHandler - Entfernen aus der Warteschlange Bereitstellungspaket: tcm: 0-22272-66560 mit Typ: CONTENT.

2013-01-23 14: 53: 12,265 DEBUG QueueLocationHandler - Entfernen der exklusiven Sperre für das Bereitstellungspaket: tcm: 0-22272-66560 mit dem Typ: CONTENT. 2013-01-23 14: 53: 12,265 DEBUG QueueLocationHandler - Die exklusive Sperre für das Bereitstellungspaket wurde entfernt: tcm: 0-22272-66560 mit dem Typ: CONTENT.

tridion Neil
quelle
Befindet sich nach der Zeile 'Transportbereitstellung starten' etwas im Protokoll? Vielleicht eine Erfolgs- oder Misserfolgsmeldung?
Quirijn
Ist das wirklich die einzige Zeile in der Protokolldatei für SmartTarget? Wenn Sie die URL in einem Browser ausprobiert haben, haben Sie dies auch von diesem Server aus getan? (Ich denke, es könnte ein Firewall-Problem sein.) Sind Sie sicher, dass Ihre Konfigurationsänderungen übernommen wurden? (Sie müssen zum Beispiel den Deployer neu starten)
Peter Kjaer
Wir haben es jetzt ein paar Mal versucht und der einzige Eintrag im Protokoll ist der Eintrag "Startbereitstellung starten". Kein Erfolg oder Misserfolg - was im Zusammenhang mit einem Misserfolg in der Veröffentlichungswarteschlange sinnvoll ist - scheint nie zum Webdienst zu gelangen oder nie eine Antwort zu erhalten.
Neil
Als wir die URL zum Webdienst getestet haben, haben wir sie vom selben Server wie der Deployer ausgeführt. Wir haben über den Browser und über WCFStorm (ein WCF-Testtool) bestätigt, dass der SmartTarget-Dienst vorhanden ist und reagiert. Wir haben sogar die "Deploy" -Methode mit Testdaten ausgeführt und festgestellt, dass sie auf dem Fredhopper-Server protokolliert werden. Das Problem scheint sich auf das FredhopperDeployerModule zu konzentrieren. Wir haben die Datei smarttarget_conf.xml aktualisiert, um einen dateibasierten Speicherort anstelle des Webdienstes ohne Unterschied zu verwenden. Erhalten Sie immer noch den Protokolleintrag "Bereitstellung bereitstellen", aber keine Datei geschrieben?
Neil
Ist dieses Problem behoben? Ich habe das gleiche Problem. Die SDL-Unterstützung hat festgestellt, dass das Problem bei der Erstellung des Webservice-Clients liegt, der für die Kommunikation mit dem SmartTarget-Bereitstellungs-Webservice verwendet wird. Unser Deployer läuft auf WAS6.1 und der Deployer SmartTarget läuft auf separaten Servern.
Gopi Jasti

Antworten:

4

Ist die SmartTarget Publisher-Erweiterung korrekt installiert?

In Ihrem Transportpaket sollte sich in der Datei component_presentations.xml ein Abschnitt mit zusätzlichen Informationen befinden. Diese Informationen werden von der Publisher-Erweiterung ausgefüllt.

Gertjan Assies
quelle
Danke Gertjan. Ich war zu dem gleichen Schluss gekommen - tatsächlich bestand das Problem darin, dass die Erweiterung nicht auf unserem separaten Publisher-Server installiert war !! Grrrr !! Ich musste die SmartTarget-Veröffentlichungs-DLL aus dem GAC auf dem CM-Server kopieren und manuell zum GAC auf dem Publisher-Server hinzufügen. Tridion.ContentManager.config und Boom-Content in Fredhopper wurden aktualisiert.
Neil
7

Ich würde den Speicherort für die XML-Dateien in der Eigenschaftendatei des Bereitstellungswebdiensts überprüfen. Stellen Sie dann sicher, dass es an diesen Speicherort schreiben kann (verwenden Sie ein Überwachungstool, um dies zu überprüfen).

Es soll Fehler korrekt behandeln (und protokollieren), aber vielleicht läuft dort etwas schief.

Was passiert, wenn Sie die Verwendung des Bereitstellungswebdiensts zum Speichern der XML-Dateien an einem Speicherort auf demselben Server ändern? Erstellt es die Datei und wird die Veröffentlichung fortgesetzt? Dies würde einen Hinweis darauf geben, wo das Problem liegt ...

Peter Kjaer
quelle
Wir haben dies versucht, also haben wir die smarttarget_conf.xml geändert, die der Deployer verwendet, um einen Dateispeicherort zu verwenden. Keine Änderung - der gleiche Protokolleintrag wird geschrieben, die Datei jedoch nicht, und letztendlich schlägt die Veröffentlichung in der Festschreibungsphase fehl. Hat jemand eine Protokolldatei für die Smart Target Deployer-Erweiterung zum Vergleichen? Ich würde mich interessieren, was nach "Start Deployment" passieren soll.
Neil
Seltsam. Ich würde erwarten , einige in diesem Fall Art von Fehlern. Haben Sie alle Dateien durchgesehen? Nur für den Fall, dass der Fehler in der Kernprotokolldatei protokolliert wird oder so ...
Peter Kjaer
Oh, und normalerweise erhalten Sie anschließend einen Eintrag mit der Aufschrift "Die Bereitstellung des Transportpakets 'D: \ Tridion \ incoming \ Zip \ tcm_0-22268-66560.Content \' für Fredhopper ist abgeschlossen." (und einige weitere Zeilen dazwischen, je nach Szenario)
Peter Kjaer
Einige zusätzliche Informationen aus dem Kernprotokoll Peter - etwas über das Ereignis onSuccess? Ich bin mir nicht sicher, ob es nur bestätigt, dass etwas nicht stimmt, und nicht der Grund dafür!
Neil
Das SmartTarget-Zeug passiert in diesem Fall, also ja - es heißt nur, dass es schief gelaufen ist.
Peter Kjaer