Checking the import log

Each time the DNF_L_IMP message flow processes an import command, it generates a log file. The name and location of the log file are determined by the -lf or -lfd parameter, which are mutually exclusive and which are described in import.

The properties of the log file are set as follows:
  • The owner is set to the user ID under which the broker runs, for example, uwmba1.
  • The access rights are set to rw-r--r--.
Each log file is a character separated value (CSV) file. Such files can be viewed and processed using a spreadsheet program. The delimiter used to separate the columns of a log file is the semicolon (;). The content of an import file is divided into the following sections:
  • General information about the import command that was issued
  • One row containing the headings for the data value columns
  • One separator row consisting of dashes (-)
  • Rows of data values separated by semicolons (;)
The general information looks similar to this:
Import file: /u/rma/rm_import.xml
Command issued: 2025-01-01 11:48:47
File mode: Partial
where:
Import file
Provides the distribution file that was imported.
Command issued
Date and time, in Coordinated Universal Time (UTC), when the import command was issued. The format is YYYY-MM-DD HH:MM:SS.
File mode
The file maintenance status of the distribution file that was imported. This can be either Complete or Partial.
If file mode is Complete, then following lines are also shown:
Delete operation performed for the following BICs and services:
BICs: '<BIC8 list>'
Services: '<service list>'
where:
<BIC8 list>
A comma-separated list of own BIC8 for which the distribution file was created.
<service list>
A comma-separated list of SWIFT services for which there were authorisations in the distribution file.
These lines indicate that, before records were imported, all RM records in the RMDS that referred to any combination of these SWIFT services and one of the BIC8s as own BIC8s were deleted.
Each data value row corresponds to one RM record in the distribution file. The columns of each row are:
OU
The OU to which the RM record refers.
issuer
The BIC8 that sent the authorisation. For authorisations of type Issued, this is the own BIC8. For authorisations of type Received, this is the correspondent BIC8.
correspondent
The BIC8 that received the authorisation. For authorisations of type Issued, this is the correspondent BIC8. For authorisations of type Received, this is the own BIC8.
service
The name of the SWIFT service:
swift.fin
For live authorisations.
swift.fin!p
For test and training (T&T) authorisations.
type
The type of authorisation:
Issued
Specifies who can send messages to the own BIC8.
Received
Specifies to whom the own BIC8 can send messages.
validity_start
The date from which the authorisation is to be used. The format is YYYY-MM-DD.
validity_end
The date up to which the authorisation is to be used. The format is YYYY-MM-DD.
datetime_issued
The date and time when the authorisation in the import file was exchanged the last time. The format is YYYY-MM-DD-HH.MM.SS.
action
The action that was performed on the RM record during import processing:
none
The RM record was not imported from the distribution file into the RMDS. Possible reasons are described in Importing authorisations.
insert
The RM record is new and was inserted into RMDS.
update
The RM record was already in the RMDS and was modified.
datetime_issued_rmds
The date and time when the authorisation in RMDS was exchanged the last time. The format is YYYY-MM-DD-HH.MM.SS. This column contains a value only if the value in the action column is none.
status_rmds
The status of the authorisation record in the RMDS:
Enabled
The authorisation is in use.
Rejected
The authorisation is not in use because it was not accepted when it was sent by the correspondent BIC.
Revoked
The authorisation is not in use because the correspondent BIC has revoked it.
Deleted
The authorisation is not in use because it was deleted.
This column contains a value only if the value in the action column is none.
status
The status of the authorisation record in the distribution file. The possible values are the same as for the status_rmds column. This column contains a value only if the value in the action column is none.
permissions
The list of allowed types or of excluded types as specified in the distribution file.
Figure 1 shows an example of an import log as viewed in a spreadsheet program. To improve readability, some columns were omitted.
Figure 1. Example of an import log
Import file: /u/rma/rm_import.xml
Command issued: 2022-08-21 21:43:57
File mode: Partial
issuer   correspondent datetime_issued      action  datetime_issued_rmds status_rmds status
-------------------------------------------------------------------------------------------
IBMADEFF IBMCDEFF      2022-07-31-18.30.00  insert                                         
IBMADEFF PTSATWFG      2022-07-31-18.30.00  none    2022-07-31-18.30.00  Enabled     Enabled
PTSATWFG IBMADEFF      2022-07-31-18.30.00  none    2022-08-18-00.00.00  Enabled     Revoked
PTSATWFG IBMCDEFF                           none                         Rejected    Enabled
PTSATWFH IBMCDEFF      2022-07-31-18.30.00  update
This log indicates:
  • The RM distribution file /u/rma/rm_import.xml was imported in file mode Partial on 21 August 2022 at 21:43:57 UTC.
  • The first RM record was inserted into RMDS because it did not yet exist in the RMDS.
  • The second RM record was not imported because:
    • The issue timestamps (2022-07-31-18.30.00) in the distribution file and in the RMDS are identical
    • The state (Enabled) in the distribution file and in the RMDS is identical
  • The third RM record was not imported because the issue timestamp in the distribution file (2022-07-31-18.30.00) is older than the issue timestamp in the RMDS (2022-08-18-00.00.00).
  • The fourth RM record was not imported because the issue timestamps in the distribution file and in the RMDS are identical (both are unspecified), but the status value in the RMDS is not Enabled.
  • The fifth RM record was updated in the RMDS because the issue timestamp in the distribution file was greater than the issue timestamp in the RMDS.