Sap Ale Idocs

SAP ALE / IDOCS

EXPERIENCE

TEAMWORK

www.jhsoftech.co.nr

JH SOFTECH

JH SOFTECH

www.jhsoftech.co.nr 5/19/2009 4:57:09 PM 5864_ER_WHITE. 2

JH SOFTECH


JH SOFTECH

Agenda 1

INTRODUCTION ALE

2 3 4

IDOCS CONFIGURATION


JH SOFTECH

Agenda Inbound system

5

Analysis

6 7 8 9

Design Conclusion

References


JH SOFTECH

ERP BriefOverview Overviewof ofALE ALE Brief VariousMethods Methodsof ofCA CA Various Benefits Benefits Disadvantages Disadvantages


JH SOFTECH

ERP BriefOverview Overviewof ofIDOCS IDOCS Brief CreatingNew NewIdocs Idocs Creating Configuration Configuration Summary Summary


JH SOFTECH

Overview of ALE Abbreviation Evolution What is ALE? Benefits Disadvantages


JH SOFTECH

ALE

Application Link Enabling


JH SOFTECH

What is ALE ? • ALE is SAP’s technology to support distributed yet integrated processes across several SAP sytem • Middleware tool in SAP’s Buisness Framework Architecture • ALE can integrate business processes and functions between R/3 system and non-R/3 systems as well as between loosely coupled R/3 Systems


JH SOFTECH

Benefits Of ALE • Communication interfaces allow connections integration with non-SAP systems. • Distribution of applications between different releases of R/3 Systems • Any SAP system can be upgraded to a newer release without affecting the existing functionality. • ALE has functions for monitoring messages flows and handling communication problems. Thus provides reliable distribution.


JH SOFTECH

ALE Consists of • Outbound Process • Inbound Process • Exception Handling


JH SOFTECH

ALE- Outbound Process Architecture


JH SOFTECH

Some Concepts used in outbound inbound • Message Control –

Is an cross application technique used in pricing, account determination, and output determination. The output determination technique triggers ALE and outputs for a business document

• Change Pointers –

Based on change document technique

–

Changes made are recorded in change document header table CDHDR


JH SOFTECH

Concepts Contd... • Selection Programs – –

These are typically implemented as functional modules . Extracts Application data and creates a mater IDoc.

–

A selection program exists for each message type.

• Filter Objects –

They remove unwanted data for each recipient of data

• Port Definition –

They are used in an outbound process to define the medium in which documents are transferred

–

ALE uses tRFC port, which transfers data in memory to buffer

• RFC Destination –

It is the logical name used to define the characteristics of a communication link to a remote system on functions needs to executed

–

In ALE it specifies information required to log on to the remote SAP system to which IDoc is sent


JH SOFTECH

Concepts Contd.. • Partner Profile – It specifies logical names, IDoc type, message type, tRFC port – Packet size for an IDoc – Mode in which process sends an IDoc (batch versus immediate) – Person to be notified in case of errors.


The Technical flow an outbound process for Masterdata

JH SOFTECH

Begin Process Flow for distributing Master Data: Objects to be distributed are selected Data is read from the databa se and formatted into IDOC format

ALE service layer is invoked via MASTER_IDOC_DISTRIBUTE ALE Distribution model is cons ulted to determine recipients Filtering conversion & Version change are carried out for each recipient Communcation Idocs are saved in the database

No Collect Idocs

Yes Execute RSEOUT00 Program Idoc Packets are stored in the ARFC Data

Execute RSARFCEX , which calls INBOUND_IDOC_PROCESS on the Remote System

Successful

No

www.jhsoftech.co.nr Done

5/19/2009 4:57:09 PM 5864_ER_WHITE. 16

JH SOFTECH

Processing in the Application Layer • The customer distribution model is consulted to make sure that a receiver has been defined • If at least one receiver exists, then IDoc selection program creates reads data object from database and creates master IDoc • Master IDoc is stored in memory • Program then calls ALE service layer using MASTER_IDOC_DISTRIBUTE passing it master IDoc


JH SOFTECH

Processing in ALE interface Layer • Receiver Determination –

Receivers are determined from the customer distribution model

• IDoc Filtering –

IDoc filter is specified in distribution model.

–

If data record doesn’t meet filter criteria, it is dropped

• Segment Filtering –

A set of segment that are not required can be filtered out.

• Field Conversion –

Values in the data records can be converted to global or to specific values for receivers


JH SOFTECH

Processing in ALE Interface Layer contd.. • Version Change for segments –

A new version of segment always contains fields from the previous version and additional fields that are added for the new version. Seg.Release in IDoc type.

• Communication IDocs are generated –

After all conversion and filtering operations ,communication records are generated .

–

One master IDoc can have multiple IDoc depending upon number of receivers

• Syntax Check is performed –

Goes through syntax check and data integrity validation.

• IDocs are dispatched to the communication layer


JH SOFTECH

Processing in the Communication layer • System reads the port definition specified in the partner profile which is then used to read RFC destination • RFC system contains communication settings to log on to remote system • The sending system calls INBOUND_IDOC_PROCESS module asynchronously on the destination system and passes IDocs via memory buffers


JH SOFTECH

ALE- Inbound Process Architecture


JH SOFTECH

Some Concepts Used in Inbound • Posting Programs –

They are implemented as function modules and they read data from IDoc and create an application data from it.

–

A process code exists for each message type. like MATM for MATMAS

–

A process code is assigned to each posting program. Like MATM to IDOC_INPUT_MATMAS

• Partner Profile –

It consists of partner number, mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.


JH SOFTECH

ALE- Inbound Process Architecture




Process Flow for Inbound

JH SOFTECH

Begin

Remote system calls IDOC_INBOUND_ASYNCHR ONOUS and passes communication idoc to the system

User id is validated & authorizations are checked

Data in the control record is validated against the partner profile

ALE Services : Filtering conversion & Version change are carried out Application Idoc is saved in the database

Yes

Process Idoc immediately

No Program RBDAPP01 is Executed Read process code from the partner profile

Process code points to the posting module

Posting Module creates the application document

www.jhsoftech.co.nr

Done

5/19/2009 4:57:09 PM 5864_ER_WHITE. 24

JH SOFTECH

Processing in the Communication Layer • The INBOUND_IDOC_PROCESS is triggered as a result of RFC from the sending system. • IDoc to be processed is passed as an input parameter. • Control is transferred to ALE/EDI layer.


JH SOFTECH

Processing in the ALE/EDI Interface Layer • Basic Integrity check –

A basic integrity check is performed on the control record data such as direction, message type, and IDoc type.

• Segment filtering and conversion –

Unwanted segments can be filtered out at this stage

• Application IDoc is created on database and syntax check is performed • The IDoc is marked ready for dispatch • IDoc is passed to the posting program –

Partner Profile is read. If the value of the Processing field is set to Process Immediately, the IDoc is passed to posting program using RBDAP001

–

Else it is buffered in the system until RDBAPP01 is executed explicitly


JH SOFTECH

Processing in the Posting Module • The processing code in the partner profile points to posting module for the specific message in IDoc • The posting module implemented as function module either calls SAP transaction using call transaction command for posting documents or invokes a direct input function module. • The results of execution is passed back via function module’s output parameters • If posting is successful, an application document is created and IDoc gets status code of 53 else it gets status code 51


JH SOFTECH

Exception Handling • Workflow is integrated in the outbound to handle exceptions. If an error occurs at stage, a designated user is notified. • Person to Be notified field in the Partner Profile is used to send the error notification.


JH SOFTECH

ALE SETUP (SALE) • Define logical systems • Assign Logical Systems to Clients • Define Communication Parameters: RFC Destination • Modeling the distribution • Generate Partner Profiles


JH SOFTECH

Define logical systems


JH SOFTECH


JH SOFTECH


JH SOFTECH

Assign Logical System Names for Clients


JH SOFTECH


JH SOFTECH


JH SOFTECH

Define Communication Parameters: RFC Destination


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH

Modeling the distribution


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH

Generate Partner Profiles


JH SOFTECH


JH SOFTECH

20.8.26.12


JH SOFTECH

IDocs


JH SOFTECH

What is an IDOC? •

• • • • •

IDoc stands

for intermediate document. It is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data. When we execute an outbound ALE or EDI Process, an IDOC is created. In an inbound ALE or EDI process, an IDOC serves as input to create an application document. Stored in the database. Every IDOC has an unique number (within a client). IDocs are based on EDI standards, ANSI X.12 and EDIFACT.


JH SOFTECH

• IDocs are independent of the sending and receiving systems.(SAPto-SAP as well as Non-SAP) • Independent of direction of data exchange. i.e. can be used by both outbound and inbound process. • IDocs can be viewed in a text editor. Data is stored in character format instead of binary format.


JH SOFTECH

IDOC Components  There

are basically two types of IDocs .

• Basic IDocs • Extended IDocs


JH SOFTECH

IDoc DEFINITION COMPONENTS Basic IDOC Type (WE30) • Basic IDoc type - defines the structure and format of the business document to be exchanged between two systems. It can either be SAP provided or customer – developed. Characteristics Name – up to 30 characters where last two signify the version no.  List of permitted segments.  Hierarchy of segments.  Mandatory/optional segments.  Minimum/maximum range of each segment.


JH SOFTECH

Segments Segments- A segment defines format and structure of the data record. They are reusable components. Data fields in IDocs may be of two types- positional and based on qualifiers. Segment Components Segment type- version independent name of segment. SAP provided begin with E1 and customer defined by Z1.


JH SOFTECH



Segment definition- version dependent. Segment definition is version dependent definition of a segment where you specify the fields that belong to the segment. Segment Definitions can be no more than 1000 bytes. SAP Segment Definitions start with E2 and customer segment definitions start with Z2.After a segment is released and a new version of SAP is installed any change to the segment definition creates a new segment definition. The name of the Segment Definition is 10 characters long and is automatically assigned by the system from the name of segment type. The last three characters represent the version of the segment.



Segment Documentation- Represents data dictionary documentation for the fields in segments.


JH SOFTECH

• A segment definition is a version of a segment. A version always contains all, and at least one field more, than the previous one. There must only be one segment definition per release. If a new segment definition is to be created, the previous one must be released.


JH SOFTECH

Extended IDocs Extending Existing IDOC Type • Used in cases where some additional information is required in addition to that supplied by the Standard IDoc Type. • In Transaction WE30 we create the IDoc as an Extension and specify the basic type for which it is an extension.


JH SOFTECH

IDOC RUNTIME COMPONENTS An IDoc is an instance of an IDoc type. At runtime following events occur.  Unique IDoc no. is allocated.  One control record is attached to the IDoc.  Segments translate into data records.  Status record are attached.


JH SOFTECH

TYPES OF RECORDS IN IDocs • Control record • Data record • Status record


JH SOFTECH


JH SOFTECH

CONTROL RECORD • All control information information like IDoc number , sender , receiver, receiver, message type. • There is only one control record per IDoc. • Structure for control record is same for all IDoc. • It is stored in EDIDC table. Documen Documentat tation ion-- WE61 WE61


JH SOFTECH

DATA RECORD They contain application data and are are divided in two partsAdministrative and Data section ( of 1000 bytes). • Administrative Section consists consists of Idoc number, number, Segment Segment Name, Segment number, Version, Segment Hierarchy etc. • Data Section contains the data of respective segment. • Data section is mapped to a segment type as defined in administrative section to interpret meaning of various data values in a record. Documen Documentat tation ion-- WE61 WE61


JH SOFTECH

STATUS RECORDS • Attached to the IDOC throughout the process . • Status code, date, time are assigned. Status codes :- For outbound processing - 0-49 For inbound processing - above 50 • Latest status code is maintained in the control record. List of status codes – WE47 Documentation- WE61


JH SOFTECH

IDoc DEVELOPMENT


JH SOFTECH

IDoc DEVELOPMENT A steps to create a new IDoc are- 1. Create a new IDoc type or an extension.

2. Assign the IDoc type to message class(we82). 3. Create programs for new or extended IDocs. 4. Customize ALE interface to recognize the IDocs and their programs.


JH SOFTECH

1. Creating a new basic IDOC type 1. Create Segment type - (WE31). 2. Create Basic IDoc type- (WE30). 3. Release the segment type and basic IDoc type.


JH SOFTECH

Creating a Segment • Go to transaction code WE31. • Enter the name for your segment type and click on the Create icon. • Type the short text. • Enter the variable names and data elements. • Save it and go back. • Go to Edit -> Set Release. • Follow steps to create more number of segments.


JH SOFTECH

Create IDOC Type • Go to transaction code WE30. • Enter the Object Name, select Basic type and click Create icon. • Select the create new option and enter a description for your basic IDOC type and press enter. • Select the IDOC Name and click Create icon. • The system prompts us to enter a segment type and its attributes. • Choose the appropriate values and press Enter. • The system transfers the name of the segment type to the IDOC editor.


JH SOFTECH

Create Message Type • Go to transaction code WE81. • Change the details from Display mode to Change mode. • After selection, the system will give this message “ The table is cross-client (see Help for further info)”. Press Enter • Click New Entries to create new Message Type. • Fill details. • Save it and go back.


JH SOFTECH

Assign Message Type to IDoc Type • Go to transaction code WE82. • Change the details from Display mode to Change mode. • After selection, the system will give this message “ The table is cross-client (see Help for further info)”. Press Enter. • Click New Entries to create new Message Type. • Fill details. • Save it and go back.


JH SOFTECH

1.Create a new IDoc type or an extension


JH SOFTECH

1.

Creating a new basic IDOC type Creating a new segment type (we31)


JH SOFTECH


JH SOFTECH


JH SOFTECH

Create an IDoc type – (we30)


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH

Release Release the segment segment type(WE31) type(WE31) and and IDoc type (WE30) (WE30)


JH SOFTECH


JH SOFTECH

2. Create a new message class (we81)Assign the IDoc IDoc to a me messa ssage ge class class (we82) (we82)


JH SOFTECH

2. Create a new message class (we81)Assign the IDoc to a message class (we82)


JH SOFTECH


JH SOFTECH

WE82


JH SOFTECH


JH SOFTECH


JH SOFTECH

3.Create programs for new or extended IDocs


JH SOFTECH

OUTBOUND PROGRAM FOR CUSTOM BASIC IDOC TYPES Outbound bound are also referred as IDoc generation programs. Based on the triggering mechanism used for IDoc generation there are three types: • Outbound IDocs from Message Control. • Outbound IDocs from stand-alone programs. • Outbound IDocs from change pointers.


JH SOFTECH

Brief rundown:  Outbound IDocs from Message Control. These programs are implemented as function modules and are specifically designed for applications that make use of message control component to generate IDocs.The interface is preset by SAP. This is mainly used by EDI processes for transactional data. ALE uses the message control for distributing transactional data. Example Purchase order.  Outbound IDocs from stand alone program These programs are developed as stand alone programs with their own interface. They can be implemented as reports or separate function modules that can be called from another program. These programs are mainly used for master data distribution in ALE.


JH SOFTECH

 Outbound

IDocs from Change Pointers These programs are implemented as function modules and their interface is set by SAP. These programs are mainly used for master data distribution based on changes made to master data. For example when material master is changed.


JH SOFTECH

PROGRAM FLOW FOR STAND ALONE • Select application data from the database . • Populate control record information. • Populate an internal table of type EDID with data records for the various segments. • Call the ALE service layer(MASTER_IDOC_DISTRIBUTE) to create the IDoc in the database. • Commit work.


JH SOFTECH

INBOUND PROGRAM FOR CUSTOM BASIC IDOC TYPES Inbound programs are also called posting programs. Basic scenario – The ALE layer calls the posting program and passes IDoc data to it. Posting programs are implemented as function modules and are designed to read IDoc data and create an application document. Advanced scenario - Function modules can be designed for advanced scenarios like mass processing , serialization checks, advanced workflow programming etc.


JH SOFTECH

PROGRAM FLOW • Read control record information. Verify control information(msg type) if message type is incorrect, raise the exception. • Read the IDoc data for the idoc.Several IDocs can be posted together. • Parse through each data record and build internal tables as required by the direct posting function module. • Call the posting program and capture the results. • Populate the return parameters. • If more IDocs are present go to step 2 else go to next one. • Return the function module. The results of the exceptions are passed to the ALE layer.


JH SOFTECH

4.Customize ALE/EDI interface to recognize the IDocs and their programs


JH SOFTECH

The steps in configuring an outbound process depend on the type of program you have developed for the outbound IDoc . For stand alone programs we have following steps• Add the message to the ALE distribution model IN sender’s side. (BD64) • Create or change partner profile.


JH SOFTECH

Configuring the inbound process • Add the message type to the ALE distribution model in receiver’s side. • Define attributes for the inbound function module. (BD51) • Allocate the function module to the logical message type.(WE57) • Create a new process code(WE42) • Create/ change a partner profile to add the message type and the process code.(WE20)


JH SOFTECH

Developing and Assigning process code to the inbound function module (WEDI)


JH SOFTECH

Attributes of inbound function module (BD51)


JH SOFTECH


JH SOFTECH

Assignment of FM to logical message and IDoc type(WE57)


JH SOFTECH


JH SOFTECH

Inbound Process code(WE42)


JH SOFTECH


JH SOFTECH

Setting Inbound Parameters for Partner Profile (we20)


JH SOFTECH


JH SOFTECH

Triggering the outbound process • Triggering the outbound process via change pointers. • Triggering the outbound process via stand alone programs. 1. Standard program for the master data 2. Custom program for your own message type


JH SOFTECH

Triggering the outbound process via change pointers.


JH SOFTECH

Change Pointers • Tracks changes made to key documents in SAP, such as Material master , customer master , and sales orders. • When master data is changed , Changes made to a document are recorded in the change document header table CDHDR, and additional change pointers are written in the BDCP table for changes relevant to ALE. • Report RBDMIDOC is executed to process change pointers and call the function module for IDoc generation logic.


JH SOFTECH

Triggering the outbound process via change pointers Activating change pointers globally (BD61)


JH SOFTECH

Activating change pointer for a message type ( BD50)


JH SOFTECH

Specify the Fields for which Change pointers are to be written ( BD52)


JH SOFTECH

BD21 – Create idoc type from change pointers


JH SOFTECH

Triggering the outbound process via stand alone programs.


JH SOFTECH

Triggering the outbound process via stand alone programs. 1. Standard program for master data e.g RBDSEMAT (BD10)


JH SOFTECH


JH SOFTECH


JH SOFTECH

Triggering the outbound process via stand alone programs. 2. Custom program for your own message type REPORT zrep_idoc_outbound. TABLES: z1seg_1,zvcust. *data declaration DATA: itab_data TYPE STANDARD TABLE OF edidd WITH HEADER LINE, itab_control_data TYPE STANDARD TABLE HEADER LINE,

OF edidc WITH

itab_comm_idoc TYPE STANDARD TABLE OF edidc WITH HEADER LINE, itab_cust TYPE STANDARD TABLE OF zvcust WITH HEADER LINE.


JH SOFTECH

SELECT customerid fname INTO CORRESPONDING FIELDS OF TABLE itab_cust FROM zvcust WHERE customerid = '000000000010000'. *fill control table itab_control_data-direct = '1'. itab_control_data-rcvpor = 'A000000083'. itab_control_data-rcvprn = 'REC_IDOC'. itab_control_data-rcvprt = 'LS'. itab_control_data-doctyp = 'ZIDOC_1'. itab_control_data-mestyp = 'ZGET'. APPEND itab_control_data.


JH SOFTECH

*fill data table LOOP AT itab_cust. CLEAR itab_data. CLEAR z1seg_1. z1seg_1-customerid = itab_cust-customerid. z1seg_1-fname = itab_cust-fname. itab_data-sdata = z1seg_1. itab_data-segnam = 'Z1SEG_1'. APPEND itab_data. ENDLOOP


JH SOFTECH

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING master_idoc_control = itab_control_data TABLES communication_idoc_control = itab_comm_idoc master_idoc_data = itab_data


JH SOFTECH

EXCEPTIONS error_in_idoc_control error_writing_idoc_status

=1 =2

error_in_idoc_data =3 sending_logical_system_unknown = 4 OTHERS = 5. COMMIT WORK. IF sy-subrc <> 0. WRITE sy-subrc. ELSE. WRITE / itab_status-status. WRITE / itab_status. ENDIF.


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH


JH SOFTECH

Inbound Processing of IDocs ALE Layer

Application Layer

Reads Idocs Process

Lock Idocs

Call Inbound Program Write Status records

message Type Call direct input function module or call transaction Return the results Application Document

Commit work Unlock Idocs www.jhsoftech.co.nr 5/19/2009 4:57:09 PM 5864_ER_WHITE. 131

JH SOFTECH

INTERFACE FOR THE FUNCTION MODULE • Importing parameters:Input_method- specifies the mode for call transaction method.eg A (all screens), e(error) and space (background) Mass processing:-used for advanced workflow scenarios. Default value is space. • Exporting parameters:Workflow_result:- Indicates if the posting was successful or not. Value of 0 indicates success and 99999 indicates failure. Aplication variable:- Used in advanced workflow scenarios. In_update_task:-specifies how the piece of code that updates database tables was invoked.


JH SOFTECH

Call_transaction_done- specifies how status codes are updated. In ALE enabled transactions the codes are updated in the program. • Tables:IDoc_control :- Input parameter Idoc_data_:- Input parameter IDoc_status:- Output parameter.Contains the status records for each idoc. Return variables:- Output parameter and is used for workflow processing.It has two field wf_param and doc_num .Doc_num contains the Idoc no. or the document no. and the values for the wf_param are processed_idocs, error_idocs, appl_objecs.


JH SOFTECH

INBOUND Function Module for Customer defined programs FUNCTION Z_IDOC_INPUT_ZGET2. *INCLUDE MBDCONWF. DATA: segty_data LIKE Z1SEG_1. DATA: itab_cust LIKE zvcust OCCURS 0 WITH HEADER LINE. DATA:wa_cust LIKE zvcust OCCURS 0 WITH HEADER LINE. LOOP AT IDOC_CONTRL. IF IDOC_CONTRL-MESTYP NE 'ZGET'. RAISE wrong_function_called. ENDIF. CLEAR: itab_cust. REFRESH itab_cust. LOOP AT idoc_data WHERE docnum EQ idoc_contrl-docnum. CASE idoc_data-segnam. WHEN 'Z1SEG_1'. segty_data = idoc_data-sdata. MOVE-CORRESPONDING segty_data TO itab_cust. ENDCASE. ENDLOOP.


JH SOFTECH

SELECT SINGLE * FROM zvcust INTO wa_cust WHERE customerid EQ itab_cust-customerid. IF sy-subrc NE 0. INSERT INTO zvcust VALUES itab_cust. ELSE SELECT MAX( customerid ) FROM zvcust INTO wa_cust-customerid. itab_cust-customerid = wa_cust-customerid + 1. INSERT INTO zvcust VALUES itab_cust. ENDIF. IF sy-subrc EQ 0. Workflow_result = 0. return_variables-wf_param = 'PROCESSED IDOCS'. return_variables-doc_number = idoc_contrl-docnum. return_variables-wf_param = 'APPL_OBJECTS'. return_variables-doc_number = itab_cust-customerid.


JH SOFTECH APPEND return_variables. idoc_status-docnum = idoc_contrl-docnum. idoc_status-status = '53'. idoc_status-msgty = 'I'. idoc_status-msgid = 'ZE'. idoc_status-msgno = '006'. idoc_status-msgv1 = itab_cust-customerid. idoc_status-msgv2 = itab_cust-FNAME. APPEND idoc_status. ENDIF. ENDLOOP. ENDFUNCTION.


JH SOFTECH

THANK YOU!


JH SOFTECH

Agenda


JH SOFTECH

Q&A

Q&A www.jhsoftech.co.nr 5/19/2009 4:57:09 PM 5864_ER_WHITE. 139

Sap Ale Idocs

Recommend Documents