This guide is intended for those responsible for the setting up and maintenance of  the EDI interface which allows the exchange of EDI messages between the SAP system and the EDI Subsystem. This document should be read in conjunction with the “EDI SAP Setup Guide”. The “EDI Partner Setup” guide should also be read if problems related to EDI Trading Partner Configuration are encountered, and this role is not being performed separately.

1.1.            Roles using this Procedure

This role is not defined since it will not be performed as a routine exercise.

1.2.            Assumptions

Various assumptions are made in this guide regarding the architecture, platforms and software used in EDI interfacing. These include:

• The configuration of the EDI component of SAP is consistent across all platforms.

• The functionality of the version of SAP used is identical to the version used for system development and testing (version 3.1H). This document will have to be updated whenever upgrades are performed, after any required changes and testing are completed.

• The EDI Subsystem refers to the hardware, Translation software and communications to an external Value-added Network (VAN).

• The EDI Translation software is assumed to be GENTRAN Director, and is referred to as “GENTRAN” in this document.

• The EDI subsystem complies with the data exchange interface defined between the systems.

• The scheduling of the GENTRAN and the SAP EDI component is sufficiently flexible to ensure that one system has completed file operations before another system attempts to use this file. This is a consequence of using a limited functionality subsystem with batch scheduling.

• The EDI process is monitored after every scheduled message transfer to ensure that system failures are dealt with promptly and correctly.

2.             AN Overview of SAP/EDI

2.1.            The SAP/EDI Process

Electronic Data Interchange (EDI) eliminates the need for paper-intensive procedures when interacting with suppliers or customers, as well as avoiding physical distribution methods such as postal or courier delivery, duplicate capturing of information by operators and the associated errors.

The purpose of the SAP/EDI interface is to allow business transaction details (such as purchase orders, and invoices) to be exchanged electronically with vendors. In order to ensure interaction with a range of vendors, SAP does not supply the EDI subsystem required to distribute EDI documents to vendors. Therefore, a mechanism is required to allow business documents (such as purchase orders) generated in SAP to be transferred to this external EDI subsystem which will deliver the  documents to vendors. Similarly, the EDI subsystem will receive business documents from vendors, which will then be transferred to the SAP system before they can be processed.

Another factor which should be considered is that the format of the documents generated by SAP is different to the format required by the EDI subsystem. Therefore the interface has to ensure that SAP documents (in IDoc format) are converted to an EDI subsystem format (the EDIFACT format) before delivery to vendors. The opposite conversion occurs when EDI documents are received by the SAP system.

Since the EDI subsystem is located on a different host to the SAP system, it is necessary to use a remote access method in order to transfer the EDI documents. The method chosen, for ease of understanding and usage is the Network File Service (NFS). This permits both systems to access the same directory structure in order to exchange information.

The interaction between the systems is controlled by using two schedulers running batch jobs, one for the SAP transfers, and another for EDI subsystem transfers. This allows flexibility, since the frequency of EDI transfers between the systems can be modified, and each component can be isolated via loose coupling. In addition, the stages of processing are clearly separated for simplicity. 

2.2.            The EDI Process

All sections of this document will make reference to the following stages of the process.

2.2.1.      Incoming EDI

• EDI messages are received by EDI subsystem.

• EDI messages are translated from EDIFACT format to IDoc format.

• (This requires a GENTRAN/Director script to invoke a translation script)

• EDI messages (IDoc format) are stored in NFS shared directory.

• SAP scheduler starts a batch process to retrieve all new inbound EDI messages (IDoc format) from NFS shared directory.

• All EDI messages in IDoc format are processed by SAP inbound processing.

2.2.2.      Outgoing EDI

• SAP Transaction (Purchase Order Form etc. ) generates IDoc messages for EDI.

• SAP scheduler starts a batch process to send all new outbound EDI messages (IDoc format) to NFS shared directory.

• The EDI messages are stored in NFS shared directory.

• GENTRAN scheduler starts a DIRECTOR script to retrieve all new EDI messages and convert them to EDIFACT format.

• EDI messages (now in EDIFACT format) are delivered to vendors over value-added network.

3.             OVERVIEW OF CONFIGURATION PROCEDURE

The following sections describe the major steps involved in configuring SAP for EDI, and ensuring that an interface to the  EDI subsystem has been put in place. These steps are outlined in the following diagram (with corresponding section alongside). These steps put core EDI functionality in place. Trading partner profiles still need to be set up on each production system for each vendor that will be involved in trading via EDI.

4.             Setting up the Network File Service (NFS)

Each Group system should have a common directory called /home/edi/  which has been set up by the Basis administrators for this Group system. All inbound and outbound files to be exchanged with the EDI subsystem should reside in a subdirectory corresponding to the SAP system and client which they are associated. The subdirectory structure should be accessible by an NFS client using the correct user id and password.

For further information, read the NFS Setup Guide.

5.             Data exchange interface

The data exchange interface will consist of a single file, used for each direction of exchange (inbound and outbound). The outbound file is overwritten by the SAP system when another file is created, and the inbound file will be deleted once SAP has successfully processed it. This means that the correct operation between SAP and the subsystem will need to be verified after each exchange. This administration responsibility is further discussed in the EDI Administration operations documents.

• Exchange directory name: /home/edi/<portname>

where <portname> consists of:

              edi<system name><client number><id char>

<system name> is the name of  system on which port exists eg. F01, PG1 etc.;

<client number> is name of client on system which will use this port; and

<id char> is a single alphabetical character such as ‘a’,’b’ etc. typically, ‘a’ will       denote dynamic outbound file naming (used for testing) whereas ‘b’ will denote        static outbound file naming. All ports will use static inbound filenames.

For example, the exchange directory for a port using dynamic file naming on           system F01, client 610 would be named edif01610a.

• Outbound Idoc Message File (Static):                    edi_out

• Inbound IDoc Message File (Static):                      edi_in

6.             CONFIGURING SAP FOR EDI

Each SAP client needs to be configured for EDI. Please read and follow the procedures outlined in the EDI SAP Setup Guide.

Port definitions (WE21) need to be created for each client enabled for EDI using the following naming convention:

• <Portname> which consists of:

              EDI<system name><client number><id char>

<system name> is the name of  system on which port exists eg. F01, PG1 etc.;

<client number> is name of client on system which will use this port; and

<id char> is a single alphabetical character such as ‘a’,’b’ etc. typically,

‘a’ will denote dynamic outbound file naming (used for testing) whereas

‘b’ will denote static outbound file naming. All ports will use static

inbound filenames.

For example, the port name using dynamic file naming on system F01, client 610     would be named EDIF01610A. Similarly, the port name using static outbound       file naming on system PG1, client 600 would be EDIPG1600B.

• The inbound file names (including path) should be /home/edi/<portname>/edi_in (note lower case). The outbound function used for dynamic EDI file naming should be EDI_PATH_CREATE_USERNAME_DT_TM and should include path /home/edi/<portname>. The static outbound filename should be /home/edi/<portname>/edi_out. Note that the <portname> used as a directory is lower case, compared to the SAP <portname> which is in upper-case.

Note that for each portname, there should be a corresponding subdirectory in /home/edi/ with the same name (in lower case) which has been created by the Basis administrator responsible for EDI NFS setup.

Partner Profiles for each trading partner should be setup on SAP by the person responsible for this role. The procedures are documented in the EDI Partner Setup Guide.

7.             Scheduling EDI Transactions

7.1.            Configuring and Operating the SAP scheduler

In order for the EDI transactions to be captured by the SAP system, inbound and outbound processes are run on a regular schedule to transfer EDI messages to and from the SAP system respectively. The mechanism for executing these processes is the SAP scheduler, formally known as the “background processing server”. The frequency of the scheduled jobs is entirely dependent on the volume of transactions required to be transferred and the scheduling requirements for the EDI subsystem. The jobs to be scheduled are programs RSEOUT00 for outbound processing (with a variant defining the correct EDI port and document type) , and  RSEINB00 for inbound processing (with a variant describing the correct EDI path and input file i.e. /home/edi/edi_in).

7.1.1.      Outbound Jobs

Naming convention for outbound jobs is:

          Z_EDI_OUT_<Client Number>_<Job Number>

where:

• <Client Number> is the number of the client on which the job is created and should be executed.

• <Job Number> is a 3 digit sequential number which is one higher than the previous job that was created eg. 001, 002 etc.

Job Class: A

Times for SAP outbound job processing: 05h00, 12h00.

Time for GENTRAN inbound processing: 1 hour after SAP outbound

Name of ABAP Program: RSEOUT00

A variant should be created in transaction WE14. The variant name for the outbound job is :

Z_EDI_OUT_<client number>,

where

• client number is the number of the client where the job is to be executed

The variant should include: port name, logical message type ORDERS and ORDCHG, and output mode 4 (Collect Idocs).

7.1.2.      Inbound Jobs

Naming convention for inbound jobs is:

          Z_EDI_IN _<Client Number>_<Job Number>

where:

• <Client Number> is the number of the client on which the job is created and should be executed.

• <Job Number> is a 3 digit sequential number which is one higher than the previous job that was created eg. 001, 002 etc.

Job Class: A

Time for inbound job processing: 17h00.

Name of ABAP program: RSEINB00

A variant should be created in transaction SE38, using program name RSEINB00. The variant name for the inbound job is :

Z_EDI_IN_<client number>,

where

• client number is the number of the client where the job is to be executed

The variant should include: path /home/edi/<portname>/edi_in

where <portname> is used to define the directory name, with details of the naming convention described in section 6, “CONFIGURING SAP FOR EDI”.

7.1.3.      Defining Jobs

• To define a job, use the interactive SAP transaction SM36.

7.1.4.      Executing Jobs

To make a job executable, it must first be released.

7.1.5.      Checking the status of jobs

To check the status of a job, use interactive SAP transaction SM37.

7.1.6.      Viewing the job log

If a job has been aborted, you should view the job log for the cause of the failure. To view the job log, use interactive SAP transaction SM37.

7.1.7.      Deleting jobs

Some time after a job has been processed, it should be deleted to release system resources. There are two options to delete a job:

• manually, job by job

• automatically, using a reorganization program that deletes jobs that older than a certain date.

7.2.            Active Monitoring

This section is only applicable if more extensive IDoc monitoring is required.

This is a special report which informs the agent in charge in critical situations (e.g. if there are too many erroneous IDoc transmissions).

7.2.1.      Active Monitoring: How It Works

To perform the analysis the 'RSEIDOCM' program must either be started or scheduled for a later start. The selection phase requires valid entries to be supplied for at least the following fields: recipient, recipient type, status group and critical number of IDocs. There are also some other parameters that can be used to further restrict the IDoc selection.

During the selection phase all IDocs are analyzed that meet the selection criteria. The possible status values of the IDocs are allocated to status groups. If the status value of the current IDoc is allocated to one of the status groups specified in the report parameters, this IDoc is counted as 'critical'. The 'number of critical IDocs' counter is incremented if any of the status values allocated to the status groups occurs. If the number of critical IDocs counted exceeds the specified limit, the situation is classified as a 'problem' and a notification is sent to the specified recipient.

The notification appears to the recipient as a task in his integrated inbox. When the task is executed, a mask with the IDoc statistics is displayed showing the values holding at the time the analysis was performed. The status groups selected for the analysis are highlighted in the statistics display in color if the value in this status group is larger than zero. The 'Refresh' function allows the person executing the task to display the current status of the IDocs. This renewed analysis is based on the same selection criteria already used for the notification.

7.2.2.      Active Monitoring: Configuration

The following configurations must be made one time for 'active monitoring':

If required, it may be a good idea to set up an organizational unit specially for the notification.

Event coupling must be activated for the 'TS3200108' standard task. The task must be maintained as a 'general task'. This can be done using the automatic workflow customizing or the task maintenance in the processor assignment function. An alternative in the task maintenance is to specify an organizational unit in the processor assignment. However, this is not recommended because of the problem of the intersection of the two sets, since the result for the set of possible processors of the task could be an empty set.

The 'RSEIDOCM' program can either be started interactively or scheduled for periodic monitoring using batch scheduling with different variants.

Batch scheduling is done using the 'Define job' function. This allows continuous periodic monitoring of the IDoc processing to be configured and automated. Job scheduling can be found by following the menu path Tools -> Administration -> Jobs -> Define job.

7.2.3.      Active Monitoring: Parameters

The recipient and recipient type fields specify who or what should be notified in the case that notification becomes necessary. This can be a work center, a job, a position, an organizational unit or a user. The recipient must be maintained in the organizational model of the PD-ORG. Analysis is only possible if a valid value has been entered here.

When the batch run is actually executed, the specified start time before batch run and end time before batch run are used to calculate the time interval to be used for selecting the IDocs based on their creation time.

The number of critical IDocs defines the threshold (a 'strictly greater than' condition), beyond which a notification should be dispatched. This parameter can also take the value zero.

Status groups are used to group together possible status values of IDocs. The allocation of a status value to a status group is known as a qualification. SAP supplies a standard qualification, but this may be changed. The set of IDocs that has been determined for analysis by a set of further selection criteria (see below) is examined to ascertain its current status. If this status is one that has been allocated to one of status groups specified in the selection, the 'number of critical IDocs' counter is incremented.

Status group F (inbox: error in application) is supplied as standard by SAP with the status values:

•  51 (application document not posted)

• 52 (application document not fully posted) and

• 57 (error when checking the application).

For each IDoc in the set of IDocs selected that has a current status of 51, 52 or 57, the 'number of critical IDocs' counter is incremented by one. If this counter reaches or exceeds the threshold specified (in this case 1), a notification is sent to the specified recipient. This would therefore be the case here if just one IDoc currently has a status value of 51, 52 or 57.

By specifying the following parameters :

• logical type, variant and function of the message,

• sender's port,

• partner type, partner function and partner number of sender

• recipient's port,

• partner type, partner function and partner number of recipient

the set of IDocs to be analysed can be restricted further.

Thus, the following parameters have to be set:

• Logical message        'ORDERS'

• Customer      '2400004'

• Batch run time           08:00 on the day of delivery

To that end, the variant MY_VAR is created for the report RSEIDOCM:

1. In the abap/4 editor, select "variant" for the report RSEIDOCM and push the "Display" button. In the next screen, create the variant 'MY_VAR'.

2. In the following screen, select, in particular, "1 day" and "0 days 14:00:00h" for start and end before batch run, respectively. The batch job itself is started at 08:00h. Status group F (inbox: error in application) is supplied as standard by SAP with the status values 51 (application document not posted), 52 (application document not fully posted) and 57 (error when checking the application).

3. In the daily batch run all the IDocs are selected that arrived the previous day between 00:00 and 18:00 and that have the logical message type 'ORDERS' and were sent by the sender '4711'. If the current status of at least two of these IDocs is allocated to the status group F, a notification is sent to the user 'MYUSER', since the 'number of critical IDocs' threshold value is set to 1.

Documents

• SAP EDI Administrator role definition

• EDI Subsystem administrator role definition