Defining Interfaces and Retention Periods for Archiving 

Use

This is where you define interfaces so that you can archive their XML messages. Manually modified or canceled messages are archived automatically.

Since processed messages are checked as either to be archived or to be deleted (and because this indicator cannot be changed), you must decide which messages you want to archive before the first message is processed.

You also enter the retention periods in the database of the followings objects:

·        Messages to be deleted

·        Messages to be archived

·        History entries for deleted messages

 

To periodically schedule jobs for archiving , in the Integration Engine menu, choose Administration ®  Schedule Archiving Jobs.

Defining Interfaces

To define interfaces for archiving, proceed as follows:

...

       1.      In the Integration Engine menu, choose Define Interfaces for Archiving and Retention Periods and enter the required interfaces. The system differentiates between sender and receiver interfaces at this point.

       2.      To include an interface in the list of interfaces displayed, enter the interface in the Name and Namespace fields, and choose Flag Interface for Archiving.

¡        You can enter the interfaces for archiving manually or by using the input help. The input help only offers you the interfaces and namespaces that are known to the Integration Directory. If you make an entry in either the Name or Namespace field, this is accounted for in the input help for both fields.

Since the interfaces that are to be archived depend on the respective applications, no default values are provided.

Enter FLIGHT* in the Name field. The input help for the Name and Namespace fields now only shows entries for interface names beginning with FLIGHT.

¡        To select multiple interfaces simultaneously, choose Multiple Selection. The system displays a table containing all interfaces known to the Integration Directory.

The table contains the interface type (Inbound/Outbound Interface), the name, and the namespace. In the Inbound/Outbound Interface column, O stands for a sender (outbound) interface and I for a receiver (inbound) interface.

You can select any number of entries in the table and add them to the list of interfaces to be archived by choosing Copy. You can use the filter function to restrict the number of interfaces displayed.

¡        It is also possible to include generic entries such as FLIGHT* in the list. You must enter the namespace in this case. The interface name is only determined when the interfaces you want to archive are determined at runtime.

Copy as few entries as possible using the input help. Use the generic entry option instead. Only specify fully qualified interfaces if lots of interfaces exist that have the same prefix, and you only want to archive one of them.

       3.      If you only want to archive the inbound version of the messages of an interface to be archived, select the checkbox under Inbound Message. If you do not select this checkbox, all existing message versions will be archived. Use the function buttons underneath the list of interfaces to be archived when selecting.

       4.      If you only want to archive the inbound version of the manually canceled messages of an interface, select the checkbox under Manually Canceled Message. If you do not select this checkbox, all existing message versions will be archived. Use the function buttons underneath the list of interfaces to be archived when selecting.

You can only select the checkbox under Manually Canceled Message if you have selected the checkbox under Inbound Message for the same interface. If you deselect the checkbox under Inbound Message, the checkbox under Manually Canceled Message will also be deselected (if already selected).

       5.      To delete an interface from the list, select the corresponding line and choose Delete Interface from List.

       6.      Save your changes.

The system displays a dialog box, in which you must specify a customizing request to transport the changes.

       7.      Specify or create a customizing request, and choose Continue.

Your changes are transported.

All selected interfaces are transported, regardless of the interface type, because the interface type (I or O) is not transferred to the customizing request.

In the customizing request, all underscores (_) in interface names are replaced by an asterisk (*) and all subsequent characters are rejected (for example, xyz_abc becomes xyz*).

Defining Retention Periods

To define retention periods for messages and history entries for messages in the database, proceed as follows:

...

       1.      On the Define Interfaces for Archiving screen, choose Retention Periods and enter in the corresponding fields the number of days that history entries marked for deletion or XML messages marked for deletion or archiving are to be retained in the database.

If you want processed synchronous XML messages without errors to be deleted immediately, enter 0.

       2.      Save your changes.

       3.      To transport you changes, in the Integration Engine menu, choose Integration Engine Configuration and then choose Change Specific Configuration Data.

The system navigates to a screen where the retention periods you specified are represented by the corresponding configuration data according to the following table:

Retention Periods

Message Type	Category	Parameter	Subparameter
Asynchronous messages without errors to be deleted	DELETION	PERSIST_DURATION	ASYNC
Asynchronous messages without errors to be archived	ARCHIVE	PERSIST_DURATION	ASYNC
Synchronous messages with errors to be deleted	DELETION	PERSIST_DURATION	SYNC
Synchronous messages without errors to be deleted	DELETION	PERSIST_DURATION	SYNC
History entries to be deleted	DELETION	PERSIST_DURATION	HISTORY

Choose Utilities ® Comparison and proceed as described in Comparing Customizing Objects.

Asynchronous XML messages to be deleted are retained in the database for 3 days. Asynchronous XML messages to be archived are retained in the database for 2 days.

The sender interface FlightBooking.Create is the only interface entered in the list.

Therefore, all XML messages that have the interface FlightBooking.Create as their sender are written to the archive and deleted from the database two days after they have been successfully processed.

All other XML messages are deleted from the database three days after they have been successfully processed.

XML messages that do not have the status Processed Successfully remain in the database.