Neu JTL → Shopify Connector: MappingTablesException / „Endpoint id is empty“ – betroffene Artikel aus Logs per SQL finden

[Puma7]

Hallo zusammen,

wir hatten beim JTL-Wawi → Shopify-Abgleich wiederholt das Problem, dass einzelne Artikel den kompletten Abgleich blockieren.

Die Fehlermeldung sah ungefähr so aus:

Controller = Product | Action = push
There is a problem with the linking - Id's (Endpoint id is empty)
The problem was caused by "Jtl\Connector\Shopify\Connector\Database\ProductTable"

MappingTablesException Code 90

Auffällig war bei uns:

Wenn man den betroffenen Artikel für den Shopify-Shop deaktiviert, läuft der Abgleich zunächst weiter. Aktiviert man denselben Artikel später wieder, kommt der Fehler erneut.

Das spricht aus meiner Sicht dafür, dass nicht der Artikel selbst das eigentliche Problem ist, sondern ein defektes Mapping im Shopify-Connector, also eine Verknüpfung zwischen JTL-Wawi-Artikel und Shopify-Produkt/Variante, bei der die Endpoint-ID leer oder beschädigt ist.

Da bei uns mehrere Artikel betroffen waren, habe ich mir eine SQL-Abfrage gebaut, um historisch aus den JTL-Connector-Logs herauszufinden, welche Artikel bereits mit diesem Fehler aufgefallen sind.

Wichtig:

Die Abfrage ist nur lesend. Sie macht kein UPDATE, DELETE, INSERT oder sonstige Datenänderungen.

Trotzdem sollte man sie natürlich mit Bedacht auf produktiven Systemen ausführen, da Logtabellen je nach Größe viele Daten enthalten können.

Vorher bitte anpassen:

DECLARE @kShop INT = 26;
DECLARE @Seit DATETIME = DATEADD(DAY, -60, GETDATE());

• 
  []@kShop muss auf die eigene Shopify-Shop-ID angepasst werden.
  []@Seit legt fest, wie weit historisch gesucht wird.
  []-60 bedeutet: letzte 60 Tage.
  []Für 360 Tage entsprechend -360 verwenden.

Die Abfrage sucht in Sync.tConnectorLogeintrag nach typischen Fragmenten des Fehlers:

• 
  []Endpoint id is empty
  []MappingTablesException
• ProductTable

Danach versucht sie aus dem Logtext folgende Informationen herauszuziehen:

• 
  []JTL-Wawi PK / kArtikel
  []SKU
  []Artikelname
  []Vaterartikel, falls es sich um einen Kindartikel handelt
  []Vater-SKU
  []Zeitpunkt des letzten Fehlers
• Anzahl der gefundenen Fehler

Hier die Abfrage:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET LOCK_TIMEOUT 5000;

DECLARE @kShop INT = 26;
DECLARE @Seit DATETIME = DATEADD(DAY, -60, GETDATE());

WITH LogTexte AS
(
SELECT
l.kConnectorLogeintrag,
l.kSyncLogsitzung,
l.dZeitpunkt,
l.kShop,
CONVERT(NVARCHAR(MAX), ISNULL(l.cMeldung, ''))
+ CHAR(10) +
CONVERT(NVARCHAR(MAX), ISNULL(l.cExtendedMessage, '')) AS LogText
FROM Sync.tConnectorLogeintrag l
WHERE l.kShop = @kShop
AND l.dZeitpunkt >= @Seit
AND (
l.cMeldung LIKE '%Endpoint id is empty%'
OR l.cExtendedMessage LIKE '%Endpoint id is empty%'
OR l.cMeldung LIKE '%MappingTablesException%'
OR l.cExtendedMessage LIKE '%MappingTablesException%'
OR l.cMeldung LIKE '%ProductTable%'
OR l.cExtendedMessage LIKE '%ProductTable%'
)
),
Positionen AS
(
SELECT
lt.*,
p1.PosPK,
p2.PosSKU,
p3.PosName,
p4.PosProblem,
p4.PosLinebreak
FROM LogTexte lt
OUTER APPLY
(
SELECT
CHARINDEX('JTL-Wawi PK = ', lt.LogText) AS PosPK
) p1
OUTER APPLY
(
SELECT
CASE
WHEN p1.PosPK > 0
THEN CHARINDEX(' | SKU = ', lt.LogText, p1.PosPK)
ELSE 0
END AS PosSKU
) p2
OUTER APPLY
(
SELECT
CASE
WHEN p2.PosSKU > 0
THEN CHARINDEX(' | Name = ', lt.LogText, p2.PosSKU)
ELSE 0
END AS PosName
) p3
OUTER APPLY
(
SELECT
CASE
WHEN p3.PosName > 0
THEN CHARINDEX(' | There is a problem', lt.LogText, p3.PosName)
ELSE 0
END AS PosProblem,
CASE
WHEN p3.PosName > 0
THEN CHARINDEX(CHAR(10), lt.LogText, p3.PosName)
ELSE 0
END AS PosLinebreak
) p4
),
Extrakt AS
(
SELECT
kConnectorLogeintrag,
kSyncLogsitzung,
dZeitpunkt,
kShop,

    TRY_CONVERT
    (
        INT,
        CASE
            WHEN PosPK > 0
             AND PosSKU > PosPK + LEN('JTL-Wawi PK = ')
            THEN SUBSTRING
            (
                LogText,
                PosPK + LEN('JTL-Wawi PK = '),
                PosSKU - (PosPK + LEN('JTL-Wawi PK = '))
            )
            ELSE NULL
        END
    ) AS kArtikel,

    LTRIM(RTRIM(
        CASE
            WHEN PosSKU > 0
             AND PosName > PosSKU + LEN(' | SKU = ')
            THEN SUBSTRING
            (
                LogText,
                PosSKU + LEN(' | SKU = '),
                PosName - (PosSKU + LEN(' | SKU = '))
            )
            ELSE NULL
        END
    )) AS SKU,

    LTRIM(RTRIM(
        CASE
            WHEN PosName > 0
            THEN SUBSTRING
            (
                LogText,
                PosName + LEN(' | Name = '),
                CASE
                    WHEN PosProblem > PosName + LEN(' | Name = ')
                    THEN PosProblem - (PosName + LEN(' | Name = '))

                    WHEN PosLinebreak > PosName + LEN(' | Name = ')
                    THEN PosLinebreak - (PosName + LEN(' | Name = '))

                    ELSE 500
                END
            )
            ELSE NULL
        END
    )) AS Artikelname,

    LogText
FROM Positionen

)
SELECT
e.kShop,
e.kArtikel,
MAX(e.SKU) AS SKU,
MAX(e.Artikelname) AS Artikelname,
a.kVaterArtikel,
CASE
WHEN a.kVaterArtikel > 0 THEN a.kVaterArtikel
ELSE a.kArtikel
END AS kVaterOderEinzelartikel,
v.cArtNr AS VaterSKU,
MAX(e.dZeitpunkt) AS LetzterFehler,
COUNT(*) AS FehlerAnzahl
FROM Extrakt e
LEFT JOIN dbo.tArtikel a
ON a.kArtikel = e.kArtikel
LEFT JOIN dbo.tArtikel v
ON v.kArtikel = CASE
WHEN a.kVaterArtikel > 0 THEN a.kVaterArtikel
ELSE a.kArtikel
END
WHERE e.kArtikel IS NOT NULL
GROUP BY
e.kShop,
e.kArtikel,
a.kVaterArtikel,
CASE
WHEN a.kVaterArtikel > 0 THEN a.kVaterArtikel
ELSE a.kArtikel
END,
v.cArtNr
ORDER BY
LetzterFehler DESC,
MAX(e.SKU);

Was macht die Abfrage genau?

• 
  []Sie liest die Connector-Logeinträge aus Sync.tConnectorLogeintrag.
  []Sie filtert auf den angegebenen Shop über @kShop.
  []Sie berücksichtigt nur Logeinträge ab dem Datum @Seit.
  []Sie sucht nach typischen Fehlerbestandteilen wie Endpoint id is empty, MappingTablesException und ProductTable.
  []Sie verbindet cMeldung und cExtendedMessage zu einem auswertbaren Logtext.
  []Sie extrahiert aus dem Logtext die JTL-Wawi-PK, SKU und den Artikelnamen.
  []Sie verknüpft den Treffer mit dbo.tArtikel, um bei Kindartikeln den Vaterartikel zu ermitteln.
  []Sie gruppiert die Treffer nach Artikel und zeigt den letzten Fehlerzeitpunkt sowie die Fehleranzahl.

Das Ergebnis zeigt dann zum Beispiel:

• 
  []kArtikel des betroffenen Artikels
  []SKU
  []Artikelname
  []kVaterArtikel
  []Vater-SKU
  []letzter Fehlerzeitpunkt
• Anzahl der gefundenen Fehler

Wichtig zur Einordnung:

Diese Abfrage findet nur Artikel, bei denen der Fehler bereits im Log protokolliert wurde. Sie erkennt also nicht automatisch alle potenziell defekten Mappings im Voraus. Wenn Logs gelöscht oder bereinigt wurden, können ältere Fälle natürlich fehlen.

Bei Variantenartikeln sollte man aus meiner Sicht nicht nur das einzelne Kind betrachten, sondern immer den Vaterartikel inklusive aller Kinder. In der Fehlermeldung wird ja ebenfalls sinngemäß empfohlen, bei Varianten Master und alle Kinder neu zu senden.

Meine bisherige Einschätzung:

Wenn ein Artikel nach Deaktivierung/Reaktivierung wieder mit Endpoint id is empty blockiert, scheint das reine Aktivieren/Deaktivieren in JTL-Wawi das Problem nicht zu beheben.

Es sieht dann eher nach einem defekten Product-/Variant-Mapping im Shopify-Connector aus.

In so einem Fall würde ich die betroffenen Artikel mit obiger Abfrage sammeln und damit gezielt ein Ticket bei JTL eröffnen, mit der Bitte, die ProductTable-/Variant-Mappings mit leerer Endpoint-ID zu prüfen bzw. zurückzusetzen.

Vielleicht hilft die Abfrage anderen, die plötzlich immer wieder einzelne Shopify-Artikel im Abgleich hängen haben und erst einmal herausfinden möchten, welche Artikel historisch betroffen waren.

----

@Laura O https://forum.jtl-software.de/threa...pify-connector-21-05-2025.235671/post-1280621

 

[Puma7]

Simple Lösung, 5 Artikel hatten anstatt regulärer UST verminderte im Dropdown. Wahrscheinlich weil ein Mitarbeiter mal über dem Dropdown Feld war und mit dem scroll Rad dien wert aus versehen geändert hatte.

 

[dapole]

Simple Lösung, 5 Artikel hatten anstatt regulärer UST verminderte im Dropdown. Wahrscheinlich weil ein Mitarbeiter mal über dem Dropdown Feld war und mit dem scroll Rad dien wert aus versehen geändert hatte.

-> Das ist 'Der JTL Klassiker'


-> Ob Steuersatz / Warengruppe
.... einmal nicht 'hingesehen' -> ZACK: schleicht sich ein 'unerkannter' Fehler ins system