EPO Consulting Wiki - Ecosio EDI Connector


Inhaltsverzeichnis

Funktionsbeschreibung EPO Connector for ecosio EDI

Mit der Lösung "EPO Connector for ecosio EDI" können SAP IDOCs SAP Outbound an die ecosio.com Plattform versendet werden und SAP Inbound entweder per "push" von der ecosio Plattform gesendet werden oder per "fetch" abgeholt werden.

Technisch basiert die Lösung auf der Implementierung von REST Services in JSON. Diese Services sind mit dem EPO Connector realisiert (ausgeliefert als SAP Installation, Mdt. 000, Transaktion SAINT/SPAM) Die Funktionen zur Integration in SAP IDOCs werden in Workbench und Customizing Transportaufträgen ausgeliefert.

Üblicherweise werden IDOCs für den Nachrichtenversand angewendet.

push

Die ecosio Plattform stößt eine Verarbeitung in SAP an, sobald eine eingehende Nachricht von einem angebundenen Partner vorliegt. Dazu muß die ecosio Plattform eine direkte (eingehende) Verbindung zum SAP System erhalten. Die eingehende Verbindung zum SAP System muss sicherheitstechnisch mittels Firewalls, Reverse Proxies oder ähnlichem entsprechend abgesichert werden.

fetch

Der SAP-Server kontaktiert (per Job) die ecosio Plattform und liest ev. vorhandene Nachrichten ein.

Altes Verhalten (bis Version 2.8.1):

Pro Abfrage werden maximal 30 Nachrichten übertragen. Falls mehr Nachrichten vorliegen, muß die Abfrage wiederholt werden.

Neues Verhalten (ab Version 2.8.2):

Es wird die Liste der verfügbaren Nachrichten abgeholt (max. 30). Falls mehr Nachrichten vorliegen, muß die Abfrage wiederholt werden. Anschließend werden die Nachrichten einzeln abgeholt und verarbeitet.


Den Vorteil der höheren Netzwerksicherheit erkauft man sich mit der Verzögerung bis zur nächsten Abfrage.

Der Report /EPO1/EXC_ECOSIO_FETCH bietet eine entsprechende Implementierung und ist Teil der Auslieferung. Der SAP User benötigt die Berechtigung B_ALE_RECV.

callback

Nachdem eine Nachricht per PUSH oder FETCH in das SAP-System eingelaufen ist und ein (oder mehrere) IDOC(s) erzeugt wurde(n), werden alle IDOC-Nummern über eine callback-Nachricht an ecosio zurückgesendet. Dabei wird die Nachrichten-ID der eingehenden Nachricht referenziert, sodaß im ecosio-Monitor eine Nachricht nun auch nach ihrer IDOC-Nummer gesucht und gefunden werden kann.

Begriffe

AppKey
ist ein Schlüssel, der die Applikation (bei uns: die EPO - Anbindung) identifiziert. Ist unterschiedlich in STAGE/PROD, und auch eindeutig in Bezug auf die ECOSIO - Schnittstellenversion
UserID
das ist die e-Mail Adresse, die einerseits zum Anmelden im Montitor benutzt wird, andererseits beim API - Aufruf
UserKey
das ist ein generierter Schlüssel (siehe Monitor), der ausschließlich bei API-Aufrufen benutzt wird. Der Monitor kann einen neuen Key generieren, der dann sofort wirksam wird (d.h. API-Aufrufe mit dem alten Schlüssel laufen dann auf Fehler).
Company UUID
ist eine eindeutige Bezeichnung für eine Firma auf einem ECOSIO-System. Ist abhängig von STAGE/PROD, und auch mandantenabhängig. Wird als zusätzlicher Selektor beim FETCH benutzt.


SERVICE_ID, SERVICE_NAME
bei eingehenden EPO-Services ist der Servicename bereits eindeutig, da eine Nachricht an einen bestimmten Server gesendet wird (z.B. Test, Produktion). Bei einem ausgehenden EPO-Service wird eine SERVICE_ID anhand der aktuellen SAP-Systemid auf einen SERVICE_NAME gemappt (EPO - Customizingtabelle /EPO1/CONFIGOUTY). Damit wird gewährleistet, daß nach einer Systemkopie von Produktivsystem auf Testsystem die ausgehenden Nachrichten des Testsystems weiterhin an das Testsystem des Partners gesendet werden (und nicht an dessen Produktivsystem).

Netzwerk / Proxy / Firewall

Die ecosio - Server haben zwar einen symbolischen Namen (z.B. 'api.test.ecosio-hub.com:8443'), dahinter verbergen sich allerdings mehrere Server, die dynamisch per LoadBalancing zugeteilt werden.

Als Folge davon wird die IP-Adresse bei einem Service-Aufruf dynamisch zugeteilt.

Problemstelle Proxy/Firewall: wenn ein Prosyserver für ausgehende Verbindungen benutzt wird, so genügt es nicht, nur 'eine' IP-Adresse freizuschalten, sondern immer alle möglichen Adressen. Bzw. jene Liste, die von ecosio bekanntgegeben wird.

Please download the parameter sheets and TLS/SSL certificates here:

https://files.ecosio.com/PROD+-+ecosio+messaging+API.zip

https://files.ecosio.com/TEST+-+ecosio+messaging+API.zip

For your firewall configuration, you will find the IPs in the parameter sheet (5 for test, 5 for prod).

Additional I listed them here:

  • TEST
    • 35.156.4.57
    • 52.57.20.161
    • 3.121.121.177
    • 34.78.41.131
    • 104.199.60.154
  • PROD
    • 52.28.241.38
    • 52.29.112.147
    • 18.192.0.156
    • 104.199.8.20
    • 35.240.83.219

Due to you have to add ecosio's TLS/SSL certificate to your SAP systems, please use the ecosio self-signed TLS/SSL certificate setting.

  • TEST
    • API base URL: https://api.test.ecosio-hub.com:8443
    • Certificate (in the TEST download): HTTPS_selfsigned8443_test-ecosio-hub-com.cer
  • PROD
    • API base URL: https://api.ecosio-hub.com:8443
    • Certificate (in the PROD download): HTTPS_selfsigned8443_ecosio-hub-com.cer

Test

Einstellungen gültig bis 19.6.2020 - nicht mehr verwenden!!!
EDI-Messaging API - https://services-test.ecosio.com
  • 52.58.134.76
Supply API - https://supply-backend-api.test.ecosio.com
  • 18.197.224.178
  • 35.157.112.170
  • 35.159.44.160

Produktiv

EDI-Messaging API - https://services.ecosio.com
  • 52.28.241.38
  • 52.29.112.147
Supply API - https:/supply-backend-api.ecosio.com
  • 18.194.51.196
  • 35.157.128.208
  • 52.29.73.159

Transaktionen

EPO Connector ecosio EDI Transaktionen

  • /EPO1/EDI Aufruf des ecosio.com Monitors Produktion
  • /EPO1/EDITEST Aufruf des ecosio.com Monitors Stage-Umgebung
  • /EPO1/EXC Anzeige des EPO Bereichsmenüs (Nachrichtenlisten, Konfiguration)
  • /EPO1/MESSAGESLIST Anzeige der Nachrichtenliste, Selektion nach dem Service 'ecosiosap' (eingehende) bzw. 'sapecosio*' (ausgehende Nachrichten)

SAP Standard Transaktionen

  • BD87 IDOC - Monitor
  • WE02, WE02 IDOC - Liste (suchen und anzeigen)
  • WEDI IDOC - Bereichsmenü

Einstellungen lt. ECOSIO

Folgende Einstellungen werden durch ECOSIO vorgeschrieben und müssen kundenspezifisch angegeben werden:

  • Sender-ID, die in den Header der XML-Nachricht eingetragen wird
  • Prefix für den ECOSIO-Dokumenttyp, der in den Header der XML-Nachricht eingetragen wird
  • kundenspezifischer Namespace in der XML Nachricht

Es ist die Entscheidung zu treffen, ob 'push' oder 'fetch' für das Empfangen von Nachrichten eingesetzt wird. Wenn möglich, sollte 'push' eingesetzt werden.

ECOSIO Monitor

Im Monitor können die versendeten Nachrichten inhaltlich überprüft werden, sowie deren Zustellungsstatus eingesehen werden.

Anmeldung mit Username (e-Mail Adresse) und Passwort:

  • Testumgebung: https://monitor-stage.ecosio.com
  • Produktiv: https://monitor.ecosio.com


UserKey (=Passwort für API-Aufrufe) anzeigen/ändern:

  • Einstellungen
  • Benutzerverwaltung
  • Button 'User Key anzeigen' -> der Key wird angezeigt, kann mit der Maus markiert und kopiert werden
  • Button 'User Key neu generieren' erzeugt einen UserKey, der SOFORT wirksam wird
    ACHTUNG: mit dem Generieren des neuen UserKeys funktioniert die Verbindung zwischen SAP und ECOSIO nicht mehr, bis der neue UserKey in der Passwort-Tabelle eingetragen wird.

Daten des Kunden

Abgesehen vom Zugang zum SAP-System ist ein Entwicklerschlüssel notwendig (erstellen der abgeleiteten OUT-Klasse).

Für das Einrichten der Partnerverbindungen ist eine vollständige Liste für jede ein- bzw. ausgehende Verbindung notwendig und muß vom Kunden bekanntgegeben werden:

  • KUNNR/LIFNR des Partners im kundeneigenen SAP-System
  • Kennzeichen: ein- oder ausgehende Nachricht
  • Nachrichtentyp (siehe Transaktion WE81)
  • IDOC-Typ (siehe Transaktion WE30)

Die Liste der IDOC-Typen ist an ECOSIO weiterzugeben, dort wird dann das entsprechende XML-Schema erstellt (das XML-Schema für IDOC-Typen erhält man mit der Transaktion WE60).

Technische Voraussetzung für eine verschlüsselte Verbindung zu ECOSIO ist das HTTPS-Service (Transaktion SMICM).

Installation

Die Installation erfolgt durch Einspielen des ECOSIO-Transportauftrages. Voraussetzungen sind:

  • die Installation des EPO-Connectors, SP11 + SP12 - Vorabtransport als Minimum
  • bei SP12 - Vorab: zusätzlich den Transport mit den Paketen MA_COMMON/TS/EXC_PARAMETERS einspielen
  • aktuellen IDOC - Monitor einspielen
  • ein Entwicklerschlüssel
  • die Partnerdaten des Kunden (siehe oben)
  • Transaktion SMICM: Goto | Services bzw. Springen | Services, aktives HTTPS-Service auf einem gültigen Port (ungleich Null)


  • Transportverzeichnis ermitteln
  • Transaktion STMS, Importübersicht, Entwicklungssystem anwählen
  • Menü: Springen | TP Parameter
  • der Parameter TRANSDIR bezeichnet das Wurzelverzeichnis für Transporte (z.B. /usr/sap/trans)


  • Hochladen der beiden Transportdateien in das Transdir - Verzeichnis
  • Transaktion CG3Z
  • die 'R' - Datei in das Unterverzeichnis data (z.B. /usr/sap/trans/data) hochladen
  • die 'K' - Datei in das Unterverzeichnis cofiles (z.B. /usr/sap/trans/cofiles) hochladen


  • Import des Transportauftrages
  • Transaktion STMS, Importübersicht, Entwicklungssystem anwählen
  • Menü: Zusätze | Weitere Aufträge | Anhängen
  • Name des Transportauftrages eingeben
  • Transportauftrag in der Liste selektieren und transportieren


  • Transportauftrag für den Weitertransport erstellen
  • Transaktion SE09, neuen Workbench - Transportauftrag erstellen
  • alle Objekte des ECOSIO-Transportauftrages aufnehmen
  • alle folgenden Änderungen können zu diesem Transportauftrag hinzugefügt werden, nach dem Abschluß der Einrichtung erfolgt der Transport über den normalen Transportweg in die weiteren SAP-Systeme

ECOSIO-Service aktivieren

Gilt nur für PUSH, nicht notwendig für FETCH:
!! Das Service muß nach jedem (Update-)Transport aktiviert werden, der das ECOSIO-Gesamtpakt enthält !!

Transaktion SICF, Pfad: default_host, epo1soa, ecosio

Mit dem Kontextmenü das Service aktivieren:

ClipCapIt-161115-104545.PNG

SSL Zertifikat einspielen

Das ECOSIO - SSL Zertifikat muß im SAP hinterlegt werden. Transaktion STRUST, Container SSL-Client (Standard) (oder, wenn wirklich gewünscht, SSL-Client (Anonym))

ClipCapIt-161215-125955.PNG

Den Container doppelklicken, Zertifikat laden, hinzufügen, speichern.

Das Zertifikat finde ich auf

https://nc.epoconsulting.com/index.php/apps/files/?dir=/Kundenprojekte/EPO/SoftwareDownload/EPO%20ecosio.EDI&fileid=225578

mit dem Namen

  • ecosio_hub_2044_08.cer für den produktiv-Server und
  • ecosio_hub_test_2044_08.cer für den Testserver von ecosio.


Sicherheitshalber die Transaktion verlassen, neu einsteigen und kontrollieren, daß das Zertifikat wirklich im Container enthalten ist.

Beim Einrichten des ausgehenden EPO-Services muß der richtige Container angegeben werden:

  • SSL-Client (Standard) -> DFAULT (normale Einstellung)
  • SSL-Client (Anonym) -> ANONYM

ICF Service neu starten

Das neue Zertifikat ist dem Server noch nicht bekannt, ICF muß neu gestartet werden (nur nach Absprache!!)

Transaktion SMICM:

  • Administration | ICM | Neustart | Ja (bereitet den Neustart vor)
  • Administration | Soft beenden | global (führt den Neustart durch).

Hart beenden geht schneller, killt aber alle gerade laufenden Prozesse und könnte daher zu Fehlern führen.

SM59 - Verbindung testen

Transaktion SM59, 2 neue HTTP-Verbindungen einrichten, muss auf jedem System separat gemacht werden:

  • ECOSIO_TEST
  • ECOSIO_PROD

Einstellungen:

  • Verbindungstyp: G
  • Beschreibung 1:
    ECOSIO Testverbindung TEST bzw.
    ECOSIO Testverbindung PROD

Technische Einstellungen:

  • Zielmaschine:
    api.test.ecosio-hub.com bzw.
    api.ecosio-hub.com
  • Port: 8443
  • Pfadpräfix: /api/v1/delivery
  • gegebenenfalls die Proxy-Einstellungen pflegen, wenn ein Proxy vorhanden ist

Anmeldung & Sicherheit, Sicherheitsoptionen:

  • SSL: aktiv
  • SSL-Zertifikat: DFAULT SSL-Client (Standard) bzw. SSL-Client (Anonym)

Speichern, Verbindungstest durchführen. Jetzt sollte ein PopUp erscheinen. Hier könnte man Username für den ECOSIO-Monitor und der AppKey als Kennwort eintragen (es genügt, daß das Popup erscheint):

ClipCapIt-161215-132141.PNG

Eine erfolgreiche Verbindung ist die Voraussetzung für alle weiteren Schritte:

ClipCapIt-161215-132105.PNG

bzw. bei 'delivery' ohne entsprechende Parameter genügt auch ein 'bad request'; der heisst immerhin, daß der Server den Request wirklich angesehen und bearbeitet hat:

ClipCapIt-170116-150324.PNG


Falls aber User/Passwort falsch waren, darf man nicht weitermachen:

ClipCapIt-170116-150530.PNG


Fehlersuche

Was tun, wenn die Verbindung nicht läuft?

HTTPIO_PLG_CANCELLED
Kontrolle, ob HTTPS aktiv ist: Transaktion SMICM, Springen | Services
HTTPS muß eingerichtet und aktiv sein:
ClipCapIt-161215-134302.PNG
Service | anlegen, Port: 8443 (oder sonst einem noch nicht benutzten Port - keinesfalls aber '0'); Protokoll: HTTPS; Service aktivieren
ICM_HTTP_CONNECTION_FAILED
wahrscheinlich wird ein Proxy zur Verbindung ins Interne eingesetzt; korrekte Proxyeinstellungen erfragen und eintragen (in der SM59 und auch in der EPO Service Konfiguration), ev. ist der ECOSIO-Server auch in der Firewall als berechtigte Adresse einzutragen. Es kann auch sein, dass der Server von der IT explizit auf eine Whitelist gesetzt werden muss, damit er angesprochen werden kann.
IcmConnInitClientSSL...
'IcmConnInitClientSSL: Proxy connection to https://services.ecosio.com:443 via inc-ixn-sap65:3128 failed (proxy returned 403 Forbidden)'
Es wurde ein Proxyserver eingerichtet, dieser lässt aber keine Verbindung zu. Basis informieren und die Verbindung freischalten lassen.
ICM_HTTP_TIMEOUT
es konnte keine Verbindung hergestellt werden: Servername, Port, Pfadpräfix testen. Ev. wird der Port auch durch eine Firewall blockiert -> durch den Netzwerktechniker kontrollieren lassen.
ICM_HTTP_SSL_ERROR
es ein Problem mit der Kompatibilität der SSL-Handshakes zwischen dem SAP (client) und dem Server; wahrscheinlich werden die vom Server angebotenen Verfahren vom Client nicht unterstützt - bzw. umgekehrt. Ein Update der Crypto-Lib ist anzudenken.

Es kann aber auch sein, dass schlicht vergessen wurde, den ICF - Service neu zu starten (siehe oben).

ICM_HTTP_SERVICE_UNAVAILABLE
Popup mit "Connection Closed"

in der Testverbindung im Reiter "Logon & Security" im Rahmen "Security Options" SSL auf aktiv setzen.

FORBIDDEN
dies kommt erst bei Aufruf über den ecosio Connector. Es konnte eine Verbindung zum Server aufgebaut werden, aber entweder fehlen die ecosio Zugangsdaten oder sie sind fehlerhaft.
Connect to proxy
8080 failed: NIEHOST_UNKNOWN(-2)
der Proxyserver kann keine Verbindung aufbauen
NIECONN_REFUSED(-10)
fehlt die Konfiguration des Proxyservers (weil kein direkter Internetzugang möglich ist)
die Firewall lässt die Verbindung nicht zu - vom Netzwerk-Team freischalten lassen
Client connection to http://api.test.ecosio-hub.com:8443 broken
Fehlerursache: Im Reiter "Anmeldung und Sicherheit" muss SSL auf aktiv gesetzt werden.

Cryptolib kontrollieren

Die Cryptolib ist die Grundlage für HTTPS. Ev. muß durch die Basis hier eine (modernere) Lib installiert werden.
Transaktion STRUST, Umfeld | SSF Version anzeigen:

  • SSFLIB Version 1.555 ... ist jedenfalls zu alt.
  • SSFLIB Version 1.840.40; CommonCryptoLib ..ist OK (mit SAPCRYPTOLIB 8.4.35, 8.4.48)

Customizing des EPO-Connectors

Nummernkreisintervalle anlegen

Transaktion SNRO, Nummernkreis /EPO1/NOR anlegen (soferne diese nicht schon existieren); Intervalle werden nicht automatisch transportiert (entweder manuell einem Transportauftrag hinzufügen, oder in jedem System separat einstellen):

Intervall Von - Nummer Bis - Nummer
00 0000000000000001 0000019999999999
01 0000020000000000 0000029999999999

Servicenamen

Die ausgehenden Services werden je nach Test und Produktion benannt. Damit ist eine einfache Trennung zwischen Test- und Produktivsystem möglich, bei Klappungen (Systemkopie) sendet das Testsystem weiterhin an den ECOSIO-Testserver.

Allgemeine Einstellungen:

  • Operation mandatory: X
  • request URL name: request
  • message fomat: json


Beispiel:

Servicename Richtung IN: use http header IN: use query string Description
ecosiosap I (in) X X JSON service ecosio.com to SAP
sapecosio_test O (out) JSON service for sending SAP IDOCs to ecosio-test.com
sapecosio_prod O (out) JSON service for sending SAP IDOCs to ecosio.com

Hinweis: ecosiosap ist nur auch für FETCH notwendig, weil die abgeholten Meldungen genau so gespeichert werden wie bei PUSH: also mit den Operations store_xml_full und store_xml_single

Inbound EPO Runtime Service Konfiguration

Für FETCH entfällt die Operation push:

Servicename Operation Nummernkreisobjekt Num.Kr.Intervall Protokoll Ausführungstyp Nachricht (+Hd) Kompr. Ausführungs FB
ecosiosap push /EPO1/NOR 00 0 HTTP S Synchron X In- und Outbound X /EPO1/ECOSIO_JSON_PROCESSING
ecosiosap store_xml_full /EPO1/NOR 00 0 HTTP S Synchron X In- und Outbound X
ecosiosap store_xml_single /EPO1/NOR 00 0 HTTP S Synchron X In- und Outbound X /EPO1/ECOSIO_IXML_PROC_SINGLE

Outbound EPO Runtime Service Konfiguration

Systemnamen ausfüllen; die UUID für fetch kann dem ECOSIO-Monitor entnommen werden.

Der appKey ist immer gleich (=EPO), aber unterschiedlich für Stage/Prod und abhängig von der ECOSIO - Interfaceversion.

FETCH
benötigt callback, fetch, message und store
PUSH
benötigt kein fetch
ECOSIO - Version 2
appKey Stage = H4E9sZuMONU7l2EvDFZGztiBvbgEleDEqOdD01mBvlRh81aw
appKey Prod = H4EbqXlNocc7Z2EvDb4sLWywjwKeIdx9mQOGyHyhHmwOVnTL
ECOSIO - Version 1 (alt)
appKey Stage = H4EbS7rDYHW9b/6ibS8uRLNPwBX3dkEB3fb8Ll4jxucksTms
appKey Prod = H4EDy9d0tePSp0P9FtGe2a8RfJZJocD9Qbh11CDQK0Wk9Axi

Standardeinstellung OUT:

  • Nummernkreisobjekt: /EPO1/NOR
  • Nummernkreisintervall: 01
  • Protokoll: 0 HTTP
  • Ausführungstyp: S Synchron
  • Nachricht (+Hd): X In- und Outbound
  • Komprimieren: X
  • Content Type: application/json; charset=utf-8
  • HTTP SSL ID: DFAULT (bzw. ANONYM - in den angegebenen Container muß das Zertifikat eingespielt werden)
  • HTTP Schema: HTTPS
Port
standardmäßig wird Port 443 benutzt.
Servicename Operation Hostname Port Pfad (URI)
sapecosio_test callback services-test.ecosio.com 443 /api/v1/callback
sapecosio_test fetch_list services-test.ecosio.com 443 /api/v1/fetch
sapecosio_test fetch_message services-test.ecosio.com 443 /api/v1/fetch/<UUID>/<messageId>
sapecosio_test message services-test.ecosio.com 443 /api/v1/delivery
sapecosio_test store
sapecosio_prod callback services.ecosio.com 443 /api/v1/callback
sapecosio_prod fetch_list services.ecosio.com 443 /api/v1/fetch
sapecosio_prod fetch_message services.ecosio.com 443 /api/v1/fetch/<UUID>/<messageId>
sapecosio_prod message services.ecosio.com 443 /api/v1/delivery
sapecosio_prod store

*) Hinweis: der Pfad für fetch_message enthält tatsächlich den Platzhalter <messageId> um klarzumachen, daß in der endgültigen URL hier die Message-ID stehen muß. Ohne diesen Platzhalter wird die Message-ID einfach an die URL angehängt.

Outbound EPO HTTP Header

Nur für FETCH (für PUSH nicht notwendig); Systemnamen entsprechend ausfüllen

Diese Einstellung ist eine Alternative zum Feld 'Content Type' in der Konfiguration für outbound services. Da aber auch der X-APP-KEY konfiguriert werden muß, es es übersichtlicher, alle Einstellungen in dieser Tabelle zu haben.

Servicename Operation HTTP Header Name HTTP Header Wert
sapecosio_test callback Content-Type application/json; charset=utf-8
sapecosio_test callback X-APP-KEY H4E9sZuMONU7l2EvDFZGztiBvbgEleDEqOdD01mBvlRh81aw
sapecosio_test fetch_list Content-Type application/json; charset=utf-8
sapecosio_test fetch_list X-APP-KEY H4E9sZuMONU7l2EvDFZGztiBvbgEleDEqOdD01mBvlRh81aw
sapecosio_test fetch_message Content-Type application/json; charset=utf-8
sapecosio_test fetch_message X-APP-KEY H4E9sZuMONU7l2EvDFZGztiBvbgEleDEqOdD01mBvlRh81aw
sapecosio_test message Content-Type application/json; charset=utf-8
sapecosio_test message X-APP-KEY H4E9sZuMONU7l2EvDFZGztiBvbgEleDEqOdD01mBvlRh81aw
sapecosio_prod callback Content-Type application/json; charset=utf-8
sapecosio_prod callback X-APP-KEY H4EbqXlNocc7Z2EvDb4sLWywjwKeIdx9mQOGyHyhHmwOVnTL
sapecosio_prod fetch_list Content-Type application/json; charset=utf-8
sapecosio_prod fetch_list X-APP-KEY H4EbqXlNocc7Z2EvDb4sLWywjwKeIdx9mQOGyHyhHmwOVnTL
sapecosio_prod fetch_message Content-Type application/json; charset=utf-8
sapecosio_prod fetch_message X-APP-KEY H4EbqXlNocc7Z2EvDb4sLWywjwKeIdx9mQOGyHyhHmwOVnTL
sapecosio_prod message Content-Type application/json; charset=utf-8
sapecosio_prod message X-APP-KEY H4EbqXlNocc7Z2EvDb4sLWywjwKeIdx9mQOGyHyhHmwOVnTL
Fehlerbild
  • Response at.erpel.messaginghub.services.heans.FetchEntryResponse@3f59b9e5 - es fehlt der 'Content Type' in der Servicekonfiguration

Service Zuordnung über SY-SYSID

Dieses Mapping sorgt für eindeutige Servicenamen in verschiedenen Systemen des gleichen Transportpfades. Das Customizing erfolgt zentral am Entwicklungssystem, Test- und Produktivsystem haben aber ihre eigenen Einstellungen (z.B. Hostname)

SAP System-ID Servicename Servicename
T01 sapecosio sapecosio_test
P01 sapecosio sapecosio_prod
Q01 sapecosio sapecosio_test

 

EPO-Lizenzfile einspielen

Transaktion /EPO1/EXC

Menü | EPO Connector Administration | Laden des Lizenzschlüssels für den EPO Connector

EPO-Produktname: "EPO1",

Lizenz File: <Pfad und Name des Lizenzfiles>

Voraussetzung: die SAP-Installationsnummer

 

Einstellungen für Statusmanager - /EPO1/ECOSIO_ESM

Als optionalen Schritt kann ein periodischer Job den Zustellungs-Status der Nachrichten bei ecosio abfragen und den IDOC-Status entsprechend setzen.

An sich ist das nicht notwendig, da bei ecosio Nachrichten grundsätzlich immer zugestellt werden, und bei technischen Problemen immer sofort der Kontakt zum Kunden aufgenommen wird.

Für Details bitte die Beschreibung für den Statusmanager befolgen.

 

Username / Passwort pflegen

Transaktion /EPO1/EC_EB_WSSP12, für jedes System im Transportpfad folgende Werte eintragen:

(das sind 2 Einträge pro SAP-System)

  • SAP-System: <sy-sysid>
  • Service: sapecosio
  • Name: UserId
  • Wert: Username wie für monitor.test.ecosio.com / monitor.ecosio.com
  • Name: UserKey
  • Wert: API-Key aus monitor.test.ecosio.com / monitor.ecosio.com


Hinweis: Es muss eine aktuelle Version des Pakets /EPO1/EXC_PARAMTERS im System eingespielt sein. Dies wird normalerweise im Zuge der EPO Connector Installation erledigt mit dem Paket MA_COMMON, TS und PARAMETERS Transport.

Fehlerbild
  • ICM_HTTP_INTERNAL_ERROR - wahrscheinlich stimmen UserId/UserKey nicht

 

SenderID pflegen - /EPO1/ECOSIO_SID

Verfügbar ab Version 2.8.1

Dieser Schritt kann entfallen, wenn das Werks- oder Buchungskreisabhängige Service implementiert wird, bzw. wenn die SenderID in der Methode UE_GET_SENDER gesetzt wird!

Transaktion SM30, Tabelle /EPO1/ECOSIO_SID

SAP System ID Sender ID
480740687
B4P 480740687

Eine Zeile mit leerer SYSID dient als Defaultwert für alle Systeme, die keine eigene Zeile haben.

Set-up Outbound IDOCs

Die Outbound IDOC Verarbeitung startet mit dem Fuba /EPO1/ECOSIO_JSON_POST. Dieser ist im IDOC Port ECOSIO (Transaktion WE21) hinterlegt. Hierin wird die Tabelle /EPO1/ECOSIO_OUT mit dem IDOC-Typ abgefragt, um die ausführende Klasse zu ermitteln. Ist für einen IDOC-Typ kein Eintrag vorhanden, führt dies zu einer Fehlermeldung. Die Basisklasse ist /EPO1/CL_EXC_ECOSIO_XML_OUT, wobei aufgrund von redefinierten Methoden in der Tabelle /EPO1/ECOSIO_OUT immer eine Z-Klasse eingetragen werden muss.

Die Hauptmethode in der gewählten Klasse ist UNIT_PROCESS. Hier wird der Request für ECOSIO generiert und über den EPO-Connector gesendet.


Folgende Schritte sind umzusetzen:

  • einrichten des EPO-Connectors für ausgehende Nachrichten
  • ableiten der Klasse /EPO1/CL_EXC_ECOSIO_XML_OUT, UserExit - Methoden redefinieren
  • kundenzspezifische Transformation kopieren/anpassen
  • Name der abgeleiteten Klasse und der Transformation in die Steuertabelle eintragen
  • Partnervereinbarungen pflegen
  • Pflege der Kunden-Lieferantenansprechpartner für das UNB-Mapping (kann entfallen, wenn die Tabelle /EPO1/ECOSIO_UNB nicht gepflegt ist bzw. eine eigenständige Lösung in der abgeleiteten Klasse implementiert wird)


ableiten der Klasse /EPO1/CL_EXC_ECOSIO_XML_OUT

Die Basisklasse ist /EPO1/CL_EXC_ECOSIO_XML_OUT enthält keine kundenspezifischen Daten. Daher ist es notwendig, für eine reale Implementierung eine abgeleitete Klasse (z.B. Z_CL_ECOSIO_OUT) zu erstellen. Alle Methoden, die mit dem Prefix 'UE_' beginnen, können bzw. müssen durch Redefinitionen ersetzt werden. Andere Methoden sollen nicht verändert werden, da diese Änderungen bei einem Update verloren gehen.

Eine Redefinition ist notwendig für:

  • UE_GET_ECOSIO_DOCTYP
    liefert den ECOSIO-Dokumententyp für den HEADER. Die Implementierung erfolgt nach den Angaben von ECOSIO. Üblicherweise wird ein kundenspezifisches Prefix mit dem Nachrichtentyp (m_edidc-mestyp) kombiniert.
  • UE_GET_NAMESPACE
    liefert den Namespace für XML-Dokumente, wie von ECOSIO vorgegeben (notwendig ab Version 2, nicht für Version 1)
  • UE_GET_SENDER
    liefert die Sender-ID, wie von ECOSIO vorgegeben


Eine Redefinition ist optional möglich für:

  • UE_GET_RECEIVER
    liefert den Receiver. Wenn dieser nicht direkt aus dem IDOC bezogen werden soll, kann eine Redefinition erfolgen.
  • UE_GET_SERVICE_ID
    liefert den Servicenamen für den EPO-Connector. Eine Redefinition ist nur notwendig, wenn nicht der Servicename 'sapecosio' benutzt werden soll.
  • UE_GET_TESTFLAG
    liefert das Testflag, welches direkt zum Nachrichtenempfänger weitergeleitet wird. Eine Redefinition ist nur notwendig, wenn von 'produktiv' auf 'test' umgestellt werden soll. Hier können die Klassen-Konstanten C_TESTFLAG_PRODUCTIVE und C_TESTFLAG_TEST benutzt werden.
  • UE_HTTP_HEADER_POSTPROCESSING
    hier kann optional eine Anpassung der HTTP-Header vorgenommen werden.
  • UE_XML_PREPROCESSING
    hier kann optional die gesamte XML-Nachricht bearbeitet werden.
    Der Aufruf erfolgt unmittelbar, bevor die Interchange-Referenz in die XML-Nachricht eingearbeitet wird.
  • UE_XML_POSTPROCESSING
    hier kann optional die gesamte XML-Nachricht bearbeitet werden.
    Der Aufruf dieser Methode erfolgt unmittelbar vor dem Senden der Nachricht.
  • UE_PARTN_UNB_MAPPING
    hier wird das Mapping von KUNNR bzw. LIFNR auf UNB-ID für die Partner AG, LF, RE, RG und WE durchgeführt

Beispiel für UE_GET_RECEIVER

Wenn z.B. ein Mapping nicht über KUNNR/LIFNR möglich ist, weil ein echtes logisches System (im Beispiel: NXP) angesprochen wird:

der Empfänger NextPharma 'NXP' wird manuell auf 'NEXTPHARMA' gemappt

CASE m_edidc-rcvprn.
WHEN 'NXP'.
  r_receiver = 'NEXTPHARMA'.
WHEN OTHERS.
  " call the default handling
  r_receiver = super->ue_get_receiver( ).
ENDCASE.

Methode /EPO1/CL_EXC_ECOSIO_XML_OUT->UNIT_PROCESS

Die Methode UNIT_PROCESS ruft die Methode GET_REQUEST auf. In der Methode GET_REQUEST werden folgende Methoden in dieser Reihenfolge aufgerufen:

  1. m_receiver = ue_get_receiver( ).
  2. m_sender = ue_get_sender( ).
  3. m_ecosio_doctyp = ue_get_ecosio_doctyp( ).
  4. m_testflag = ue_get_testflag( ).
  5. m_namespace = ue_get_namespace( ).

Methode /EPO1/CL_EXC_ECOSIO_XML_OUT->UE_GET_RECEIVER

OBSOLET - nicht mehr verwenden - UE_GET_RECEIVER_BP über die Tabelle /EPO1/ECOSIO_DEF einstellen ! Hinweis: die Logik für das Mapping eingehender Nachrichten wird mit hart codierten Abhängigkeiten realisiert.

Ermittelt den <RECEIVER> im Message-XML epo-Header.

Der Receiver wird zuerst aus dem IDOC Kontrollsatz aus dem Feld Receiver Partnernummer EDIDC-RCVPRN gesetzt. Anschließend wird in der Tabelle /EPO1/ECOSIO_UNB mittels des IDOC Nachrichtentyps gelesen. Die Tabelle wird mit folgenden Einträgen ausgeliefert:

MESTYP PRIO CMP_VALUE CMP_TABLE CMP_FIELD TRANS_NAME
DELFOR 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_DELFOR
DELJIT 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_DELFOR
DESADV 0 WE KNVK KUNNR /EPO1/ECOSIO_RECEIVER_DELVRY
GSVERF 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_GSVERF
INVOIC 0 RE KNVK KUNNR /EPO1/ECOSIO_RECEIVER_INVOIC
ORDCHG 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_ORDERS
ORDERS 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_ORDERS
ORDRSP 0 AG KNVK KUNNR /EPO1/ECOSIO_RECEIVER_ORDERS
STPPOD 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_DELVRY

Die Spalte PRIO erlaubt es, unterschiedliche Einstellungen entsprechend ihrer Priorität abarbeiten zu lassen. Die Einträge werden mit aufsteigender Nummer abgearbeitet.

Mittels der angegebenen Transformation werden die Werte aus dem XML-IDOC ermittelt. Anschließend wird aus der angegebenen SAP Tabelle (immer KNVK) aus dem Feld NAME1 der korrekte RECEIVER Wert versucht zu ermitteln. Dabei gilt folgende Logik: Es wird in der Tabelle KNVK (Ansprechpartner im Kundenstamm oder im Lieferantenstamm - siehe Tab. /EPO1/ECOSIO_UNB) nach dem Ansprechpartner der Abteilung ZEDI gesucht. Wird mehr als ein Eintrag ermittelt, dann wird der Eintrag mit Abteilung ZEDI und der Funktion ZS verwendet (wenn vorhanden). Beispiel Eintrag:

ClipCapIt-161101-131117.PNG

 

Methode /EPO1/CL_EXC_ECOSIO_XML_OUT->UE_GET_RECEIVER_BP

Ermittelt den <RECEIVER> im Message-XML epo-Header.

Der Receiver wird zuerst aus dem IDOC Kontrollsatz aus dem Feld Receiver Partnernummer EDIDC-RCVPRN gesetzt. Anschließend wird in der Tabelle /EPO1/ECOSIO_BPO mittels des IDOC Nachrichtentyps gelesen.

Die Tabelle wird mit wahlweise mit einem Set der folgenden Einträgen ausgeliefert:

Nachrichtentyp Priorität Tabelle Suchfeld Ergebnisfeld Part.verw. Prio-Feld Prio-Wert WHERE Transformation
DELFOR 0 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_DELFOR
DELINS 0 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_DELFOR
DELJIT 0 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_DELFOR
DESADV 0 KNVK KUNNR NAME1 WE PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_DELVRY
GSVERF 0 KNVK KUNNR NAME1 AG PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_GSVERF
INVOIC 0 KNVK KUNNR NAME1 RE PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_INVOIC
ORDCHG 0 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_ORDERS
ORDERS 0 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_ORDERS
ORDRSP 0 KNVK KUNNR NAME1 AG PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_ORDERS
SHPADV 0 KNVK KUNNR NAME1 WE PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_SHPMNT
STPPOD 0 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_DELVRY
Nachrichtentyp Priorität Tabelle Suchfeld Ergebnisfeld Part.verw. Prio-Feld Prio-Wert WHERE Transformation
DELFOR 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_DELFOR
DELINS 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_DELFOR
DELJIT 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_DELFOR
DESADV 0 /EPO1/ECOSIO_BPC CUSTOMER IDNUMBER WE TYPE ZKUD XDELE = '' AND TYPE IN ('ZKU', 'ZKUD') /EPO1/ECOSIO_RECEIVER_DELVRY
GSVERF 0 /EPO1/ECOSIO_BPC CUSTOMER IDNUMBER WE TYPE ZKUD XDELE = '' AND TYPE IN ('ZKU', 'ZKUD') /EPO1/ECOSIO_RECEIVER_GSVERF
INVOIC 0 /EPO1/ECOSIO_BPC CUSTOMER IDNUMBER RE TYPE ZKUD XDELE = '' AND TYPE IN ('ZKU', 'ZKUD') /EPO1/ECOSIO_RECEIVER_INVOIC
ORDCHG 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_ORDERS
ORDERS 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_ORDERS
ORDRSP 0 /EPO1/ECOSIO_BPC CUSTOMER IDNUMBER AG TYPE ZKUD XDELE = '' AND TYPE IN ('ZKU', 'ZKUD') /EPO1/ECOSIO_RECEIVER_ORDERS
SHPADV 0 /EPO1/ECOSIO_BPC CUSTOMER IDNUMBER WE TYPE ZKUD XDELE = '' AND TYPE IN ('ZKU', 'ZKUD') /EPO1/ECOSIO_RECEIVER_SHPMNT
STPPOD 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_DELVRY

Die Spalte PRIO erlaubt es, unterschiedliche Einstellungen entsprechend ihrer Priorität abarbeiten zu lassen. Die Einträge werden mit aufsteigender Nummer abgearbeitet.

Die angegebene Transformation muß eine Tabelle mit den Spalten PARVW (Partnerart) und PARTN (Partnernummer) aus dem XML-IDOC zurückliefern.

Innerhalb dieser Tabelle wird die Partnerverwendung in der Spalte PARVW gesucht, PARTN ist dann der RECEIVER.

Anschließend wird aus der angegebenen SAP Tabelle/View im Suchfeld der RECEIVER gesucht und der Wert des Ergebnisfeldes zurückzugeliefert. Falls es mehrere Treffer gibt, so kann mit Prioritätsfeld/Prioritätswert ein Eintrag höher priorisiert werden.

Mit dem WHERE - Feld kann eine (beliebige) zusätzliche WHERE - Klausel definiert werden.

 

Methode /EPO1/CL_EXC_ECOSIO_XML_OUT->UE_CHANGE_MESSAGE_ID

Die ecosio Message ID, welche aus dem Response gelesen ermittelt wird, wird um den String @ecosio ergänzt. Die ecosio Message ID wird in der Folge im Funktionsbaustein /EPO1/ECOSIO_JSON_POST mittels Status Update in den IDOC Steuersatz, Feld EDIDC-ARCKEY geschrieben.

Anleitung zum Ableiten der Klasse

Start der Transaktion SE80, Selektion des kundeneigenen Paketes (z.B. ZEPO1_ECOSIO).

Mit dem Kontextmenü: Anlegen | Klassenbibliothek | Klasse

ClipCapIt-161109-161434.PNG
  • Klassenname: z.B. Z_CL_ECOSIO_OUT
  • Oberklasse: /EPO1/CL_EXC_ECOSIO_XML_OUT
  • Beschreibung: Outbound ECOSIO message
  • gewöhnliche ABAP-Klasse
  • Final: nur setzen, wenn keine weiter Ableitung mehr erfolgen soll (das ist meist der Fall - finale Klassen haben einen leichten Performancevorteil zur Laufzeit, können aber nicht als Basisklasse für weitere Klassen eingesetzt werden)
ClipCapIt-161111-123528.PNG
  • Sichern und aktivieren.


Redefinieren von Methoden mit dem Kontextmenü auf der jeweiligen Methode: Redefinieren

ClipCapIt-161109-162048.PNG

Code anpassen, speichern und aktivieren.

kundenspezifische Transformation kopieren/anpassen

!!! nur notwendig für ECOSIO-Version 1 !!! ..nicht mehr ab EPO-Ecosio-Package V22 (hier wird der Namespace in der abgeleiteten OUT-Klasse gesetzt)

Für ausgehende Nachrichten muß der Kunden-Namespace über eine XSLT-Transformation in das XML eingebracht werden. Grundlage ist die Transformation /EPO1/ECOSIO_SET_NAMESPACE, die unter einem neuen Namen (z.B. ZEPO1_ECOSIO_SET_NAMESPACE) gespeichert wird.

In der kopierten Transformation müssen die 3 Strings 'customer' durch die von ECOSIO vorgegebenen Namespace ersetzt werden:

ClipCapIt-161111-150302.PNG


Sichern und aktivieren.

Steuertabelle pflegen

Transaktion SM30, Tabelle /EPO1/ECOSIO_OUT

Für jeden IDOC-Typ muß ein Eintrag mit dem Namen der abgeleiteten Klasse und dem Namen der kopierten Transformation erstellt werden.
Neu ab ECOSIO-Package V22: es genügt ein Eintrag mit leerem Message Typ (als Default-Zeile) mit dem Namen der abgeleiteten Bearbeitungsklasse:

ClipCapIt-161109-162927.PNG

bzw.

ClipCapIt-161215-102714.PNG

Sichern, die Einträge werden in einem Transportauftrag hinterlegt.

VDA-Nummern

VDA-Nummern sichern die lückenlose Übertragung von Liefer-Nachrichten, indem jede Nachricht seine eigene Nummer und die Nummer der vorherigen Nachricht enthält. Die vergebenen Nummern selbst dürfen Lücken aufweisen.

Als Vereinfachung wird die Interchange-Referenz (eindeutig pro Partner und Nachrichtenart) bei ECOSIO als VDA-Nummer mitverwertet. Eine eigene Logik für VDA-Nummern entfällt daher auf SAP-Seite.

Interchange - Referenz

Die Interchange-Referenznummer ist eine fortlaufende Nummer, die für jede Kombination Empfänger/Nachrichtenart eindeutig und lückenlos aufsteigend vergeben wird.

Die jeweils letzte Interchange-Referenznummer wird in der Tabelle /EPO1/ECOSIO_IR hinterlegt.

Die Methode GET_INTERCHANGE_REFERENCE liest die letzte Nummer, erhöht diese um 1 und schreibt die neuen Daten zurück in die Tabelle.

Die Interchange-Referenznummer wird schließlich in das EDI_DC40-Segment der Nachricht eingetragen. Dies wird durch das Schreiben des IDOC Status erreicht!

Hinweis: Die Felder INTREF und ARCKEY können bei einem IDOC Status update mitgegeben werden und werden dabei auch in den Steuersatz (Tabelle EDIDC) geschrieben! Dies passiert im Funktionsbaustein /EPO1/ECOSIO_JSON_POST.

ClipCapIt-161109-174508.PNG

Hinweis: falls noch alte Daten in der Tabelle /EPO1/ECOSIO_INT bestehen, so werden diese automatisch in die Tabelle /EPO1/ECOSIO_IR übernommen, sobald die entsprechende Kombination Empfänger/IDOC-Typ benutzt wird. Es erfolgt die Umsetzung auf Empfänger/Nachrichtenart.

ECOSIO - Empfängerport definieren

Der Port definiert den Funktionsbaustein, der die Verarbeitung von ausgehenden IDOCs durchführt. Für den ECOSIO-Port ist das der Funktionsbaustein /EPO1/ECOSIO_JSON_POST, der seinerseits das IDOC im XML-Format über den EPO-Connector versendet.

Transaktion WE21

ClipCapIt-161111-142356.PNG


Im Bereich ABAP-PSS (bzw. ABAP-PI) wird ein neuer Eintrag angelegt:

Port ECOSIO
Beschreibung ecosio.com IDOC Ausgang
Funktionsbaustein /EPO1/ECOSIO_JSON_POST

Partnervereinbarungen pflegen

In den Partnervereinbarungen werden die Nachrichtentypen zu jedem Kunden/Lieferanten hinterlegt. Im Grunde werden hier jene Schlüsselfelder hinterlegt, mit deren Hilfe ein Anwendungsprogramm den richtigen Port (=Verarbeitungsmethode) finden kann: Applikation/Nachrichtenart/Verarbeitungscode für ausgehende Nachrichten (gemappt auf den verarbeitenden Port bzw. in Folge Funktionsbaustein) bzw. Partnerart/Kundennummer für eingehende Nachrichten (gemappt auf den Verwendungscode).

Hinweis: diese Einstellungen werden nicht transportiert, sie sind in jedem System separat einzustellen.

Transaktion WE20

ClipCapIt-161111-141850.PNG

Im Bereich KU (Kunden) bzw. LI (Lieferanten) wird für jeden angebunden Kunden bzw. Lieferanten ein Eintrag mit den benutzten Nachrichtentypen erstellt.


Beispiel:

Ausgangsparameter Ausgangsoptionen Nachrichtensteuerung
Partnerrolle Nachrichtentyp Nachr.variante Basistyp Text Applikation Nachrichtenart V.Code Text
LF DELFOR DELFOR02 Lieferabruf für Zul. EL Einkauf LP-Abruf LPH1 ME14
DELINS DELFOR02 Liefer-/Feinab. f. Zul.
BA DELJIT DELFOR02 Lieferfeinabruf für Zul. E1 Anlieferung LPJ1 ME13
AG DESADV DELVRY03 Lieferung: Lieferavis V2 Versand LALE Lieferavis an AG DELV Lieferung DELVRY01: DESADV/CARNOT/WHSORD/SHPORD
GSVERV GSVERF03 Gutschriftsverfahren
RE INVOIC INVOIC01 Rechnung / Faktura V3 Fakturierung (ZRDE, ZATE) SD09
AG ORDCHG ORDERS05 Bestell-/Auftragsänd. EF Eink. Bestellung (ZEDI) ME11
LF ORDERS ORDERS05 Einkauf/Verkauf EF Eink. Bestellung ZEDI ME10 ME10 : ORDERS: Bestellung
LF ORDRSP ORDERS05 Einkauf/Verkauf V1 Verkauf ZEDI Auftragsbestätigung SD10 ORDRSP Bestellbestätigung
LF REQOTE ORDERS05 Anfrage / Inquiry EA Einkauf Anfrage NEU Neu ME12 REQOTE: Anfrage
LF STPPOD DELVRY03 Empfangsbest. (POD) E1 Anlieferung OPOD OPOD

Für ein logisches System ist die Partnerrolle immer 'LS'

Eingangsparameter
Partnerart Nachrichtentyp Nachr.variante V.Code Text
-- DELFOR Lieferabruf für Zulieferer
-- DELINS DELI Lieferabruf/Feinabruf für Zulieferer
-- DELJIT Lieferfeinabruf für Zulieferer
-- DESADV DELS Lieferavis (DESADV mit DELVRY01)
-- DESADV DESA Lieferavis (DESADV mit DESADV01)
-- GSVERV GSVE Gutschriftsverfahren
-- INVOIC IV01 BBPIV Eingangsrechnung
-- ORDCHG ORDC Bestell-/Auftragsänderung
-- ORDERS ORDE Bestellung / Auftrag
-- ORDRSP ORDR ORDRSP Bestellbestätigung
-- STPPOD Empfangsbestätigung (POD)

Partner-Mapping

Das Partner-Mapping kann über die Tabelle KNVK, über die Geschäftspartner (Business-Partner-Tabellen BUT000 und BUT0ID) oder kundenzpezifisch nach einer vom Kunden anzugebenden Logik erfolgen.

In der Folge werden die notwendigen Schritte für 'KNVK-Mapping' bzw. 'GP-Mapping' beschrieben.

 

Partner-Mapping über KNVK

KNVK-Mapping: Ansprechpartner ZEDI anlegen

Notwendig, wenn entweder in der Steuertablle /EPO1/ECOSIO_UNB (="UNB-Logik") oder in den Steuertabellen /EPO1/ECOSIO_BPO bzw. /EPO1/ECOSIO_BPI (="BP-Logik") der Tabellenname KNVK eingetragen ist.

Transaktion SPRO (DE):

  • Vertrieb
  • Stammdaten
  • Geschäftspartner
  • Ansprechpartner
  • Standardabteilungen definieren

Bzw. bei Sprache EN:

  • Sales and Distribution
  • Master Data
  • Business Partners
  • Contact Person
  • Define Standard Departments

Neuen Eintrag definieren:

  • Name: ZEDI
  • Bezeichnung: EDI identifier
ClipCapIt-161111-161625.PNG

Speichern


Dann noch die Funktionen der Ansprechpartner:

  • Funktionen Ansprechpartner definieren / Define Contact Person Functions


a) Mapping mit BP-Logik: neuen Eintrage definieren:

  • Funktion: ZS
  • Beschreibung: EDI Standard Partner


b) Mapping mit alter UNB-Logik: neue Einträge definieren:

  • Funktion: ZI
  • Beschreibung: Standard In EDI
  • Funktion: ZS
  • Beschreibung: Standard Out EDI
ClipCapIt-161205-163841.PNG
KNVK-Mapping: Pflege der Kunden-Lieferantenansprechpartner

Für das UNB-Mapping (kann entfallen, wenn die Tabelle /EPO1/ECOSIO_UNB nicht gepflegt ist bzw. eine eigenständige Lösung in der abgeleiteten Klasse implementiert wird).

Standardmäßig wird für das Mapping bei jedem angebundenen Kunden/Lieferanten ein Dummy-Ansprechparter 'ZEDI' hinterlegt und im Namen die UNB-ID (lt. ECOSIO) eingetragen.

Eine vollständige Liste der zugehörigen Partner findet sich in XD02/XK02 unter Vertriebsbereich, Partnerrollen

Kunden

Transaktion XD02, Reiter 'Ansprechpartner', einfügen:

  • Name = (Bezeichnung lt. ECOSIO)  !!der Name steht in der 1. Spalte!!
  • Abteilung: ZEDI
ClipCapIt-161111-160653.PNG

Sichern

Lieferanten (auch: Spediteure)

Transaktion XK02, Checkbox 'Ansprechpartner' markieren

ClipCapIt-161111-160408.PNG
  • Name = (Bezeichnung lt. ECOSIO)  !!der Name steht in der 2. Spalte!!
  • Abteilung: ZEDI
ClipCapIt-161111-160429.PNG

Sichern

Customizing: Ansprechpartner einblenden

Es kann vorkommen, daß in der Transaktion XK02 die Checkbox 'Ansprechpartner' nicht aufscheint - muß im Customizing (nach Rückfrage, ob erlaubt..) eingestellt werden:

Transaktion SPRO
Finanzwesen
Debitoren- und Kreditorenbuchhaltung
Kreditorenkonten
Stammdaten
Anlegen der Kreditorenstammdaten vorbereiten
  • Bildaufbau pro Aktivität definieren

Anzeigen Kreditor (Zentral) -> für XK03, Ändern Kreditor (Zentral) -> für XK02

  • Doppelklick auf 'Allgemeine Daten'
  • Doppelklick auf 'Ansprechpartner'
  • von 'Ausblenden' nach 'Kanneingabe' ändern
  • speichern


Gegebenenfalls auch für die Kontengruppe zumindest auf Kanneingabe schalten XK03: Zusätze | Verwaltungsdaten -> Anzeige der Kontengruppe

Transaktion SPRO
Finanzwesen
Debitoren- und Kreditorenbuchhaltung
Kreditorenkonten
Stammdaten
Anlegen der Kreditorenstammdaten vorbereiten
  • Kontengruppe mit Bildaufbau definieren (Kreditoren)
  • Doppelklick auf die zu ändernde Kontengruppe
  • Doppelklick auf 'Allgemeine Daten'
  • Doppelklick auf 'Ansprechpartner'
  • von 'Ausblenden' nach 'Kanneingabe' ändern
  • speichern

Mapping über Geschäftspartner (Business Partner )

Notwendig in S/4-Systemen (ab SAP_BASIS = 751), bzw. auch in R/3, wenn das UNB-Mapping über die Geschäftspartner angewendet wird.


Customizing: Identifikationsnummern ZKU, ZKUD, ZLI, ZLID anlegen

Transaktion SPRO (DE):

  • Anwendungsübergreifende Komponenten
  • SAP-Geschäftspartner
  • Geschäftspartner
  • Grundeinstellungen
  • Identifikationsnummern
  • Identifikationstypen definieren:
ID-Typ Bezeichnung ID Eindeutig Alpha
ZKU EDI Identifier Kunde X X
ZKUD EDI Identifier Kunde (Default) X X
ZLI EDI Identifier Lieferant X X
ZLID EDI Identifier Lieferant (Default) X X
  • Identifikationsarten definieren:
ID-Art Bezeichnung ID-Typ Organisationen
ZKU EDI Identifier Kunde ZKU X
ZKUD EDI Identifier Kunde (Default) ZKUD X
ZLI EDI Identifier Lieferant ZLI X
ZLID EDI Identifier Lieferant (Default) ZLID X

Bzw. bei Sprache EN:

  • Cross-Application Components
  • SAP Business Partner
  • Business Partner
  • Basic Settings
  • Identification Numbers
  • Define Identification Categories
  • Define Identification Types

 

GP-Mapping: Identifikationsnummern zuordnen

Standard: ID-Art ZKU bzw. ZLI vergeben; nur, wenn Mehrdeutigkeiten notwendig sind, muß eine ID mit ZKUD/ZLID definiert sein. Diese ID gilt dann mit höherer Priorität.

Transaktion BP, Kunden-/Lieferantennummer eingeben

  • Reiter 'Technische Identifikation' (ganz rechts)
  • neue Zeile eintragen:
  • ZKU / ZKUD für Kunden,
  • ZLI / ZLID für Lieferanten eingeben
  • die ID kommt in die Spalte Technische Identifikationsnummer

Set-up Inbound IDOCs

Optionen push oder fetch

Inbound IDOCs werden entweder mit der Operation push von ecosio.com an SAP geliefert oder mit der Operation fetch von SAP aus bei ecosio.com abgeholt.

In beiden Fällen wird der Fuba /EPO1/ECOSIO_PROC_IDOC_IN zur Verarbeitung aufgerufen.

Die Operationen store_xml_full und store_xml_single müssen wie hier abgebildet eingestellt sein.

Die Operation store_xml_full speichert das XML Dokument, welches aus dem JSON Element "message" mittels base64 Decoding ermittelt wird.

Die Operation store_xml_single speichert jedes einzelne IDOC XML. In einem XML Dokument aus "message" können 1 bis n IDOC XML enthalten sein.

ClipCapIt-161008-133019.PNG

Operation push

Hier wird der SICF Handler epo1soa/ecosio und das im EPO Connector konfigurierte Service ecosiosap, Operation push mit dem Fuba /EPO1/ECOSIO_JSON_PROCESSING verwendet.

Nach der Installation ist zu überprüfen, dass in Transaktion SICF der Handler ecosio aktiv ist:

ClipCapIt-161008-124919.PNG

Weiters muss das EPO Connector Inbound Service ecosiosap mit der Operation push angelegt sein:

ClipCapIt-161008-125106.PNG
ClipCapIt-161008-125155.PNG
ClipCapIt-161008-125218.PNG
ClipCapIt-161008-125257.PNG

Operation fetch

Oder sie werden mit der Operation fetch mittels des SAP Programms /EPO1/EXC_ECOSIO_FETCH von ecosio.com abgeholt. Der SAP User benötigt die Berechtigung B_ALE_RECV.

Für dieses Programm ist ein Job einzurichten, der periodisch nach neuen Nachrichten bei ECOSIO nachfragt. Die Periodendauer ist üblicherweise im Bereich 15..60 Minuten.

Ableiten der Klasse /EPO1/CL_EXC_ECOSIO_XML_IN

Die Basisklasse /EPO1/CL_EXC_ECOSIO_XML_IN ist ohne weitere Änderungen einsatzfähig. Bei speziellen Anforderungen kann sie abgeleitet werden (z.B. Z_CL_ECOSIO_IN). Alle Methoden, die mit dem Prefix 'UE_' beginnen, können durch Redefinitionen ersetzt werden. Andere Methoden sollen nicht verändert werden.

Eine Redefinition ist optional möglich für:

  • UE_INSERT_MESSAGE_ID
    Die ecosio - Message-ID wird in den Steuersatz des IDOCs in das Feld ARCKEY (Tabelle EDIDC) eingetragen und mit dem String @ecosio beendet (Feld Identification)
  • UE_PARTN_UNB_MAPPING
    Hier wird das Mapping der UNB-IDs auf KUNNR bzw. LIFNR für die Partner AG, LF, RE, RG und WE durchgeführt
  • UE_SENDER_UNB_MAPPING
    Die UNB-ID des SENDERs (im HEADER) wird auf eine Partnernummer (KUNNR bzw. LIFNR) gemappt
  • UE_SET_RESPONSE
    Normalerweise wird ein leerer JSON-Response '{}' zurückgesendet
  • UE_SINGLE_IDOC_PREPROCESSING
    Für bestimmte Nachrichtentypen wird an dieser Stelle ein fehlerhaftes UNB-Mapping korrigiert
  • UE_SPLIT_MESSAGES
    Hier wird eine einkommende XML-Nachricht auf einzelne IDOCs aufgespaltet


Methode /EPO1/CL_EXC_ECOSIO_XML_IN->UNIT_PROCESS

Die Methode UNIT_PROCESS behandelt eine komplette, eingehende Nachricht:

  • Sender - UNB-ID mappen
  • ecosio - MessageID in die Nachricht einfügen
  • Nachricht in einzelne IDOCs aufsplitten
  • vereinzelte IDOCs abarbeiten

Steuertabelle pflegen

Wenn eine abgeleitete Klasse erstellt wurde, so muß sie im Customizing hinterlegt werden. Das Eintragen der Basisklasse ist nicht notwendig (stört aber auch nicht):
Transaktion SM30, Tabelle /EPO1/ECOSIO_IN

Für das eingehende Service (ecosiosap) muß der Name der abgeleiteten Klasse eingetragen werden:

ClipCapIt-161213-132910.PNG

Sichern, die Einträge werden in einem Transportauftrag hinterlegt.

Inbound Idoc Verarbeitung

Der Fuba /EPO1/ECOSIO_PROC_IDOC_IN liest zuerst die Klasse aus. Ist keine "Z-Klasse" in Tabelle /EPO1/ECOSIO_IN eingetragen, wird die Klasse /EPO1/CL_EXC_ECOSIO_XML_IN verwendet.

ClipCapIt-161008-131941.PNG

Die Hauptmethode in der gewählten Klasse ist UNIT_PROCESS


Laufzeitfehler im Fuba IDOC_INBOUND_XML_SOAP_HTTP

Sollte nicht sein, ist aber schon 2x aufgetreten: hier könnte ein Code stehen, der eine bestehende IDOC-Nummer erwartet (obwohl das IDOC erst erzeugt werden soll). Als Folge wird eine Exception ausgelöst:
"Eine Exception vom Typ CX_SY_RANGE_OUT_OF_BOUNDS ist aufgetreten.."

Korrektur: siehe SAP-Note 2907319, bzw. Modifikation im Include LEDINF10, vor der Zeile 886 kann man die IDOC-Nummer mit einem Dummywert befüllen:

l_edi_dc40-docnum = '0000000000000000'.

So sieht (sah) der fehlerhafte Code aus:

ClipCapIt-210315-122848.PNG

Fetch - Programm als Job einplanen

Nur für FETCH notwendig, nicht für PUSH!!

Variante erstellen
  • Transaktion SE38 oder SE80 starten und den Report /EPO1/EXC_ECOSIO_FETCH starten
  • Radiobutton 'fetch' selektieren
  • Checkbox 'Testmode' deselektieren
  • diese Einstellungen als Variante speichern (z.B. Name 'BATCH')
  • testweise den Report laufen lassen - ein gutes Ergebnis enthält keine Fehlermeldungen und schaut etwa so aus:
    ClipCapIt-170124-142809.PNG
  • in der EPO-Liste enthält der Response einen JSON-formatierten String:
    ClipCapIt-170124-143619.PNG


Job einplanen
  • Transaktion sm36
  • Jobname: z.B. ECOSIO_FETCH
  • Startbedingung: Uhrzeit angeben und Periode definieren (so im Bereich 15 Minuten bis 1 Stunde)
  • Step hinzufügen: Report /EPO1/EXC_ECOSIO_FETCH und den zuvor vergebenen Variantennamen
  • Druckangaben:
  • Ausgabegerät: LOCL
  • Titel: ECOSIO EDI fetch
  • Verweildauer: 8 (löschen nach 8 Tagen)
  • Druckzeitpunkt: in den Spool (NICHT sofort drucken lassen)
  • kein Selektionsdeckblatt
  • speichern und schließen


Fehlermöglichkeiten

  • ICH_HTTP_CONNECTION_ERROR - es konnte keine Verbindung zum Server aufgebaut werden. Wenn die Verbindung in der SM59 funktioniert hat, sind die Verbindungseinstellungen für den EPO-Connector falsch (z.B. falscher Servername/falscher Port, fehlender Proxy, etc.)
  • ICM_HTTP_INTERNAL_ERROR - wahrscheinlich stimmen UserId/UserKey nicht. Tritt die FM bei der SM59 auf, dann ist möglicherweise STRUST nicht ausgeführt worden (Server-Zertifikat).
  • Der Response lt. EPO-Listanzeige einen Inhalt ähnlich wie at.erpel.messaginghub.services.heans.FetchEntryResponse@3f59b9e5 - fehlt der 'Content Type' in der Servicekonfiguration bzw. in den HTTP-Header - Einstellung
  • FORBIDDEN - es konnte eine Verbindung zum Server aufgebaut werden, aber entweder fehlen die ecosio Zugangsdaten oder sie sind fehlerhaft.
  • Transformation /EPO1/ECOSIO_MESSAGES: Kein gültiger Quellkontext angegeben Diese Meldung weist darauf hin, dass die Transformation in Methode ue_sender_unb_mapping_bp ein Problem hat. In einem Fall war m_idoc_message einfach leer. Das kann daran liegen, dass ecosio tatsächlich Schrott liefert (z.B EDIFACT statt IDOC) oder dass wir nichts lesen konnten, weil der Zugriff nicht funktioniert (siehe nächster Punkt)
  • Bei Nachschau in der /EPO1/EXC Protokoll-Liste zeigt sich die ecosio-Meldung {"failure":{"errorCode":"104","reason":"USER_NOT_PERMITTED","details":"User is not permitted access to the requested document!","reference":""}} Ursache war hier eine falsche UUID von ecosio vergeben.
  • In Operation callback (Outgoing) steht z.B. folgender Text: "Keine Berechtigung zum Senden von IDocs des Nachrichtentyps ORDERS". Das liegt womöglich an zu geringen Rechten des Users, der das Fetch-Programm ausführt.

Job für Inbound IDOCs

Eingehende IDOCs werden nicht immer gleich verarbeitet, auch wenn dies in der Partnervereinbarung so gewünscht ist. Dieser Job sorgt dafür, daß IDOCs, die an die Applikation übergeben werden können, auch gleich verarbeitet werden. Wenn bereits ein FETCH - Job eingerichtet wird/wurde, kann dort auch ein 2. Step eingefügt werden (dann läuft halt nur 1 Job und nicht 2).


Variante erstellen
  • Transaktion SE38 oder SE80 starten und den Report RBDAPP01 starten
  • Alle Felder unverändert lassen (damit werden alle IDOCs selektiert)
  • Variante speichern (z.B. Name 'BATCH_ALLE')


Job einplanen
  • Transaktion sm36
  • Jobname: z.B. IDOC_EINGANG_ALLE
  • Startbedingung: Uhrzeit angeben und Periode definieren (entweder kurz nach dem FETCH - Job, oder alle paar Minuten)
  • Step hinzufügen: Report RBDAPP01 und den zuvor vergebenen Variantennamen
  • Druckangaben:
  • Ausgabegerät: LOCL
  • Titel: IDOC Eingang verarbeiten
  • Verweildauer: 8 (löschen nach 8 Tagen)
  • Druckzeitpunkt: in den Spool (NICHT sofort drucken lassen)
  • kein Selektionsdeckblatt
  • speichern und schließen

Fehlersuche / Korrektur

der Zusammenhang der Daten

Eingehende Nachrichten werden je nach den Einstellungen des EPO-Connectors sofort gespeichert. Allgemeine Informationen stehen in der Tabelle /EPO1/XMLHEAD, hier die wichtigsten Felder:

Feld Inhalt
TRANSACTIONID die EPO - Transaktions-ID (lt. Nummernkreisobj.)
MESSAGEDIRECTION I - eingehend, O - ausgehend
NORANGENO Nummernkreis-Objekt
SERVICE EPO - Service (z.B. 'sapecosio_<sysid>')
OPERATION Operation (z.B. 'fetch')
STATUS 50 = gespeichert, 53 = OK, 54 = Fehler
FKEY1 ECOSIO - Message ID
FKEY2 Nachrichtentyp
FKEY3 IDOC - Nummer (wenn ein IDOC angelegt wurde)

Einkommende Nachrichten werden unter jener Operation abgelegt, unter der sie abgerufen wurde (z.B. 'fetch' oder 'push').

Der Inhalt der Nachricht wird unter der Operation 'xml_store_full' abgelegt (d.h. der Inhalt in XML-Format).

Inhalte von extrahierten (vereinzelten) IDOCs werden unter der Operation xml_store_single' abgelegt, diese Einträge werden zu IDOCs umgewandelt, und nur diese bekommen die IDOC-Nummer im Feld FKEY3 eingetragen. Hier ist der Status interessant, der beim Anlegen eines IDOC gesetzt wird.

fehlendes UNB-Mapping

Symptom: eingehende IDOCs haben den Status 'EDI: Partnervereinbarung nicht vorhanden' (Transaktion BD87):

ClipCapIt-161111-170812.PNG

Kontrolle des IDOC - Steuersatzes:

ClipCapIt-161111-170900.PNG

Das Mapping konnte nicht durchgeführt werden, die UNB-ID ist keinem Kunden/Lieferanten zugeordnet.

Wenn das Mapping allerdings funktioniert hat und die Partnernummer ausgefüllt ist, so fehlt die entsprechende Partnervereinbarung für die Kombination Kunden/Lieferanten | Partnerart | Nachrichtentyp (siehe Transaktion WE20).


Lösungsweg:

  • UNB-ID Mapping für den Partner pflegen
  • alle betroffenen IDOCs manuell in der Transaktion WE19 öffnen, korrigieren (richtige Kunden-/Lieferantennummer eintragen)
ClipCapIt-161111-171259.PNG
  • Status auf 30 rücksetzen und nochmals verarbeiten lassen

Fehlersuche eingehendes IDOC - Rezept

Transaktion BD87

ClipCapIt-161111-171629.PNG

fehlerhaftes IDOC selektieren und anzeigen lassen:

ClipCapIt-161111-171647.PNG

..die Partnernummer (lt. UNB-Mapping) wurde nicht gezogen. Warum nicht? Kontrollsatz anzeigen:

ClipCapIt-161111-171827.PNG

Im Feld 'Identifizierung' steht die EPO-Transaktionsnummer, anhand derer die eingehende Nachricht im EPO-Monitor kontrolliert werden kann.


Welche Felder wurden für das Mapping herangezogen?

alte Logik (obsolet)

Transaktion SE16, Tabelle /EPO1/ECOSIO_UNB, Selektion MESTYP = DESADV (lt. Nachrichtentyp des IDOC). Im Ergebnis ist z.B.

CMP_VALUE WE
TRANS_NAME /EPO1/ECOSIO_RECEIVER_DESADV

Kontrolle der Transformation in der Transaktion STRANS

ClipCapIt-161111-172421.PNG


Zusammen heißt das: das Partner-Feld ist PARVW im Segment E1EDKA2, der Wert (lt. CMP_VALUE) muß WE sein, die LIFNR bzw. KUNNR wird aus dem Feld PARTN im gleichen Segment genommen.

BP-Logik

Klasse /EPO1/CL_EXC_ECOSIO_XML_IN, bzw. eine davon abgeleitete Klasse (gemäß Tabelle /EPO1/ECOSIO_IN)

Methode UE_SENDER_UNB_MAPPING_BP
  • Auslesen der Absender-Daten mit der Transformation /EPO1/EXC_ECOSIO_GET_SENDER: SENDER (die ecosio ID) und SNDPRT (der Partnertyp - KU oder LI)
Methode UNB_MAPPING_BP
  • lesen der Steuerinformation aus Tabelle /EPO1/ECOSIO_BPI, abarbeiten entsprechend der Priorität

Im Ergebnis ist z.B.

PRIO 0
MAPPING_TABLE KNVK
SEARCH_FIELD NAME1
RESULT_FIELD KUNNR
PRIO_FIELD PAFKT
PRIO_VALUE ZS
WHERE_VALUE ABTNR = 'ZEDI'

Daraufhin wird in der Tabelle KNVK im Feld NAME1 die Kundennummer gesucht, eingeschränkt auf die Abteilung 'ZEDI'. Das Mapping-Ergebnis finden wir im Feld KUNNR.

Falls es mehrere Treffer gibt, wird jene Zeile bevorzugt, die im Feld PAFKT den Wert ZS stehen hat.

Methode UE_SENDER_UNB_MAPPING_BP
  • der übersetzte Wert (Kundennummer/Lieferantennummer) wird über die Transformation /EPO1/EXC_ECOSIO_SET_SENDER in das Feld <SNDPRN> zurückgeschrieben (das ist der Steuersatz der IDOCs).

Daten des eingehenden IDOC suchen

Transaktion /EPO1/EXC, EPO Connector Daten, Liste Nachrichten und Anzeige der Nachrichten

TransaktionsID (lt. Beispiel: z.B. 1955) eingeben, Selektion ausführen. In der Ergebnisliste nach rechts scrollen bis zum Fremdschlüssel 1 (das ist die ECOSIO-MessageID), diesen markieren und in die Zwischenablage kopieren.

Zurück zur Selektion, die TransaktionsID aus der Eingebe löschen und den Fremdschlüssel 1 aus der Zwischenablage befüllen. Nun werden alle Messages zu dieser MessageID angezeigt.

Die lesbaren Daten stehen in den Zeilen mit der Operation store_xml_full (gesamte Nachricht, alle IDOCs) bzw. store_xml_single (einzelne IDOCs). In den Zeilen mit der Operation push sind die Daten auch enthalten, aber Base64 codiert und daher nicht direkt lesbar:

ClipCapIt-161114-125337.PNG


Mit einem Doppelklick auf die Zeile öfnet sich die XML-Ansicht der eingehenden Nachricht, hier muß nun der entsprechende Datenblock gesucht werden (im Beispiel ist das das Feld PARVW im Segment E1EDKA2, welches den Wert 'WE' haben muß):

ClipCapIt-161114-125535.PNG


Der zugehörige Wert des Feldes PARTN ist die UNB-ID, zu der kein Mapping gefunden wurde.

Kontrolle des UNB-ID Mappings: Transaktion SE16, Tabelle KNVK, Selektion nach

  • NAME = DE01 (lt. Beispiel)
  • KUNNR = nicht leer (weil eine Kundennummer gesucht wird, andernfalls muß LIFNR nicht leer sein)
ClipCapIt-161114-130626.PNG


Es muß genau ein Ergebnis mit gefüllter KUNNR/LIFNR geben. Andernfalls sind die Ansprechpartner in den Kunden-/Lieferantendetails zu korrigieren.

IDOC erneut verarbeiten

Nach der Korrektur der Kunden-/Lieferantendaten kann das IDOC in der Transation BD87 erneut verarbeitet werden.

 

eingehende Nachricht nochmals verarbeiten

Bei FETCH ist das ganz einfach: mit dem Report /EPO1/EXC_ECOSIO_FETCH kann eine abgeholte Nachricht nochmals verarbeitet werden (!!! nicht im Produktivsystem.. da werden neue IDOCs erzeugt !!!), 'Verwende Daten aus SAP' mit der Nachrichten-ID; Testlauf deaktivieren.

Bei PUSH muß der Status der eingehenden Nachricht in der Transaktion /EPO1/EXC unter EPO Connector Administration/Status von Nachrichten manuell setzen die eingehende Nachricht auf den Status 50 gesetzt werden.

Anschließend mit EPO Connector Daten/Inbound Nachrichten (Ext->SAP)/In: Ausführen einer Nachricht mit EPO Runtime nochmals ausführen. Lt. Customizing den aufgerufenen Funktionsbaustein debuggen (für PUSH ist der Standard /EPO1/ECOSIO_JSON_PROCESSING).

 

Outbound - IDOC - Beispiel

(dummy-Beispiel)

ClipCapIt-161201-112645.PNG

Die wichtigsten Merkmale des IDOC-XML:

  • im epo:HEADER ist der Absender und der Empfänger (UNB-ID) sowie der ECOSIO-Dokumententyp hinterlegt
  • der eigentliche IDOC - Abschnitt ist mit dem kundenspezifischen Namespace versehen
  • im Feld REFINT wurde die Interchange-Referenz eingefügt

Inbound - IDOC - Beispiel

(dummy-Beispiel)

ClipCapIt-161114-133943.PNG

Die wichtigsten Merkmale des IDOC-XML:

  • der epo:HEADER
  • Sender hat im Feld SNDPRT den Wert 'KU', d.h. das UNB-Mapping sucht eine KUNNR
  • die Liste der Partner - die Auswertung erfolgt lt. verknüpfter Transformation und Steuerinformation der Tabelle /EPO1/ECOSIO_UNB

Falscher Pfad

Fehlermeldung mit Status 04: "ECOSIO communication: missing message-id: (see EPO log)", zeigt in den "EPO Connector Daten" die Meldung "HTTP/1.1 405 Method Not Allowed". In den Metadaten der Sendung sieht man dann eventuell einen falschen Pfad im Feld URI: "https://api.test.ecosio-hub.com:443/api/v1/fetch/delivery" Hier etwa ist ein "/fetch" zu viel, und diesen Pfad kennt ecosio nicht.

UNB-ID / Partner - Mapping, Ablauf

Das Mapping der sogenannten UNB-ID hat die Aufgabe, ein bestimmtes Feld im Idoc herauszulesen, das den Receiver bezeichnet, und danach für diesen Partner (= Kunde oder Lieferantennummer) die zugehörige ID (GLN, DUNS, UID, etc.) zu ermitteln. Es geschieht wie folgt:

In den Basisklassen /EPO1/CL_EXC_ECOSIO_XML_OUT oder /EPO1/CL_EXC_ECOSIO_XML_IN wird das Mapping mit Hilfe der Steuertabelle /EPO1/ECOSIO_UNB bzw. /EPO1/ECOSIO_BPO und /EPO1/ECOSIO_BPI umgesetzt.

Für R/3 gilt: Auf SAP-Seite wird das Mapping über einen Ansprechpartner der Gruppe 'ZEDI' zum jeweiligen Kunden/Lieferanten gefunden, abgelegt in der Tabelle KNVK im Feld NAME1.

Für S/4 gilt: Das Mapping passiert mit Hilfe der Views /EPO1/ECOISO_BPC und /EPO/ECOSIO/BPV. Voraussetzung ist, dass die erforderlichen ID-Nummern der Business-Partner in der Tabelle BUT0ID mit den ID-Typen ZKU, ZKUD (für Kunden) sowie ZLI und ZLID (für Lieferanten) gepflegt sind.

KNVK-Mapping (alt-nicht mehr verwenden - unsaubere Logik)
In der Customizingtabelle /EPO1/ECOSIO_UNB sind pro Nachrichtenart (und Priorität) Informationen hinterlegt, die einerseits steuern, welches Feld der ausgehenden IDoc-Nachricht herangezogen wird um den Receiver der Nachricht zu ermitteln, und andererseits bei einer eingehenden Nachricht aus der Sender-ID die SAP-Kundennummer bzw. die SAP-Lieferantennummer zu ermitteln.

  • Partnerrolle im IDoc (CMP_VALUE)
  • ID-Tabelle, die die ID enthält (im R/3 normalerweise KNVK)
  • Feld in der ID-Tabelle (KUNNR bzw. LIFNR in der KNVK) für ausgehende Nachrichten; bei eingehenden Nachrichten wird KUNNR/LIFNR vertauscht
  • Name der Transformation zum Extrahieren der Partnerinformation (z.B. /EPO1/ECOSIO_RECEIVER_INVOIC für Message-type INVOIC)

GP-Mapping (neu seit Version 2.7)
In den neuen Customizingtabellen /EPO1/ECOSIO_BPO und /EPO1/ECOSIO_BPI kann das KNVK-Mapping und das GP-Mapping sauber abgebildet werden. Sauber bedeutet: es gibt getrennte Tabellen für Inbound/Outbound - Mapping und somit keine impliziten Feld-Vertauschungen bei eingehenden Nachrichten.

Die Umschaltung auf GP-Mapping erfolgt über die Tabelle /EPO1/ECOSIO_DEF

In der Customizingtabelle /EPO1/ECOSIO_BPO sind pro Nachrichtenart (und Priorität) dei Steuerinformationen für das Mapping des Empfängers hinterlegt

  • Partnerrolle im IDoc (CMP_VALUE)
  • Mappingtabelle (im R/3 normalerweise KNVK, für S/4 die Views /EPO1/ECOSIO_BPV für Lieferanten oder /EPO1/ECOSIO_BPC für Kunden)
  • das Feld, welches die SAP-Kunden-/Lieferantennummer enthält (KNVK: KUNNR bzw. LIFNR, GP: CUSTOMER oder VENDOR)
  • das Feld, welches die ID enthält (KNVK: NAME1, GP: IDNUMBER)
  • der PRIO-Feldname, der bei mehrdeutigen Treffern eine Selektion auf einen eindeutigen Datensatz ermöglicht
  • der zugehörige PRIO-Wert
  • eine zusätzliche WHERE - Bedingung für die Selektion
  • Name der Transformation zum Extrahieren der Partnerinformation (z.B. /EPO1/ECOSIO_RECEIVER_INVOIC für Message-type INVOIC)

In der Customizingtabelle /EPO1/ECOSIO_BPI sind pro Partnerart (KU, LI oder LS) die Steuerinformation für das Mapping des Absenders hinterlegt

  • Mappingtabelle (im R/3 normalerweise KNVK, für S/4 die Views /EPO1/ECOSIO_BPV für Lieferanten oder /EPO1/ECOSIO_BPC für Kunden)
eine leerer Tabellenname bedeutet, daß kein Mapping durchgeführt wird (ohne Fehlermeldung); notwendig für Partnerart = LS
  • das Feld, welches die ID enthält (KNVK: NAME1, GP: IDNUMBER)
  • das Feld, welches die SAP-Kunden-/Lieferantennummer enthält (KNVK: KUNNR bzw. LIFNR, GP: CUSTOMER oder VENDOR)
  • der PRIO-Feldname, der bei mehrdeutigen Treffern eine Selektion auf einen eindeutigen Datensatz ermöglicht
  • der zugehörige PRIO-Wert
  • eine zusätzliche WHERE - Bedingung für die Selektion


KNVK - Beispiel einer Tabellenzeile /EPO1/ECOSIO_UNB (für ausgehende Nachrichten):

Nachrichtentyp Priorität Part.verw. Tabelle Feld Transformation
DELFOR 0 LF KNVK LIFNR /EPO1/ECOSIO_RECEIVER_DELFOR
  • Zur Nachrichtenart DELFOR wird die Transformation /EPO1/ECOSIO_RECEIVER_DELFOR aufgerufen, um die Partnerinformationen zu extrahieren
  • wir benötigen die Partnernummer zur Partnerverwendung 'LF'
  • In der Tabelle 'KNVK', Feld 'LIFNR' wird nach der Partnernummer gesucht (mit Einschränkung: ABTNR = 'ZEDI')

Im R/3 muss die UNB-ID für den Partner im Feld NAME1 der Tabelle KNVK hinterlegt sein.

Die Priorität erlaubt es, für eine Nachrichtenart unterschiedliche Mapping-Methoden zu hinterlegen, die der Reihe nach (beginnend mit der niedrigsten Nummer) abgearbeitet werden - bis ein Treffer erzielt wird.


KNVK- und GP - Beispiel einer Tabellenzeile /EPO1/ECOSIO_BPO (für ausgehende Nachrichten):

Nachrichtentyp Priorität Tabelle Suchfeld Ergebnisfeld Part.verw. Prio-Feld Prio-Wert WHERE Transformation
ORDERS 0 /EPO1/ECOSIO_BPV VENDOR IDNUMBER LF TYPE ZLID XDELE = '' AND TYPE IN ('ZLI', 'ZLID') /EPO1/ECOSIO_RECEIVER_ORDERS
ORDERS 1 KNVK LIFNR NAME1 LF PAFKT ZS ABTNR = 'ZEDI' /EPO1/ECOSIO_RECEIVER_ORDERS

GP-Mapping:

  • Zur Nachrichtenart OPDERS wird die Transformation /EPO1/ECOSIO_RECEIVER_ORDERS aufgerufen, um die Partnerinformationen zu extrahieren
  • wir benötigen die Partnernummer zur Partnerverwendung 'LF'
  • Im View '/EPO1/ECOSIO_BPV', Feld 'VENDOR' wird nach der Partnernummer gesucht (mit der WHERE-Einschränkung: ABTNR = 'ZEDI')
  • die ID steht im Feld IDNUMBER
  • bei mehrfachen Treffern wird jene Zeile gewählt, in der das Feld TYPE den Wert ZLID (=Default vendor) hat

KNVK-Mapping:

  • Zur Nachrichtenart OPDERS wird die Transformation /EPO1/ECOSIO_RECEIVER_ORDERS aufgerufen, um die Partnerinformationen zu extrahieren
  • wir benötigen die Partnernummer zur Partnerverwendung 'LF'
  • In der Tabelle 'KNVK', Feld 'LIFNR' wird nach der Partnernummer gesucht (mit der WHERE-Einschränkung: ABTNR = 'ZEDI')
  • die ID steht im Feld NAME1
  • bei mehrfachen Treffern wird jene Zeile gewählt, in der das Feld PAFKT den Wert ZS (=Standard-Abteilung) hat


Die Priorität erlaubt es, für eine Nachrichtenart unterschiedliche Mapping-Methoden zu hinterlegen, die der Reihe nach (beginnend mit der niedrigsten Nummer) abgearbeitet werden - bis ein Treffer erzielt wird.


Es ist folgender Ablauf des Mappings implementiert:

ausgehend, Klasse /EPO1/CL_EXC_ECOSIO_XML_OUT

  • lesen der Tabelle /EPO1/ECOSIO_DEF um die Art des Mappings (KNVK / GP) zu bestimmen
  • bei KNVK-Mapping:
  • Methode UE_GET_RECEIVER:
    Mapping des Empfängers (im Nachrichtenkopf) von Kunden-/Lieferantennummer auf UNB-ID
  • lesen der Tabelle /EPO1/ECOSIO_UNB nach dem Messagetyp
  • sortiert lt. PRIO folgende Schritte durchführen, bis eine UNB-ID gefunden wurde
  • Anwenden der Transformation lt. /EPO1/ECOSIO_UNB, auslesen der Partner-Informations-Liste
  • lt. Vergleichswert die richtige Partnernummer aus der Liste selektieren
  • Suche in der Vergleichstabelle (KNVK) entweder im Feld KUNNR oder LIFNR nach der Partnernummer, im Feld NAME1 muß die UNB-ID hinterlegt sein. Wenn mehrere 'ZEDI-Partner eingetragen ist, so hat der mit PAFKT = 'ZS' markierte Eintrag die höhere Priorität
  • bei GP-Mapping:
  • Methode UE_GET_RECEIVER_BP:
    Mapping des Empfängers (im Nachrichtenkopf) von Kunden-/Lieferantennummer auf UNB-ID
  • lesen der Tabelle /EPO1/ECOSIO_BPO nach dem Messagetyp
  • sortiert lt. PRIO folgende Schritte durchführen, bis eine UNB-ID gefunden wurde
  • Anwenden der Transformation lt. /EPO1/ECOSIO_BPO, auslesen der Partner-Informations-Liste
  • lt. Rolle die richtige Partnernummer aus der Liste selektieren
  • Suche in der angegebenen Tabelle im Suchfeld nach der Partnernummer, im Ergebnisfeld muß die UNB-ID hinterlegt sein. Wenn mehrere Partner gefunden werden, so hat jener Eintrag Priorität, dessen PRIO-Feld den PRIO-Wert enthält


Das folgende Mapping der anderen Partner erfolgt nur beim KNVK-Mapping

  • Methode UE_PARTN_UNB_MAPPING:
    Mapping der Partner in der Liste der Partner von Kunden-/Lieferantennummern auf UNB-IDs
  • auslesen der Liste Partnerverwendung/Partnernummer aus der ausgehenden XML-Nachricht
  • Reduktion der Liste auf die Partnerverwendungen 'AG', 'LF', 'RE', 'RG' und 'WE'
  • lesen der Tabelle /EPO1/ECOSIO_UNB nach dem Messagetyp (wichtig ist hier allerdings nur das Feld CMP_FIELD)
  • Mapping der Partnernummern lt. Tabelle KNVK nach LIFNR/KUNNR
  • Rückschreiben der erfolgreich gemappten Partner in die XML-Nachricht
  • Methode GET_REQUEST:
  • der vorbereitete Empfänger (UNB-ID) wird in den <epo:HEADER><epoheader:RECEIVER> eingetragen


eingehend, Klasse /EPO1/CL_EXC_ECOSIO_XML_IN

  • lesen der Tabelle /EPO1/ECOSIO_DEF um die Art des Mappings (KNVK / GP) zu bestimmen
  • bei KNVK-Mapping:
  • Methode UE_SENDER_UNB_MAPPING:
    Mapping der Absender - UNB-ID auf SAP-bekannte Kunden-/Lieferantennummer
    An dieser Stelle wird die Gesamtnachricht (incl. EPO-Header und allen Einzelnachrichten) verarbeitet.
  • auslesen der SENDER-UNB-ID aus der eingehenden Nachricht mit der Transformation /EPO1/EXC_ECOSIO_GET_SENDER nach M_SENDER
  • ECOSIO Version 1: <epo:HEADER><epo:SENDER>
  • ECOSIO Version 2: <epoheader:HEADER><epoheader:SENDER>
  • auslesen der Partnerart mit der Transformation /EPO1/EXC_ECOSIO_GET_SENDER aus dem EDI_DC40/SNDPRT-Segment nach M_SNDPRT
  • suche nach der Sender-UNB-ID in der Tabelle KNVK im Feld NAME1, oder in Views /EPO1/ECOSIO_BP* im Feld IDNUMBER.
  • auslesender zugehörigen Kunden-/Lieferantennummer (je nach M_SNDPRT) lesen (Abteilung = 'ZEDI', TYPE 'ZKU', 'ZKUD', 'ZLI', 'ZLID')
  • M_SNDPRT = 'KU': KNVK-KUNNR auslesen bzw. S/4: /EPO1/ECOSIO_BPC-CUSTOMER auslesen
  • M_SNDPRT = 'LI': KNVK-LIFNR auslesen bzw. S/4: /EPO1/ECOSIO_BPV-VENDOR auslesen
  • zurückschreiben der Kunden-/Lieferantennummer in die Nachricht mit der Transformation /EPO1/EXC_ECOSIO_SET_SENDER in das Element <EDI_DC40> <SNDPRN>
  • bei GP-Mapping:
  • Methode UE_SENDER_UNB_MAPPING_BP:
    Mapping der Absender - UNB-ID auf SAP-bekannte Kunden-/Lieferantennummer
    An dieser Stelle wird die Gesamtnachricht (incl. EPO-Header und allen Einzelnachrichten) verarbeitet.
  • auslesen der SENDER-UNB-ID aus der eingehenden Nachricht mit der Transformation /EPO1/EXC_ECOSIO_GET_SENDER nach M_SENDER
  • ECOSIO Version 1: <epo:HEADER><epo:SENDER>
  • ECOSIO Version 2: <epoheader:HEADER><epoheader:SENDER>
  • auslesen der Partnerart mit der Transformation /EPO1/EXC_ECOSIO_GET_SENDER aus dem EDI_DC40/SNDPRT-Segment nach M_SNDPRT
  • suche nach der Sender-UNB-ID in der Tabelle (lt. /EPO1/ECOSIO_BPI)
  • auslesender zugehörigen Kunden-/Lieferantennummer (je nach M_SNDPRT) lesen (Abteilung = 'ZEDI', TYPE 'ZKU', 'ZKUD', 'ZLI', 'ZLID')
  • M_SNDPRT = 'KU': KNVK-KUNNR auslesen bzw. S/4: /EPO1/ECOSIO_BPC-CUSTOMER auslesen
  • M_SNDPRT = 'LI': KNVK-LIFNR auslesen bzw. S/4: /EPO1/ECOSIO_BPV-VENDOR auslesen
  • zurückschreiben der Kunden-/Lieferantennummer in die Nachricht mit der Transformation /EPO1/EXC_ECOSIO_SET_SENDER in das Element <EDI_DC40> <SNDPRN>


  • Ablaufstruktur FETCH:
  • /EPO1/CL_EXC_ECOSIO_FETCH->PROCESS_IDOCS
    hier werden die per FETCH abgeholten Nachrichten abgearbeitet
  • Funktionsbaustein /EPO1/ECOSIO_PROC_IDOC_IN
    wählt lt. Nachrichtenart die Klasse für die Inbound - Bearbeitung und ruft UNIT_PROCESS auf
  • /EPO1/CL_EXC_ECOSIO_XML_IN->UNIT_PROCESS:
    macht das Mapping für den Sender und die Partner
  • /EPO1/CL_EXC_ECOSIO_XML_IN->UE_SENDER_UNB_MAPPING/->UE_SENDER_UNB_MAPPING_BP:
    Mapping Sender-UNB-ID auf Kunden-/Lieferantennummer im Header
  • /EPO1/CL_EXC_ECOSIO_XML_IN->UE_PARTN_UNB_MAPPING:
    Mapping der Partner-UNB-IDs auf Kunden-/Lieferantennummern in den Partner-Segmenten (nur beim KNVK-Mapping)
  • Meldungen vereinzeln und mit dem Funktionsbaustein /EPO1/ECOSIO_PROC_IDOC_SINGLE verarbeiten


Hinweis zur Fehlersuche beim Mapping - im EPO-Log
  • zusammengehörige ecosio-Nachrichten haben den gleichen FKEY1 im EPO-Log. Im IDOC steht diese ID im Steuersatz, Reiter 'Details', Feld 'Identification' (ARCKEY) - es gilt der Teil vor dem Suffix '@ecosio'
  • die originale Sender-ID findet man in der Originalnachricht der eingehenden 'fetch_message' - Operation (einmal im EPO-Header, noch einmal im EDI_DC40 - Segment). Dazu muss man den message-Teil der Nachricht mittels BASE64 - Decoder in ein XML umwandeln.
  • die gemappte Sender-ID findet man in der 'store_single - Operation im EDI_DC40 - Segment, Feld SNDPRN

Partnervereinbarung, WE20

Für die automatische IDOC-Verarbeitung (senden: Ermittlung des Ports, empfangen: ermittlung der Verarbeitungsroutine) muß die Partnervereinbarung für jede Anbindung konfiguriert werden.

Ausgangsparameter (Beispiel)

Ausgangsparameter Ausgangsoptionen Nachrichtensteuerung
Partnerrolle Nachrichtentyp Basistyp Text Applikation N.Art V.Code Text
SC, FA (EN) DELFOR DELFOR02 Lieferabruf für Zulieferer ## ## ## ##
BA, OA (EN) DELJIT DELFOR02 (Just-In-Time) Lieferfeinabruf für Zulieferer ## ## ## ##
AG, SP (EN) DESADV DELVRY07 Lieferung: Lieferavis V2 ZLDE DELV
WE, SH (EN) DESADV DESADV01 Lieferung: Lieferavis V2 Z001 SD05
LF, VN (EN) GSVERF GSVERF03 Cred. memo procedure MR ERS6 MRRL
INVOIC INVOIC02 Rechnung FI
LS INVOIC INVOIC02 Rechnung MM V3 ZSDI SD09
LF, VN (EN) ORDCHG ORDERS05 Bestell-/Auftragsänderung EF Eink. Bestellung NEU ME11 ORDCHG: Bestelländerung
LF, VN (EN) ORDERS ORDERS05 Einkauf/Verkauf EF Eink. Bestellung NEU ME10 ORDERS: Bestellung
AG, SP (EN) ORDRSP ORDERS05 Bestell-/Auftragsbestätigung EF Einkauf ZNEU Bestellung ME10 ####
LF, VN (EN) REQOTE ORDERS05 Anfrage / Inquiry EA Einkauf Anfrage NEU ME12 REQOTE: Anfrage
LF, VN (EN) STPPOD DELVRY07 Empfangsbestätigung (POD) - proof of delivery ## ## ## ##

Eingangsparameter (Beispiel)

Eingangsparameter
Partnerart Nachrichtentyp V.Code Text
-- DELFOR DELI DELINS Lieferabruf/Feinabruf für Zulieferer
-- DELINS DELI DELINS Lieferabruf/Feinabruf für Zulieferer
-- DESADV DELS Lieferavis (DESADV mit DESADV01)
-- DESADV DESA Lieferavis (DESADV mit DESADV01)
-- GSVERF GSVE GSVERF Gutschriftsverfahren
-- INVOIC INVF Rechnungseingang (Finanzbuchhaltung)
-- INVOIC INVL Logistik-Rechnungsprüfung (MM)
-- ORDCHG ORDC Bestell-/Auftragsänderung
-- ORDERS ORDE Bestellung / Auftrag
-- ORDRSP ORDR ORDRSP Purchase order confirmation

Erweiterung - Buchungskreisabhängige Services

Ab Version 2.8.1 ist es ist möglich, ausgehende Nachrichten abhängig vom Buchungskreis an unterschiedliche Endpunkte bei ECOSIO zu senden. Umgekehrt wird für jeden Endpunkt bei ECOSIO (ausgehendes Service in SAP) auch ein eingehendes Service eingerichtet. Folgende Punkte müssen dafür angepasst werden:

  • ein- und ausgehende Services komplett einrichten (d.h. passende Service-IDs und Servicenamen, UserID/UserKey, Service-URLs, ..)
  • Zum Auslesen des Buchungskreises aus einer ausgehenden Nachricht wird eine Transformation benötigt. Es sind die Transformationen /EPO1/ECOSIO_GET_WERKS und /EPO1/ECOSIO_GET_WERKS_INVOICE bereitgestellt, alternativ kann eine Z-Transformation erstellt werden; die (standard-)Ergebnisfelder der Transformation sind BUKRS (Buchungskreis), BELNR (Belegnummer -> führt zum Buchungskreis) oder WERKS (Werk).
  • Customizing der Tabelle /EPO1/ECOSIO_BKR:
  • für jeden Buchungskreis ist eine Zeile anzulegen, eine Zeile mit leerem Buchungskreis bzw. leerer SystemID wird als Defaulteinstellung für jene Buchungskreise bzw. Systeme übernommen, die keine eigene Zeile haben
  • SENDER_ID: lt. ECOSIO
  • SERVICE_ID_OUT: werksabhängige Service-ID für ausgehende Nachrichten (z.B. 'sapecosio_at')
  • SERVICENAME_IN: zugehöriger eingehender Servicename, der dem ausgehenden Service zugeordnet ist (z.B. 'ecosiosap_at').
  • damit die Callback - Funktion weiß, an welches ausgehende Service gesendet werden muß
  • damit FETCH die Nachrichten (STORE_XML_FULL, STORE_XML_SINGLE) unter dem richtigen Servicenamen speichern kann
  • Customizing der Tabelle /EPO1/ECOSIO_OUT:
  • für jeden Nachrichtentyp muß eine passende Transformation 'WERKS_XSLT' eingetragen werden (siehe oben), die das Werk aus einer ausgehenden Nachricht extrahieren kann (z.B. '/EPO1/ECOSIO_GET_WERKS', '/EPO1/ECOSIO_GET_WERKS_INVOIC')
  • eine Zeile mit leerem Nachrichtentyp dient als Defaulteinstellungen für Nachrichtentypen, die keine eigene Zeile haben
  • Anpassen der abgeleiteten OUT-Klasse (z.B. Z_CL_ECOSIO_OUT zur Basisklasse: /EPO1/CL_EXC_ECOSIO_XML_OUT):
  • Methode UE_INIT_PARAMETERS
    redefinieren, gesamten Code aktivieren
  • Methode UE_GET_SENDER:
    Redefinition der Methode löschen, die Sender-ID wird in der Methode UE_INIT_PARAMETERS gesetzt und soll an dieser Stelle nicht mehr verändert werden


Serviceselektion für ausgehende Nachrichten

  • je nach Nachrichtentyp (siehe Tabelle /EPO1/ECOSIO_OUT) wird eine passende Transformation gewählt und auf das XML der ausgehenden Nachricht angewendet. Ergebnis ist der Buchungskreis BUKRS bzw. eine Belegnummer BELNR, aus der der Buchungskreis ermittelt werden kann
  • In der Tabelle /EPO1/ECOSIO_BKR werden die buchungskreisabhängigen Einstellungen gelesen
  • die weitere Nachrichtenverarbeitung erfolgt nun mit den buchungskreisspezifischen Einstellungen


Callback - Serviceselektion

Eine ausgehende Callback - Message wird ausgelöst, wenn eine Nachricht erfolgreich eingegangen ist.

PUSH: ist ein eingehendes Service, es ist der Inbound-Servicename bekannt. Über die Tabelle /EPO1/ECOSIO_BKR kann die zugehörige Outbound-Service-ID ermittelt werden. In einem zweiten Schritt wird mittels System-ID der Outbound-Servicename ermittelt.

FETCH: ist ein ausgehendes Service, anhand der Tabelle /EPO1/ECOSIO_BKR wird das zugehörige Inbound-Service ermittelt und zum Speichern der Nachrichten (Operation: store_xml_full, store_xml_single) benutzt.
Für Callback wird das gleiche ausgehende Service wie für Fetch benutzt.

 

Erweiterung - Werksabhängige Services

Es ist möglich, ausgehende Nachrichten abhängig vom Werk an unterschiedliche Endpunkte bei ECOSIO zu senden. Umgekehrt wird für jeden Endpunkt bei ECOSIO (ausgehendes Service in SAP) auch ein eingehendes Service eingerichtet. Die Erweiterung auf systemabhängige SystemID ist seit Version 2.8.1 möglich. Folgende Punkte müssen dafür angepasst werden:

  • ein- und ausgehende Services komplett einrichten (d.h. passende Service-IDs und Servicenamen, UserID/UserKey, Service-URLs, ..)
  • Zum Auslesen des Werkes aus einer ausgehenden Nachricht wird eine Transformation benötigt. Es ist die Transformation /EPO1/ECOSIO_GET_WERKS bereitgestellt, alternativ kann eine Z-Transformation erstellt werden
  • Customizing der Tabelle /EPO1/ECOSIO_WRK:
  • für jedes Werk ist eine Zeile anzulegen, eine Zeile mit leerem Werk bzw. leerer SystemID wird als Defaulteinstellung für jene Werke bzw. Systeme übernommen, die keine eigene Zeile haben
  • SENDER_ID: lt. ECOSIO
  • SERVICE_ID_OUT: werksabhängige Service-ID für ausgehende Nachrichten (z.B. 'sapecosio_at')
  • SERVICENAME_IN: zugehöriger eingehender Servicename, der dem ausgehenden Service zugeordnet ist (z.B. 'ecosiosap_at').
  • damit die Callback - Funktion weiß, an welches ausgehende Service gesendet werden muß
  • damit FETCH die Nachrichten (STORE_XML_FULL, STORE_XML_SINGLE) unter dem richtigen Servicenamen speichern kann
  • Customizing der Tabelle /EPO1/ECOSIO_OUT:
  • für jeden Nachrichtentyp muß eine passende Transformation 'WERKS_XSLT' eingetragen werden (siehe oben), die das Werk aus einer ausgehenden Nachricht extrahieren kann (z.B. '/EPO1/ECOSIO_GET_WERKS')
  • eine Zeile mit leerem Nachrichtentyp dient als Defaulteinstellungen für Nachrichtentypen, die keine eigene Zeile haben
  • Anpassen der abgeleiteten OUT-Klasse (z.B. Z_CL_ECOSIO_OUT zur Basisklasse: /EPO1/CL_EXC_ECOSIO_XML_OUT):
  • Methode UE_INIT_PARAMETERS
    redefinieren, gesamten Code aktivieren
  • Methode UE_GET_SENDER:
    Redefinition der Methode löschen, die Sender-ID wird in der Methode UE_INIT_PARAMETERS gesetzt und soll an dieser Stelle nicht mehr verändert werden


Serviceselektion für ausgehende Nachrichten

  • je nach Nachrichtentyp (siehe Tabelle /EPO1/ECOSIO_OUT) wird eine passende Transformation gewählt und auf das XML der ausgehenden Nachricht angewendet. Ergebnis ist das WERK
  • In der Tabelle /EPO1/ECOSIO_WRK werden die werksabhängigen Einstellungen gelesen
  • die weitere Nachrichtenverarbeitung erfolgt nun mit den werksspezifischen Einstellungen


Callback - Serviceselektion

Eine ausgehende Callback - Message wird ausgelöst, wenn eine Nachricht erfolgreich eingegangen ist.

PUSH: ist ein eingehendes Service, es ist der Inbound-Servicename bekannt. Über die Tabelle /EPO1/ECOSIO_WRK kann die zugehörige Outbound-Service-ID ermittelt werden. In einem zweiten Schritt wird mittels System-ID der Outbound-Servicename ermittelt.

FETCH: ist ein ausgehendes Service, anhand der Tabelle /EPO1/ECOSIO_WRK wird das zugehörige Inbound-Service ermittelt und zum Speichern der Nachrichten (Operation: store_xml_full, store_xml_single) benutzt.
Für Callback wird das gleiche ausgehende Service wie für Fetch benutzt.

 

Erweiterung - Message Bulk

Ziel: Nachrichten zu einer bestimmten Kombination Empfänger/Nachrichtentyp sollen nicht sofort gesendet werden, sondern gesammelt durch einen Job (ev. nur 1x pro Tag).

Prozessablauf: Die IDocs müssen versendet werden. Da aber die asynchrone EPO-Operation 'message_bulk' verwendet wird, bleiben die Nachrichten im EPO Connector gespeichert. Die IDocs bekommen den Versand-Status 18, der EDI-Archivschlüssel bleibt aber leer (Selektionsmöglichkeit im EPO IDoc Monitor).

Die im EPO Connector zwischengespeicherten Nachrichten müssen mit dem Report /EPO1/EXC_ECOSIO_MESSAGE_BULK zu einem späteren Zeitpunkt an ecosio versendet werden.

Technik: Der Report /EPO1/EXC_ECOSIO_MESSAGE_BULK kann als SAP Job eingeplant werden. Die Selektionsparameter werden an die Klasse /EPO1/CL_EXC_ECOSIO_MSG_BULK zur eigentlichen Verarbeitung weitergegeben.

Die Klasse /EPO1/CL_EXC_ECOSIO_MSG_BULK darf für Kundenanpassungen abgeleitet werden, alle Methoden ausser der SEND - Methode dürfen redefiniert werden.

Wenn zusätzliche Parameter übergeben werden sollen, so sind entsprechende Klassenattribute anzulegen und mit eigenen öffentlich zugänglichen Methoden zu befüllen. Die Klassenattribute können dann in den redefinierten Methoden benutzt werden.

 

Operation 'message_bulk' einrichten

Analog der EPO-Operation 'message' wird eine EPO-Operation 'message_bulk' angelegt, aber die Verarbeitung von 'S' (synchron) nach 'A' (asynchron) gestellt.

Üblicherweise also für die EPO-Services 'sapecosio_test' und 'sapecosio_prod'.

Folgende Felder werden nicht benötigt, und sollten der Klarheit halber gelöscht werden:

  • Hostname
  • Port
  • Pfad
  • Content Type
  • SSL ID


Hinweis: die Protokollierung des Nachrichteninhaltes ('Nachricht (+Hd)') muß aktiv sein, damit der Nachrichteninhalt protokolliert wird - und später wieder aufgesammelt werden kann; '<ttO' für ausgehende Nachrichten, bzw. 'X' für ein- und ausgehende Nachrichten.

 

Customizing /EPO1/ECOSIO_M_B

Für jede Kombination Empfänger/Nachrichtentyp muß eine Zeile erstellt werden und das 'Aktiv'-Flag gesetzt werden. Ab nun werden alle Nachrichten zu dieser Kombination nicht mehr als Operation 'message', sondern als 'message_bulk' gespeichert - nicht aber versendet.

Als Empfänger muß die ecosio-ID hinterlegt werden, im Standard also der Name des Ansprechpartners 'ZEDI' in der Transaktion XD02 bzw. XK02.

 

Spezialanforderungen / Konditionen für 'message_bulk'

Wenn die Entscheidung, ob mit 'message_bulk' gesendet werden soll, von den Inhalten des IDOCs abhängt, so muß in der ecosio-Outbound-Klasse (mit der Basisklasse /EPO1/CL_EXC_ECOSIO_XML_OUT) die Methode UE_GET_OPERATION redefiniert werden.

Im Standard wird nur Empfänger/Nachrichtentyp mit der Tabelle /EPO1/ECOSIO_M_B abgeglichen.

 

Job /EPO1/EXC_ECOSIO_MESSAGE_BULK

Erst dieser Report sammelt die aufgelaufenen Nachrichten zusammen, fasst jeweils gleiche Kombinationen Empfänger/Nachrichtentyp zusammen und versendet alle Nachrichten in einer einzigen Nachricht.

Dieser Report muß als Job eingeplant werden, wenn die Nachrichten periodisch versendet werden sollen.


Pflichtfelder für den Report:

  • Servicename (default: sapecosio)
  • Name der asynchronen Operation (default: message_bulk)
  • ausführende Klasse (default: /EPO1/CL_EXC_ECOSIO_MSG_BULK); hier kann der Name einer vom Kunden abgeleitete Klasse hinterlegt werden


Optionale Felder für eine selektive Einschränkung:

  • Empfänger
  • Nachrichtenart
  • Status (in der EPO - Nachrichtenliste)


Die Checkbox 'Testmodus' muß für einen produktiven Programmlauf gelöscht werden.

 

Kennzeichnung im EPO Connector Monitor

In der Transaktion /EPO1/EXC, Anzeige der gespeicherten Nachrichten:

  • die aufgesammelten Einzelnachrichten (die nicht sofort versendet werden) haben die Operation 'message_bulk'; im FKEY3 steht wie üblich die IDOC-Nummer
  • beim Versenden der Sammel-Nachricht wird die ecosio-ID in den FKEY1 der Einzelnachrichten geschrieben, somit kann man über diesen Schlüssel alle zusammengehörigen Nachrichten finden (die gespeicherten Einzelnachrichten und die gesendete Sammelnachricht)

 

Ablauf / Zusammenfassung

In der Tabelle /EPO1/ECOSIO_M_B ist die Einstellung für Partner (ecosio-ID) und Nachrichtenart hinterlegt

ClipCapIt-210604-094731.PNG

Vorerst werden passende Nachrichten nur gesammelt, aber nicht gesendet

ClipCapIt-180919-121234.PNG
Interner Ablauf:
  • Methode UNIT_PROCESS, Methode UE_GET_OPERATION:
entscheidet anhand der Customizingtabelle /EPO1/ECOSIO_M_B, ob die aktuelle Nachricht normal (operation message) oder per Message Bulk (operation message_bulk) gesendet werden soll
  • lt. customizing ist die Operation message_bulk auf asynchron eingestellt, d.h. die Nachricht verbleibt in der Logtabelle und wird NICHT gesendet
  • in den Fremdschlüssel 3 wird der String 'MESSAGE_BULK' geschrieben


Der Report /EPO1/EXC_ECOSIO_MESSAGE_BULK liest diese Nachrichten, fasst sie zusammen und versendet

ClipCapIt-180919-121313.PNG
ClipCapIt-180919-121326.PNG

Anschließend sieht man die tatsächlich versendete Sammelnachricht in der Liste der Nachrichten

ClipCapIt-180919-121400.PNG
interner Ablauf:
  • selektieren der noch nicht gesendeten Nachrichten (lt. Selektionsparametern)
falls kein expliziter Status angegeben ist, wird nach Status = 50..52 selektiert
  • sortieren der passenden Nachrichten (Nachrichtenart und Empfänger)
  • zusammenfassen der passenden Nachrichten (Nachrichtenart und Empfänger)
  • senden der zusammengefassten Nachrichte
  • der Parameter 'I_IS_MESSAGE_BULK' muß gesetzt sein, damit diese zusammengefasste Nachricht nun tatsächlich gesendet und nicht wieder asynchron verbucht wird
  • der Status der selektierten Bulk-Nachrichten wird auf 'gesendet' gesetzt
  • der Status der IDOCs wird aktualisiert


..und weiter rechts die Fremdschlüsseln

ClipCapIt-180919-121420.PNG
  • Fremdschlüssel 1 - ecosio - Nachrichten-ID der zusammengehörigen Nachrichten (der eindeutige Schlüssel im ecosio-Monitor)
  • Fremdschlüssel 2 - die Nachrichtenart
  • Fremdschlüssel 3 - die IDOC-Nummer für die Einzelnachrichten, das Kennzeichen 'MESSAGE_BULK' für die versendete Sammelnachricht

 

laufende Rechnungsnummern

In ausgehenden Bulk-Rechnungen muß eine laufende Nummer eingepflegt werden.

  • benutzt wird die Tabelle /EPO1/ECOSIO_MBI für den Zähler der Rechnungsnummer (allerdings - allgemein gehalten, auch für andere Nachrichtenarten geeignet)
  • Sperrobjekt /EPO1/ECOSIO_MBI (Funktionsbausteine: ENQUEUE_/EPO1/ECOSIO_MBI, DEQUEUE_/EPO1/ECOSIO_MBI)
  • Transformation /EPO1/ECOSIO_MSG_BLK_ID_INVOIC um die ID in jede Rechnung der Sammelnachricht einzufügen
  • ableiten der Klasse /EPO1/CL_EXC_ECOSIO_MSG_BULK nach Z_CL_ECOSIO_MSG_BULK
  • Methode UE_GET_MESSAGE_BULK_ID redefinieren (Code aktivieren)
  • Methode UE_XML_PREPROCESSING redefinieren (Code aktivieren), bei Nachrichtenart = INVOIC wird eine neue ID gezogen und mittels der Transformation in die XML-Nachricht eingefügt (in einem neuen Segment E1EDK02 mit dem Qualifier '020').


  • in der Variante für das Versenden der BulkMessages muß der neuen Klassenname Z_CL_ECOSIO_MSG_BULK als Parameter gesetzt werden

Beispiel, wie die ID ins XML eingefügt wird (nach dem letzten E1EDK02-Segment):

ClipCapIt-181114-143005.PNG


Hinweis: die Tabelle /EPO1/ECOSIO_IR (Interchange Reference) bietet gemeinsam mit der Methode GET_INTERCHANGE_REFERENCE zwar eine sehr ähnliche Funktion, allerdings auf Ebende der SAP-Partner. Bei MessageBulk werden allerdings die bereits gemappten ecosio-IDs benutzt, um zusammengehörige Nachrichten zusammenzufassen. Also ist es durchaus berechtigt, hier eine eigene Tabelle zu nutzen.

 

Erweiterung auf Rechnungsnummern

Bei ausgehenden Rechnungen wird gerne eine Kennzeichnung durch laufende Nummern verlangt. Dazu muß die Klasse /EPO1/CL_EXC_ECOSIO_MSG_BULK abgeleitet werden auf z.B. Z_CL_ECOSIO_MSG_BULK.

Die Methoden UE_XML_PREPROCESSING und UE_GET_MESSAGE_BULK_ID müssen redefiniert werden, und eine laufende Nummer in das XML eingebracht werden.

Anschließend muss die Job-Variante für den Report /EPO1/EXC_ECOSIO_MESSAGE_BULK so umgestellt werden, daß die abgeleitete Klasse aufgerufen wird.

(siehe Beispielimplementierung)

 

Erweiterung Attachments

Diese Erweiterung ist nur für die ecosio Version 2 wirksam, die Version 1 unterstützt keine Attachments. Genaugenommen handelt es sich um die Version 2a, denn die ursprüngliche Version 2 kann keine Attachments zur Nachricht zuordnen. Mit dieser Erweiterung wird das XML-Strukturelement EPODOCUMENT befüllt.

In der Klasse für ausgehende Nachrichten wurde die Methode ADD_ATTACHMENT hinzugefügt. Diese Methode soll in der redefinierten UserExit - Methode UE_XML_PREPROCESSING aufgerufen werden, um Attachments zur Nachricht hinzuzufügen.

Die hinzugefügten Attachments werden in der Methode GET_REQUEST automatisch in den Request eingefügt.

Erweiterung manuelles Versenden

Dieser Modus wurde für das manuelle hinzufügen von Attachments erstellt (z.B. an Ausgangsrechnungen), kann aber auch für andere Verarbeitungen eingesetzt werden.

Der Ablauf:

  • Customizing der Tabelle /EPO1/ECOSIO_M_M, welche Nachrichtenarten/Partner manuell versendet werden sollen
(ein Eintrag mit einer Nachrichtenart und leerem Partner dient als Default-Einstellung für alle Partner)
  • customizing der Operation 'message_manual' als asynchron
  • alle entsprechenden Nachrichten werden nun nicht mehr gesendet sondern nur in der Log-Tabelle gespeichert
  • ein separat zu schreibender Report sammelt die wartenden Nachrichten auf (auswerten/auslesen der Tabellen /EPO1/XMLHEAD//EPO1/XMLDATA) und ermöglicht die weitere Bearbeitung
  • z.B. dem Hinzufügen von Attachments
  • beim Senden wird die Methode UNIT_PROCESS mit dem Flag I_IS_MANUAL_MESSAGE aufgerufen, damit wird die Nachricht entweder sofort versendet oder als Bulk-Nachricht für den gesammelten Versand aufgesammelt

Hinweis: noch gibt es keine Beispiel-Implementierung für diesen Spezialfall

 

Erweiterung - Empfang von nicht-XML Dateien

Für die Verarbeitung von Text- oder CSV-Dateien (etc. ..) muß die Basisklasse /EPO1/CL_ECOSIO_FETCH_PROC abgeleitet werden und die Methode PROCESS_MESSAGE redefiniert werden. Als Vorlage für eine Implementierung kann die Standard - Klasse /EPO1/CL_ECOSIO_FETCH_PR_IDOC der IDOC - Verarbeitung genommen werden.

Der Parameter IV_MESSAGE enthält dann den Nachrichteninhalt, dieser kann beliebig weiterverarbeitet werden.

Voraussetzung: ecosio Version 2.11.0 oder höher.

 

Customizing /EPO1/ECOSIO_FPC

Für jeden eingehenden Nachrichtentyp muß eine Zeile angelegt werden:

  • ECOSIO docuemntTypeId: Nachrichtentyp (gemäß den Angaben von ecosio)
  • Klasse/Interface: Name der abgeleiteten Klasse

 

Erweiterung - Versand von elektronischen Rechnungen (X-Rechnung)

Die Verarbeitungsklasse /EPO1/CL_ECOSIO_DOC_XRE_OUT kann X-Rechnungen im XML-Format an ecosio senden. Der Versand wird allerdings nicht iwe üblich über eine Partnervereinbarung gesteuert, sondern durch ein separates Programm (z.B. das EPO-Rechnungsbuch, Transaktion /EPO1/OIL. Sie befindet sich im Paket /EPO1/EXC_ECOSIO_DOCUMENT und wird seit Version 2.10.0 ausgeliefert.

Was ist zu tun:

  • Klasse ableiten
  • abgeleitete Klasse im Customizing hinterlegen

 

Klasse /EPO1/CL_ECOSIO_DOC_XRE_OUT ableiten

Die Verarbeitungsklasse (z.B. Z_CL_ECOSIO_DOC_XRE_OUT) zur Basisklasse /EPO1/CL_ECOSIO_DOC_XRE_OUT) anlegen.

Redefinieren der Methoden

  • UE_GET_DOCUMENT_TYPE: setzt den Dokumenttyp (kundenspezifisches Prefix + 'XRECHNUNG1p2p2)
  • UE_GET_NAMESPACE: setzt den kundenspezifischen Namespace, wie von ecosio vorgegeben
  • UE_GET_SENDER: setzt die ID für den Absender, wie von ecosio vorgegeben
  • UE_GET_SERVICE_ID: ist nur dann zu redefinieren, wenn nicht das Standard EPO-Service 'sapecosio' verwendet wird
  • UE_GET_RECEIVER_SMTP: falls die Zustellung per e-Mail erfolgen soll, ist hier die Ermittlung der e-Mail Adresse zu implementieren. Ansonsten wird die Leitweg-ID aus der Rechnung für die Zustellung über PEPPOL verwendet.

 

Customizing Tabelle /EPO1/SUBCLASSES

Der Name der Basisklasse und der abgeleiteten Klasse wird hier eingetragen:

Klasse/Interface Modus Klasse/Interface
/EPO1/CL_ECOSIO_DOC_XRE_OUT Z_CL_ECOSIO_DOC_XRE_OUT
(dies nur als Beispiel)

 

Erweiterung - Versand von flachen Dateien (statt XML)

Die Verarbeitungsklasse /EPO1/CL_EXC_ECOSIO_FLAT_OUT erstellt aus einem IDOC eine flache Datei, das Format entspricht dem Format eines Datei-Ports (in der WE20). Sie befindet sich im Paket /EPO1/EXC_ECOSIO_FLATIDOC und wird seit Version 2.11.2 ausgeliefert.

Was ist zu tun:

  • Klasse ableiten
  • abgeleitete Klasse im Customizing hinterlegen
  • Port anlegen
  • Partnervereinbarung anpassen

 

Klasse /EPO1/CL_EXC_ECOSIO_FLAT_OUT ableiten

Die Verarbeitungsklasse (z.B. Z_CL_ECOSIO_FLAT_OUT) zur Basisklasse /EPO1/CL_EXC_ECOSIO_FLAT_OUT) anlegen.

Redefinieren der Methode UE_SET_EPO_HEADER: in dieser Methode muß eine Zeile mit Dokumenttyp;Sender;Empfänger;Dateinamen; erzeugt und an die Parametertabelle CT_FILE angehängt werden.

Dokumenttyp
  • lt. Definition von ecosio (ist jeweils abzustimmen)
Sender und Empfänger
  • die IDs bei ecosio
Dateiname
  • ist ebenfalls mit ecosio bzw. dem Empfänger abzustimmen

Beispiel:
TESTKUNDE-ORDERS;315734475;4023083000008;LAGER_123456;

 

Customizing Tabelle /EPO1/SUBCLASSES

Der Name der Basisklasse und der abgeleiteten Klasse wird hier eingetragen:

Klasse/Interface Modus Klasse/Interface
/EPO1/CL_EXC_ECOSIO_FLAT_OUT Z_CL_ECOSIO_FLAT_OUT
(dies nur als Beispiel)

Innerhalb des Funktionsbausteines /EPO1/ECOSIO_POST_FLATIDOC wird in dieser Customizingtabelle die aktuell aufzurufende Klasse für die Basisklasse /EPO1/CL_EXC_ECOSIO_FLAT_OUT ermittelt.

 

Port ECOSIO_FF

In der WE21 ist ein neuer Port zu erstellen, z.B. ECOSIO_FF. Der aufzurufende Funktionsbaustein ist /EPO1/ECOSIO_POST_FLATIDOC.

 

Partnervereinbarung anpassen

In der WE20 muß der neu angelegte Port ECOSIO_FF hinterlegt werden (für jede Kombination Partnerart/Partner/ausgehender Nachrichtentyp).

 

Erweiterung - Versand von flachen Dateien ohne IDOC - Basis

Solche Dateien können z.B. über ein Druckprogramm erstellt werden.

Die Verarbeitungsklasse /EPO1/CL_EXC_ECOSIO_JSON_OUT bietet nur recht grundlegende Funktionen an, größere Teile müssen selbst implementiert werden. Da es keinen Zusammenhang mit IDOCs gibt, spielt die Partnervereinbarung hier keine Rolle. Dennoch muß der Dokumententyp und der Empfänger korrekt bereitgestellt werden.

Was ist zu tun:

  • Klasse ableiten
  • abgeleitete Klasse im Customizing hinterlegen

 

Klasse /EPO1/CL_EXC_ECOSIO_JSON_OUT ableiten

Die Verarbeitungsklasse (z.B. Z_CL_ECOSIO_JSON_OUT) zur Basisklasse /EPO1/CL_EXC_ECOSIO_JSON_OUT) anlegen. Falls keine Methoden/Attribute der Basisklasse benutzt werden, ist eine Vererbung gar nicht notwendig.

Die Methode SEND_FILE muß dann von der Datenquelle (z.B. Druckprogramm) aufgerufen werden.


Neu erstellen der Methode SEND_FILE mit den Parametern

  • IV_DOCUMENT_TYPE Dokumententyp
  • IV_RECEIVER_ID Empfänger
  • IV_FILE_NAME Dateiname
  • IT_FILE Datei-Inhalt (Tabelle)


Die Verarbeitungsschritte:

  • erstellen der Steuerzeile (erste Zeile in der Datei)
  • Steuerzeile und Datei verbinden, in einen XSTRING umwandeln
  • versenden an ecosio
  • Ergebnis (Response) auswerten, Message-ID auslesen und im EPO-Log hinterlegen


Customizing /EPO1/FIELD_MAP:

  • für ein- und ausgehende Richtung das Schlüsselwort '[camelCase]' einstellen


Beispiel für SEND_FILE

  method SEND_FILE.

    FIELD-SYMBOLS:
      <line> TYPE ANY.

    DATA:
      lt_file          TYPE TABLE OF string,
      lv_request       TYPE xstring,
      lv_string        TYPE string,
      lv_transactionid TYPE /epo1/transactionid,
      lv_nrobject      TYPE /epo1/nrobject,
      lv_nrsobj        TYPE /epo1/nrsobj,
      lv_norangeno     TYPE /epo1/norangeno,
      lv_fkey1         TYPE /epo1/fkey1,
      lv_fkey2         TYPE /epo1/fkey2,
      lv_fkey3         TYPE /epo1/fkey3,

      BEGIN OF ls_request,
        message TYPE string,
      END OF ls_request,

      BEGIN OF ls_response,
        message_id TYPE string,
      END OF ls_response.


    " create the first line
    " <document_type>;<sender_id>;<receiver_id>;<doc_name>;
    " !!! replace '<SENDER_ID> by Your own sender id !!!
    CONCATENATE iv_document_type ';<SENDER_ID>;' iv_receiver_id ';' iv_file_name ';'
      INTO lv_string.
    APPEND lv_string TO lt_file.

    " copy the file
    LOOP AT it_file ASSIGNING <line>.
      lv_string = <line>.
      APPEND lv_string TO lt_file.
    ENDLOOP.

    " convert to xstring
    CONCATENATE LINES OF lt_file INTO lv_string SEPARATED BY cl_abap_char_utilities=>cr_lf.
    lv_request = str_2_xstr( lv_string ).
    CALL FUNCTION '/EPO1/EXC_ENCODE_BASE64'
      EXPORTING
        i_xstring             = lv_request
      IMPORTING
        E_BASE64              = ls_request-message
              .

    " upload the file to ecosio
    call_service(
      EXPORTING
        is_request_data  = ls_request
      IMPORTING
        es_response_data = ls_response
        es_callstatus    = es_callstatus
        ev_transactionid = lv_transactionid
        ev_nrobject      = lv_nrobject
        ev_nrsobj        = lv_nrsobj
        ev_norangeno     = lv_norangeno ).

    ev_message_id = ls_response-message_id.

    " update the EPO log table with FKEY1, FKEY2 and FKEY3
    lv_fkey1 = ev_message_id.
    lv_fkey2 = iv_document_type.
    lv_fkey3 = iv_file_name.

    UPDATE /epo1/xmlhead
      SET fkey1 = lv_fkey1
          fkey2 = lv_fkey2
          fkey3 = lv_fkey3
      WHERE transactionid = lv_transactionid
        AND nrobject      = lv_nrobject
        AND nrsobj        = lv_nrsobj
        AND norangeno     = lv_norangeno
        AND nryear        = 0.

  endmethod.

 

ECOSIO Schnittstellenversionen

Version 1

IDOC - Aufbau:

<epo:EPOEDI.. >
  <epo:HEADER>
    <epo:SENDER>..
    <epo:RECEIVER>..
    <epo:DOCUMENTTYPE>..
    <epo:TESTFLAG>..
  </epo:HEADER>
  <epoidoc:MESSAGE>
    <customeridoc:DELFOR02>
      <IDOC BEGIN="1">
        ...

Im Header findet sich fix der Namensraum epo mit der Definition xmlns:epo="http://www.epoconsulting.com". Die Message steht im Namensraum epoidoc: xmlns:epoidoc="http://www.epoconsulting.com/idocs".

Die Nachricht selbst steht im kundeneigenen Namensraum, der für jeden Kunden separat festgelegt ist, z.B. xmlns:customeridoc="http://www.epoconsulting.com/idocs/company-name".

Version 2

IDOC - Aufbau:

<epo:EPOEDI.. >
  <epoheader:HEADER>
    <epoheader:SENDER>..
    <epoheader:RECEIVER>..
    <epoheader:DOCUMENTTYPE>..
    <epoheader:TESTFLAG>..
  </epoheader:HEADER>
  <epo:MESSAGE>
    <epo:DELFOR02>
      <IDOC BEGIN="1">
        ...

Die Hauptnachricht, die Message und die Nachricht selbst befinden sich im Namensraum epo mit der kundenspezifischen Definition xmlns:epo="http://www.epoconsulting.com/customer-name", der Header und seine Felder liegen im Namensraum epoheader: xmlns:epo="http://www.epoconsulting.com/header".

D.h. die Namespace-Aliasse heissen nun immer gleich, nur ändert sich die Definition für den epo-Alias auf einen kundenspezifischen Namen.

Version 2a

IDOC - Aufbau:

<epo:EPOEDI.. >
  <epoheader:HEADER>
    <epoheader:SENDER>..
    <epoheader:RECEIVER>..
    <epoheader:DOCUMENTTYPE>..
    <epoheader:TESTFLAG>..
  </epoheader:HEADER>
  <epo:MESSAGE>
    <epo:EPODOCUMENT>  (beliebig viele Dokumente in der Nachricht)
      <epo:DELFOR02>
        <IDOC BEGIN="1">
          ...
        </IDOC>
      </epo:DELFOR02>

      <epo:ATTACHMENTS> (optionales Element)
        <epo:ATTACHMENT> (beliebig viele Wiederholungen)
          <epo:NAME>attachment.pdf</epo:NAME>
          <epo:MIMETYPE>application/pdf</epo:MIMETYPE>
          <epo:ATTACHMENTDATA>(Inhalt, Base64 codiert)</epo:ATTACHMENTDATA>
        </epo:ATTACHMENT>

        <epo:ATTACHMENT>
          ...
        </epo:ATTACHMENT>
      </epo:ATTACHMENTS>
    </epo:EPODOCUMENT>
  ...


Auf Serverseite soll diese Version kompatibel zur Version 2 sein; Unterschied: es gibt das neue Element <epo:DOCUMENT> um die eigentliche Nachricht herum, zusätzlich kann es das Element <epo:ATTACHMENTS> geben, welches eine beliebige Anzahl von Attachments enthält.

Codeanpassungen für beide Versionen

Beide ECOSIO-Versionen sollen mit der gleichen Codebasis abgedeckt werden können.

Version 1
die Transformation /EPO1/ECOSIO_SET_NAMESPACE muss in den Kundennamensraum kopiert werden, die 3 Strings für den kundenspezifischen XML-Namensraum werden angepasst. Der Aufruf wird durch die Tabelle /EPO1/ECOSIO_OUT gesteuert, im Feld XSLTNAME wird der Name der Transformation eingetragen.
im ersten Schritt wird mit der kundenspezifischen Transformation der kundenspezifische Namensraum gesetzt
im zweiten Schritt wird der EPO-Header mit der Transformation /EPO1/ECOSIO_ECOSIOTAG_ADD_V1 gesetzt.
Version 2
der kundenspezifische Namensraum und der EPO-Header werden gemeinsam mit der Transformation /EPO1/ECOSIO_ECOSIOTAG_ADD_V2 in das XML eingebracht, eine kundenspezifische Transformation ist nicht notwendig.
Version 2a
wie Version 2, aber mit der Transformation /EPO1/ECOSIO_ECOSIOTAG_ADD_V2A wird das neue Strukturelement 'EPODOCUMENT' eingebracht und Anhänge vorbereitet.


Steuerung im Programmablauf
Die Methode UE_GET_NAMESPACE (neu ab Version 2) liefert in der Originalausprägung (=nicht redefiniert) einen Leerstring. In diesem Fall wird die alte ECOSIO Version 1 abgearbeitet.
Ansonsten gilt lt. Customizing in der Tabelle /EPO1/ECOSIO_DEF die Version 2, Version 2a (=mit Attachments).

Changelog

NextCloud: Kundenprojekte / EPO / SoftwareDownload / EPO ecosio.EDI

EPO_Connector_ecosio_EDI_v<version>_<ta>.zip

Nach dem Import: Transaktion SICF, Service epo1soa/ecosio aktivieren.

Version 2.14

Version 2.14.0

Transportauftrag WK1K902121 19.06.2021

  • Fetch - Report: Umstellung Selektionsschirm für das Nachverarbeiten gespeicherter Nachrichten
  • Fetch: Vorbereitung für Abholen und verarbeiten von PDF-Dateien (d.h. nicht-strukturierte Dateien)

Aktivitäten vor dem Import:

  • keine

Version 2.13

Version 2.13.0

Transportauftrag WK1K901956 11.06.2021

  • Restrukturierung von Paketen: Auslagern von OI relevante Elemente ins ECOSIO_Document

Aktivitäten vor dem Import:

  • keine

Version 2.12

Version 2.12.5

Transportauftrag WK1K901935 04.06.2021

  • Message Bulk: Tabelle /EPO1/ECOSIO_M_B von Customizing- auf Stammdatentabelle umgestellt
  • Message Bulk: Korrektur der Ablaufsteuerung in UNIT_PROCESS

Aktivitäten vor dem Import:

  • keine

 

Version 2.12.4

Transportauftrag WK1K901814 08.04.2021

  • Bugfix inbound: bei fehlendem Sender-Mapping (BP) nicht den SNDPRN überschreiben (zuvor: überschreiben aus dem EPO Header) - Korrektur für 2.12.3

Aktivitäten vor dem Import:

  • keine

 

Version 2.12.3

Transportauftrag WK1K901808 01.04.2021

  • Bugfix inbound: bei fehlendem Sender-Mapping (BP) nicht den SNDPRN überschreiben (zuvor: überschreiben aus dem EPO Header)

Aktivitäten vor dem Import:

  • keine

 

Version 2.12.2

Transportauftrag WK1K901791 23.03.2021

  • Transformation für Attachment - Entfernung: geänderte Syntax, gleiche Funktionalität

Aktivitäten vor dem Import:

  • keine

 

Version 2.12.1

Transportauftrag WK1K901759 18.03.2021

  • Bugfix inbound: bei fehlendem Sender-Mapping (BP) nicht den SNDPRN überschreiben

Aktivitäten vor dem Import:

  • keine

 

Version 2.12.0

Transportauftrag WK1K901752 16.03.2021

  • Versions-Info in der Klasse /EPO1/CL_ECOSIO_VERSION
  • ecosio Version '2A': kein leeres 'ATTACHMENTS' - Tag mehr (wenn es keine Attachments gibt)
  • Status-Manager: wenn der Response 'failure' enthält, so wird der zugehörige Text im IDOC-Status hinterlegt (in einem separaten Status)

Aktivitäten vor dem Import:

  • Update des EPO-Connector: SP12 - Vorab Version 4.3.0 (WK1K901495) vom 15.01.2021, oder neuer

Aktivitäten nach dem Import:

  • falls es in eine Kunden-Implementierung die Methode /EPO1/CL_ECOSIO_CALLBK->SEND aufgerufen wird, muß der Parameter IS_MESSAGETYPE aus dem Aufruf entfernt werden

 

Version 2.11

Version 2.11.10

Transportauftrag WK1K901452 11.12.2020

  • Flat File - IDOC: Erweiterung zum Umbenennen (Postprocessing) der IDOC - Segmentdaten

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.9

Transportauftrag WK1K901297 30.10.2020

  • Korrektur Sender-Mapping für eingehende Nachrichten: akzeptiert nun auch Leerzeichen innerhalb der ID
  • Vorbereitung für Statusabfrage von ausgehenden e-Rechnungen

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.8

Transportauftrag WK1K901245 22.10.2020

  • Restrukturierung EPO-Connector - gemeinsam mit dem neuen SP12 installieren! (durchgängige Verwendung der Service-ID)

Aktivitäten vor dem Import:

  • Update des EPO-Connector: SP12 - Vorab Version 4.0.1 (WK1K901313) vom 30.10.2020, oder neuer

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.7

Transportauftrag WK1K901234 08.10.2020

  • Umstellung der statischen Methoden 'UNB_MAPPING_BP' auf Instanzmethoden, diese können nun auch redefiniert werden
  • Korrektur Sender-Mapping (BP) f. eingehende Nachrichten: keine Exception - sondern IDOC anlegen lassen (korrigiert den Fehler in den Versionen 2.11.2 - 2.11.6)

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.6

Transportauftrag WK1K901163 04.09.2020

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.5

Transportauftrag WK1K901146 02.09.2020

  • Korrektur in Sender-Mapping für ausgehende Nachrichten

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.4

Transportauftrag WK1K901067 28.08.2020

  • IDOC als flache Datei senden: neue UserExit-Methoden für den EPO-Header in die Klasse /EPO1/CL_EXC_ECOSIO_FLAT_OUT eingefügt
  • Korrektur in der Methode UE_GET_SERVICE_ID
  • Umstellung der ecosio Version für X-Rechnungen von '2' nach '2A' (nach dem neueren Schema - zusätzliches Tag '<epo:EPODOCUMENT>')

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.3

Transportauftrag WK1K901043 14.08.2020

  • Korrektur der generierten Pragmas ##NO_TEXT in Klassen
diese Korrektur ist nur für ältere SAP-Releases wichtig, keine funktionalen Änderungen gegenüber 2.11.2

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.2

Transportauftrag WK1K900956 13.08.2020

  • Erweiterung der IN- und OUT-Klasse für das BP-Mapping der Partner (Vorbereitung für UE-Methoden)
  • RECEIVER_ENDPOINT nun auch für ecosio Version 2 implementiert
  • Vorbereitung für den IDOC-Export als flache Datei (statt XML) - Klasse /EPO1/CL_EXC_ECOSIO_FLAT_OUT

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.1

Transportauftrag WK1K900920 15.07.2020

  • Codeanpassung für Plain Text - Dateien
  • Parameter-Bereinigung: ET_DOCNUM ersetzt durch ET_ID (erfordert ev. Codeanpassungen in abgeleiteten Klassen)
  • Logging der IDOC-Nummern auch bei der Operation 'fetch_message' (so lange der Platz im Feld FKEY3 ausreicht)

Aktivitäten nach dem Import:

  • keine

 

Version 2.11.0

Transportauftrag WK1K900831 05.06.2020

  • Callback: Pass-Through-Header entfernt, ersetzt durch das neue Index - Element im Request (vermeidet Fehler bei sehr langer Objektliste)
  • Callback - neue Logik für success/failure (Fehler, wenn es zumindest einen Fehler gab oder kein Objekt erstellt wurde)
  • Fehlerkorrektur IDOC - Transformation f. ausgehende IDOCs (fehlender Namespace - seit Version 2.10.0)
  • neue Steuertabelle /EPO1/ECOSIO_FPC und Basisklasse für Fetch - Processing (abhängig vom Nachrichtentyp), ermöglicht die Behandlung von Plain Text - Dateien

Aktivitäten vor dem Import:

  • Update des EPO-Connector: SP12 - Vorab WK1K900875 vom 25.5.2020 (oder neuer)

Aktivitäten nach dem Import:

  • keine

Version 2.10

Version 2.10.0

Transportauftrag WK1K900805 24.04.2020

  • Erweiterung für X-Rechnungen / Dokumente
  • Korrektur in der FETCH - Klasse (Flag für weitere Nachrichten, falls mehr als 30 Nachrichten zum Abholen vorliegen)
  • neue Basisklasse für ausgehende JSON Webservices
  • Callback: Liste der IDOCs nicht mehr im Header, sondern im Request-Body

Aktivitäten vor dem Import:

  • Update des EPO-Connector: SP12 - Vorab vom 24.4.2020 (oder neuer)

Aktivitäten nach dem Import:

  • nur für 2.10.0: den Korrektur - Transport WK1K900838 einspielen (sonst entsteht ein ungültiges IDOC - XML beim Senden); korrigiert in der Version 2.10.1

Version 2.9

Version 2.9.9

  • Transportauftrag WK1K900741 27.02.2020
  • Korrektur für das UNB-Mapping für eingehende Nachrichten

Aktivitäten nach dem Import:

  • keine

Version 2.9.8

  • Transportauftrag WK1K900734 24.02.2020
  • Korrektur für das Absender-Mapping für eingehende Nachrichten
  • "CONDENSE l_wherestring NO-GAPS." herausgelöscht, es hat Partnernummern mit SPACE im Wort verändert.
  • Sperr-Mechanismus für FETCH Report
  • Bereinigung moderner Pragmas (Probleme auf alten SAP-Releases)

Aktivitäten vor dem Import:

  • aktuelles SP12 einspielen (Stand 28.11.2019 oder später)
    (z.B. EPOConnector_SP12_PreRelease_as_transport_WK1K900596.zip)

Aktivitäten nach dem Import:

  • keine

Version 2.9.6

  • Transportauftrag WK1K900676 20.01.2020
  • Korrektur für Message Bulk (paketfremde Objekte)

Aktivitäten nach dem Import:

  • keine


Version 2.9.5

  • Transportauftrag WK1K900669 17.01.2020
  • Korrektur für Message Bulk (Mapping des Empfängers für INVOIC)
  • Korrektur im Report für das Senden von Control Status IDocs

Aktivitäten nach dem Import:

  • keine


Version 2.9.4

  • Transportauftrag WK1K900649 20.12.2019

Aktivitäten nach dem Import:

  • Option: Den Report /EPO1/IDOC_STATUS_RESEND als Job einplanen, um den garantierten Versand sicher zu stellen.


Version 2.9.3

  • Transportauftrag WK1K900557 14.11.2019
  • Korrektur der Textausgabe im Report /EPO1/EXC_ECOSIO_CONTROL_STAT
  • Fetch Programm mit neuer Option für Testzwecke aus dem EPO Connector neben ecosio JSON Nachrichten auch IDoc XML Nachrichten (mit und ohne EPO Header) zu verarbeiten. Damit lassen sich SAP IDocs aus IDoc XMLs erstellen. 1. Schritt: File in den EPO Connector hochladen mit EXC Service sapecosio, Operation=store (oder von ecosio abholen). 2. Schritt. Mit dieser neuen Option des Fetch-Programms ein Idoc in SAP anlegen.

Aktivitäten nach dem Import:

  • keine


Version 2.9.2

  • Transportauftrag WK1K900548 11.11.2019
  • UNB-Mapping (alte Logik) für Partner bei eingehenden IDOCs: Korrektur für die Behandlung der Partnerart 'LI' (ist ein Lieferant, nicht Kunde)
  • Fetch (neues API): Korrektur für Logging der IDOC-Nummern in den EPO-Nachrichten

Aktivitäten vor dem Import:

  • aktuelles SP12 einspielen (Stand 12.11.2019 oder später)


Version 2.9.1

  • Transportauftrag WK1K900506 05.11.2019
  • Syntax für alte Releases anpassen

Aktivitäten nach dem Import:

  • keine


Version 2.9.0

  • Transportauftrag WK1K900468 04.11.2019

Aktivitäten nach dem Import:

  • keine


Version 2.8

Version 2.8.3

  • Transportauftrag WK1K900466 25.10.2019
  • Korrektur für Fetch - Report (schreiben der ecosio-message ID in den FKEY1)
  • Erweiterung Inbound: Partner (AG, WE, LF..) können nun auch im Feld LIFNR stehen (bisher: nur PARTN)

Aktivitäten nach dem Import:

  • ev. Anpassung von Reports, die die Klasse /EPO1/CL_EXC_ECOSIO_FETCH / Methode FETCH_MESSAGE benutzen (neuer Parameter EV_DOC_TYPE_ID)


Version 2.8.2

  • Transportauftrag WK1K900039 27.05.2019
  • neus Fetch - API von ecosio ansprechen

Aktivitäten nach dem Import:

  • für FETCH (nicht notwendig für PUSH)
  • Operation 'fetch_list' und 'fetch_message' einrichten
  • Operation 'fetch' löschen


Version 2.8.1

  • Transportauftrag WK1K900032 10.05.2019
  • Customizingtabelle für systemabhängige SenderID
  • Buchungskreisabhängiges Service: Erweiterung für ORDRSP und INVOICE (falls der Buchungskreis nicht im IDOC enthalten ist)
  • Werksabhängiges Service: Erweiterung auf SystemID - Abfrage

Aktivitäten nach dem Import:

  • Werksabhängiges Service: für das Senden von INVOICEs muß die separate Transformation /EPO1/ECOSIO_GET_WERKS_INVOIC in der Tabelle /EPO1/ECOSIO_WRK eingetragen werden (nicht - eindeutige Datenquellen: bei einer Bestellung ORDERS steht das Werk in E1EDKA1/LIFNR mit PARVW = 'WE', bei INVOICE steht hier aber eine komplett andere Bedeutung drinnen)


Version 2.8.0

  • Transportauftrag I01K902629 18.04.2019
  • neuer Report STATMAN (/EPO1/EXC_ECOSIO_STATMAN) für ecosio - Status
  • Umstellung auf ecosio Version 2a (etwas erweitertes XML, um Attachments zu Nachrichten eindeutig zuordnen zu können)
  • Attachments für Nachrichten (neue Methode ADD_ATTACHMENT für die XML_OUT-Klasse)
  • Manuelle (ausgehende) Nachrichten, die nicht sofort versendet werden (z.B. in Verbindung mit manuell hinzuzufügenden Attachments)
  • Werksabhängiges Service: Vorbereitung auf INVOICE (liest den Buchungskreis)

Aktivitäten nach dem Import:

  • bei der Umstellung auf Version 2a (mit Attachments): Kontrolle/Korrekturen aller Z-Transformationen, die z.B. im Postprocessing aufgerufen werden; in der ecosio-Version 2a hat das IDOC nun ein zusätzliches Element <epo:EPODOCUMENT> im Pfad, um bei Sammelnachrichten die Nachricht und das Attachment zusammenzuhalten

ältere Versionen

Version 2.7.4

  • Transportauftrag I01K902304 20.12.2018
  • zusätzliche Prüfung des EPO Headers in der ausgehenden XML-Nachricht
  • kleine Korrekturen für Import in alten SAP-Systemen

Aktivitäten nach dem Import:

  • keine


Version 2.7.3

  • Transportauftrag I01K902203 03.12.2018
  • Korrektur der Fehlerbehandlung bei eingehenden Nachrichten (keine Exception mehr, sondern IDOC anlegen lassen und den Status auf Fehler setzen)
  • BulkMessage: Vorbereitung für das Hinzufügen von laufenden Nummern

Aktivitäten vor dem Import:

  • IDOC - Monitor installieren (hier haben wir nun Abhängigkeiten)

Aktivitäten nach dem Import:

  • keine


Version 2.7.2

  • Transportauftrag I01K902157 09.11.2018
  • BulkMessage: Vorbereitung für ein XML Preprocessing
Aktivitäten nach dem Import:
  • keine


Version 2.7.1

Transportauftrag I01K902145 vom 08.11.2018

  • Korrektur Tabelle /EPO1/ECOSIO_DEF ist jetzt Customizing-Tabelle


Version 2.7

  • Transportauftrag I01K902138 06.11.2018
  • Korrektur Partnermapping (Rollen: AG, WE, RG, etc.)
  • Partnermapping für S/4 - Systeme über die BP-Tabellen (neues Customizing)
  • Korrektur der Callback - URL, wenn der AppKey im HTTP-Header steht (und nicht in der URL der Operation)
Aktivitäten nach dem Import:
  • optional für R/3: umstellen des Partner-Mappings von KNVK-Logik auf die BP-Logik
  • optional: den AppKey aus allen URLs entfernen und dafür in der HTTP-Header Tabelle eintragen


Version 2.6

  • Transportauftrag I01K902076 15.10.2018
  • Partnermapping über BP-Tabellen (für S/4 Systeme erforderlich, für R/3 optional möglich)

Aktivitäten nach dem Import:

  • keine


Version 2.5

  • Transportauftrag I01K901960 17.09.2018
  • neue Funktion 'Message Bulk' für Sammel-Nachrichten

Aktivitäten vor dem Import:

  • Update des Paketes /EPO1/TS und /EPO1/MA_COMMON
  • Update des SP12 - Vorabtransportes

Aktivitäten nach dem Import:

  • keine


Version 2.4

  • Transportauftrag I01K901788 11.05.2018
  • In der Methode /EPO1/CL_EXC_ECOSIO_XML_IN->UE_SENDER_UNB_MAPPING wird nun ein Eintrag mit der Funktion ZI (Abteilung ZEDI wie bisher) berücksichtigt.
  • Korrektur der Transformationen für UNB-Mapping (vollständige Strukturen erzeugen)
  • GET_RECEIVER: Fehlerbehandlung bei zu langen KUNNR/LIFNR im IDOC

Aktivitäten nach dem Import:

  • keine


Version 2.3

  • Transportauftrag I01K901327 13.06.2017
  • Die ecosio Message ID wird um den String '@ecosio' ergänzt
  • Bei FETCH wird nun auch ein callback ausgelöst, damit werden die IDOC-Nummern an den ecosio-Monitor weitergeleitet und können dort für die Nachrichtensuche eingesetzt werden

Aktivitäten nach dem Import:

  • bei FETCH muß nun auch im ausgehenden sapecosio-Service die Operation callback eingerichtet werden
  • für den FETCH - Job (wenn eingerichtet) muß die Variante neu angelegt werden, weil es nun andere Reportparameter gibt


Version 2.2

  • Transportauftrag I01K901??? ??.04.2017
  • Transformations-Fehler abfangen, Fehlermeldungen ausgeben


  • Transportauftrag I01K901204 02.04.2017
  • Out-Klasse: Interchange Referenz ohne 100er Trennzeichen ausgeben
  • Werksabhängiger ECOSIO-Endpunkt (Zusatz-Customizing, OUT-Klasse angepasst, CALLBACK umgestellt)
  • besseres Logging von Fehlermeldungen von ECOSIO

Aktivitäten nach dem Import:

  • für den FETCH - Job (wenn eingerichtet) muß die Variante neu angelegt werden, weil es nun andere Reportparameter gibt


  • Transportauftrag I01K901126 23.02.2017
  • Transformation GET_SENDER: erweitern auf ECOSIO Version 2 (Namespace)
  • CALLBACK speichert nun die MessageID in die Headertabelle
  • IN-Klasse: Exceptions in FORMAT_MESSAGE abfangen, Transformation GET_SENDER ergänzen
  • ZEDI - Logik erweitert mit Priorität in der Tabelle /EPO1/ECOSIO_UNB

Aktivitäten nach dem Import:

  • der ECOSIO - Testserver heißt nun ecosio-test (statt ecosio-stage) und horcht auf Port 443; alle Verbindungen (auch SM59) entsprechend umstellen. Auf allen Systemen, auch in der Produktion - damit nach einer Klappung das Testsystem wieder funktioniert.


  • Transportauftrag I01K901088 23.01.2017
  • EDI_DC40/SNDPRN und EDI_DC40/RCVPRN ebenfalls lt. Mapping austauschen
  • DESADV: Partner-Felder heißen hier PARTNER_Q (=PARVW) und PARTNER_ID (=PARTN); wird ab nun auch unterstützt


  • Transportauftrag I01K901063 16.01.2017
Änderung gegen Version 2.1:
  • der Aufbau ausgehender Nachrichten ändert sich, bereits das äusserste Element EPOEDI wird mit dem Kundenspezifischen Namensraum versorgt. Damit entfällt die Notwendigkeit, eine kundenspezifische Transformation für den Namensraum des IDOC - Elementes zu haben. Auf der Seite ECOSIO korrespondiert diese Änderung mit der Einführung der Version 2 (=nicht kompatibel zur ECOSIO Version 1).
  • das UNB-Mapping funktioniert nun auch bei DESADV (anderer Segmentaufbau, erweiterte Transformationen)

Aktivitäten vor dem Import:

  • Einträge der Tabelle /EPO1/ECOSIO_OUT retten (Klassenname, der Transformationsname wird nur für ECOSIO Version 1 benötigt)
Aktivitäten nach dem Import bei Umstellung auf ECOSIO Version 2:
  • OUT - Klasse: Methode UE_GET_NAMESPACE redefinieren
  • OUT - Klasse: Methode UE_XML_PREPROCESSING - Namespace Handling deaktivieren (Redefinition löschen)
  • Transformation für kundeneigenen Namespace deaktivieren/löschen

Aktivitäten nach dem Import

  • Pflege der Tabelle /EPO1/ECOSIO_OUT, eine Zeile mit leerem MESTYP genügt als Default


Version 2.1

  • Transportauftrag I01K901014 13.12.2016
  • FETCH - Klasse/-Programm: Fehlermeldungen vom ECOSIO-Server ausgeben
  • InterchangeReferenz ohne Leerzeichen übertragen
  • UNB-Mapping auch für die Partner AG, LF, RE, RG und WE (in beiden Richtungen), neue statische Methode UNB_MAPPING und User-Exit Methode UE_PARTN_UNB_MAPPING für die Klassen /EPO1/CL_EXC_ECOSIO_XML_IN und /EPO1/CL_EXC_ECOSIO_XML_OUT
  • ausgehendes IDOC: Revceiver im EDIDC40-Segment auch mappen (gleich wie den RECEIVER im HEADER)
Aktivitäten:
  • Klasse /EPO1/CL_EXC_ECOSIO_XML_DEL_BK löschen (wenn vorhanden)
  • Tabelle /EPO1/VDA_TRACK löschen (wenn vorhanden)
  • Datentyp /EPO1/TRANSID löschen (wenn vorhanden)
  • Domaine /EPO1/TRANSID löschen (wenn vorhanden)
  • Nummernkreisobjekt /EPO1/VDA löschen, wenn es nach dem Import noch vorhanden ist


  • Transportauftrag I01K900994 06.12.2016
  • keinen Workflow mehr auslösen, wenn beim IDOC senden Fehler auftreten


  • Transportauftrag I01K900988 05.12.2016
  • InterchangeReferenz nach Nachrichtentyp (nicht IDOC-Typ) und Partner ermitteln: Tabelle /EPO1/ECOSIO_INT wird automatisch in die Tabelle /EPO1/ECOSIO_IR übergeführt
  • InterchangeReferenz: Warteschleife, falls die Nummernvergabe durch eine Sperre blockiert wird (=Wiederholversuche)
  • VDA-Behandlung entfernt;


Aktivitäten vor dem Transport

  • Test-/Produktion: Einträge der Tabelle /EPO1/VDA_TRACK retten, zu jeder Nachrichtenart (bzw. eben IDOC-Typ) den höchsten Zählerstand aufschreiben.
  • in der abgeleiteten Klasse Z_CL_ECOSIO_OUT die VDA-spezifischen redefinierten Methoden löschen (falls vorhanden):
  • UE_GET_TRANSID_NEW
  • UE_GET_TRANSID_OLD
  • UE_LOG_TRANSACTION
  • UE_REQUEST_INJECT_TRANSID
Ein einfacher Syntax Check nach dem Import zeigt, was zu tun ist.


Aktivitäten nach dem Transport

  • NACH DEM TRANSPORT in die Produktion: neue Einträge in die neue Tabelle /EPO1/ECOSIO_IR einfügen. Wenn dies per SE16/Debugger nicht möglich ist, so muß dies im Entwicklungssystem gemacht werden und die Tabelleninhalte über einen Transport in die Produktion gebracht werden.
  • Tabelle /EPO1/VDA_TRACK löschen (wenn vorhanden)


  • Transportauftrag I01K900898 17.10.2016
  • Übergabe eines leeren Responses an ECOSIO vermeidet eine Fehlermeldung

Offene Fragen

Wie stellt man die Nachrichtenfindung/Konditionen ein?