Data Exchange and Integration Between Different Systems Using Custom IDoc's and EDI - ALE Process - A Complete Reference

Data Exchange and Integration between Different Systems using Custom IDocs and EDI/ALE Process A Complete Reference
Applies to:
Up to ECC 6.0. For more information, visit the ABAP homepage.
Summary
This document describes the tools and procedures to use Custom IDocs for data transfer and exchange between different systems. There may be a case where the standard IDocs and processes are not sufficient enough to do data transfer. In those cases, this article will help the consultants to develop custom process and custom IDocs to do Data Transfer.
Note: This document is based on the assumption that, project requirements are not full- filled by Standard IDocs and Standard Message Types, IDoc Types, Process Codes, Inbound Function Modules etc.
Author:
Rohit Khan
Company: SAP India Global Delivery Created on: 24 August 2011
Author Bio
Rohit is working as a SAP Netweaver Consultant at SAP India GD. He is a certified Netweaver Development consultant and a certified Enterprise Architect.
SAP COMMUNITY NETWORK 2011 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1
Table of Contents
Introduction ......................................................................................................................................................... 3 Audience ............................................................................................................................................................. 3 Purpose............................................................................................................................................................... 3 Dependencies/Pre-requisites.............................................................................................................................. 3 Technical Process steps ..................................................................................................................................... 3 Demo Instructions ............................................................................................................................................... 4 Part 1 Development for Outbound Processing ............................................................................................ 4 Part 2 Development for Inbound Processing ............................................................................................. 17 Part 3 - Testing the IDoc process ................................................................................................................. 24 Part 4 - Checking the results in Receiving System ....................................................................................... 29 Conclusion ........................................................................................................................................................ 30 Related Content ................................................................................................................................................ 31 Copyright........................................................................................................................................................... 32
Introduction
A quick reference guide to develop Custom IDocs and Custom EDI/ALE to process data exchange and transfer between homogeneous (SAP-to-SAP) or heterogeneous systems (SAP-to-Non SAP or Non SAP-toSAP)
Audience
SAP Technical/ALE/EDI/IDoc Consultants
Purpose
The purpose of this document is to help the consultants develop Custom IDoc development and Custom EDI/ALE settings.
Note: This document is showing the process flow from SAP to SAP only for demo purpose. The same model can be applied to develop the custom process in case of communication between an External System and SAP system. Please go to the related content below for more information Three scenarios can be possible:Scenario 1: External System (Non SAP) to SAP ECC Scenario 2: SAP ECC to External System (Non SAP) Scenario 3: SAP to SAP This document applies to all the above scenarios as the Custom Development will be in SAP Box always. While doing the same, the consultant has to consider and check if the SAP is a Receiver or Sender and do the customization and development accordingly
Dependencies/Pre-requisites
Authorization to maintain Logical Systems Authorization to maintain EDI:Logical Message Types Authorization to maintain the assignment of Logical Message Types to Basic Types/IDoc Types
Note: Some of the important authorization objects required to complete the whole part 1 to part 4 series below include B_ALE_LSYS, S_ADMI_FCD, S_RFC_ADM, S_IDOCPART, S_IDOCPORT, S_IDOCDEFT, S_IDOCDEFT, S_RFC, S_ALE For more information on how to find the exact authorization objects, refer to the related link below for Wiki link on how find the same
Technical Process steps

The document is divided in to four parts:Part 1 Describes the development for Outbound Processing Part 2 Describes the development for Inbound Processing Part 3 Describes the testing of the IDoc process Part 4 Describes how to check the results in Receiving System
Demo Instructions
Let us now see how we create a Custom IDoc Communication and EDI/ALE settings so that two different systems can Handshake with each other.
Part 1 Development for Outbound Processing 1. Custom Segment Creation An IDoc Segment is a DDIC structure containing the relevant fields that carry the data and information being exchanged between two systems (Systems can be Non-R/3 to R/3 or R/3 to R/3). Let us now create a custom IDoc Segment: Go to T-Code: WE31 and provide the name for the Custom Segment, in this example, we have ZDEMOSG. Hit Create Button and proceed as below.
Note:If the segment name is more than 7 characters, the system will give you an information message Assigned name is longer than 7 characters. Reason for this message: The segment name is not compatible with older releases like 4.0 or R/2 Systems. In that case the name of the segment may need to be converted to make it compatible
Note: This document takes the example of the transferring the System Messages data. In SAP we have the system table T100 which stores the messages according to Message Class
Once the segment fields have been created and saved, the IDoc segment needs to be Released. To release the segment, go to Edit Set Release in the main screen.
Once the segment is released, the Release Box will be checked.
2. Custom Basic/IDoc Type creation An IDoc type is the container for the data exchange. It is nothing but a flat file that contains the data in the segment structures. To create an IDoc type, we go to T-Code: WE30, and provide the name of the custom IDoc type.
Note: If the segment name is more than 8 characters, the system will give you an information message Assigned name is longer than 8 characters. Reason for this message: The name is not compatible with older releases like 4.0 or R/2 Systems. In that case the name may need to be converted to make it compatible
Hit Create Button and choose the option Basic Type and proceed as shown below. The other option Extension can be used when we are Extending a Standard Idoc Type to include custom fields.
In the pop-up choose the option, Create New and provide some meaningful Description.
In the next step, we will create and assign the segment ZDEMOSG created in the Step 1 above. To do this, keep the cursor on the IDoc name and hit Create Button and proceed as below.
Provide the name of the already created segment and details like Minimum number and Maximum number.
Note:Minimum number and Maximum number indicates the number of segments in the IDoc type generated at run-time.
Hit Enter in the pop-up and the segment will be inserted as below,
Hit Save and go back to the main screen. Now we need to release the IDoc type. To release, go to EditSet Release
Hit the Header Data icon
and we can see all the relevant details
3. Custom Message Type creation A Message Type determines the content of the message to be exchanged or transferred between systems. For Example, to exchange or transfer Material BOMs the standard message type provided is BOMMAT or for material data exchange, we have MATMAS. To create a new custom message type, go to T-Code: WE81 and proceed as below. Click on the icon Display Change
Note: When clicking the DisplayChange icon the system issues a caution message Caution: The table is cross-client. This message serves to warn you that each change you make will have an effect on all other clients in the system.
Click on icon and create the custom message type and provide the name of the message type as below.
Hit Save and the system will prompt you for a Workbench Request. Save and proceed.
4. Assign Custom Message Type to Custom IDoc Type Once the Logical Message Type has been created, the next step is to assign it to the Custom IDoc Type created in the previous steps above. This is a mandatory step as we know that Message Type is used to determine the content of the message to be transferred and the content is carried in IDoc Type. Go to T-Code: WE82 and proceed as below, Click in the icon DisplayChange. The system will give the same information message that we got while creating a Custom Message Type. Click and proceed.
Click on icon and give the name of the Custom Message Type, IDoc/Basic Type and Release as below.
Hit Save and the system will prompt you for the Workbench Request. Provide the same and continue.
5. Once the above IDoc settings are complete the next step is to configure an RFC Connection for the Receiving System. To configure an RFC connection, go to T-Code: SM59 and proceed as below,
Now we provide the required parameters to the new RFC connection. Please see the below example. Click on Create button and proceed as below. Provide Technical Settings and Logon data.
6. Create a Logical System for Receiver System/Target System A Logical System is an application system in which the applications work together. In SAP terms, a Logical System is nothing but a client. In ALE communication distributed systems are identified by Logical System within a network. To create a logical system for receiver system, go to T-Code: BD54 and provide the name of the system, by choosing the new entries button. The system will prompt you for a workbench request. Provide the same and proceed.
7. Create PORT for processing an IDoc in the Receiving System A Communication port needs to be established that defines the type of connection with the partner. The Port defines the technical attributes of the connection between a SAP system and other systems. It also defines the medium in which data is exchanged between the two systems. There are different types of Ports available.
Let us briefly understand the feature of each one of them,
Port
Transactional RFC File CPI-C Internet ABAP-PI XML
Feature
Used for ALE communication Used by EDI Used to communicate with an R/2 system Used to connect to Internet Applications Used for custom IDoc processing via ABAP programming interface Used for processing files in IDoc/XML format
Note: Since this demo shows data exchange between SAP systems, we are using tRFC, in case of heterogeneous
systems, we will use EDI
To create a Port, we go to T-Code: WE21 and proceed as below, Choose the Port type as tRFC and hit Create button.
In the pop-up that appears you can either choose the option, own port name and provide the name or you can choose the system to generate it for you,
In the proceeding screen, provide some meaningful description and also provide the name of the RFC destination as created in the steps above.
Hit Save and proceed. 8. Creating a Partner Profile for processing an IDoc in the Receiving System Partner profiles declare the communication medium to be used with a partner. Partner profiles are used to declare the communication medium to be used with a partner. To create a Partner Profile for the Receiving System, go to T-Code: WE20 and proceed as below. Choose Partner Type LS and hit Create button.
Since we are sending the IDoc to the Receiving System we will maintain the Outbound Parameters. Proceed as below, Click on Create outbound parameter icon and proceed as below,
Enter the details like, Message Type (Custom message type created previously), Receiver port, Basic type (Custom IDoc type created previously). Hit Save and proceed.
This step marks the end of the settings and customizations required from the Sender Side.
Part 2 Development for Inbound Processing Now let us proceed and see the custom process and settings for processing IDocs required in Receiving Side or Partner. This document demos the Receiving System as an R/3 system. For processing the IDoc in the Receiving System, we need to create a Custom Process Code and a Custom Inbound Function Module apart from other settings. Let us now create the same and understand the process. 1. Creating a Custom Inbound Function Module
For the demo purpose only, the below sample function module is created to process the Inbound IDoc data. See the below screen shots. Function Module Name: Z_IDOC_INPUT_DEMO Function Module Interface should like below:-
Note: The below source code is just a demo and could be used for reference while creating an Inbound Function Module in real-time scenario. For the demo purpose, this document is taking the example of updating/inserting the d/base table T100 (Messages) from the IDoc. In real time there could be some other d/base structure or custom DDIC objects, so need to shape up accordingly.
Demo Code:FUNCTION Z_IDOC_INPUT_DEMO. *"---------------------------------------------------------------------*"*"Local Interface: *" IMPORTING *" REFERENCE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD *" REFERENCE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC *" EXPORTING *" REFERENCE(WORKFLOW_RESULT) LIKE BDWFAP_PAR-RESULT *" REFERENCE(APPLICATION_VARIABLE) LIKE BDWFAP_PAR-APPL_VAR *" REFERENCE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK *" REFERENCE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS *" TABLES *" IDOC_CONTRL STRUCTURE EDIDC *" IDOC_DATA STRUCTURE EDIDD *" IDOC_STATUS STRUCTURE BDIDOCSTAT *" RETURN_VARIABLES STRUCTURE BDWFRETVAR *" SERIALIZATION_INFO STRUCTURE BDI_SER *" EXCEPTIONS *" WRONG_FUNCTION_CALLED *"----------------------------------------------------------------------
*"---------------------------------------------------------------------* * -- Information for the developer:* -- Example Function Module for processing Inbound IDocs for ALE or EDI * -- This function module has been built to read the data records * -- from IDoc Type ZIDOCTYP * -- Since we will be using using some ALE constants in this function * -- module, please always include the include program 'MBDCONWF' in * -- the TOP include of the function group of the inbound function * -- module *"---------------------------------------------------------------------* DATA : ls_zdemosg TYPE zdemosg. " IDoc demo segment DATA : ls_t100 TYPE t100. " Messages table used for demo * -- Read IDoc Control Record READ TABLE idoc_contrl INDEX 1. * -- Read data records from IDoc Segments LOOP AT idoc_data WHERE docnum = idoc_contrl-docnum. CASE idoc_data-segnam. WHEN 'ZDEMOSG'. ls_zdemosg = idoc_data-sdata. WHEN 'ZEX123'. " Demo only segment ZEX123 " In case we have more segments, we will process here WHEN 'ZEX456'. " Demo only segment ZEX456 " In case we have more segments, we will process here WHEN OTHERS. ENDCASE. ENDLOOP. * -- Now we move data from idoc segment to local available workarea MOVE ls_zdemosg-langu TO ls_t100-sprsl. MOVE ls_zdemosg-apparea TO ls_t100-arbgb. MOVE ls_zdemosg-msgno TO ls_t100-msgnr. MOVE ls_zdemosg-msgtext TO ls_t100-text. " and so on ......... .... " we will map and pass the values from IDoc segment " to the local strcture ls_t100 and then update in the d/base MODIFY t100 FROM ls_t100. * -- Now we write the IDoc status record CLEAR idoc_status. IF sy-subrc <> 0. "Error has occurred! workflow_result = c_wf_result_error. return_variables-wf_param = c_wf_par_error_idocs. return_variables-doc_number = idoc_contrl-docnum. APPEND return_variables. idoc_status-docnum = idoc_contrl-docnum. idoc_status-status = '51'. idoc_status-msgty = 'E'. idoc_status-msgid = 'B1'.
idoc_status-msgno = '561'. idoc_status-msgv1 = idoc_contrl-sndprn. idoc_status-repid = sy-repid. ELSE. workflow_result = c_wf_result_ok. return_variables-wf_param = c_wf_par_processed_idocs. return_variables-doc_number = idoc_contrl-docnum. APPEND return_variables. return_variables-wf_param = c_wf_par_appl_objects. return_variables-doc_number = idoc_contrl-docnum. APPEND return_variables. idoc_status-docnum = idoc_contrl-docnum. idoc_status-status = c_idoc_status_ok. ENDIF. APPEND idoc_status. ENDFUNCTION.
2. Maintaining Characteristics of the Inbound Function Module This step is an important step in processing IDoc Inbound functionality through the Inbound Function Module which has the Business logic. This step serves as a link between the Basic/IDoc type and Message Type and also when processing the data records using the process code (We will see more details about process code in the steps below). To maintain the characteristics, go to T-Code: BD51. Since this is a cross-client entry, the system will prompt an information message, Caution: The table is cross-client. Hit continue and proceed as below. Click on New Entries button and create a new entry. Proceed as below. Maintain the entries. Click Save and the system will prompt for the Workbench Request. Save and proceed.
The second column Input type contains three values, 0, 1 and 2. 0 option is for Function Modules for processing IDocs in packets, whereas, 1 and 2 is for function modules that process IDocs per call.
Note: Two groups of function modules are used to post IDocs: Function modules which process IDocs in mass. These transfer packets of IDocs for which individual IDocs are updated in the same Logical Unit of Work (LUW) Function modules which process one IDoc per call
Input type is the field that determines the way inbound function modules are used for posting
3. Assign Inbound Function Module to Logical Message Type and Basic/IDoc Type After maintaining the characteristics of the Inbound Function Module, next step is assigning the function module to Logical Message Type and Basic/IDoc type. To create the link, go to T-Code: WE57 and proceed as below. Click on the Change icon and the system will prompt an Information Message, Caution: The table is cross-client. Hit Enter and continue. Click on the New Entries button and maintain the entries. Proceed as below.
4. Create Custom Process Code Process Code: Process Codes are used in both ALE and EDI framework to identify the function module or API (Application Programming Interface) to be invoked for subsequent processing. Inbound as well as outbound interfaces use process code but for different purposes.
Note: Outbound Process Codes are stored in table TEDE1, while Inbound Process Codes are stored in TEDE2. T-Code for Inbound Process Code: WE42, T-Code for Outbound Process Code: WE41
To create a custom process code, go to T-Code: WE42 and proceed as below, Click on the button DisplayChange, and then click on the button New Entries and proceed. While saving the system will prompt you for the Customizing Request, save the same and continue.
Now Click on the folder Logical message on the left of the screen and maintain the below entries,
5. Creation of Partner Profile Now we need to create the partner profile in the Receiving System which represents the Sender. Go to T-Code: WE20 and enter the partner details as shown below. We need to enter, the Custom Process Code that we created to process the Inbound IDoc and provide the name of the Message Type in the screen, Inbound paramtrs
This marks the end of tasks required to be done on the Receiving side.
Part 3 - Testing the IDoc process 1. SENDER RECEIVER In this case, we will generate the IDoc from SENDER (for demo which is an SAP system) and push it to the RECEIVING System (SAP system) Go to T-Code: WE19 (Tool to test the IDoc processing Inbound/Outbound) in the SENDER system and proceed as below, Choose the option Via message type and put the Message Type ZDEMOMAS and hit Execute.
Note: Other options to execute the same can be achieved through options, Basic type or an Existing IDoc (in case we have one).
Click on the header EDIDC and enter the Control record (IDoc) information, proceed as below,
Note: SAPEC1 is the default port of the sender. The logic behind this is, SAP + System ID. Ex. System ID is EC1.
Next we fill the data in the IDoc segment, proceed as below,
After filling the data record, hit the button Start outbound processing. The system will trigger the outbound processing. Proceed as below,
Now we check that the data has been pushed to the Receiving System, by confirming the IDoc status in the Sending System. Go to T-Code: WE02 and proceed as below,
Double Click on the node Control Record Status of the IDoc,
on the Left pane, and we can check the Control
This finishes the task of sending the IDoc to the Receiving System.
Part 4 - Checking the results in Receiving System Check the IDoc received in Receiving System 1. Log on to the Receiving System and check the IDoc that has been received and posted. Again we go to T-Code: WE02 and proceed as below,
Double click on the line item, and we can check that IDoc status is 53 Application Document Posted.
2. Let us now confirm the data record, by check the entries in d/base table, T100. Go to T-Code: SE16 and we can check that, a line item has been inserted.
For quick of the above record in T100, go back to the Part 3 of this document where we are populating the data record (IDoc segment)
This task finishes the complete cycle from pushing the IDoc from the Sender to receiving and processing the IDoc in the Receiving System
Conclusion
This step by step quick guide will help the technical consultants to develop custom IDocs and required customizations and settings required to handle the data transfer between an SAP Non-SAP or between SAP systems
Related Content
Quick Guide EDIIDoc Interfacing to SAP ECC from External System Creating a New Function Module (Inbound Processing with ALE Services) Reorganizing Change Pointers How to Find Authorization Object for any Transaction Code For more information, visit the ABAP homepage
Copyright
Copyright 2011 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 Oracle Corporation. JavaScript is a registered trademark of Oracle Corporation, 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.

Data Exchange and Integration Between Different Systems Using Custom IDoc's and EDI - ALE Process - A Complete Reference

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Exchange and Integration Between Different Systems Using Custom IDoc's and EDI - ALE Process - A Complete Reference

Uploaded by

Copyright:

Available Formats

Data Exchange and Integration between Different Systems using Custom IDocs and EDI/ALE Process A Complete Reference

Company: SAP India Global Delivery Created on: 24 August 2011

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 2

Technical Process steps

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 3

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 4

Once the segment is released, the Release Box will be checked.

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 5

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 6

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 7

Hit the Header Data icon

and we can see all the relevant details

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 8

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 9

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 10

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 11

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 12

Let us briefly understand the feature of each one of them,

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 13

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 14

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 15

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 16

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 17

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 18

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 19

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 20

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 21

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 22

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 23

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 24

Next we fill the data in the IDoc segment, proceed as below,

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 25

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 26

Double Click on the node Control Record Status of the IDoc,

on the Left pane, and we can check the Control