SAP IDoc Konnektor

Dieser Artikel beschreibt, wie Sie den IDoc-Konnektor in Syncler einrichten, XML-IDocs einlesen und IDocs an Zielsysteme senden – wahlweise lokal, per (S)FTP/FTPS oder per HTTP.

Funktionsumfang

• Einlesen von IDoc-XML-Dateien
  • Quellen: lokales Verzeichnis, FTP/SFTP/FTPS, HTTP (per Syncler-API Übergabe)
  • Automatische Schemaerkennung aus XSD/XML: fachliche Objekte (z. B. E1KNA1M, E1KNVKM) + Kontrolldatensatz EDI_DC40
  • Auftrennung verschachtelter Strukturen in Objektgruppen (inkl. „multitext“ für Langtexte wie TDLINE)
• Bereitstellen der gelesenen IDocs an Syncs (Datensatz-Speicher)
• Versenden von IDoc-XML
  • Ziele: lokales Verzeichnis, FTP/SFTP/FTPS, HTTP-Endpoint
  • Automatisches Erzeugen des IDoc-Headers und des Kontrolldatensatzes EDI_DC40
• Schemaaufbau
  • Aus XSD/Schema-XML von lokalem/remote Verzeichnis oder direkt aus SchemaXml-Feld
  • Option SchemaMaxOccurs: begrenzt Link-Typen (1..N) zur lesbaren UI-Darstellung
• Validierung/Diagnose
  • Verbindungsprüfung (FTP/SFTP/FTPS), Quellpfade, Logging

Voraussetzungen

• Zugriff auf IDoc-Schema-Dateien (*.xml/XSD) – lokal oder per (S)FTP
• Für (S)FTP/FTPS: Host, Port, Benutzer, Kennwort; ggf. Schlüsseltausch (SFTP)
• Für HTTP-Sendung: Ziel-URL + Zugangsdaten (Basic Auth)
• Schreib-/Leserechte auf den eingerichteten Verzeichnissen

Einrichtung

1. System anlegen

• Typ: IDOC
• Name & Beschreibung vergeben

2. Schemaquelle wählen
   (mindestens eine Option – Reihenfolge der Auswertung wie unten)

• SchemaDirectory (lokal, On-Prem)
• RemoteSchemaDirectory (per FTP/SFTP/FTPS)
• SchemaXml (Schema direkt einfügen)
• Falls keine der drei Quellen gesetzt ist, wird das Standardschema aus Schema/IDOC der Anwendung geladen. (DEBMAS, MATMAS, ORDERS)

3. Verzeichnis- und Transportparameter

• Eingang (lesen)
  • Lokal: SourceDirectory (optional BackupDirectory/LogDirectory)
  • Remote: FtpServer, FtpPort, FtpUsername, FtpPassword, SFtp (SFTP an/aus), FtpS (FTPS an/aus), RemoteSourceDirectory, optional RemoteBackupDirectory
• Ausgang (schreiben)
  • Lokal: TargetDirectory
  • Remote: RemoteTargetDirectory
  • HTTP (senden): SendUrl, SenderUsername, SenderPassword
• HTTP (empfangen via Service)
  • IDoc-XML kann über den Syncler-API als XmlString-Parameter angeliefert werden (keine Pfadkonfiguration nötig).

4. IDoc-Kontrollwerte (optional, empfohlen)

• SNDPOR, SNDPRT, SNDPRN, RCVPRN, RCVPOR, RCVPRT
  → Werden beim Senden im EDI_DC40 genutzt, sofern nicht explizit im Datensatz gesetzt.

5. Speichern & Validieren

• „Validieren“ führt Verbindungsprüfung für (S)FTP/FTPS sowie Pfadchecks aus.

Wie der Konnektor Schemas erkennt

Der Konnektor baut zur Laufzeit Objekte und Objektgruppen aus XSD/XML:

• Hauptobjekt: aus erstem Segment unterhalb IDOC ermittelt (z. B. E1KNA1M, E1MARAM, E1EDK01)
• Kontrolldatensatz EDI_DC40 wird als Objektgruppe (Link: default) dem Hauptobjekt angefügt
• Unterobjekte werden anhand von minOccurs/maxOccurs zu Linktypen:
  • - (einmalig), 1, 2, … (maxOccurs), list (bei sehr vielen/0 = „beliebig“)
  • Langtexte mit TDLINE → Linktyp multitext (Zeilen werden automatisch zusammengeführt)
• Schlüsselspalten (z. B. KUNNR, MATNR, BELNR) werden als ID-Spalten markiert
• Als Updated-Zeit wird aus EDI_DC40 CREDAT + CRETIM abgeleitet (Spalte IDoc_Createddate)

Tipp: Mit SchemaMaxOccurs begrenzen Sie übermäßig tiefe Wiederholungen für eine kompakte UI.

Daten lesen (Eingang)

Quellen

• HTTP (XmlString): Übergabe an den Konnektor (über Syncler-API). Optionales Logging in LogDirectory.
• (S)FTP/FTPS: Abruf aus RemoteSourceDirectory (Filter: *.xml)
• Lokal: Abruf aus SourceDirectory (Filter: *.xml)

Ablauf beim Lesen

1. Datei/XML wird geladen und gegen das Hauptschema gematcht (über Header/Root‐Name).
2. Das IDoc wird in Syncler-Objekte überführt (inkl. EDI_DC40 & Unterobjekten).
3. Pro passendem Sync (gleicher SourceObject-Name) wird der Datensatz im Datensatz-Speicher gespeichert.
4. Erfolg:
   • Remote: Datei wird nach RemoteBackupDirectory kopiert (falls gesetzt) und auf der Quelle gelöscht
   • Lokal: Datei wird in BackupDirectory kopiert (falls gesetzt) und gelöscht

Ansprechpartner (E1KNVKM) werden nur erzeugt, wenn das übergeordnete Kundenobjekt (E1KNA1M) im System über einen Sync verarbeitet wird (Schutz gegen „verwaiste“ Unterobjekte).

Daten schreiben (Ausgang)

Sie können IDoc-Objekte aus Syncs heraus als XML erzeugen und senden:

Zielkanäle

• HTTP (SendUrl + Basic Auth): POST mit application/xml
  • Erwartete positive Antwort (z. B.) „IDoc-XML-inbound ok“
• SFTP/FTP/FTPS (RemoteTargetDirectory): Upload mit Dateinamen <Objekt>_yyyy-MM-dd_HHmmss.xml
• Lokal (TargetDirectory): Dateiablage mit gleichem Namensschema

Kontrolldatensatz EDI_DC40

• Wird aus dem Set-Objekt übernommen oder automatisch ergänzt:
  DIRECT=2, TABNAM=EDI_DC40, CIMTYP="", SNDPOR/SNDPRT/SNDPRN/RCVPRN/RCVPOR/RCVPRT (aus Verbindung),
  CREDAT/CRETIM (Now), SERIAL/DOCNUM (Zeitstempel)
• Parent/Child‐Szenario: bei E1KNVKM wird der Parent (E1KNA1M) als Segment mitgegeben; die Debitorennummer (KUNNR) wird aus ParentId gesetzt.

Arbeiten in Syncs

• Alle Datensätze lesen / Initial-Sync
  • Liest verfügbare Dateien/XML ein und liefert anschließend Datensatz-Speicher des Syncs in Batches (1000) an Ihre Verarbeitung.
• Änderungen lesen
  • Wie oben, optional mit LAST_SYNC_DATE (Zeitfilter für Datensatz-Speicher-Abfrage).
• Sonstige
  • Ziehen gezielt Datensatz-SPeicher-Einträge (per GUID oder Record-ID) erneut in die Verarbeitung.
• Sperren/Locks werden nicht verwendet.

Häufige Fragen (FAQ)

Kann ich IDocs ohne Schema verarbeiten?
Ein Standardschema wird versucht – für stabile Verarbeitung immer ein passendes Schema bereitstellen (lokal/remote/SchemaXml).

Was passiert mit Dateien nach erfolgreichem Einlesen?
Sie werden (falls konfiguriert) nach Backup kopiert und anschließend gelöscht.

Wie werden Ansprechpartner (E1KNVKM) verarbeitet?
Nur gemeinsam mit einem passenden Kunden-Sync (E1KNA1M). Andernfalls werden sie übersprungen.

Wie steuere ich Mehrfach-Segmente (1..n)?
Über das geladene Schema: Link-Typen werden entsprechend maxOccurs gesetzt (1,2,…,list).