CA-EDI. Certification of the EDI Interface

Transcription

1 CA-EDI Certification of the EDI Interface SAP AG Page 1 of 14

2 Introduction The EDI interface is intended to connect an EDI subsystem with the SAP system. EDI subsystems perform the following tasks related to EDI processing: Conversion of data Message and Interchange Handling Communication Administration of partner profiles Monitoring of processing From the SAP side, the EDI interface is based on IDoc technology, which is independent of EDI standards. All data is transferred in files between the R/3 System and the EDI subsystem. Synchronous RFC (Remote Function Call) is implemented to define the time of transfer for a file between the two systems. The following data can be transferred using the EDI interface: Outbound IDocs: IDocs are transferred from the R/3 System to the EDI subsystem. Inbound IDocs: IDocs are transferred from the EDI subsystem to the R/3 System. Status report: The EDI subsystem sends a status report to the R/3 System on the progress of the processing of the outbound IDocs. Certification of an EDI subsystem involves technical testing of the interface between the R/3 System and the EDI subsystem. The transfer of outbound IDocs, inbound IDocs and status reports is tested. The test is carried out using the UN/EDIFACT standard for EDI. The following messages may be used: Outbound purchase order (ORDERS), inbound order (ORDERS), outbound order confirmation (ORDRSP) and inbound order acknowledgment (ORDRSP). SAP AG Page 2 of 14

3 Steps in the Certification Process This section describes the individual steps involved in certification. 1. Initiation 2. Consulting 3. The Test Initiation Certification is open to all suppliers of EDI subsystems. Firstly, the supplier contacts SAP and receives all the documentation and example data required for the certification test. After receiving the information, the supplier can then decide whether or not to proceed with the certification test. If the test is to take place, a certification agreement is signed by the supplier and SAP. When this agreement has been finalized, the consulting process and the test are arranged. If the test is completed successfully, a certificate is presented to the supplier, who becomes an SAP certification partner for the EDI interface. Consulting The prospective certification partner is entitled to attend a one day in-house consulting session at SAP. During this session, the prospective certification partner receives the necessary information concerning the installation environment for the test. The partner also has the opportunity to discuss any unclear aspects of the IDoc interface with SAP experts. At the end of the session, the supplier and SAP agree a date on which the test will take place at SAP. SAP AG Page 3 of 14

4 The Test The test is conducted in-house at SAP and lasts one day. It involves testing the ability of the partner s EDI subsystem to connect to the SAP System using a reproducible procedure (CATT - Computer Aided Test Tool). The following data flows, including synchronous RFC (file interface), are tested: Outbound IDocs, from the SAP system to the EDI subsystem, Inbound IDocs, from the EDI subsystem to the SAP system, and Status report, from the EDI subsystem to the SAP system. More details about the test are given in the following subsections. General Information The file interface is used for the test. The synchronous RFC triggers the appropriate receiving system. The test is divided into two parts: testing the technical connection (data exchange by file, started via RFC) testing a message chain consisting of a purchase order / sales order and order confirmation / order acknowledgment The test simulates two business partners, a customer and a vendor, in one SAP system. Of course, in a real business situation, both parties would have their own SAP system. The customer uses the SAP MM module and the vendor uses the SAP SD module. Electronic Commerce Document System R/3, MM IDoc System R/3, SD IDoc Status IDoc Status IDoc EDI Subsystem Transaction EDI Subsystem SAP AG 1998 CSP/ICC (Th.Becker) June 1998 / 2 Technical Connection Firstly, the data flow from the SAP system to the EDI subsystem is tested. For this purpose, an IDoc file is created by SAP and an executable program (e.g. out.script) is started in the EDI subsystem via the program rfcexec (rfcexec.exe on NT). Secondly, the data flow from the EDI subsystem to the SAP system is tested, using either an IDoc file or a status file. The program startrfc (startrfc.exe on NT) is used by the EDI subsystem to start the SAP system. SAP AG Page 4 of 14

5 Triggering with Port Type File IDoc Interface Write RFC Read RFC IDoc file Read rfcexec out.script Call IDoc file Status report 1 startrfc in.script status.script Write Call EDI subsystem SAP AG 1998 CSP/ICC (Th.Becker) June 1998 / 3 Contents of Control Records and Status Records For outbound IDocs, the following control record fields are tested: REFINT Interchange reference REFGRP Group reference REFMES Message reference ARCKEY Key for the EDI archive Since these four fields do not always have to be filled, the certification process checks that some of these fields have a value. These values are sent to the SAP system with the status record. The field contents are not checked for semantic meaning. The same fields are checked when dealing with inbound IDocs. In this case, however, they are sent directly with the IDoc in the appropriate control record. All other fields are handled functionally by the EDI interface. The partner profile for inbound processing is determined by the following fields: SNDPRT Partner type of sender SNDPFC Partner function of sender SNDPRN Partner number of sender MESTYP Logical message MESCOD Logical message code MESFCT Logical message function TEST Indicator for test or production messages These fields should therefore be filled according to the existing partner profile. In the case of status records, the fields DOCNUM and STATUS are checked functionally. All other fields can be filled according to the EDI subsystem. Message Chain The message chain is prepared and tested in several steps. Firstly, a purchase order is generated (by the CATT Computer ) in purchasing. This purchase order (IDoc type ORDERS01) is converted by the EDI subsystem into an EDIFACT message (type ORDERS). Finally, it is converted back into a sales order (IDoc type ORDERS01) and transferred to sales. Only the SAP SD module can determine the correctness of the sales order. When the correctness has been verified, an order confirmation is automatically transferred to the EDI subsystem (as IDoc type ORDERS01). The EDI subsystem converts the IDoc into an EDIFACT message (type ORDRSP) and back again into an IDoc (type ORDERS01) which is transferred to purchasing as an order acknowledgment. The SAP MM module then determines whether the acknowledgment matches the original purchase order. SAP AG Page 5 of 14

6 Step 1a A purchase order for vendor 1 is generated and transferred to the EDI subsystem as an outbound IDoc. Then the document is sent to the SAP system in an inbound IDoc as a sales order from customer 1. Step 1b The SAP system responds to step 1a by issuing an order confirmation to customer 1 which is transferred to the EDI subsystem as an outbound IDoc. Then the document is sent to the SAP system in an inbound IDoc as an order acknowledgment from vendor 1. Step 2a A purchase order with a single item and schedule lines for the item is created for vendor 1 and transferred to the EDI subsystem as an outbound IDoc. Then the document is sent to the SAP system in an inbound IDoc as a sales order from customer 1. Step 2b The SAP system responds to step 2a by issuing an order confirmation to customer 1 which also contains a single item and schedule lines for the item. This order confirmation is transferred to the EDI subsystem as an outbound IDoc. Then the document is sent to the SAP system in an inbound IDoc as an order acknowledgment from vendor 1. Step 3a A purchase order with several items and schedule lines for the items is created for vendor 1 and transferred to the EDI subsystem as an outbound IDoc. Then the document is sent to the SAP system in an inbound IDoc as a sales order from customer 1. Step 3b The SAP system responds to step 3a by issuing an order confirmation to customer 1 which also contains several items and schedule lines for these items. This order confirmation is transferred to the EDI subsystem as an outbound IDoc. Then the document is sent to the SAP system in an inbound IDoc as an order acknowledgment from vendor 1. Step 4a Five purchase orders are generated. The purchase orders are created for vendors 1 and 2 as well as a non-defined vendor. These five purchase orders are transferred to the EDI subsystem as outbound IDocs. The EDI subsystem converts the four IDocs directed to vendors 1 and 2, the IDoc directed to the non-defined vendor will cause a processing error in the EDI subsystem. A status report about these five IDocs is subsequently created. Then the four remaining documents are sent to the SAP system in four inbound IDocs as sales orders from customer 1 and customer 2. Step 4b The SAP system responds to step 4a by issuing four order confirmations to both customer 1 and customer 2. In addition four purchase orders are created for vendor 1 and vendor 2 (see step 4a). There are now eight outbound IDocs in the SAP system ready to be transferred. The recipients of the order confirmations are customer 1 and customer 2 and the recipients of the purchase orders are vendor 1 and vendor 2. These eight IDocs are transferred to the EDI subsystem. The EDI subsystem converts the eight IDocs. A status report about the IDocs is subsequently created. Then the documents are sent to the SAP system in eight inbound IDocs as sales orders from customer 1 and customer 2 as well as order acknowledgments from vendor 1 and vendor 2. SAP AG Page 6 of 14

7 Installation Environment and Example Scripts The SAP system is running on application server cpmat01, this is a Windows NT installation. The machine is separated by a firewall from the network, the EDI subsystem is installed in. The machine hw1149 (HP-UX B A) serves as the communication gateway in the network to be installed in. The machine of the certification partner is assigned to one of the following machine names: pctmp34, pctmp35, pctmp36, pctmp37, pctmp38 or pctmp39. Installation Environment Firewall EDI Subsystem pctmp101, SAP Gateway hw1149, /home/ediadm/<subsystem>/... export System R/3 (MM & SD) cpmat01 D:\PARTNERS SAP Router sapgate1, FTP rfcexec startrfc SAP AG 1998 CSP/ICC (Th.Becker) June 1998 / 4 The user account on hw1149 is EDIADM (UID=101) and belongs to user group USERS (GID=20). Templates for the necessary scripts you will find in the directory assigned to the certification partner. SAP AG Page 7 of 14

8 IDoc Outbound (out.script) #!/bin/sh DIREXEC=/home/ediadm DIRWORK=/home/ediadm/<subsystem> cd $DIRWORK date >> $DIRWORK/ediadm.trace FILE= basename $1 $DIREXEC/bin/get_cpmat01. $FILE $DIREXEC/bin/rm_cpmat01. $FILE $DIRWORK echo get IDoc file $FILE from cpmat01 >> $DIRWORK/ediadm.trace echo remove file $FILE from cpmat01 >> $DIRWORK/ediadm.trace echo --- next run EDI subsystem with file $FILE >> $DIRWORK/ediadm.trace chmod 666 $DIRWORK/ediadm.trace Status Report (status.script) #!/bin/sh DIREXEC=/home/ediadm DIRWORK=/home/ediadm/<subsystem> cd $DIRWORK date >> $DIRWORK/ediadm.trace $DIREXEC/bin/put_cpmat01. $1 echo put IDoc file $1 to cpmat01 >> $DIRWORK/ediadm.trace echo --- next run SAP system with file $1 >> $DIRWORK/ediadm.trace $DIREXEC/startrfc 3 t d MAT u EDIADM p CERTIFY c 500 h /H/sapgate1/S/3297/H/cpmat01 s 17 g hw1149 x sapgw00 F EDI_STATUS_INCOMING E PATHNAME=D:/PARTNERS/$1 E PORT=SUBSYSTEM rm $DIRWORK/$1 echo remove IDoc file $1 from hw1149 >> $DIRWORK/ediadm.trace chmod 666 $DIRWORK/ediadm.trace IDoc Inbound (in.script) #!/bin/sh DIREXEC=/home/ediadm DIRWORK=/home/ediadm/<subsystem> cd $DIRWORK date >> $DIRWORK/ediadm.trace $DIREXEC/bin/put_cpmat01. $1 echo put IDoc file $1 to cpmat01 >> $DIRWORK/ediadm.trace echo --- next run SAP system with file $1 >> $DIRWORK/ediadm.trace $DIREXEC/startrfc 3 t d MAT u EDIADM p CERTIFY c 500 h /H/sapgate1/S/3297/H/cpmat01 s 17 g hw1149 x sapgw00 F EDI_DATA_INCOMING E PATHNAME=D:/PARTNERS/$1 E PORT=SUBSYSTEM rm $DIRWORK/$1 echo remove IDoc file $1 from hw1149 >> $DIRWORK/ediadm.trace chmod 666 $DIRWORK/ediadm.trace SAP AG Page 8 of 14

9 Additional Documentation Mapping Proposal A mapping proposal for IDoc type ORDERS01 to EDIFACT messages ORDERS and ORDRSP you ll find in file Certification-40.xls. Documentation of Data Structures Record Types The documentation about the IDoc record types Control Record, Data Record and Status Record you ll find in file Docu-Records_f.htm. IDoc Type ORDERS01 The documentation about the IDoc type ORDERS01 you ll find in file Docu-ORDERS01_f.htm. Parsable Documentation The parsable documentation of the IDoc record types and the IDoc type ORDERS01 you ll find in file Parser-Records-ORDERS01.txt. The syntax, the documentation is based upon, you ll find in file Parser-SyntaxE.txt. Triggering (File Interface) The technical documentation required for the couppling of an EDI subsystem and the SAP system via the file interface you ll find in file TriggeringE.htm. This documentation is part of the customer documentation of System R/3, release 4.0. Example Data For each step of the message chain to be tested, you get example data for outbound IDocs as well as inbound IDocs. The example data you ll find in files <step>-<direction>.txt. Training For the IDoc interface the following courses are scheduled: 1. BC620 SAP IDoc Interface (Standard) The course is intended to consultants, administrators and project teams. 2. CA210 The EDI class The course is intended to consultants, administrators and project teams. 3. BC621 SAP IDoc Interface (Development) The course is intended to developers. ABAP programming skills are a must. SAP AG Page 9 of 14