
Hier legen Sie die Interfaces fest, deren Messages archiviert werden sollen.Manuell modifierte oder beendete Messages werden automatisch archiviert.
Da bereits verarbeitete Messages entweder als zu archivieren oder als zu löschen gekennzeichnet werden (und diese Markierung nicht mehr geändert werden kann), müssen Sie die Entscheidung, welche Messages archiviert werden sollen, noch vor der Verarbeitung der ersten Message treffen.
Zur nachträglichen Festlegung von Interfaces für die Archivierung steht der Report RSXMB_DEL_TO_ARCH zur Verfügung. Mit diesem Report können Sie Messages zu bestimmten Interfaces nachträglich zur Archivierung vorsehen.
Zudem geben Sie für folgende Objekte die Verweilzeiten in der Datenbank an:
Die Jobs für die Archivierung können Sie im Menü Integration Engine über Administration → Archivierungsjobs einplanen periodisch einplanen.
Um Interfaces für die Archivierung festzulegen, verfahren Sie wie folgt:
Da es von den jeweiligen Anwendungen abhängt, welche Interfaces archiviert werden sollen, werden keine Vorschlagswerte angeboten.
Sie geben im Feld Name FLIGHT* ein. Die Eingabehilfe für das Feld Name oder Namenraum zeigt nur noch Einträge, deren Interface-Name mit FLIGHT beginnt.
Die Tabelle enthält den Typ des Interfaces (Inbound/Outbound Interface), den Namen und den Namensraum. In der Spalte Inbound/Outbound Interface steht O für ein sendendes (Outbound) Interface oder I für ein empfangendes (Inbound) Interface.
Sie können beliebige Einträge in der Tabelle markieren und mit Übernehmen der Liste der zu archivierenden Interfaces hinzufügen. Über die Filterfunktion können Sie die Liste der angezeigten Interfaces einschränken.
Übernehmen Sie so wenig Interfaces wie möglich per Eingabehilfe, und nutzen Sie eher die Möglichkeit der generischen Eingabe. Geben Sie einzelne voll qualifizierte Interfaces nur dann an, wenn es sehr viele Interfaces mit dem gleichen Präfix gibt, Sie aber nur eines davon archivieren wollen.
Sie können das Ankreuzfeld unter Manuell beendete Message nur dann markieren, wenn Sie für das gleiche Interface bereits das Ankreuzfeld unter Eingangs-Message markiert haben. Wenn Sie für ein Interface die Markierung unter Eingangs-Message entfernen, wird folglich auch die Markierung (falls vorhanden) unter Manuell beendete Message entfernt.
Ein Dialogfenster erscheint, in dem Sie einen Customizing-Auftrag zum Transportieren der Änderungen angeben müssen.
Ihre Änderungen werden entsprechend transportiert.
Alle selektierten Interfaces werden unabhängig vom Interface-Typ transportiert, da der Interface-Typ (I bzw. O) nicht in den Customizing-Auftrag übernommen wird.
In dem Customizing-Auftrag werden alle Unterstriche (_) in Interface-Namen durch einen Asterisk (*) ersetzt und alle nachfolgenden Zeichen werden verworfen (zum Beispiel wird xyz_abc zu xyz* ).
Um die Verweilzeiten für Messages sowie für Historieneinträge zu Messages in der Datenbank festzulegen, verfahren Sie wie folgt:
Wenn fehlerfrei verarbeitete synchrone XML-Messages sofort gelöscht werden sollen, geben Sie eine 0 ein.
Sie gelangen in eine Sicht, in der die von Ihnen spezifizierten Verweilzeiten durch entsprechende Konfigurationsdaten gemäß folgender Tabelle abgebildet werden.
Verweilzeiten
| Art der Message | Kategorie | Parameter | Subparameter |
|---|---|---|---|
|
Fehlerfreie zu löschende asynchrone Messages |
DELETION |
PERSIST_DURATION |
ASYNC |
|
Fehlerfreie zu archivierende asynchrone Messages |
ARCHIVE |
PERSIST_DURATION |
ASYNC |
|
Fehlerhafte zu löschende synchrone Messages |
DELETION |
PERSIST_DURATION |
SYNC |
|
Fehlerfreie zu löschende synchrone Messages |
DELETION |
PERSIST_DURATION |
SYNC |
|
Zu löschende Historieneinträge |
DELETION |
PERSIST_DURATION |
HISTORY |
Wählen Sie Hilfsmittel → Vergleich und verfahren Sie wie in Vergleich von Customizing-Objekten beschrieben.
Die Verweildauer für zu löschende asynchrone XML-Messages beträgt 3 Tage, die für zu archivierende asynchrone XML-Messages beträgt 2 Tage.
In der Liste ist als einziges Interface das sendende Interface FlightBooking.Create eingetragen.
Hiermit werden alle XML-Messages, die als Sender das Interface FlightBooking.Create haben, zwei Tage nach ihrer erfolgreichen Verarbeitung ins Archiv geschrieben und aus der Datenbank gelöscht.
Alle anderen XML-Messages werden drei Tage nach ihrer erfolgreichen Verarbeitung aus der Datenbank gelöscht.
XML-Messages, die nicht den Status erfolgreich verarbeitet haben, bleiben in der Datenbank erhalten.