Mit diesem Eingangsagenten können CommLog-Ereignisse ausgewertet werden. Sobald ein Profil mit diesem Eingangsagenten aktiviert wurde, empfängt es die konfigurierten (siehe unten) CommLog-Ereignisse (des Control Centers). Wichtiger Hinweis: Im verwendeten Partner-Kanal muss die Option "CommLog verwenden" aktiv sein, damit CommLog-Ereignisse erzeugt werden. Beim Protokoll X.400 muss zusätzlich im Antwortweg X.400 des sendenden Profils die Option Empfangsbestätigung verlangen aktiv sein.

images/download/attachments/137312319/414-version-1-modificationdate-1691031665638-api-v2.png

(1) Datenrichtung der Daten, auf die sich die CommLog-Ereignisse beziehen.

(2) Typ der CommLog-Ereignisse. Auswahloptionen:

MDN. Positive Empfangsbestätigungen.
NDN. Negative Empfangsbestätigungen.

Hinweis: Manche Protokoll-Arten (z. B. FTP und SSH), siehe (3), erzeugen keine MDNs/NDNs. CommLog-Ereignisse bestehen aber nicht nur aus MDNs und NDNs, d. h. bei diesen Protokoll-Arten gibt es dennoch CommLog-Ereignisse, aber eben keine MDN-Ereignisse. Die Einstellung (2) ist deshalb bei diesen Protokollen wirkungslos.

(3) Auswahl der CommLog-Ereignisse für alle oder bestimmte Übertragungs-Protokolle.

(4) Auswahl der CommLog-Ereignisse für alle oder bestimmte Partner.

Vorlage für Quellstruktur und Rückgabewerte

Der Eingangsagent liefert XML-Daten. Stellen Sie im Profil bitte das Eingangsformat XML ein, mit dem Wert event für Feld XML-Tag für Datenblatt.

Laden Sie in Phase 3 über das Quellstruktur-Menü die XML-Vorlage CommLogEvent.

Nachfolgend beispielhafte XML-Eingangsdaten.

<?xml version="1.0" encoding="UTF-8"?>
<event>
	<id_event>1478274779834002</id_event>
	<id_entry>1478274779865005</id_entry>
	<id_channel>1470905156701141</id_channel>
	<id_partner>1470904732807002</id_partner>
	<remote_id>
		<address_attr>http://62.206.113.210:9191/</address_attr>
		<remote_id_val>MARBEHO-TEST</remote_id_val>
	</remote_id>
	<local_id>KNUSTAS2</local_id>
	<type>
		<code_attr>2</code_attr>
		<protocol_attr>1</protocol_attr>
		<protocol_subtype_attr>1</protocol_subtype_attr>
		<direction_attr>2</direction_attr>
		<type_val>message disposition notification</type_val>
	</type>
	<message_id>1449559883.94.1478274779709.JavaMail.SYSTEM@LobsterTestsystem</message_id>
	<resource>merbeho_ordersp_11037911.xml</resource>
	<result>
		<code>0/0</code>
		<text>null</text>
	</result>
</event>

Die dortigen Werte haben folgende Bedeutung.

Element	Bedeutung	Werte
direction_attr	Richtung	0: nicht spezifiziert 1: eingehend 2: ausgehend
message_id	Nachrichten-Typ	0: nicht spezifiziert 1: Message 2: MDN 3: NDN 4: Message pending (eingehend) 5: MDN pending (eingehend) 6: ACE-Request 7: ACE-Response
protocol_attr und protocol_subtype_attr	Protokoll-Typ und -Subtyp	0: Protokoll-Typ nicht spezifiziert 1: Protokoll-Typ AS2 2: Protokoll-Typ FTP 1: FTP plain 2: FTPS explizit 3: FTPS implizit 3: Protokoll-Typ OFTP 1: ISDN 2: TCP/IP 3: TCP/IP TLS 5: Protokoll-Typ MAIL 1: SMTP (eingehend oder ausgehend) 2: ASMTP 3: POP3 (eingehend) 4: IMAP 6: Protokoll-Typ SSH 1: SCP 2: SFTP 3: SSH remote 7: Protokoll-Typ X.400 2: Lobster X.400-Client 8: Protokoll-Typ Fax
code und text	Response Code und Response Text	Die Bedeutung von Response Code und Response Text ist protokollabhängig und wird direkt dem jeweiligen Protokollblock entnommen. Für AS2 gibt es beispielsweise folgende mögliche Codes: processed, processed/warning, processed/error und failure/error. Der Inhalt von Response Text ist nicht normiert und wird 1:1 aus der Antwort des Partners übernommen.