Flat File Interfaces in SAP: Applies To

Flat File Interfaces in SAP

Applies to:
Flat File Interfaces
Summary
To implement a flat file interface, the following CLIENT standards are applicable:
each interface needs to have an interface identification
data of the interface is stored in a customer table (interface catalogue)
the directory location is stored in a logical file, the logical file name is stored in the customer table
when running the interface, we record the start and end date and time, status in a history table
there are standards for file names, and these are generated automatically by the interface start function
the middleware system does the file transfer based upon the filename
the security/authorization can be determined on the logical file path
Author(s): Aveek Ghose
Company: IBM India
Created on: 20/11/2006
Author Bio
Aveek has 12 years experience in IT and has worked in SAP projects across the Globe..
Aveek has a MS in Information Systems from George Mason University ( USA ) and a MS in
Economics from Virginia Tech in the USA. Currently he is working in IBM India as a
Consultant.
.
SAP DEVELOPER NETWORK | sdn.sap.com

2006 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

1
Table of Contents
Applies to: ........................................................................................................................................ 1
Summary.......................................................................................................................................... 1
Author Bio ........................................................................................................................................ 1
The use of Flat File Interfaces in the CLIENT environment ............................................................ 3
Interface identification...................................................................................................................... 3
CLIENT Interface Identification table............................................................................................... 4
Logical file name .......................................................................................................................... 4
Physical file path - name .............................................................................................................. 5
Programming standards for file handling......................................................................................... 6
Error handling .................................................................................................................................. 8
Screen Shots of Interface tables and parameters of Function modules: ........................................ 9
Related Content............................................................................................................................. 12
Disclaimer and Liability Notice....................................................................................................... 12

2006 SAP AG

2
The use of Flat File Interfaces in the CLIENT environment

To implement a flat file interface, the following CLIENT standards are applicable:
each interface needs to have an interface identification
data of the interface is stored in a customer table (interface catalogue)
the directory location is stored in a logical file, the logical file name is stored in the customer table
when running the interface, we record the start and end date and time, status in a history table
there are standards for file names, and these are generated automatically by the interface start function
the middleware system does the file transfer based upon the filename
the security/authorization can be determined on the logical file path
Interface identification
Each batch interface will be uniquely identified by an interface key. The key consists of 3 parameters and
logically describes the source, destination and content of any interface file.
Organizational Unit : This represents the logical business unit within Client that is responsible for the
interface. This could be the CLIENT center, a region, a market or a subsidiary within a market.
Example :
CH11
0000
CLIENT Center Globally managed interface
Client Suisse SA
GB11 Client UK (tbc)

For outbound interfaces the organizational unit indicates the origin of the data. For inbound interfaces the
organizational unit identifies the destination of the data.
For each organizational unit a separate batch schedule will be set up with the holiday and factory calendar
specific to that region/market/subsidiary. For this reason we will make use of company codes to describe the
organizational unit. In case the organizational unit is not a legal Client entity (e.g. the AMS region as a whole)
we will make use of dummy company codes and maintain these in a separate table.
External system / partner : This represents the name of the external partner or legacy system that
receives/sends the interface file. This can correspond to an actual legacy system or can be the name of an
EDI partner.
For the naming conventions of this external systems, see the document of the basis team for external
systems (see also appendix).
The external system / partner needs to be stored in customer table /EUR/XEEXTPAR: CLIENT External
Partner Master (see also appendix).
Interface Identifier : This describes the type of message being sent to/from the external partner. It is
effectively a unique name for a CLIENT standard plug-in.

2006 SAP AG

3
Example :
CSORD01
EDI order interface
CSINV01
EDI invoice interface
FICAR01
CARAT Common interface POPL message
The interface identifier describes what kind of data is in the file.

The interface identifier needs to be stored in customer table /EUR/XEINTMAS: CLIENT Interface ID Master.
Naming convention for this field is now PPDMMMMMNN
Where:
PP -
Process area e.g. FI
D-
Direction (I - Inbound; O - Outbound)
MMMMM Message content (ORD - Orders, PRDPL - Product P&L, etc). Essentially 5 bytes to
describe the message.
NN Sequence number. This is used to uniquely identify interface programs with similar content.
Example - Both R/3 core and CRM have orders inbound interfaces.
For each interface the 3 parameters above answer the following questions :
Who is the data from?
(organizational unit for outbound / External system for inbound)
Who is the data for?
(organizational unit for inbound / External system for outbound)
What data is in the file? (interface identifier)

These three identifiers will be used to save the specific information about the interface, to save the run
history and it is also used in the filename, and consequently in the middleware system as routing
mechanism.
When a new interface is created, you first have to check that there is not an existing interface. Therefore you
need to contact interface coordinator. This person will check the interface catalogue and check for similar
interfaces and he will give the name of the external system and the interface identifier to be used for the new
interface.
CLIENT Interface Identification table

All interfaces are stored in this CLIENT Interface Identification table: see table /EUR/XEINTID in section 2.
For maintenance, see transaction SM30 for this table.
The interface coordinator is owner of this table but each development coordinator is for having the right
entries in this table for his own interfaces.
Logical file name
The standards of the logical file name are described in a document of the basis team (see also appendix).
See above: shortcut to document: Standards-SIDLogicalSystemsClients.
Use transaction FILE to create the logical file.

2006 SAP AG

4
The following set-up is used in CLIENT:

-> no logical path definition is created
-> all information is stored in the logical file name definition
See picture below.
Physical file path - name

The standards for the physical file path are stored in the following document: (See also appendix).
See above: shortcut to document : Standards-SIDLogicalSystemsClients.
The concept of the interface identification key is maintained also in the file name. This will reduce complexity
within SAP and will give the adapter a key with which to determine routing information for the middleware.
The file name consists of :
[ORGANIZATIONAL UNIT] .
[EXTERNAL SYSTEM] .
[INTERFACE IDENTIFIER] .
[SEQUENCE NUMBER] . DAT
For example an interface with
Organizational unit = Client Suisse (CH11)
External system = CHEINFO+
Interface identifier = FIOTRPRC01
with file number 176
will have as file name : CH11. CHEINFO+. FIOTRPRC01.000000000176.DAT
The middleware system normally uses only the organizational unit, external system and interface identifier to
identify the correct route for the file.

2006 SAP AG

5
Programming standards for file handling

When the file starts, we have to call function /EUR/X_INTERFACE_START_PROC.
When ending the interface, we have to call function /EUR/X_INTERFACE_END_PROC.
We have a specific header and footer: see structure
/EUR/XINTERFACE_FOOTER and structure /EUR/XINTERFACE_HEADER.
/EUR/X_INTERFACE_START_PROC
The function has the following importing parameters:
BUKRS
: Organizational unit
INTID
: Interface identifier
PARNUM
: Partner number
INPUT_FILENAME
: Local file for upload/download
PARALLEL_RUNS_ALLOWED
: Parallel runs allowed = 'X', if the flag is set, the last interface run is
not checked to not have status 'in process'.
NORMAL_RUN
: Run mode normal = 'X', if the flag is not set, the function assumes it is a rerun and
it will get validated with the last sequence number and no new entry will be created in the history table
TEST_RUN
NO_SEQ_CHECK
for inbound files
: Test run = 'X': if set, there is not updating of the history table
: No sequence check = 'X', if set, there is no check on the sequence number
NO_HEAD_FOOTER
: No header nor footer, if set, no checks are performed on the header or
footer, and the header and footer are not removed
Exporting parameters:
XEINTID
PHYSICAL_FILENAME
: CLIENT Interface Identification table

: Logical file name
HEADER
: Interface header record
Table parameters:
INPUT_FILE
: EDI Interface file structure
Functionality of the Function Module.

Based upon the organizational unit, interface identifier and partner number, table /EUR/XEINTID is read.
This gives the specific interface information.
All interface information for this interface is selected by the history table /EUR/XEINTHIS and sorted by date
and time
If the flag PARALLEL_RUNS_ALLOWED is not set, then we check that the last specific interface run is not in
status 'In process'.

2006 SAP AG

6
The header records is now filled using the information from /EUR/XEINTID, the date and time is set to the
current date and time. The sequence number is the current sequence number of the last interface added by
1.
We get the physical path using function FILE_GET_NAME using the logical file name stored in table
/EUR/XEINTID. For inbound interfaces, the physical path is concatenated with the file name. For outbound
interfaces, the same is done if the filename is not empty. If the filename INPUT_FILENAME is empty, the
following filename is built:
physical path + XEINTID-BUKRS + '.' + XEINTID-PARNUM '.' + XEINTID-INTID + '.' + new sequence
number + '.DAT'
If it is inbound interface, some additional checks are done:
The file is opened and completely read into table parameter INPUT_FILE.
If the flag NO_HEAD_FOOTER is not set and NORMAL_RUN is set, the header is read and checked: record
type, sequence number, partner number. The footer records is also read and checked: record type is
checked and also the number of records
The header and the footer are removed from the table parameter INPUT_FILE.
If the TEST_RUN parameter is empty, then the history table /EUR/XEINTHIS is updated with the current
date and time if the status is not 'in process', otherwise the time stamp is not changed.
During Inbound interface processing the HEADER and FOOTER are provided in the file.
During Outbound interface processing
The HEADER will be built by function module /EUR/X_INTERFACE_START_PROC, but will still need to be
written into the file by the interface code
The FOOTER record needs to be built and written into the file by the interface code.
/EUR/X_INTERFACE_END_PROC
This function is to be called at the end of the interface processing.
The function has the following importing parameters:
HEADER
: Interface header record
STATUS
: Status
RECCT
: Total records of the file
TRANS
: Number of transactions
ERRCT
: Number of incorrect transactions
TEST_RUN
: Test run
MEMHOLD
TYPE : Free Text (e.g. last record processed)
There are no export parameters nor table parameters.

The following statuses are valid:
'in process' : 1
'successfully finished' : 2
2006 SAP AG

7
'failure': 3
The function updates the specific record using the HEADER record information in the history table
/EUR/XEINTHIS. If the status is not in process, then the current date and time is set, otherwise the time
stamp is not changed.
Error handling
The /EUR/X_INTERFACE_START_PROC function and the /EUR/X_INTERFACE_END_PROC function
return specific exceptions back to the calling program whenever errors for these functions.
The calling program can decide how to handle this exceptions. However, if an entry is already made in the
history table, the purpose is to set the status to 3:failure. If there were no errors, the status should be set to
2: success. This change is done when you call the /EUR/X_INTERFACE_END_PROC function with the
proper import parameters.
If an interface has the status in process and a new interface run is requested with the option
PARALLEL_RUNS_ALLOWED = space, then an the interface start function will return an exception. In this
situation, the entry in the history table with the status in process has to be checked and if there is not
interface running anymore and all reconciliation activities have taken place, the status should be changed in
the table.
It is possible to code (within the interface program itself) sending the output report via SAPMail to designated
users in the case of error. The fields /EUR/XEINTID-BUS_AGENT_TYPE, /EUR/XEINTID-BUS_AGENT,
/EUR/XEINTID-IS_AGENT_TYPE, /EUR/XEINTID-IS_AGENT are used to determine where the output
should be directed. The EDI Orders interface program /EUR/VGTRB_EDI_ORDERS_INT is a good example
of this functionality.
HEADER RECORD
Regardless of the content of the file, the first record of any interface flat file should always be the HEADER
record. It consists of the following fields :
Field
Description
Type
Size
Valueset / Example
RECTYPE
Record type
CHAR
10
'HEADER'
BUKRS
Organizational Unit
CHAR
e.g.: '0937' (Client Suisse)
PARNUM
External partner / system
CHAR
10
e.g.: 'CARAT'
INTID
Interface Identifier
CHAR
12
e.g.: 'CSINV01'
SEQNO
File sequence number (table

XEINTHIS keeps log of previous
sequence numbers for this
interface)
NUMC
12
e.g.: '000000000005'

2006 SAP AG

8
BEGDA
File creation date
DATS
YYYYMMDD
BEGTI
File creation time
TIMS
HHMMSS
This record is defined as structure /EUR/XINTERFACE_HEADER in the data dictionary.

FOOTER RECORD
Regardless of the content of the file, the last record of any interface flat file should always be the FOOTER
record. It consists of the following fields :
Field
Description
Type
Size
Valueset / Example
RECTYPE
Record type
CHAR
10
'FOOTER'
RECORDS
Total number of records in file
NUMC
12
e.g.: '000000000100'
TRANS
Total number of LUWs in file
NUMC
12
e.g.: '000000000025'
CHKSUM
Control checksum value (is based

on a control algorithm)
NUMC
25
e.g.: '000000000012586'
This record is defined as structure /EUR/XINTERFACE_FOOTER in the data dictionary.
Screen Shots of Interface tables and parameters of Function modules:

2006 SAP AG

9

2006 SAP AG

10

2006 SAP AG

11
Related Content
Please include at least three references to SDN documents or web pages
Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces
and therefore is not supported by SAP. Changes made based on this information are not supported and can
be overwritten during an upgrade.
SAP will not be held liable for any damages caused by using or misusing the information, code or methods
suggested in this document, and anyone using these methods does so at his/her own risk.
SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of
this technical article or code sample, including any liability resulting from incompatibility between the content
within this document and the materials and services offered by SAP. You agree that you will not hold, or
seek to hold, SAP responsible or liable with respect to the content of this document.

2006 SAP AG

12

Flat File Interfaces in SAP: Applies To

Uploaded by

Flat File Interfaces in SAP: Applies To

Uploaded by

Flat File Interfaces in SAP