Scribd
Upload
527 views

Interface Function Specification

The document describes the functional and technical design of an EDI architecture. It outlines the requirements, assumptions, functional design for outbound and inbound messages, technical design of the transfer function and SAP scheduler, and external dependencies. The architecture facilitates the transfer of IDOC messages between SAP and an EDI subsystem using NFS to move files between UNIX and Windows. It includes translation of messages to EDI standard format and uses unattended scheduling to trigger processes.

Uploaded by

krishman316
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
527 views

Interface Function Specification

The document describes the functional and technical design of an EDI architecture. It outlines the requirements, assumptions, functional design for outbound and inbound messages, technical design of the transfer function and SAP scheduler, and external dependencies. The architecture facilitates the transfer of IDOC messages between SAP and an EDI subsystem using NFS to move files between UNIX and Windows. It includes translation of messages to EDI standard format and uses unattended scheduling to trigger processes.

Uploaded by

krishman316
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 6

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

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

Creation
Creation
1
EDI sub-System
Management &
Control

Sender
Sender
Queue
Queue
2

Transfer
Transfer

Standard or EC
Development

Unattended
scheduler
Translation
((Outbound Script)
3

Receiving
Receiving
Queue
Queue

Custom Development

Translation
EDI
EDITranslator
standard
message

Dispatch
VAN
via VAN

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
SAP
SAPEDI
EDIimport
import
process
process
Unattended Schedular
Unattended Schedular

5
EDI Sub-System
Management &
Control

Receiver
ReceiverQueue
Queue

Custom Development

Transfer
Transfer
2
4
Sender
SenderQueue
Queue

Translate
Translateinto
into
EDI
EDIstandard
standard
message
message

Standard or EC
Development
1
Transported
Transportedvia
via
VAN
VAN

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
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)

Responsibility

You might also like