Quick Guide EDI/IDoc Interfacing to SAP ECC from External System

Transcription

1 Quick Guide EDI/IDoc Interfacing to SAP ECC from External System Applies to: Up to ECC 6.0. For more information, visit the ABAP homepage. Summary IDoc Interface: EDI Application Scenario The application scenarios describe business processes in which EDI can be implemented. Consequently, two partners are always involved in these processes: The sender and the recipient of the EDI message. The scenarios should describe a business process as simply as possible, while remaining realistic. The process described here in this document can serve as templates or starting points for customer-defined business processes. The scenario covered in this guide involves the IDoc interface, wherein, the data is received from an external system and the subsequent processing in the R/3 system is done. This processing of the data in the R/3 system is called Inbound Processing or also Inbound Author: Rohit Khan Company: SAP India GD Created on: 15 Nov 2010 Author Bio Rohit is working as a SAP Netweaver Consultant at SAP India GD. He is based out of Gurgaon facility. rohit.khan@sap.com SAP AG 1

2 Table of Contents Introduction... 3 Dependencies/Pre-requisites... 3 Technical Process steps... 4 Customizing Steps... 5 Demonstration... 5 Related Content Copyright SAP AG 2

3 Introduction This short How to Guide will guide the SAP Technical Consultants to bridge the interface between an R/3 and External System. This scenario is based on an EDI scenario. Example: The following figure shows the creation of DEBMAS and ADRMAS IDoc in the R/3 from an External System through flat file Dependencies/Pre-requisites Basic ABAP knowledge Knowledge of IDoc interface Knowledge of EDI process 2010 SAP AG 3

4 Technical Process steps The scenario covered in this guide involves the IDoc interface and the corresponding EDI settings, wherein, the data is received from an external system and the subsequent processing in the R/3 system is done. This processing of the data in the R/3 system is called Inbound Processing or Inbound Inbound Process Flow: Receiving Data from External System Let us now understand some basic concepts about Inbound Processing, External System Send data to R/3 System Transfer R/3 System Check port & partner, generate IDoc Post document Yes No No Error Handling Inbound processing includes: Receiving IDoc data from an External System through flat files Creating the Inbound IDoc Finding the correct processing type via Partner Profile Creating the Application Document For the above process to work, we must maintain the IDoc interface for Inbound processing: In the Partner Profile (WE20), the receiving system must be maintained as the partner for inbound processing and the Message Types should be maintained The IDoc is passed directly to the Application Function Module according to the Partner Profile settings and processed according to Process Code An Application IDoc is created in the database Along with the above settings, we need to write an Interface Program. This interface program will pick the data file that is dumped into the Application Server 2010 SAP AG 4

5 We need to define this flat file as Logical File using the T-Code FILE We need to assign Physical Path to the Logical Path created above In the program we also need to take care of the mapping. This will involve mapping the source fields from the file to the respective fields in the segments of the corresponding Message Types Finally we will call the respective function module for IDoc processing Customizing Steps Following customizing need to be taken care: Creation of Logical File path Creation of Partner Profile, involving the following Defining the Partner Type - Logical System Defining the Inbound parameters Assigning the corresponding Process Code (Process code identifies the type of data processing for inbound processing. The IDoc interface uses the process code to find the business process which controls the conversion of the IDoc into the SAP document) Choosing the Mode of Processing Trigger by background program Trigger immediately Demonstration Now we will see the Demo of all the steps involved as discussed above: 1. Create a Logical File name using T-Code - FILE. Click on the New Entries button to create new entry 2010 SAP AG 5

6 2. Define a Logical file path. Click on New Entries button after you place the cursor on the Folder 'Logical File Path Definition'. Enter the required values and save 3. Assign the Physical Path to the Logical Path in the similar fashion as done above, after you place the cursor on the folder 'Assignment of Physical Path to Logical Path' 2010 SAP AG 6

7 To get the Physical file name from the Logical file path created above, we will use the standard function module 'FILE_GET_NAME'. This function module converts a logical file name to the corresponding physical file name and path for the hardware platform concerned. The below example is for demo:- DATA lv_filename TYPE localfile. CALL FUNCTION 'FILE_GET_NAME' EXPORTING client = sy-mandt logical_filename = p_file operating_system = sy-opsys IMPORTING file_name = lv_filename EXCEPTIONS file_not_found = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE e048(/asu/general) WITH lv_filename. ELSE. OPEN DATASET lv_filename FOR INPUT IN TEXT MODE ENCODING NON-UNICODE IGNORING CONVERSION ERRORS. IF sy-subrc <> 0. MESSAGE e004(/asu/general) WITH lv_filename. ELSE. ASSIGN w_data TO <fs_data>. DO. READ DATASET lv_filename INTO <fs_data>. IF sy-subrc EQ 0. MOVE-CORRESPONDING <fs_data> TO w_data. APPEND w_data TO t_data. CLEAR w_data. ELSE. EXIT. ENDIF. ENDDO. CLOSE DATASET lv_filename. ENDIF. ENDIF. Note: - Here t_data is nothing but the internal table which we will populate with the file data and w_data is the work area, and, <fs_data> is the field symbol of type of the structure of t_data With OPEN DATASET you can use ENCODING (NON-UNICODE or DEFAULT) statement depending upon the character representation in which the content of the file is handled 2010 SAP AG 7

8 4. The system will prompt you for the transport request. Save it. After we have defined a logical file path, the next step is to create a Partner 5. Define Partner Profile using T-Code - WE20 a. In the Inbound Parameters, make entries for the Message Type. In our example, we have entered DEBMAS and ADRMAS Note: You must maintain the Partners with whom you communicate via IDoc in the Partner Profiles: choose the message to be sent to the partner and define the path to be used, as well as how inbound messages are processed 2010 SAP AG 8

9 b. Select the Message Type ADRMAS/DEBMAS (Ex. below) and click on Detail screen button to further specify the attributes like Process code and Inbound options 2010 SAP AG 9

10 Let us see, what the above settings stand for o o Process Code - A process code identifies the type of data processing for inbound processing Use - The IDoc interface uses the process code to find the business process which controls the conversion of the IDoc into the SAP document. You can also change the ALE option and processing type in the Process Code. See below SAP AG 10

11 Ex. DEBM - EDI Customer master. This process code contains FM to process the inbound IDoc Process by Function Module - Using this option in the Partner profile we can determine the processing of IDoc. There are two options available for this o o Trigger by Background program - This option can be chosen if you want your interface program to create the IDoc when the program is run in background mode. This will create the IDoc with status 64 (IDoc ready to be transferred to the application) Trigger immediately - This will immediately create the application IDoc and post it in the system, with the relevant status 53 (IF successfully posted) After all these settings are done, we need to write the interface program for populating the IDoc structure EDI_DC40 and EDI_DD40 and call the relevant FM for generating and IDoc The following figure will explain the process in more detail 2010 SAP AG 11

12 Legacy System Flat Files from Application layer ABAP to create and Post IDoc Fill structure: EDI_DC40 & Fill Tables: EDI_DD40 Call FM IDOC_INBOUND_SINGLE The EDI_DC40 structure needs to be populated with the fields, MSGTYP, IDOCTYP, DIRECT, SNDPOR (SAP+SY-SYSID), SNDPRN, SNDPRT, RCVPOR (SAP+SY-SYSID), RCVPRN, RCVPRT. See example below... *& * *& Form FILL_IDOC_HEADER *& * * text * * * --> p1 text * <-- p2 text * * FORM fill_idoc_header. DATA: lv_port TYPE c LENGTH 10, "Port (SAP System, EDI subsystem) lv_rcvprn TYPE bdaledc-rcvprn. " Partner details *Select the receiving partner details SELECT SINGLE logsys INTO lv_rcvprn FROM t000 WHERE mandt EQ sy-mandt. w_idoc_header-mestyp = 'DEBMAS'. w_idoc_header-idoctyp = 'DEBMAS06'. w_idoc_header-direct = '2'. CONCATENATE 'SAP' sy-sysid INTO lv_port. w_idoc_header-sndpor = lv_port. w_idoc_header-sndprn = 'LEGACY'. w_idoc_header-sndprt = 'LS'. w_idoc_header-rcvpor = lv_port. w_idoc_header-rcvprn = lv_rcvprn. w_idoc_header-rcvprt = 'LS'. ENDFORM. "Direction for IDoc transmission "Sender port (SAP System, EDI subsystem) "Partner Number of Sender "Partner type of sender "Receiver port (SAP System, EDI subsystem) "Partner Number of Receiver "Partner Type of Receiver 2010 SAP AG 12

13 The EDI_DD40 Tables Structure needs to be filled with the corresponding required segments in the program. We need to map the fields from the flat file to the corresponding segments and its fields in the program. Also we need to pass the other information required for the strcture EDI_DD40 like, EDI_DD40- SEGNAM, EDI_DD40-MANDT and EDI_DD40-SDATA = data from the mapped fields of the segment. Check the below code for how do we do the same. *& * *& Form FILL_IDOC_SEGMENT *& * * text * * * --> p1 text * <-- p2 text * * FORM fill_idoc_segment. DATA w_e1kna1m TYPE e1kna1m. " Master customer master basic data (KNA1) DATA: t_idoc_segment w_idoc_segment TYPE TABLE OF edi_dd40, TYPE edi_dd. DATA t_data TYPE TABLE OF file_data_str. Strcture for file data records LOOP AT t_data INTO w_data. *===============================================* * Fill Segment E1KNA1M w_e1kna1m-kunnr = w_data-customer. w_e1kna1m-anred = w_data-title_medi. w_e1kna1m-ktokd = w_data-groupe_cpt. w_e1kna1m-land1 = w_data-pays. w_e1kna1m-name1 = w_data-nom_1. w_e1kna1m-name2 = w_data-nom_2. w_e1kna1m-ort01 = w_data-ville. w_e1kna1m-pstlz = w_data-code_post. w_e1kna1m-sortl = w_data-anc_numcpt. w_e1kna1m-spras = w_data-spras. w_e1kna1m-stcd1 = w_data-siret. w_e1kna1m-stcd2 = w_data-siren. w_e1kna1m-stras = w_data-adresse_1. w_e1kna1m-telf1 = w_data-telephone. w_e1kna1m-telfx = w_data-telecopie. w_e1kna1m-stceg = w_data-id_tva_cee. * Other fields of EDI_DD40 w_idoc_segment-segnam = E1KNA1M. w_idoc_segment-mandt = sy-mandt. w_idoc_segment-sdata = w_e1kna1m. APPEND w_idoc_segment TO t_idoc_segment. ENDLOOP. ENDFORM. " FILL_IDOC_SEGMENT After filling all the required strctures, we call the FM IDOC_INBOUND_SINGLE to post the IDoc in SAP as we can see from the above figure SAP AG 13

14 After all the mapping and rules (if any - customer specific) is done, we will call the function module and pass the header and segment information. It should generate an IDoc with the some status. We can go and check the status of the IDoc generated using the T-Code: WE02. Note: We need to make sure that the parameter PI_DO_COMMIT in 'IDOC_INBOUND_SINGLE' is checked. The parameter PI_DO_COMMIT controls whether the function module sends a 'COMMIT WORK'. If no COMMIT command is sent and the application carries out rollback if an error occurs, the IDoc is deleted from the database, i.e. there is no longer an IDoc in which the error could be documented and the user will see IDOC: Error EA613 with FM IDOC_INBOUND_SINGLE 2010 SAP AG 14

15 Related Content SAP AG 15

16 Copyright Copyright 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iseries, pseries, xseries, zseries, eserver, z/vm, z/os, i5/os, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty SAP AG 16