Kurzbeschreibung

Dieser Service wird entweder täglich oder in vorgegebenen Intervallen ausgeführt (SCHEDULER) und archiviert alle erfolgreich beendeten Nachrichten (SUC / MAN) innerhalb eines definierten Zeitraumes. Falls nur gewisse Systeme archiviert werden sollen so kann man diese in einer Property angeben. Der MIME-Stream der Nachricht wird auf das Filesystem/ins Archiv geschrieben und die Metadaten in einen Index indiziert . Alle archivierten Dateien erhalten eine Disc als Symbol im Nachrichtenmonitor. Durch eine zusätzliche Checkbox im NachrichtenMonitor kann nun auch, wie gewohnt, im Index gesucht werden. Soll eine Nachricht bei der Archivsuche zur Anzeige gebracht werden, wird über die Archiv-ID (in der Regel die Message-ID), die im Index abgelegt ist, aufs Archiv zugegriffen.

Einrichtung

Konfiguration, allgemein

Der Service ist ein SCHEDULER-Service.

Als Service-Klasse wird org.b2bbp.service.inbound.scheduled.SchedulerRegisterService angegeben.

Konfiguration, Service-Properties

Scheduler-Konfiguration

Zunächst muss der SCHEDULER-Service konfiguriert werden. (siehe SCHEDULER-Service-Doku).
Als Serviceklasse muss folgende Property gesetzt werden:

Konfiguration des Archivierungsintervalls

Folgende Properties sind zur Konfiguration vorgesehen, in welchem Zeitraum Nachrichten archiviert werden sollen.
(***) einer dieser beiden Werte muss gesetzt sein.

Konfiguration der zu archivierenden Nachrichten

Folgende Properties sind zur Konfiguration vorgesehen, welche Nachrichten archiviert werden sollen.

Falls die AttributID auf B3P_ARCHIVE_FILESERVICE gesetzt wurde und außerdem an der FileWriterAction o.ä. B3P_ARCHIVE_FILESERVICE=true in den MessageContext geschrieben, oder am FileService B3P_ARCHIVE_FILESERVICE=true gesetzt wurde, werd das Attribut B3P_BASE_MESSAGE_EDI bzw. B3P_BASE_MESSAGE archiviert.

Das wird benötigt, falls Nachricht nicht per Mail empfangen bzw. gesendet wurde und damit keine B3P_MIME_MSG_MAIN gespeichert wurde.

Liste der für die Archivierung relevanten ATTRIBUTIDS und IndexSuffixes. Nicht alle diese Attribute müssen archiviert werden: zum Beispiel ist die Archivierung von verschlüsselten Streams selten sinnvoll.

B2B Nachrichten Attribut-Ids für die Archivierung von AS4-Nachrichten

Diese Attribute befinden sich nicht in der ATTRIBUTE_ARCHIVE Tabelle. Daher ist die Eigenschaft B3P_ARCHIVE_NON_MIME auf true zu setzen.

Distribution Indizieren/Archivieren

Mit diesen Properties besteht die Möglichkeit zu wählen, welche AttributeIDs indiziert bzw. archiviert werden sollen. Diese Properties müssen nicht gesetzt sein. Sie dienen lediglich dazu eine Distribution zu ermöglichen. (->TMS)

Konfiguration der Indexer-Klasse

Zu dem Indexer müssen noch folgende Konfigurationen in den GLOBAL PROPERTIES vorgenommen werden.

(*): Die Archvierung der Clearinghistorien wird bei folgenden Archivesystemen unterstützt:

• ArchiveFileSystem
• ArchiveFileSystemGUIDExternalPerDay
• ArchiveFileSystemSeparate
• ArchiveFileSystem_ZipPerDay
• ArchiveNscale
• ArchiveIxos

Konfiguration der Property B3P_ARCHIVE_SYSTEMS

Falls nur bestimmte Systeme archiviert werden sollen so kann man diese in der Property B3P_ARCHIVE_SYSTEMS angeben dann werden nur noch die durch die ILN Nummern gegebene Systeme archiviert. Die Property könnte folgenden Inhalt haben:

9903078000005;9900563000003

Durch das setzten der Property B3P_ARCHIVE_SYSTEMS_PRE_FIX auf NOT wird die Property negiert das heißt es werden alles Systeme archiviert welche nicht angegeben sind.

Konfiguration der Property B3P_ARCHIVE_CHANNELS

Falls nur Nachrichten in bestimmten Channels archiviert werden sollen so kann man dies mit der Property B3P_ARCHIVE_CHANNELS machen. Dazu in der Property die Channels durch ; getrennt angeben. Die Property könnte folgenden Inhalt haben:

INBOUND_SOPTIM; INBOUND_SAP

Durch das setzten der Property B3P_ARCHIVE_CHANNELS_PRE_FIX auf NOT wird die Property negiert das heißt es werden nur Nachrichten archiviert welche nicht in den angegeben Channels sind.

Konfiguration der Property B3P_INDEX_ONLY_CHANNELS

Sollen die gesplitteten Nachrichten aus den Splitchannels indexiert warden, so kann man die Splitchannels mit Komma oder Semikolon separiert in dieser Property angeben. Diese Nachrichten werden dann nach der Archivierung des entsprechenden Zeitraums indexiert, jedoch nicht archiviert (weil der Beleg bereits mit der Ursprungsnachricht archiviert wurde).

Archivierung von Nachrichten ohne Eintrag in ATTRIBUTE_ARCHIVE Tabelle

Es kann vorkommen, dass aufgrund von Fehlern o.ä. kein Eintrag in die ATTRIBUTE_ARCHIVE Tabelle vorhanden ist. In diesem Falle lässt sich die B3P_BASE_MESSAGE bzw. CURRENT_PAYLOAD archivieren. Dafür alle Attribute, die archiviert werden sollen mit in die Property B3P_ARCHIVE_MSGS aufnehmen und folgende Property hinzufügen:

B3P_ARCHIVE_NON_MIME=true

Konfiguration der Property B3P_ARCHIVE_STATES

Standardmäßig werden nur Nachrichten mit dem Verarbeitungssatatus SUC und MAN archiviert. Sollen auch Nachrichten mit einem anderen Status archiviert werden, so kann man das in der Property B3P_ARCHIVE_STATES angeben. Sollen z.B. zusätzlich Status ERR berücksichtigt werden, so setzt man die Property auf:

SUC;MAN;ERR

Bereits archivierte Nachrichten (Status ARC) werden aber immer übersprungen, selbst wenn man diesen Status angibt. Um die Archivierung bei solchen Nachrichten zu wiederholen, muss man sie davor auf den Status “Manuell Beendet” MAN setzen.

Konfiguration des Export-Klasse

Angabe des Export –Klasse, z.B.: Exportieren der Daten aufs FileSystem, oder an ein Archiv. Wird diese Property nicht gesetzt, wird nicht exportiert.

Dazu muss der voll qualifizierende Klassenname der zugehörigen Implementierung angegeben werden.

Folgende Unterabschnitte listen die zur Verfügung stehenden Implementierungen und Klassennamen. Zudem werden die zusätzlichen Konfigurationen angegeben.

ArchiveFileSystem

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileSystem

Diese Klasse archiviert die Nachrichten auf dem Dateisystem in einem Ordner. AS2 chiffrierte Nachrichten werden mit der Dateiendung ‚.crypt‘, AS2 dechiffrierte Nachrichten mit der Dateiendung ‚.decrypt‘, alle anderen Nachrichten mit der Dateiendung ‚.txt‘ gespeichert. Als Dateiname dient die Mail-Message-ID.

Zu dieser Exportklasse müssen noch folgende Konfigurationen in den GLOBAL PROPERTIES vorgenommen werden.

(*) : Diese Properties müssen nur gesetzt werden, wenn Suche im Index/Archiv aus dem Nachrichtenmonitor gewünscht ist.

(**): Diese Property muss nur gesetzt werden, wenn AS2 Nachrichten archiviert werden.

ArchiveFileSystemSeparate

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileSystemSeparate

Diese Klasse archiviert die Nachrichten ebenfalls aus dem Dateisystem, allerdings den jeweiligen Nachrichtentyp (UTILMD, MSCONS,…) in separaten Ordnern. Eine Anzeige der Nachrichten in Nachrichtenmonitor ist bisher nicht implementiert.

Zu dieser Exportklasse müssen noch folgende Konfigurationen in den GLOBAL PROPERTIES vorgenommen werden.

ArchiveFileSystemZIP

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileSystemZIP

Diese Klasse archiviert die Nachrichten in ein Zip-Archiv. Pro Archivierungslauf wird ein neues Archiv erstellt. Optional besteht die Möglichkeit eine Obergrenze der im Archiv enthaltenen Dateien anzugebe. In diesem Fall wird beim Erreichen der Obergrenze ein neues Zip-Archiv angelegt.

In den ServiceProperties des ArchivJob kann optional folgende Property angegeben werden.

Für beide Einstellungen gilt:

• Format: ganze positive Zahl > 0; Beispiel: 1000
• Anmerkung: Ist diese Property nicht gesetzt, wird pro Joblauf ein Archiv erstellt.

Zu dieser Exportklasse müssen noch folgende Konfigurationen in den GLOBAL PROPERTIES vorgenommen werden.

(*) : Diese Properties müssen nur gesetzt werden, wenn Suche im Index/Archiv aus dem Nachrichtenmonitor gewünscht ist.

(**): Diese Property muss nur gesetzt werden, wenn AS2 Nachrichten archiviert werden.

ArchiveFileSystemZipInSubfolders

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileSystemZIPInSubfolders

Diese Klasse verhält sich bis auf 2 Unterschiede genau wie ArchiveFileSystemZIP. Die Unterschiede sind:

• Die ZipArchive werden in einem zu konfigurierten temp-Verzeichnis erstellt und nachdem das Archiv geschlossen wurde an den Zielort kopiert
• Die Files werden in Unterverzeichnissen des Export-Verzeichnis angelegt, die als Namen die ersten 3 Zeichen des Filenamens tragen.

In den ServiceProperties sind folgende Einstellungen möglich.

Zu dieser Exportklasse müssen noch folgende Konfigurationen in den GLOBAL PROPERTIES vorgenommen werden.

(*) : Diese Properties müssen nur gesetzt werden, wenn Suche im Index/Archiv aus dem Nachrichtenmonitor gewünscht ist.

(**): Diese Property muss nur gesetzt werden, wenn AS2 Nachrichten archiviert werden.

ArchiveFileSystemGUIDExternalPerDay

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileSystemGUIDExternalPerDay

Diese Klasse archiviert die Nachrichten in eine definierbare Ordnerstruktur. Die Archivstruktur ist, wie folgt aufgebaut:

WURZELVERZEICHNIS/MANDANT/JAHR/MONAT/TAG

Pro Tag wird ein neues Verzeichnis erstellt. Pro Tagesverzeichnis werden maximal eine konfigurierbare Anzahl an Nachrichtenpaaren / Trillingen geschrieben (max. 7500 Trillinge) und dann ein neuer Ordner geöffnet (TAG.1 ,TAG.2 usw). Die Archivierung der externen Nachrichten und der Logdateien lassen sich in den Serviceproperties an und ausschalten.

In den ServiceProperties des ArchivJob kann optional folgende Property angegeben werden.

Zu dieser Exportklasse müssen noch folgende Konfigurationen in den GLOBAL PROPERTIES vorgenommen werden.

ArchiveFileSystemSeparateTemporal

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileSystemSeparateTemporal

Diese Klasse archiviert Nachrichten in verschiedene Ordner je nach Archivierungszeitpunkt. In den Service-Properties kann konfiguriert werden, wie viele Ordner pro Stunde erstellt werden.

Eine Anzeige im Monitor ist nicht möglich.

Beispiel: Werden 4 Ordner pro Stunde erstellt, dann wird eine Nachricht, die zwischen 10:00 und 10:15 archiviert wird in den Ordner ‘1000’ geschrieben. Eine Nachricht, die zwischen 11:15 und 11:30 archiviert wird in den Ordner ‘1115’ geschrieben usw. .

Hinweis: Falls die Ordner noch nicht existieren, werden diese erstellt.

Gleichzeitiges Laden von archivierten Nachrichten, die durch unterschiedlich Systeme archiviert wurden

Um gleichzeitig Nachrichten, die durch unterschiedliche Archiv-Systeme archiviert wurden, laden zu können, muss die folgende Extension ergänzt und müssen die folgenden drei GLOBAL PROPERTIES konfiguriert werden.

(*): Bisher wird hier nur der Wert “ArchiveFileSystemZIP;ArchiveGUIDPerDayZIP” unterstützt.

ArchiveFileNet

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveFileNet

Diese Klasse archiviert die Nachrichten in ein FileNet-Archiv. Bisher ist nur ein Speichern ins Archiv implementiert, es ist kein erneutes Anzeigen im Nachrichtenmonitor möglich.

Es werden folgende Serviceparameter benötigt:

ArchiveIxos

Klasse: com.nextlevel.b2bbp.ixos.ArchiveIxos

Diese Klasse archiviert die Nachrichten in ein IXOS-Archiv.

Nach der Änderung aller unter aufgeführten Einstellungen muss die B2B neu gestartet werden.

Folgende GLOBAL PROPERTIES müssen gesetzt werden:

(*) : Diese Properties müssen nur gesetzt werden, wenn Suche im Index/Archiv aus dem Nachrichtenmonitor gewünscht ist. (**): Diese Property muss nur gesetzt werden, wenn AS2 Nachrichten archiviert werden.

Falls die Daten gezipped in das Archiv geschrieben werden sollen, muss folgende Global Property gesetzt werden:

Falls die Archivaufrufe signiert werden sollen, werden folgende Global Properties benötigt:

Des Weiteren muss der Private Key als Extension unter B3P_IXOS_PRIV_KEY sowie das Zertifikat als Extension unter B3P_IXOS_CERT hinterlegt werden.

Falls für unterschiedliche SystemMpids unterschiedliche Archive verwendet werden sollen, kann eine Extension B3P_IXOS_MPID_MAPPING angelegt werden.

Die Einträge der Extension sehen folgendermaßen aus:

systemMpid=http://10.100.50.200:8080/archive;0046;GX
systemMpid2=http://10.100.50.200:8080/archive;0046;FX

Falls für unterschiedliche FormatTypes unterschiedliche Archive verwendet werden sollen, kann eine Extension B3P_IXOS_BDEW_TYPE_MAPPING angelegt werden.

Die Einträge der Extension sehen folgendermaßen aus:

# Key durch formatType [erst ab 05.2023]
formatType=http://10.100.50.200:8080/archive;0046;FX
formatType2=http://10.100.50.200:8080/archive;0046;FX

Falls kein passender Eintrag gefunden wurde, wird das Archiv verwendet, was per Global Properties definiert wurde. Die Zusammenarbeit der beiden Extensions B3P_IXOS_MPID_MAPPING und B3P_IXOS_BDEW_TYPE_MAPPING ist nicht vorgesehen.

Weiterhin können die folgenden Eigenschaften zur Performanceverbesserung gesetzt bzw. angepasst werden. Die Eigenschaften werden in der Extension B3P_IXOS_MPID_MAPPING als key-value-Paare gesetzt (key=value). Weitere Information zu diesen Eigenschaften sind hier nachzulesen: HttpConnectionParams.

Die Ixos Doku ist unter http://help.sap.com/… zu finden. Interessant für die http Schnittstelle ab Seite 242. Für Signatur zusätzlich Seite 292.

ArchiveSer

Klasse: com.nextlevel.b2bbp.ixos.ArchiveSer

Der ArchiveSer ist eine Varinate des ArchivIxos, der anders konfigurierte Header bei der Übergabe an das Archivsystem verwendet, aber gleich konfiguriert wird.

ArchiveReturnMimeId

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveReturnMimeId

Die Archivierung der Emails wird extern (nicht über die B2B) durchgeführt. Aus der B2B sollen aber die Absprünge ins Archivsystem realisiert werden.

Dafür wird die Archivierung simuliert (wie üblich mit der ArchiveJob). Dabei wird aber nur die MimeID im Archvie-Index gespeichert und auch als Archive-ID verwedet.

siehe auch: Verlinkung eines externen Archivsystems über die Email-Anhangnamen

ArchiveSelectiveAndReturnInnerArchiveId

Klasse: org.b2bbp.service.inbound.scheduled.ArchiveSelectiveAndReturnInnerArchiveId

Der ArchiveSelectiveAndReturnAttachmentName dient dazu auf Systemen, auf denen der Großteil der Archivierung nicht von der B2B übernommen wird, verbleibende zu archivierende Attribute unter der passenden ArchivID zu sichern. Bisher einzig bekannter Einsatz ist, den zuvor genannten ArchiveReturnMimeId zu benutzen um versandte PDFs zu archivieren.

Konfigurationen

B3P_ARCHIVE_MSGS, B3P_ARCHIVE_MSGS_ONLY und B3P_INDEX_MSGS_ONLY werden nicht unterstützt.

DummyArchive

Mithilfe des DummyArchive Archivsystems kann der ArchivJob dazu genutzt werden, Nachrichten auf ARC zu setzten. Das DummyArchive Archivsystem schreibt keinerlei Nachrichten in ein Archivsystem. Eine Indizierung der Nachrichten findet trotzdem statt.

Klasse: org.b2bbp.service.inbound.scheduled.DummyArchive

Parameter: VS_STATE

Mithilfe des Parameters kann den “erfolgreich” Archiverten Nachrichten ein beliebiger VS-Status gegeben warden, z.B. ARP oder ARC