Admin: Hinweis auf den frueheren Umweg ueber die Preisaenderung entfernt

2026-09-01T13:48:43Z

Hinweis auf den frueheren Umweg ueber die Preisaenderung entfernt

← Nächstältere Version		Version vom 1. September 2026, 13:48 Uhr
Zeile 1:		Zeile 1:
	Manchmal soll ein Artikel erneut vollständig zum Portal hochgeladen werden, ohne dass ihn jemand im PIM anfasst - zum Beispiel am Ende eines nächtlichen SQL-Jobs, der Felder direkt in der Datenbank berechnet und schreibt. Dafür gibt es die Prozedur <code>spHTKOmniSeller_TriggerUpload</code>. Sie meldet einen oder mehrere Artikel für den nächsten Upload an; der Upload-Dienst holt sie beim nächsten Durchlauf ab und überträgt sie komplett.		Manchmal soll ein Artikel erneut vollständig zum Portal hochgeladen werden, ohne dass ihn jemand im PIM anfasst - zum Beispiel am Ende eines nächtlichen SQL-Jobs, der Felder direkt in der Datenbank berechnet und schreibt. Dafür gibt es die Prozedur <code>spHTKOmniSeller_TriggerUpload</code>. Sie meldet einen oder mehrere Artikel für den nächsten Upload an; der Upload-Dienst holt sie beim nächsten Durchlauf ab und überträgt sie komplett.

	~~Früher wurde dafür oft~~ der ~~Umweg über eine Preisänderung genutzt (~~Artikel ~~in einer Dummy-Preisliste um einen Cent verändern). Das funktioniert nicht mehr: seit Upload und Preisübertragung getrennte Wege gehen~~, ~~löst eine reine Preisänderung nur noch einen Preis-Job aus.~~ Felder~~, die nur im vollständigen Artikel-Upload mitreisen - etwa~~ Lieferdatum, Texte oder Attribute ~~- kommen darüber nicht mehr im Portal an~~.		Übertragen wird dabei der vollständige Artikel, also auch Felder wie Lieferdatum, Texte oder Attribute.

	== Voraussetzungen ==		== Voraussetzungen ==

Admin: Artikel angelegt: Upload per SQL anstossen mit spHTKOmniSeller_TriggerUpload

2026-09-01T13:46:46Z

Artikel angelegt: Upload per SQL anstossen mit spHTKOmniSeller_TriggerUpload

← Nächstältere Version		Version vom 1. September 2026, 13:46 Uhr
Zeile 1:		Zeile 1:
	-		Manchmal soll ein Artikel erneut vollständig zum Portal hochgeladen werden, ohne dass ihn jemand im PIM anfasst - zum Beispiel am Ende eines nächtlichen SQL-Jobs, der Felder direkt in der Datenbank berechnet und schreibt. Dafür gibt es die Prozedur <code>spHTKOmniSeller_TriggerUpload</code>. Sie meldet einen oder mehrere Artikel für den nächsten Upload an; der Upload-Dienst holt sie beim nächsten Durchlauf ab und überträgt sie komplett.

			Früher wurde dafür oft der Umweg über eine Preisänderung genutzt (Artikel in einer Dummy-Preisliste um einen Cent verändern). Das funktioniert nicht mehr: seit Upload und Preisübertragung getrennte Wege gehen, löst eine reine Preisänderung nur noch einen Preis-Job aus. Felder, die nur im vollständigen Artikel-Upload mitreisen - etwa Lieferdatum, Texte oder Attribute - kommen darüber nicht mehr im Portal an.

			== Voraussetzungen ==

			Die Prozedur wird mit dem Datenbank-Update automatisch angelegt. Zusätzlich muss der Upload-Dienst so eingestellt sein, dass er die angemeldeten Artikel auch abholt. In der <code>OmniSellerUpload.ini</code> im Ordner des Upload-Dienstes:

			<pre>[ChangeTracking]
			Enabled=1
			TrackOHTKSyncData=1</pre>

			Danach den Upload-Dienst einmal neu starten.

			<code>Enabled=1</code> ist der Hauptschalter, ohne ihn läuft die Änderungsüberwachung gar nicht. <code>TrackOHTKSyncData=1</code> ist die empfohlene Einstellung für diesen Weg. Ist stattdessen <code>TrackKHKArtikel=1</code> gesetzt, funktioniert die Prozedur ebenfalls, sie richtet sich automatisch nach dem, was eingeschaltet ist. Ist keine der beiden Optionen aktiv, meldet die Prozedur das im Klartext und es wird nichts hochgeladen.

			== Aufruf ==

			Alle Aufrufe brauchen den Mandanten. Ausgeführt werden sie in der Datenbank, in der auch die Artikel liegen.

			=== Ein Artikel ===

			<pre>EXEC dbo.spHTKOmniSeller_TriggerUpload @Mandant = 1, @Artikel = '1100292';</pre>

			=== Mehrere Artikel ===

			Mehrere Artikelnummern können in einem Aufruf übergeben werden. Als Trennzeichen sind Komma, Semikolon, Tabulator und Zeilenumbruch erlaubt, Leerzeichen um die Artikelnummern herum werden entfernt.

			<pre>EXEC dbo.spHTKOmniSeller_TriggerUpload @Mandant = 1, @Artikel = '1100292, 1100293; 1100294';</pre>

			=== Liste aus einer Abfrage ===

			Für längere Listen oder für den Einsatz in einem SQL-Job kann die Auswahl aus einer Abfrage kommen. Dazu vor dem Aufruf eine temporäre Tabelle mit dem festen Namen <code>#HTKOmniTriggerUpload</code> und der Spalte <code>Item</code> anlegen und füllen. Der Parameter <code>@Artikel</code> entfällt dann.

			<pre>CREATE TABLE #HTKOmniTriggerUpload (Item nvarchar(255) NOT NULL);

			INSERT INTO #HTKOmniTriggerUpload (Item)
			SELECT a.Artikelnummer
			FROM dbo.KHKArtikel a
			WHERE a.Mandant = 1
			AND a.USER_OmniDeliveryPossibleDate IS NOT NULL;

			EXEC dbo.spHTKOmniSeller_TriggerUpload @Mandant = 1;

			DROP TABLE #HTKOmniTriggerUpload;</pre>

			Beide Wege lassen sich auch kombinieren: was in der temporären Tabelle steht und was in <code>@Artikel</code> übergeben wird, ergibt zusammen die Liste.

			== Parameter ==

			* <code>@Mandant</code> - Pflichtangabe, der Mandant der Artikel.
			* <code>@Artikel</code> - eine Artikelnummer oder eine Liste. Kann entfallen, wenn die temporäre Tabelle verwendet wird.
			* <code>@Variation</code> - optional. Ohne Angabe werden alle Ausprägungen des Artikels angestoßen, was der Normalfall ist. Mit Angabe einer AusprägungID beschränkt sich der Aufruf auf diese eine Ausprägung.
			* <code>@Info</code> - optional, Standard 1. Die Prozedur gibt dann eine kurze Ergebnisübersicht und gegebenenfalls Hinweise aus. In einem SQL-Job, der keine Ausgabe erwartet, kann <code>@Info = 0</code> gesetzt werden.

			== Einsatz in einem SQL-Job ==

			Der typische Fall: ein Job berechnet nachts Werte und schreibt sie in die Artikeltabelle. Damit die neuen Werte auch im Portal ankommen, wird die Prozedur am Ende des Jobs mit den betroffenen Artikeln aufgerufen.

			Wichtig ist dabei, nur die Artikel anzustoßen, bei denen sich tatsächlich etwas geändert hat. Schreibt der Job jede Nacht stumpf alle Artikel, werden sonst auch jede Nacht alle Artikel hochgeladen. In der Regel genügt dafür eine Bedingung im UPDATE des Jobs, die den alten mit dem neuen Wert vergleicht.

			== Kontrolle ==

			Die Prozedur startet keinen Upload sofort, sondern meldet die Artikel an. Der Upload-Dienst prüft in kurzen Abständen (Standard fünf Sekunden) auf neue Anmeldungen und arbeitet sie ab. Ob etwas angekommen ist, zeigt die Warteschlange:

			<pre>SELECT TOP 50 * FROM HTKOmniUploadQueue WITH (NOLOCK)
			ORDER BY InsertDate DESC;</pre>

			Ist die Tabelle direkt nach dem Aufruf leer, hat der Dienst die Einträge bereits übernommen. Bleiben Einträge dauerhaft liegen, läuft der Upload-Dienst nicht oder die Einstellungen in der <code>OmniSellerUpload.ini</code> passen nicht.

			== Hinweise ==

			* Angemeldet wird der Artikel, entschieden wird trotzdem nach den üblichen Regeln: Artikel, die einem Portal nicht zugeordnet oder dort nicht aktiv sind, werden nicht übertragen.
			* Artikelnummern, die es im angegebenen Mandanten nicht gibt, laufen ins Leere.
			* Große Listen erzeugen entsprechend viele vollständige Uploads. Bei mehreren tausend Artikeln sollte der Aufruf in eine Zeit gelegt werden, in der die Portale ohnehin ruhig sind.

Admin: Die Seite wurde neu angelegt: „-“

2026-09-01T13:41:40Z

Die Seite wurde neu angelegt: „-“

Neue Seite

OmniSeller:Upload Trigger im SQL - Versionsgeschichte

Admin: Hinweis auf den frueheren Umweg ueber die Preisaenderung entfernt

Admin: Artikel angelegt: Upload per SQL anstossen mit spHTKOmniSeller_TriggerUpload

Admin: Die Seite wurde neu angelegt: „-“