Your SlideShare is downloading. ×
0
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
IDOCS ALE
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IDOCS ALE

2,103

Published on

ALE IDOCS

ALE IDOCS

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,103
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
325
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Application Link Enabling –SAP data interfacing  ALE is SAP proprietary technology that enables data communications between two or more SAP systems and or R/3 and external systems. ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time . ALE is SAP’s solution to support distributed applications.
  • An IDOC Type: is an SAP Data Dictionary defined structure provides the highest level definition for a file has a predefined structure represents a series of related business documents An IDOC (formally ‘Message’): is the occurrence of a message type is the actual representation of a business transaction
  • The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
  • The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
  • The IDOC data records contain the data of the message. The data records are passed in an internal table and they have to match the structure of the IDOC (sequence of segments, min/max, hierarchy etc.) EDIDD is a generic structure used for all IDOC segments SEGNAM field identifies the segment type SDATA contains the actual data of the segment
  • Status Record- table EDIDS –Information we get from Status record: Status number Message IDoc type Direction Data and time stamp Detailed description of status by code and text Location of exception in Intermediate Document Detector of exception by program and user. The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound IDocs begin from '50'. When an IDoc is created, the IDoc Interface sets the status in the function module EDI_DOCUMENT_CLOSE_CREATE. All additional status records are written explicitly by the function module EDI_DOCUMENT_STATUS_SET. It is possible to have Custom Statuses also.
  • The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
  • The first step in creating a new IDOC is to create all the segments that go into that IDOC. There are some rules that have to be followed while creating the segments: The name of that segment type must start with ‘Z1’ For each field in the segment you have to define a field name, a data element for the segment structure and a data element for the segment documentation. The data element for the segment structure has to be of data type ‘CHAR’ The IDOC tools create overall three structures: Z1nnnnn - field names Z2nnnnn - data elements for structure definition Z3nnnnn - data elements for documentation IDoc type IDoc structure type Receiver port/partner type/partner number Sender port/sender type/sender number
  • The next step is to create the IDOC type by “assembling” all the necessary segments. Part of our scenario analysis was to define the layout of the IDOC. We should have addressed the following questions: Which segments should be used ? What is the hierarchy of the segments ? Which segments are mandatory and which are optional ? How often may a segment be repeated ? SAP recommends to create the structures as flat as possible. Usually each level of segment hierarchy results in a looping structure in the corresponding program. Therefore it’s easier to deal with flat structures. Conceptually the IDOC type describes the technical structure of the message
  • Here is how to create a new IDOC type by assembling previously defined segments: Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type Select creation of new basic IDOC type Put segments into the IDOC Segment -> Create Enter segment name Enter attributes (Mandatory/Minimum/Maximum number)
  •   Once the IDOC type is defined a message type has to be created. A message type determines how the data in the IDOC is being processed. This allows to use the same IDOC in different scenarios but process the data differently through different message types. A Message Type is the equivalent of a business document type. It characterizes the data being sent across systems, e.g. MATMAS is a message type for Material Master. Here is how to define a new message type : Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type Go to message type maintenance: Environment -> Message types Table view -> Display -> Change New entries Customer message types should be in the customer name range (starting with Z) Last step of the IDOC creation process is to link the new IDOC type with the new message type. Later in the process the message type will be linked to the outbound and inbound programs. With these configurations it is determined how the IDOC is being processed. The relationship between IDOC type and message type is a 1-to-many relationship. That means an IDOC can be associated with multiple message types thus allowing the IDOC to be processed differently, but a message type refers to exactly one IDOC type. Here is how to link the message type with the IDOC type : Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain message type for Intermediate structure Choose function “EDI: Message types and assignment to IDOC types” Link your message type with your IDOC type Table view -> Display -> Change New entries Message type : Z…… Basic IDOC type: Z…..
  • The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
  • The application drives distribution: ALE does not read application tables to build messages, instead the applications have ALE-calls built in. Data consistency is ensured by the database: the application document and the ALE-document (IDOC) are posted in the same LUW (logical unit of work). Hence if one fails to post, both fail. The following slides give more details on output processing.
  • At the point in an application where an ALE message may need to be sent, the application can query the distribution model to determine whether its message type is in use. The query can also determine the filter objects required by the recipient(s), allowing IDocs to be built containing only the relevant information if need be. The alternative is to build an IDOC containing all the application data and use the ALE recipient determination to remove unwanted data segments.
  • If the previous query showed that an ALE message is required, the application builds an IDocs an internal table and passes it to the ALE layer via a function call.
  • If no recipients have been specified by the application, ALE will refer to the distribution model to determine recipients. The recipient determination is data-dependent: segments containing data not specified in the model are removed from the IDOC. For example, if the model states that only information for company code 1000 is to be transmitted, segments containing information for other company codes would be deleted. The ALE distribution model is discussed later.
  • For each recipient and message type, segments can be removed independent of their contents. This allows transmission costs to be reduced in cases when the receiving system cannot or need not process the filtered segments.
  • Individual field values can be converted if needed; for example, two-digit plant codes in R/2 would need to be converted to four digit values for R/3. Field conversion should be used sparingly for performance reasons. If many fields need conversion, with many different values, customers should consider using a third party converter. SAP is in contact with a number of manufacturers and is planning to certify those that meet ALE requirements.
  • The version changer allows systems with different release levels (e.g. 3.0 and 4.0) to communicate with one another. This is technically possible because extensions to messages are restricted to make the version changer work efficiently. The section on intermediate documents (IDocs) deals with this in more detail.
  • Links needed to be able to keep track of the documents created for the initial application document. The application document is linked to the IDOC, which is in turn linked to the communication layer's transaction ID.
  • Dispatch control is where technical parameters are maintained: whether to pass the IDocs to the file interface for EDI-subsystems, or to other systems via asynchronous remote function calls. whether IDocs should be sent immediately or cumulated and sent periodically by a batch job; in the latter case the packet size (see later) is determined here.
  • First step in creating our own ALE scenario is to do a scenario analysis. We have to understand what the data looks like that is going to be exchanged, how we it is being extracted and how it is being processed. We have to consider the following questions: How is the Data Container (IDOC) being structured ? Which data fields have to be transferred ? How many logical groups of data (header vs. line item) do we have ? Do we have hierarchical structures ? Are there any optional or mandatory groups ? How long are the data fields ? When should which data be sent ? How does the triggering work ? Where is the data being extracted from ? What should the receiver to with the data ? Once we have done our analysis we should have a clear understanding about the IDOC structure. Assuming we have designed the layout of our IDOC it is fairly simple and straightforward to define that IDOC in SAP with the so called IDOC definition tools. There are 4 main steps involved in creating the IDOC: Create segments Create IDOC type Create message type Link message type with IDOC type
  • In implementing an outbound program we have two deals with mainly two issues: Designing the program logic Defining a trigger mechanism for the program The program logic defines how the data gets extracted from the application tables and how the IDOC is being created. The trigger mechanism defines how the interface (and an ALE scenario is nothing else than a SAP-to-SAP interface) gets kicked off. In the following, we will first focus on program logic and than explore different options to trigger the outbound IDOC creation.
  • The fundamental logic of an outbound IDOC program is fairly simple. It can be subdivided into 3 steps: Select the data from the application tables Fill the data into the IDOC Pass the IDOC to the ALE layer Compared to a traditional interface program the main difference is that the data is selected into the IDOC format and send to the ALE layer as opposed to writing the data out to a flat file. The selection logic itself is the pretty much the same. The entry point into the ALE layer is the function module “MASTER_IDOC_DISTRIBUTE”. All ALE functionality that was introduced earlier (Receiver determination, Segment filtering, Version Control, Dispatch Control) is buried in that function module. That functionality is totally transparent to a programmer - all he is concerned with is to call MASTER_IDOC_DISTRIBUTE with the appropriate parameters.
  • Let’s have a closer look at the function module “MASTER_IDOC_DISTRIBUTE” Conceptually “MASTER_IDOC_DISTRIBUTE” accepts as a parameter exactly one IDOC. That IDOC is passed in the two structures “master_IDoc_control” and “master_IDoc_data”. “master_IDoc_control” is a one-dimensional data structure (field string) that holds the IDOC control record. We will see shortly the minimal information that needs to go into the IDOC control record. “master_IDoc_data” is a two-dimensional data structure (table), that holds all the data records of the IDOC to be sent out. We will shortly see what information needs to put into the data records of an IDOC. “communication_IDoc_control” is a data structure that returns back additional control record information of the IDOC that was created. The most important information passed back is the IDOC number. This data structure doesn’t have to be filled before “MASTER_IDOC_DISTRIBUTE” is called.
  • Since the EDIDD structure is used for all different type of IDOCs containing all sorts of Segments, filling the EDIDD structure is a little bit tricky. First you have to fill the 55-byte header with the Segment name. Second the 1000-byte SDATA field needs to be filled. This is a two-step process (similar to a COBOL - redefine construct): First, fill the data into a field string that has the structure of the segment type you want to fill Secondly, move the whole field string into the SDATA field Note: The receiver of the IDOC needs to execute the reverse logic. The SEGNAM information helps to parse out the SDATA field by moving it into a field string that matches the layout of the segment type specified in the SEGNAM field.
  • There are a couple of general rules that have to be followed when constructing the IDOC program: All fields must be left-justified Currency Amounts must be converted All SAP codes must be converted into ISO codes SAP codes that have to be converted include Currency keys, country Keys, Unit of measure and Shipping instructions.
  • All fields in the IDOC are defined with a data type of ‘CHAR’. SAP choose that approach to ensure independency of any internal binary representations. All fields have to left-justified. ABAP automatically converts different data types into each other. However, this automatic conversion doesn’t produce the desired left-justification for all data types. SAP requires to convert the all data types with the exception of ‘char’, ‘cuky’, ‘clnt’, ‘accp’, ‘numc’, ‘dats’, ‘tims’ or ‘unit’. The easiest way to left-justify the fields is with the ‘Condense’ statement
  • SAP decided not to use any SAP specific codes in the IDOC. Instead they recommend to use ISO codes. Note: This decision a relict from the EDI world. In an SAP-to-SAP scenario it doesn't make sense, because the receiver program has to do the conversion back into the SAP code ! As long as the sender and receiver have the same assumptions about the codes, there is no technically reason to do code conversions. SAP delivers a set of function modules to do these conversion: Currency keys: ‘currency_code_sap_to_iso’ Country keys: ‘country_code_sap_to_iso’ Units of measure: ‘unit_of_measure_sap_to_iso” Shipping instructions: ‘sap_to_iso_package_type_code’ The Currency Amounts has also be converted with the function module ‘currency_amount_sap_to_idoc’ Note: There is a similar set of function modules to do the conversion in the opposite directions (from ISO to SAP). These function modules have to be used on the receiving side.
  •   The distribution of systems (ALE) makes it necessary to be able to identify every system individually within a network. The "logical system" is used to do this. A logical system is an application system within which the applications are coordinated to work in one database. In the SAP sense of the word, a logical system corresponds to a client.
  • The Remote Function Call is controlled via the parameters of the RFC destination. The RFC destinations must be maintained in order to create an RFC port. The name of the RFC destination should correspond to the name of the logical system in question. The following types of RFC destinations are maintainable: · R/2 links · R/3 links · internal links · logical destinations · CMC link · SNA/CPI-C connections · TCP/IP links · links of the ABAP/4 drivers
  • You specify the technical characteristics of the link between the SAP System and the other system in the port definition. The following port types are supported: Asynchronous RFC R/2 System File interface The ALE interface generates ports automatically. The EDI interface assigns numbers internally for these ports. Hence the ports can be identified explicitly. The system can only generate the numbers if a number range is entered for the number range object EDIPORT in number range 01.
  •   Tells the ALE Layer how to send Msg. Between systems. The Partner No. is the logical system name of the other system. The Partner type is ‘LS’ ( logical system) for ALE. The Partner Class is a free text field that classifies Partners.
  •   The Distribution Model is a tool that stores information about the flow of messages across various systems. The model stores data that dictates which messages flow to which logical systems. It Combines logical systems, message types, and filter objects to represent the distribution scenario and is maintained with in the IMG (transaction SALE).In the IMG, the model is maintained from a senders perspective A distribution model is owned and mastered by one logical system and distributed to other logical systems
  • The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
  •   A filter object type is used in the Customer Distribution Model to impose a selection criterion on the message type flowing to a logical system. A filter object type with a value associated with it is called a filter object . A Filter Object Type is used in the Customer Distribution Model to impose a selection criterion on the message (type) flowing to a logical system A Filter Object is a Filter Object Type with a value associated with it, e.g. BUKRS (company code) is a filter object type available for message type DEBMAS (Customer Master). A filter object with value BUKRS = 1001 will allow distribution of Customer Master data for Company Code ‘1001’ only for that specific Logical System
  • For master data the decision what trigger mechanism to use is mainly a question if there is a requirement to send out only data objects that have been changed since the last time the object has been sent or not (e.g. only send materials that have been added/changed since the last run). If only changed objects should be send out, then change pointers are a natural way of triggering if they exist. Typically a change pointer exists whenever a change document exists. However there are certain exceptions (e.g. Classification writes change pointers but no change documents). If no change pointers exists than a standalone program is the solution. The program needs to keep track of all the changes since the last run (e.g. in a custom table w/ date/timestamp and key to data object). If there is no need to send out changed objects than a standalone program similar to the exercise (and RBDMSEMAT) is sufficient. Typically there is a need to specify the the objects to be sent out (e.g. Selection screen with Material number from/to)
  • For transactional data the main criteria to pick a solution is to decide if transactional integrity is a requirement. If so, than data has to be posted within the same LUW as the application document and non- or double-processing of IDocs has to be avoided. That leaves only the options of hard coding the ALE logic or using output determination. In the case of hardcode calls to the ALE layer the existence of a user-exit determines if this scenario can be implemented within the enhancement concept of SAP (No Modification vs. Modification). However, there is not always a need for transactional integrity. For example in SAP-to-Legacy scenarios one could decide to implement an interface in a less restrictive way (since the legacy system can typically not ensure transactional integrity anyway). An example could be an interface were all open orders are extracted in IDOC format from SAP and send to legacy. For those kind of solutions the same trigger mechanism than for master data can be used.
  • Change Pointers is a technique that was specifically developed to support master data distribution for changed data only. Change Pointers are (usually) based on change documents. Change documents (table CDHDR, CDPOS) are documents that are written to provide an audit trail about changes made to certain data (old value, new value, person who made the change etc.). While change documents keep track of all the changes made in the system, the change pointers are temporary in a sense that they have a status associated with them that keeps track if the change has already been processed or not. The change pointers therefore give a clear picture what changes need to be sent out. Change Pointer based IDOCs are usually generated with a batch job (RBDMIDOC) RBDMIDOC determines and calls a message type-specific function module that loops over the open change pointers and generates an IDOC for each of them.
  •   Change Pointers are R/3 objects that mark changes to SAP Master data. Change Pointers are managed by mechanisms in a SMD tool and are based on Change Document Objects. CD objects record the changes in table CDHDR & CDPOS. Internal mechanisms update table BDCP & BDCPS, which host the change pointer. In case there are any changes to the data by running transaction BD21for the particular message type we can pick up the changed materials for that particular message type. Activate change pointers for message type or generally.   
  •  
  • There are three major pieces of configuration necessary for a change pointer-based outbound scenario: Change Pointer creation definition Change Pointer activation Function module related configuration Change Pointer creation: IMG: Extensions -> Master data distribution -> Activate change pointer per change document item With this configuration you define which change document element are relevant for creating a change pointer Change Pointer activation: This configuration is not any different from any of the existing change pointer-based ALE scenarios. There are two steps involved: Activate change-pointers generally Activate change-pointers per message type Function module related configuration: IMG: Extensions -> Master data distribution -> Set up additional data for message type This configuration is necessary to “publish” new function module to RBDMIDOC. It ties the message type to the function module.
  • The first part of input processing mirrors output processing, with version change, segment filter and field value conversion. The IDOC is first written to the database, with a link to the IDOC in the sending system, and then input control takes over: the type of input is determined (function module, workflow, workitem) the input timing is determined (immediate or cumulated and processed in batch) who should be informed in case of error If serialization is necessary, the application posting function can call an ALE-API (function module) to determine whether the IDOC has been overtaken (explained later). IDOC processing is complete when an application document is created or changed; to signal this, a success status record is added to the IDOC in the same LUW (logical unit of work) as that in which the application document is processed. The only exception to the above is the with ORDERS and ORDCHG, where a call transaction is first called and then the status is updated.
  •  
  •  
  •  
  • On the inbound side there are 3 major elements that need to be developed to finalize a custom ALE scenario: Inbound function module: The function module is responsible for processing the IDOC and creating an application document from the IDOC data. The function module is called by the ALE layer and has to return back information about the success of the document posting. ALE configuration: The ALE layer has to have knowledge which function module to call for a certain message type / IDOC type. These assignments are made through ALE configuration Workflow task: ALE error handling is done via workflow. A workflow task has to be defined that can be executed for the case that the application document posting in the function module was not successful. The ALE layer gets the information about the success of the posting passed from the inbound function module. The workflow takes is started by the ALE layer. Here is a more detailed look at these 3 components and how they interact. INBOUND_IDOC_PROCESS is the generic entry point for all inbound IDOC processing. This function module is called by the sending SAP systems and gets one or more IDocs passed as parameter. All the ALE layer functionality that we learned about previously (Version change, segment filtering, field conversions) are handled in that function module. INBOUND_IDOC_PROCESS takes information out of the control record of the IDOC to access the partner profile. Part of the partner profile is a process code that is tied to an inbound IDOC function module. This function module is then being called. The SAP naming convention for an inbound function module is IDOC_INPUT_<MSGTYPE>. Since we have to stay within the customer name space, a custom inbound module typically is called Z_IDOC_INPUT_<MSGTYPE>. The inbound function module reads the rest of IDOC data and posts the application document. It returns status information back to the ALE layer about the success of that posting. Depending on the return information of the inbound function module, the ALE layer (INBOUND_IDOC_PROCESS) triggers a workflow task to initiate error handling. The information which task to start is part of the ALE configuration.
  • Here is a example scenario for Material master Error handling: Inbound function module tells ALE layer that an error has occurred ALE triggers object’s (I.e. IDOCMATMAS) event ‘inputErrorOccured’ Object’s event is linked with standard task (I.e 0007946: MATAMAS_Error) Work item appears in user’s inbox When user executes work item, object’s method ‘InputForeground’ is executed When IDOC was successfully processed, object’s event ‘inputFinished’ is triggered, which completes work item.
  • Unfortunately there is not enough time in this class to cover more of workflow. Please refer to the workflow class and the ALE programmers guide. Here is a summary of the necessary steps to enable IDOC error handling: Create a new Business Object for IDOC as child of IDOCAPPL Create new customer task Create event-couplings linking InputErrorOccured to standard task InputFinished to function module Update Process Code to refer to the above mentioned objects and events To support mass processing: Create new object type as child of IDOCPACKET
  • There are a number of issues you have to keep in mind when developing inbound IDOC programs. We will briefly discuss four of them. For a more detailed description please refer to the ALE programmers guide.
  • On the outbound side, we discussed the problem of transactional integrity (for transaction data). We noted, that the IDOC has to be created within the same LUW than the application document. Both together make up the successful transaction. The similar concept applies to the inbound side. It is imperative to ensure that an incoming IDOC only gets processed once and that in the case of a rollback both the IDOC and the application document are backed out. The key is to update the IDOC status record (which indicates that the IDOC has been processed) and the application document within the same LUW. Since the application document gets posted by the IDOC function module and the status records get updated by the ALE layer (INBOUND_IDOC_PROCESS), NO Commit work should be issued by the IDOC function module. This constraint doesn’t doesn’t apply to master data since a second posting would not lead to duplicate documents.
  • This slide depicts the interaction between the ALE layer and the IDOC function module in more detail. Note, that the application document is posted by the function module whereas the IDOC status records are updated by the ALE layer. To make both updates part of one LUW, the IDOC function module should NOT issue a Commit Work !
  • For some IDOC types it might be a problem if one IDOC is overtaken by another IDOC, because later updates would be overwritten by earlier ones. Since this is dependent on the IDOC type this serialization function is not build in to the ALE layer. It needs to be coded within the application function module.
  • SAP delivers a function module (IDOC_SERIALIZATION_CHECK) that detects overtaken function modules. Prerequisite for using that function module is the definition of a serialization object. Note, that there is no automatic handling of serialization errors. All you can do is to feed back an error status to the ALE layer and then kick of a workflow task to deal with that error.
  • Instead of processing one IDOC at a time it is possible to run in “mass processing mode”. In this mode the IDOC function module receives a number of IDOCs as input parameter and it processes them with one Commit Work. This can have performance benefits. The inbound function module has to be coded so that it can handle multiple IDOCs and the attributes of the function module in the ALE configuration has to be set to mass processing. For examples on how to program ‘mass processing’ function modules please refer to the ALE programmers guide.
  • The easiest way to write Inbound function modules is to use a ‘Call Transaction’ statement to create an application document out of the IDOC data. This is easy to program and the programmer doesn’t need knowledge about the underlying data structures. Another benefit is the ability to process error IDOCs in foreground, which actually runs the transaction in foreground, allowing the user to step through the screens of the transactions. However there are two big drawbacks in using call transactions within IDOC function modules: Call transaction is slow Call transactions issue an implicit COMMIT WORK. Therefore data consistency can not be guaranteed !! SAP recommends not to use Call Transactions because of the data consistency problems. They require a transaction to be ALE-enabled instead. However, there are a number of delivered IDOC function modules that use non-ALE-enabled transactions. Bottom line: Use a function modules to post your documents, if possible. Use can use Call Transaction, if transaction is ALE-enabled If Transaction is not ALE-enabled, you use it at your own risk For master data, data consistency is not that big of an issue
  • Transcript

    • 1. IBM Global Services © Copyright IBM Corporation 2006 Overview of ALE / IDOCs March, 2006
    • 2. IBM Global Services © Copyright IBM Corporation 2006 Topics to coverTopics to cover  What is ALE?  Components of ALE.  Anatomy of an IDoc.  ALE Processing  Transactions For Monitoring and Processing IDocs.  Questions
    • 3. IBM Global Services © Copyright IBM Corporation 2006 ALE TerminologyALE Terminology •ALE - Application Linking & Enabling •IDoc - Intermediate Document •EDI - Electronic Data Interchange
    • 4. IBM Global Services © Copyright IBM Corporation 2006 ALE ObjectiveALE Objective
    • 5. IBM Global Services © Copyright IBM Corporation 2006 ALE!! What is it ?? It is a set ofIt is a set of  Tools,  programs and  data definitions that provides the mechanism forthat provides the mechanism for distributing functionality and data acrossdistributing functionality and data across multiple system.multiple system.
    • 6. IBM Global Services © Copyright IBM Corporation 2006 What Data can be Exchanged ?What Data can be Exchanged ? Transaction Data –SD, MM, FI, CO, etc. Master Data –Material, Customer, Vendor, etc. Control Data –Organizational Reference Information •Plants, Sales Orgs, etc. Data required to enable tightly coupled, distributed applications –Separate HR, Separate Treasury, etc.
    • 7. IBM Global Services © Copyright IBM Corporation 2006 Features –ALE / IDocsFeatures –ALE / IDocs Distributed System yet integrated with SAP R/3 Based on ‘Application-to-Application integration using ‘Message Architecture’ Reliable communication Data is exchanged using “IDocs” Support both R/2, R/3 and External system If network problem, message is buffered ALE support backward compatibility ALE ensure that , data is transferred only once
    • 8. IBM Global Services © Copyright IBM Corporation 2006 ALE ScenarioALE Scenario Document SAP System R/3 SAP System R/3 IDoc EDI SubsystemEDI Subsystem IDocIDoc
    • 9. IBM Global Services © Copyright IBM Corporation 2006  What is ALE ?  Components of ALE.  Anatomy of an IDoc.  ALE Processing  Transactions For Monitoring and Processing IDocs.  Trouble Shooting  Questions Topics to coverTopics to cover
    • 10. IBM Global Services © Copyright IBM Corporation 2006 Components of ALEComponents of ALE Services:Services: Application ServicesApplication Services Distribution ServicesDistribution Services Communication ServicesCommunication Services Tools:Tools: Customizing ToolsCustomizing Tools Development ToolsDevelopment Tools
    • 11. IBM Global Services © Copyright IBM Corporation 2006 Application ServicesApplication Services Services:Services: Application ServicesApplication Services Distribution ServicesDistribution Services Communication ServicesCommunication Services Tools:Tools: Customizing ToolsCustomizing Tools Development ToolsDevelopment Tools This is where the SAP applications ( SD, FI, MM etc. ) generate their data and documents
    • 12. IBM Global Services © Copyright IBM Corporation 2006 Distribution ServicesDistribution Services Services:Services: Application ServicesApplication Services Distribution ServicesDistribution Services Communication ServicesCommunication Services Tools:Tools: Customizing ToolsCustomizing Tools Development ToolsDevelopment Tools  Recipients  Formats and Filters the data  Creates IDocs ( Intermediate Documents
    • 13. IBM Global Services © Copyright IBM Corporation 2006 Communication ServicesCommunication Services Services:Services: Application ServicesApplication Services Distribution ServicesDistribution Services Communication ServicesCommunication Services Tools:Tools: Customizing ToolsCustomizing Tools Development ToolsDevelopment Tools •TCP/IP •RFC •tRFC • etc
    • 14. IBM Global Services © Copyright IBM Corporation 2006 Development ToolsDevelopment Tools Services:Services: Application ServicesApplication Services Distribution ServicesDistribution Services Communication ServicesCommunication Services Tools:Tools: Customizing ToolsCustomizing Tools Development ToolsDevelopment Tools  Model Maintenance Tool. (for configuring the flow of data between systems ) Shared Master Data(SMD)tools (for distributing master data )  Customization parameters (within SAP for IDoc filtering and conversion. )
    • 15. IBM Global Services © Copyright IBM Corporation 2006 Customizing ToolsCustomizing Tools Services:Services: Application ServicesApplication Services Distribution ServicesDistribution Services Communication ServicesCommunication Services Tools:Tools: Customizing ToolsCustomizing Tools Development ToolsDevelopment Tools Tools for creating and modifying IDocs
    • 16. IBM Global Services © Copyright IBM Corporation 2006 Application Data Master IDOC Determine Receipients Determine Receipients Filter/Convert Data, Create IDOC Filter/Convert Data, Create IDOC Comm. IDOC Application Functions Application Functions Filter/Convert Data Filter/Convert Data Comm. IDOC CarrierCarrier Application Layer Distribution/ ALE Layer Communication Layer ApplicationApplication In a Nut ShellIn a Nut Shell
    • 17. IBM Global Services © Copyright IBM Corporation 2006 Topics to coverTopics to cover  What is ALE ?  Components of ALE.  Anatomy of an IDoc.  ALE Processing  Transactions For Monitoring and Processing IDocs.  Trouble Shooting  Questions
    • 18. IBM Global Services © Copyright IBM Corporation 2006 IDoc ConceptIDoc Concept  R/3 System System 1 SAP Document  EDI subsystem  R/3 System  R/2 System  3rd party software System 2 IDoc
    • 19. IBM Global Services © Copyright IBM Corporation 2006 IDoc StructureIDoc Structure Status Record IDoc-ID Status information Data Record IDoc-ID Sequence/Hierarchy Segment Format definition for • header data • item data Control Record IDoc-ID Sender-ID Receiver-ID IDoc type and logical message External structure
    • 20. IBM Global Services © Copyright IBM Corporation 2006 Control record Data Record Status Record IDOC “Intermediate Document”
    • 21. IBM Global Services © Copyright IBM Corporation 2006 The very first record of an IDoc package is always a control record. The structure of this control record of the structure EDIDC and describes the contents of the data contained in the package. The control record goes to table EDIDC Control RecordControl Record
    • 22. IBM Global Services © Copyright IBM Corporation 2006 Message TypeMessage Type Message Type indicates How to Know what the data Means Data Exchanged by IDOC and EDI is known as Messages Message of same kind belong to the same message type Message types are stored in table EDMSG
    • 23. IBM Global Services © Copyright IBM Corporation 2006 All records in the IDoc, which come after the control record, are the IDoc data. They are all structured alike, with a segment information part and a data part, which is 1000 character in length, filling the rest of the line. Data & Segment info is stored in EDID4 for release 4.x and EDID3 for release 2.x and 3.x. Data RecordData Record
    • 24. IBM Global Services © Copyright IBM Corporation 2006 Status RecordStatus Record Information about the IDoc status like: IDoc identification number Status number - table verified IDoc type Direction Data and time stamp; Structure: EDIDS
    • 25. IBM Global Services © Copyright IBM Corporation 2006 Status of IDOCStatus of IDOC  A two-digit status is assigned to an IDoc to allow the processing to be monitored.  The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound IDocs begin with '50'.  Status confirmation when using port type 'File': The external system writes the status records in a status file, which is read by the R/3 System. In this case, the confirmation always refers to outbound IDocs.  Status confirmation using IDoc type SYSTAT01: The system sending the confirmation writes the status records as data records of IDoc type SYSTAT01. All port types and both directions can be entered.
    • 26. IBM Global Services © Copyright IBM Corporation 2006 Idoc SegmentsIdoc Segments TCODE: WE31
    • 27. IBM Global Services © Copyright IBM Corporation 2006 Idoc TypesIdoc Types TCODE: WE30
    • 28. IBM Global Services © Copyright IBM Corporation 2006 How to Attach SegmentsHow to Attach Segments
    • 29. IBM Global Services © Copyright IBM Corporation 2006 Message TypesMessage Types WE81 WE82
    • 30. IBM Global Services © Copyright IBM Corporation 2006 IDOC Type/ Message Type/ Processing Function ModuleIDOC Type/ Message Type/ Processing Function Module Valid combination of Message type and IDOC type are stored in table EDIMSG Combination of message type and IDOC type determine the processing algorithm. This is usually a function module and is set up in table EDIFCT.
    • 31. IBM Global Services © Copyright IBM Corporation 2006 Topics to coverTopics to cover  What is ALE ?  Components of ALE.  Anatomy of an IDoc.  ALE Processing. i.Outbound Processing ii.Inbound Processing  Transactions For Monitoring and Processing IDocs.  Trouble Shooting  Questions
    • 32. IBM Global Services © Copyright IBM Corporation 2006 Outbound Processing
    • 33. IBM Global Services © Copyright IBM Corporation 2006 Outbound processing: directOutbound processing: direct Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDOCs Comm. layer asynch. RFC or EDI CLinks C Comm. layer
    • 34. IBM Global Services © Copyright IBM Corporation 2006 Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs Comm. layer asynch. RFC or EDI Links C Querying the ModelQuerying the Model asynch. RFC or EDI Comm. layer C - ALE supplies APIs (function modules) to allow applications to query the model  Is anybody interested in my message type?  Optional: what filter objects are they interested in?
    • 35. IBM Global Services © Copyright IBM Corporation 2006 Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs - The application creates the IDOCThe application creates the IDOC - Technically it is stored as anTechnically it is stored as an internal tableinternal table - Passed to ALE via an APIPassed to ALE via an API (function module)(function module) Links C Handover IDoc to ALEHandover IDoc to ALE asynch. RFC or EDI C Comm. layer
    • 36. IBM Global Services © Copyright IBM Corporation 2006 Receiver determinationReceiver determination Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs asynch. RFC or EDI Links C asynch. RFC or EDI C Comm. layer - If the application has no specifiedIf the application has no specified recipientsrecipients  ALE refers to the customerALE refers to the customer distribution model to determinedistribution model to determine themthem  Data not relevant to receiverData not relevant to receiver (according to model) is removed(according to model) is removed in ALE layer.in ALE layer.
    • 37. IBM Global Services © Copyright IBM Corporation 2006 Segment filterSegment filter Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs asynch. RFC or EDI Links C asynch. RFC or EDI C Comm. layer - The filter is data-independentThe filter is data-independent - IDOC segments that are notIDOC segments that are not required can be removedrequired can be removed - The filter is message and receiver-The filter is message and receiver- specificspecific
    • 38. IBM Global Services © Copyright IBM Corporation 2006 Field value conversionField value conversion Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs asynch. RFC or EDI Links C asynch. RFC or EDI C Comm. layer - The contents of individualThe contents of individual fields can befields can be  translated to new valuestranslated to new values  suppressedsuppressed - The filter is message andThe filter is message and receiver-specificreceiver-specific
    • 39. IBM Global Services © Copyright IBM Corporation 2006 Version changeVersion change Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs Comm. layer asynch. RFC or EDI Links C asynch. RFC or EDI C Comm. layer - IDOCs can be changed to olderIDOCs can be changed to older versionsversions - Systems with different releaseSystems with different release levels can communicatelevels can communicate without additional applicationwithout additional application logiclogic
    • 40. IBM Global Services © Copyright IBM Corporation 2006 Make LinksMake Links Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs CCLinks asynch. RFC or EDI C Comm. layer - Links are written between IDOCLinks are written between IDOC andand  Application object containedApplication object contained in IDOCin IDOC  Communication-Layer'sCommunication-Layer's "Transaction-ID""Transaction-ID"
    • 41. IBM Global Services © Copyright IBM Corporation 2006 Dispatch controlDispatch control Application posting Need to create IDOC? Create master IDOC Customer Distribution Model Receiver determination Segment filter Field value conversion Version change ALE layer Dispatch control Database M Application document posted simultaneously with IDocs C asynch. RFC or EDI Links C asynch. RFC or EDI C Comm. layer - Technical comms parameters areTechnical comms parameters are defineddefined - EDI or aRFC (asynch. remoteEDI or aRFC (asynch. remote function call)function call) - Send immediately or cumulateSend immediately or cumulate and send via batch joband send via batch job  If batch, packet size isIf batch, packet size is determineddetermined
    • 42. IBM Global Services © Copyright IBM Corporation 2006 Scenario analysisScenario analysis • How does the IDOC look like ? • How is data being sent ? • How is the data being received ?
    • 43. IBM Global Services © Copyright IBM Corporation 2006 Outbound program development • Program logic – “How is the IDOC being created ?” • Triggering – “How is the IDOC creation kicked off ?”
    • 44. IBM Global Services © Copyright IBM Corporation 2006 Program logicProgram logic • Select data from application tables • Fill data into IDOC • Pass IDOC to ALE layer (Call function MASTER_IDOC_DISTRIBUTE) • Commit Work • Receiver determination • Segment filtering • Version Control • Dispatch Control IDOC program ALE layer MASTER_IDOC_DISTRIBUTE
    • 45. IBM Global Services © Copyright IBM Corporation 2006 MASTER_IDOC_DISTRIBUTEMASTER_IDOC_DISTRIBUTE Call function ‘MASTER_IDOC_DISTRIBUTE’  Exporting  master_idoc_control: IDOC control record  Tables  communication_idoc_control: returned information about the distribution  master_idoc_data: IDOC data segments
    • 46. IBM Global Services © Copyright IBM Corporation 2006 Filling an EDIDD structureFilling an EDIDD structure Header (55bytes) SDATA (1000bytes) …. SEGNAM ….EDIDD Z1SEG Field1 Field2 Field3 Field4 “10” “ABC” MOVE “Z1SEG” to EDIDD-SEGNAM MOVE “10” to Z1SEG-FIELD1 MOVE “ABC” to Z1SEG-FIELD2 MOVE Z1SEG to EDIDD-SDATA
    • 47. IBM Global Services © Copyright IBM Corporation 2006 General Programming rulesGeneral Programming rules  Design Guidelines for creating IDOC data records: • Left-justified filing of IDOC Fields • Replacing SAP codes with ISO codes  currency keys  country keys  unit of measure  shipping instructions • Converting Currency Amounts
    • 48. IBM Global Services © Copyright IBM Corporation 2006 Left-justified FillingLeft-justified Filling  All fields must be left-justified  Character fields:  automatic  Non-character fields:  ‘Condense’ statement must be used  Check IDOC documentation to find out which fields require a ‘condense’  All types unequal to ‘char’, ‘cuky’, ‘clnt’, ‘accp’, ‘numc’, ‘dats’, ‘tims’ or ‘unit’ require a condense
    • 49. IBM Global Services © Copyright IBM Corporation 2006 Code ConversionsCode Conversions  Replacing SAP codes with ISO codes – Currency keys: ‘currency_code_sap_to_iso’ – Country keys: ‘country_code_sap_to_iso’ – Units of measure: ‘unit_of_measure_sap_to_iso’ – Shipping instructions: sap_iso_package_type_code’ • Conversion of currency amounts – ‘currency_amount_sap_to_iso’
    • 50. IBM Global Services © Copyright IBM Corporation 2006 Basic Configuration ElementsBasic Configuration Elements  Create and allocate Logical System  Define Ranges (Idocs, Ports, etc )  Define RFC Destinations  Define Ports  Maintain Customer Model  Create Partner Profiles
    • 51. IBM Global Services © Copyright IBM Corporation 2006 Logical SystemLogical System TCODE: BD54; Stored in table T000
    • 52. IBM Global Services © Copyright IBM Corporation 2006 Allocate Logical System to the clientAllocate Logical System to the client SALE > BASIC SETTINGS > SET UP LOGICAL SYSTEM > ASSIGN LOGICAL SYSTEM TO THE CLIENT TCODE: SCC4
    • 53. IBM Global Services © Copyright IBM Corporation 2006 Number RangesNumber Ranges  Maintain number ranges for ports  Maintain number ranges for IDocs  Maintain number ranges for IDoc types and segment version  Maintain number range for change pointers
    • 54. IBM Global Services © Copyright IBM Corporation 2006 Maintaining RFC DestinationsMaintaining RFC Destinations TCODE: SM59
    • 55. IBM Global Services © Copyright IBM Corporation 2006 Displaying and Maintaining PortsDisplaying and Maintaining Ports A port is a logical representation of aA port is a logical representation of a communication channel in SAP withcommunication channel in SAP with the data communicated being IDocsthe data communicated being IDocs. TCODE: WE21
    • 56. IBM Global Services © Copyright IBM Corporation 2006 Partner ProfilesPartner Profiles TCODE: WE20
    • 57. IBM Global Services © Copyright IBM Corporation 2006 Partner Profiles-OutboundPartner Profiles-Outbound
    • 58. IBM Global Services © Copyright IBM Corporation 2006 Partner Profiles-InboundPartner Profiles-Inbound
    • 59. IBM Global Services © Copyright IBM Corporation 2006 Distribution ModelDistribution Model TCODE: BD64
    • 60. IBM Global Services © Copyright IBM Corporation 2006 Transfer of dataTransfer of data Transfer master data for material, customer, vendor to different client or system with BALE
    • 61. IBM Global Services © Copyright IBM Corporation 2006 Filter ObjectsFilter Objects BD95 BD59
    • 62. IBM Global Services © Copyright IBM Corporation 2006 Sending Master Data IdocsSending Master Data Idocs Only send objects that have changed ? Change Pointer available? Master data ? Standalone with custom logic to keep track of changes Change Pointer based Program y N Y Standalone program with user-definable selection criteria N Y
    • 63. IBM Global Services © Copyright IBM Corporation 2006 Sending Transactional Data IdocsSending Transactional Data Idocs Ensure trans- actional Integrity? Output Determinat ion available ? Transaction Data ? hard coded ALE layer Modification Output determination based Program y N Y N Y User-Exit available? N Hardcoded ALE layer no Modification Y See Master data
    • 64. IBM Global Services © Copyright IBM Corporation 2006 Change PointersChange Pointers Application Posting • Post Application document • Create Change Document • Are changes ALE relevant ? •Write Change Pointers • Commit Work ALE configuration • ALE relevant Fields Batch Program (RBDMIDOC) IDOC Module (Masteridoc_Create_ SMD_<MSGTYPE>) • Read Change Pointers • Fill IDOC • Call ALE layer • Update Change Pointer Master data Change pointers ALE layer Master_IDOC_DISTRIBUTE • Determine IDOC module • Call IDOC module
    • 65. IBM Global Services © Copyright IBM Corporation 2006  Change PointersChange Pointers BD61 BD50
    • 66. IBM Global Services © Copyright IBM Corporation 2006  Change Pointers… ContinuedChange Pointers… Continued BD52 BD60
    • 67. IBM Global Services © Copyright IBM Corporation 2006 IDOC moduleIDOC module  IDOC module has to be implemented as function module  Naming Convention: MASTERIDOC_CREATE_SMD_<msgtype>  Function module reads change pointers information to get data that needs to go into IDOC  Function module logic:  Read change pointers  Fill IDOC structure  Call ALE layer  Update Change Pointer status  Commit Work
    • 68. IBM Global Services © Copyright IBM Corporation 2006 ALE Configuration For Change PointersALE Configuration For Change Pointers • Define change pointer creation • Define which change document fields are to be logged • Change pointer activation • Activate generally • Activate per message type • “Publish” new function module • Link message type to function module
    • 69. IBM Global Services © Copyright IBM Corporation 2006 ALE For Transactional data ---- Output DeterminationALE For Transactional data ---- Output Determination NACE
    • 70. IBM Global Services © Copyright IBM Corporation 2006 Output Determination -- Access SequenceOutput Determination -- Access Sequence
    • 71. IBM Global Services © Copyright IBM Corporation 2006 Output Determination -- Output TypesOutput Determination -- Output Types
    • 72. IBM Global Services © Copyright IBM Corporation 2006 Output Types -- DetailsOutput Types -- Details
    • 73. IBM Global Services © Copyright IBM Corporation 2006 Output Types -- Partner FunctionsOutput Types -- Partner Functions
    • 74. IBM Global Services © Copyright IBM Corporation 2006 Output Types -- Processing RoutinesOutput Types -- Processing Routines
    • 75. IBM Global Services © Copyright IBM Corporation 2006 Output Types -- ProceduresOutput Types -- Procedures
    • 76. IBM Global Services © Copyright IBM Corporation 2006 Output Types -- Procedures ControlOutput Types -- Procedures Control
    • 77. IBM Global Services © Copyright IBM Corporation 2006 Output Types -- Condition recordsOutput Types -- Condition records
    • 78. IBM Global Services © Copyright IBM Corporation 2006 Inbound Processing
    • 79. IBM Global Services © Copyright IBM Corporation 2006 Inbound Processing.Inbound Processing. Application posting Field value conversion ALE layer Input control Database A Simultaneously update IDOC's status Comm. layer asynch. RFC or EDI Version change Segment filter C A Post application document Process IDOCSerialization
    • 80. IBM Global Services © Copyright IBM Corporation 2006 Input ControlInput Control Application posting Field value conversion ALE layer Input control Database A Simultaneously update IDOC's status Comm. layer asynch. RFC or EDI Version change Segment filter C A Post application document Process IDOCSerialization - For each message type and senderFor each message type and sender one can defineone can define  when to processwhen to process (immediate/batch)(immediate/batch)  whether to call applicationwhether to call application directly or start customerdirectly or start customer workflowworkflow  who should get work items inwho should get work items in case of errorcase of error - Incoming IDOC packets are passed toIncoming IDOC packets are passed to applicationapplication
    • 81. IBM Global Services © Copyright IBM Corporation 2006 Application InputApplication Input Application posting Field value conversion ALE layer Input control Database A Simultaneously update IDOC's status Comm. layer asynch. RFC or EDI Version change Segment filter C A Post application document Process IDOCSerialization - Inbound IDOCs are passed toInbound IDOCs are passed to the application via athe application via a standardized functionstandardized function interfaceinterface
    • 82. IBM Global Services © Copyright IBM Corporation 2006 SerializationSerialization Application posting Field value conversion ALE layer Input control Database A Simultaneously update IDOC's status Comm. layer asynch. RFC or EDI Version change Segment filter C A Post application document Process IDOCSerialization - When processing theWhen processing the inbound IDOC, theinbound IDOC, the application can call an ALEapplication can call an ALE API (function module) toAPI (function module) to check that the IDOC has notcheck that the IDOC has not been overtakenbeen overtaken  If change No. 1 arrivesIf change No. 1 arrives after change No. 2, theafter change No. 2, the IDOC containing it hasIDOC containing it has been overtaken (by thebeen overtaken (by the IDOC containing theIDOC containing the later change)later change)
    • 83. IBM Global Services © Copyright IBM Corporation 2006 FM Assignment to Message Type and IDoc typeFM Assignment to Message Type and IDoc type TCODE: WE57
    • 84. IBM Global Services © Copyright IBM Corporation 2006 Process CodesProcess Codes WE41 WE42
    • 85. IBM Global Services © Copyright IBM Corporation 2006 Process Codes in Inbound and OutboundProcess Codes in Inbound and Outbound TCODE: WE64
    • 86. IBM Global Services © Copyright IBM Corporation 2006 FM For Inbound EDIFM For Inbound EDI TCODE: BD67
    • 87. IBM Global Services © Copyright IBM Corporation 2006 Inbound Program DevelopmentInbound Program Development INBOUND_IDOC_PROCESS IDOC ALE layer IDOC_INPUT_<MSGTYPE> • Read IDOC data • Post Application data • Send Success info back to ALE layer ALE configuration • Partner Profiles • Process Code • Function module attribute • Function module registry Workflow Task Call function Return Variables If ERROR, trigger • Version change • Segment filter • Field conversion
    • 88. IBM Global Services © Copyright IBM Corporation 2006 ALE error handlingALE error handling User action R/3 action Execute Workitem Fix error and reprocess IDoc or Flag IDoc for deletion Error in inbound function module ALE triggers error event Workitem appears in user's Inbox Display IDoc for user processing (IDoc method "InputForeground") ALE triggers end event Workitem completed input Error Occurred input Finished
    • 89. IBM Global Services © Copyright IBM Corporation 2006 ALE error handlingALE error handling  Necessary Steps:  Create new object type in Business Object Repository for IDOC; object is child of IDOCAPPL  Create new customer task  Create event-couplings linking  Event ‘inputErrorOccured’ linked to standard task  Event ‘inputFinished’ to function module  To support mass processing:  Create new object type as child of IDOCPACKET  Maintain process code to refer the above objects and events
    • 90. IBM Global Services © Copyright IBM Corporation 2006 Advanced Inbound TopicsAdvanced Inbound Topics • Data consistency • Serialization • Individual vs. mass processing • Call transaction function modules
    • 91. IBM Global Services © Copyright IBM Corporation 2006 Data ConsistencyData Consistency • Problem: – Ensure transactional integrity • Don’t process and IDOC twice • Allow for IDOC reprocessing after rollback of application document posting • Solution: – Application document must be posted in the same LUW as the IDOC status records – IDOC function module must not use a ‘Commit Work’
    • 92. IBM Global Services © Copyright IBM Corporation 2006 Data ConsistencyData Consistency ALE Layer Application function module Read IDoc(s) Commit Work Unlock IDoc(s) and application objects Lock IDoc(s) Write IDoc(s) status Write links Optional: Write serialization data Trigger event(s) Lock application objects Optional: Serialization check Process IDoc data Write application data to DB
    • 93. IBM Global Services © Copyright IBM Corporation 2006 SerializationSerialization Receiver 1 2 1 2 Object X, changed twice: First IDOC overtaken Comm. LayerSender !?!? Input from IDOC 1 must be prevented in order not to lose information from IDOC 2
    • 94. IBM Global Services © Copyright IBM Corporation 2006 SerializationSerialization  Check, if IDOC has been overtaken  Use function module ‘IDOC_SERIALIZATION_CHECK’  react to overtaken IDOCs according to your needs  Prerequisite is the definition of a serialization object
    • 95. IBM Global Services © Copyright IBM Corporation 2006 Mass ProcessingMass Processing  Processing more than one IDOC can improve throughput:  more than one IDOC is processed per Commit Work  the function can be coded to add multiple entries to a table with one update command (‘array insert’)  Function module has to be coded in a way that it supports mass processing  Attribute of delivered function module specifies if mass processing is supported or not
    • 96. IBM Global Services © Copyright IBM Corporation 2006 Call TransactionCall Transaction  Pros:  Error reprocessing in foreground  Easy to program  Cons:  Call Transaction has significant performance overhead  Automatic Commit work, no data consistency  Recommendation:  Try to use function modules that update database directly  If you want to use ‘Call transaction’, they have been ‘ALE- enabled’ to guarantee data concistency
    • 97. IBM Global Services © Copyright IBM Corporation 2006 Topics to coverTopics to cover  What is ALE ?  Components of ALE.  Anatomy of an IDoc.  ALE Processing  Transactions For Monitoring and Processing IDocs.  Questions
    • 98. IBM Global Services © Copyright IBM Corporation 2006 Monitoring IDocsMonitoring IDocs • The IDoc interface offers 2 different approaches for tracking of data load and data flow: Reports for monitoring Workflow for notifications • Both approaches are based on the concept of status transitions, i.e. an IDoc changes its status from a given value to another value.
    • 99. IBM Global Services © Copyright IBM Corporation 2006 List Of All IDocs Created. (Default, Additional, EDI)-- WE02/ WE05List Of All IDocs Created. (Default, Additional, EDI)-- WE02/ WE05
    • 100. IBM Global Services © Copyright IBM Corporation 2006 Selection Program For Issuing Output -- WE15Selection Program For Issuing Output -- WE15
    • 101. IBM Global Services © Copyright IBM Corporation 2006 Process All Selected IDocs. WE14Process All Selected IDocs. WE14
    • 102. IBM Global Services © Copyright IBM Corporation 2006 Test Tool For Idoc Processing (WE19)Test Tool For Idoc Processing (WE19)
    • 103. IBM Global Services © Copyright IBM Corporation 2006 Select IDocs BD87Select IDocs BD87
    • 104. IBM Global Services © Copyright IBM Corporation 2006 Idoc Search For Business Contents (Database). WE09Idoc Search For Business Contents (Database). WE09
    • 105. IBM Global Services © Copyright IBM Corporation 2006 Status Conversion With Trfc Execution. BD75Status Conversion With Trfc Execution. BD75
    • 106. IBM Global Services © Copyright IBM Corporation 2006 QuestionsQuestions
    • 107. IBM Global Services © Copyright IBM Corporation 2006

    ×