EDI Functional Design

EDI

Functional Design

table of contents

1 EDI Technical architecture..................................................................................................................... 3

1.1 Purpose................................................................................................................................................................... 3

1.2 EDI Interface Architecture......................................................................................................................... 3

1.3 Business Requirements................................................................................................................................... 3

1.4 Assumptions......................................................................................................................................................... 3

1.5 Functional Technical Design...................................................................................................................... 4

1.5.1 Outbound Message....................................................................................................................................... 4

1.5.2 Inbound Message.......................................................................................................................................... 5

1.6 Technical Design............................................................................................................................................... 6

1.6.1 Transfer Function......................................................................................................................................... 6

1.6.2 SAP Unattended Scheduler Function....................................................................................................... 6

1.7 External Dependencies.................................................................................................................................. 7

1 EDI Technical architecture

1.1 Purpose

The purpose of the document is to describe the functional technical design and the physical technical design of the EDI architecture. The secondary purpose of this document is to get approval to proceed with the detailed technical design and implementation of the EDI architecture.

1.2 EDI Interface Architecture

The purpose of the EDI interface architecture is to facilitate the movement and control of IDOC messages to and from the EDI sub-system. The EDI interface architecture will provide the basic components needed to automate the transfer of EDI messages between SAP and the EDI sub-system..

1.3 Business Requirements

· A mechanism to transfer EDI messages between the SAP system (UNIX) and the EDI sub-system (PC);

· The interface architecture should meet the short to medium term EDI requirements. These include:

Þ Low volume EDI traffic; and

Þ A cost effective solution resulting in basic control mechanisms.

· All standard operations procedures must be in place to operate the architecture. These procedures include:

Þ Installation;

Þ Start-up and shut-down; and

Þ Scheduler monitoring and maintenance.

1.4 Assumptions

· There will be a separate EDI sub-system for each SAP database server;

· An asynchronous batch driven interface (not event driven) with minimal controls will be developed to meet the short to medium term business requirements;

· Telkom will provide the translation mappings from an IDOC to an EDIFACT message and vice-versa;

· Telkom will provide all scripts for the Gentran:Director product i.e. translation maps, and upload and download scripts;

· All inbound IDOCs are appended to a single file per day; and

· All operational issues relating directly to the Gentran:Director product will be dealt with by the EC team.

1.5 Functional Technical Design

The functional technical design depicts at a technical level the functions offered by the proposed architecture. A functional technical design is provided for both outbound and inbound messages.

1.5.1 Outbound Message

Description

1. An EDI IDOC is created (in SAP) and stored in the sender queue at the UNIX operating system (OS) level;

2. A transfer process is activated that transfers the EDI IDOC from the sender queue to the EDI sub-system receiving queue;

3. The EDI sub-system control mechanism triggers (based on a schedule) the EDI translator which retrieves the IDOC file and translates the IDOCs into an EDIFACT standard message; and

4. The EDI sub-system transmits the EDIFACT message via the VAN.

Architectural Constraints

· Status information is not passed back to the SAP system to indicate a successful transmission of an EDI message. This would lead to manual controls, comparing EDI sub-system and SAP EDI system statuses; and

· The EDI sub-system cannot be externally triggered by SAP to initiate the outbound processes i.e. interface is not event driven.

1.5.2 Inbound Message

Description

1. A EDIFACT message is transported via the VAN and stored in the EDI sub-system;

2. The EDI control mechanism triggers off the translation process which translates the EDIFACT message into a IDOC message;

3. The EDI translator script stores the SAP IDOC in the sender queue;

4. A transfer process is activated that transfers the EDI IDOC from the sender queue to the EDI sub-system receiver queue; and

5. The SAP control mechanism triggers (based on a schedule) the SAP EDI inbound process which retrieves and imports the IDOC into the SAP system.

Architectural Constraints

· Status information is not passed back to the EDI sub-system to indicate a successful import of a EDI message into SAP.

1.6 Technical Design

1.6.1 Transfer Function

Only the custom components of the design are described below. The assumption is that the other components will be provided by the vendor and/or Telkom.

Requirements

· A transfer process which facilitates the movement of the IDOC from the UNIX directory to the PC directory and vice versa; and

· A basic error handling function.

Inputs

· IDOC message in Sender Queue.

Outputs

· IDOC message in Receiving Queue.

Mechanism

· NFS mounted drive;

· NFS exported drive - UNIX; and

· LAN Workplace PRO NFS client - PC.

Detailed Description

A directory will be exported as a NFS drive from the SAP UNIX box. This NFS drive will then be mounted on the PC via LAN Workplace PRO NFS client. A USER ID and PASSWORD will be required to mount the drive for security. The IDOC will be stored on the drive and will be “seen” by both the UNIX and PC Operating Systems as a standard file.

Technical Risks

· There is no transport validations beyond what the NFS mechanism provides; and

· There are security considerations to be considered with the use of NFS drives (i.e. well documented security holes within the NFS mechanism).

1.6.2 SAP Unattended Scheduler Function

Requirements

· A Control Module that triggers the SAP EDI inbound processes, which processes any IDOC messages which have been transferred to the SAP system directory.

Inputs

· Schedule.

Outputs

· Initiation trigger to the SAP EDI inbound process.

Mechanism

· SAP Job scheduler.

Detailed Description

A job will be inserted into the SAP job scheduler (SM36) which will initiate program “RSEINB00” (Inbound Processing of Intermediate Documents (EDI)) based upon a pre-determined schedule.

Technical Risks

· The EDI sub-system will receive no feedback from the SAP system on the status of the IDOC processing; and

· No automatic restart capabilities and error notification will be provided if the IDOC processing fails on the SAP box beyond the standard workflow provided by SAP.

1.7 External Dependencies

The following table identifies the key tasks/deliverables of external parties to the project:

Deliverable	Responsibility
Outbound Script (Gentran)
Inbound Script (Gentran)
Configuration of Gentran unattended scheduler (Outbound)
Configuration of Gentran unattended scheduler (Inbound)
Gentran Translation Mappings (IDOC to EDIFACT and vice-versa)