HI

Former Member · ‎2008 Feb 12

WHAT IS ALE ? HOW IS RFC RELATED TO ALE AND IDOC ??? ..

WHAT IS VALUE TABLE AND CHECK TABLE ? WHAT IS THE SIMILARITY AND DIFFERENCE BETWEEN THEM ?

WHAT IS BUFFERING ? WHAT ARE THE DIFFERENT TYPES OF IT AND ON WHAT BASIS ARE THEIR CLASSIFIED ?

Former Member · ‎2008 Feb 12

1) What is buffereing ?

Buffering is used to improve the performance while accessing the database tables. Bufering technich allows to maintain the databse records in application server itself. So performance can be improved.

There are 3 buffering categories

i) Buffering not allowed

ii) Buffereing allowed but switched off

iii)Bufeereing switched on

Buffering types:

i) Single records buf. Single record can be loaded in Apl Server from database

ii) Generic area bufeered: Group of records can be loaded in apl server from database server

iii) fully buffered : entire database table can be loaded from database to apl server

*2) Difference between value table and check table

I will explain it with an example.

Assume there are two tables employee(ZEMP) and department(ZDEPT) and having the fields as following

ZDEPT:

DEPT Primary Key

………….

…………..

ZEMP:

IDNO Primary Key

DEPT Foreign Key

………….

…………..

When making the DEPT as foreign key the system displays one popup in which you have to provide check table manually and pressing Generate Proposal. Then it will provide the relationship between those two tables.

If you maintain the value table (ZDEPT) for DEPT field in domain level. When making it as foreign key It provides small popup which ask as following.

Create a proposal with values table ZDEPT as check table?

If u press OK then it will create foreign key relationship without providing check table manually.

Values table doesn’t provide input help except the following case.

For example table ZTABLE contains domain ZDOMAIN which have the check table the table itself ZTABLE. In this case it provides input help from the value table if it doesn’t have other input help. Because value table have the least priority for displaying input help ( See the Hierarchy ).

The fields of the other tables which have the ZDOMAIN. In this case it never displays input help from value table.

Note: Input help from value table doesn’t provide the input help indicator. If you press F4 it will work.

The Hierarchy which decides from where to used the Input Help is:

1. Input help defined explicitly in ABAP Program or Dialog Module.

2. Input Help Attached to the referenced Database Table field.

3. Using the contents of Check Table as an input help if neither (1) or (2) help are there.

4. Input help from Fixed value or Value range given in Domain.

Reward me if it is useful.

Former Member · ‎2008 Feb 12

hi,

WHAT IS ALE ?

ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems.

ALE provides intelligent mechanisms where by clients can achieve integration as well as distribution of applications and data.

ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.

The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system.

ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

HOW IS RFC RELATED TO ALE AND IDOC

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an

RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an

asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.

WHAT IS VALUE TABLE AND CHECK TABLE?

Value Table

This is maintained at Domain Level.

When ever you create a domain , you can entered allowed values. For example you go to Domain SHKZG - Debit/credit indicator. Here only allowed values is H or S.

When ever you use this Domain, the system will forces you to enter only these values.

This is a sort of master check . To be maintained as a customization object. This mean that if you want to enter values to this table you have to create a development request & transport the same.

Check table

For example you have Employee master table & Employee Transaction table.

When ever an employee Transacts we need to check whether that employee exists , so we can refer to the employee master table.

This is nothing but a Parent & Child relationship . Here data can be maintained at client level , no development involved.

As per DBMS what we call foregin key table, is called as check table in SAP.

There is 1 more important Difference in Value Table and Check Table is that:

1. The contents of the check will be used as an input help(F4 Help) for a particular field on which a check table is assigned.

But the contents of Value Table are never used in Input Help.

The Heirarchy which decides from where to used the Input Help is:

1. Input help defined explicitly in ABAP Program or Dialog Module.

2. Input Help Attached to the referenced Database Table field.

3. Using the contents of Check Table as an input help if neither (1) or (2) help are there.

4. Input help from Fixed value or Value range given in Domain.

WHAT IS BUFFERING ? WHAT ARE THE DIFFERENT TYPES OF IT AND ON WHAT BASIS ARE THEIR CLASSIFIED ?

The system ensures that data transfer between the R/3 System and the database system is as efficient as possible. To do this, it uses the following techniques:

Table buffering: The program accesses data from the buffer of the application server.

Database request buffering: Individual database entries are not read or passed to the database until required by an OPEN SQL statement.

When you analyze trace records, you should also examine the system's buffering mechanisms.

Table Buffering

Tables can be either partially or fully buffered (refer to Buffering Database Tables). This means that an OPEN SQL statement only accesses the database if the results of the statement are not already in the buffer. Consequently, the SQL Trace does not contain a command or command sequence for every OPEN SQL statement. On the other hand, every SQL statement in the trace file has been sent to the database and executed.

Database Request Buffering

To minimize the number of time-consuming PREPARE operations, each work process on the application server has a buffer of SQL statements that it has already prepared. The default buffer size is 250 statements.

Whenever an OPEN SQL statement appears in a program, the work process checks whether it already exists in the "statement cache". If it does, the statement is executed immediately; that is, there is no further PREPARE operation, and the statement is executed using a REOPEN (for SELECT) or a REEXEC (for INSERT, UPDATE, or DELETE).

If the statement does not exist in the buffer, it must be prepared for the subsequent OPEN or EXEC operation. The buffer administration uses a LRU (least recently used) algorithm to delete those statements, whenever necessary, that are only seldom used. Frequently-used statements normally only need to be prepared once.

Application servers buffer DECLARE, PREPARE, OPEN, and EXEC statements in the cursor cache of their work processes. Once the system has opened a cursor for a DECLARE statement, it can carry on reusing it in the same work process.

The buffering type defines which table records are loaded into the buffer of the application server when a table record is accessed. There are the following buffering types:

Full buffering: All the records of the table are loaded into the buffer when one record of the table is accessed.

Generic buffering: When a record of the table is accessed, all the records having this record in the generic key fields (part of the table key that is left-justified, identified by specifying a number of key fields) are loaded into the buffer.

Single-record buffering: Only the records of a table that are really accessed are loaded into the buffer.

Hope this helps, Do reward.

Edited by: Runal Singh on Feb 12, 2008 3:17 PM

Former Member · ‎2008 Feb 12

Hi,

IDoc Definition:An intermediate document (IDoc) is a container for exchanging data between R/3, R/2 and non-SAP systems.

Use:

ALE uses IDoc to exchange data between logical systems. Non SAP-systems can use IDoc as the standard interface for data transfer. IDoc are created by message types and (object) methods when data is to be distributed.

Structure:

An IDoc represents a configuration of an IDoc type that determines the IDoc structure. An IDoc consists of a header, several data segments and status records.The functions of the individual elements of an IDoc are as follows:

The contents, structure, sender, receiver and current status of the IDoc are defined in the IDoc header.

Each data segment contains a standard header consisting of a sequential segment number, a description of the segment type and a 1000 character long string field containing the actual data of the segment. The status records show the history of the processing steps applied to the IDoc so far. The structure of the IDoc is recorded in the SAP System. The structure definition covers the

following: The segment sequence. Hierarchical relationships between segments are possible. The number of times a segment can occur is specified for each segment, as is whether the segment is a mandatory segment or an optional segment. The fields cont ained in a segment. In the example shown above the IDoc contains a header segment that has to be the first segment of the message.

Thereafter there must be at least one additional item. The following conditions apply:

Each item must be followed by at least one sub-item and at most 99

Up to 9999 text segments can appear after an item's sub-items (optional)

The last segment in a message must be an accumulation segment (ACCUM)

An IDoc can only contain character fields.

Modeling Distribution:

Purpose:

To implement the distribution of business application processes and functions using ALE you need to construct a logical Distribution Model of the whole system. Within the framework of this configuration customers can specify what applications are to run on what systems and what messages are to be exchanged between the applications .

Distribution Model:

Definition: The distribution model describes the ALE message flows between logical systems.

Use:

You can specify the relationships between logical systems, message types, BAPIs and filters inthe distribution model. Applications and the ALE layer use the model to determine the receivers and to control data distribution.

Structure:

In the distribution model you can specify the messages to be sent to a logical system. You can also define requirements for message content and dispatch in the Filters. The distribution model consists of one or more views that you can define. With more complex distribution tasks you can assign business sub-areas or groups of logical systems to separate views. To ensure correct functioning the relevant views of the distribution model must be available in all the logical systems involved in ALE. You can find the functions for distributing views in Customizing for ALE.

Creation of Custom IDOc type and message Type

First Create Partner Profile(WE20 Tcode) and Port Definition in WE19 Tcodes.

take the Basis help to create them.

1.First create segments in WE31 Tcode with the required dataelements

2.Create the Basic Idoc Type in WE30

release the Segments and IDOC type.

3.Create Message type in We81

4.Assign the message type to IDOC type in WE82 T code

5.Create the process code in We41 (for Outbound) WE42 (for Inbound)

6.Create A fun module in SE37 starting with ZIDOC_OUTPUT_.. by copying some Inbound (for Inbound) Outbound Fun module

7.Create Workflow setting if needed ..

8. Assign the fun module to Idoc Type, Message Type and WF object (if it is there)

9.Define setting for fun module in BD51

10.In BD51 Define the settings for Fun module..

10.Assign the Processs Code to Fun mod`ule

Outbound:

Step 1. Application document is created when transaction is saved.

2. Message control is invoked.

3. Messages are processed by system.

4. Messages are Edited (if desired).

5. Output (ALE / EDI) is checked

6. Validate against Message control record from Partner Profile

7. Application Document is saved.

8. Entry NAST table is created for every selected output program

along with Medium & Timing.

9. Check for Process Immediately .

If (yes)

Determine Processing Program from TNAPR Table.

ELSE

Execute RSNASTED Program.

10. Read Partner Profile to determine Process Code.

11. Process Code points to the Function Module & Invoked.

12. IDoc is generated.

13. Check for ALE Request.

if (Yes)

Perform Filters, Conversions, Version Changes etc.

Else.

IDoc is stored in DATABASE.

INBOUND:

Step 1. EDI Subsystem creates an IDoc file from EDI Messages

2. Subsystem calls Functional Module EDI_DATA_INCOMING from startRFC program.

3. Data in Control Record is validate against the Partner Profile.

4. IDoc is generated in Database and syntax check is carried out.

5. IDoc file is deleted once file read.

6. Event PROCESSSTATE REACHED is triggered in Idoc Object Workflow.

7. Check for Process Immediately.

If NO

Execute RBDAPP01 Program

Else

Read Process Code from Partner Profile

Process Code Points to Function Module

Application Document Posted.

IDoc Outbound Triggers

Last edited: 2000-04-26 18:17 +0200

IDocs should be sent out at certain events. This may be the change of data, periodically or at manual request. Therefore you have to define a trigger.

NAST Messages Based Outbound IDocs

One of the key tables in R/3 is the table NAST. This tables records message reminders written by applications. Every time an applications sees the necessity to pass information to a third party, usually a printed document. a record is written to NAST, which schedules the send of the message. The very same table is consequently also used by EDI, as an IDoc is only the paperless form of a printed document.

NAST messages are created by application NAST type IDocs are designed to be triggered by an output message, which is generated by an application. This is a standard functionality in most of the SAP core applications. Those applications - e.g. VA01, ME21 - perform calls to the function group V61B. The actual message is created with the function module MESSAGING by use of the customized condition technique.

NAST contains object key, sender and receiver Such an output message is stored as a single record in the table NAST. That record stores all information that is necessary to create an IDoc. This includes mainly an object key to identify the processed object and application to the message handler and the sender and receiver information.

Messages are processed by FORM einzelnachricht IN PROGRAM RSNAST00 The message reminders which are stored in table NAST, are processed by a FORM which is included in the standard ABAP RSNAST00. This routine interpretes the NAST record and decides how the output is generated. RSNAST00 is also designed as a stand-alone ABAP, which looks for unprocessed NAST messages in table NAST and processes them appropriately.

NAST is shared by SapScript and EDI The entries in NAST are not purely reserved for IDoc generated. Rather, the record stores reminders for any type of output, especially the print or facsimile output distribution. RSNAST00 decides which media is used and then calls the appropriate processing routine.

Programs are customized in table TNAPR The processing routine for the respective media and message is customized in the table TNAPR. This table records the name of a FORM routine which processes the message for the chosen media and the name of an ABAP where this FORM is found.

Workflow Based Outbound IDocs

Not every application is creating messages. This is especially true for those master data applications. However, most applications fire a workflow event during update. This workflow event can easily be used to trigger the IDoc distribution.

Workflow is called to a function module Many SAP R/3 applications issue a call to the function SWE_EVENT_CREATE during update. This function module ignites a simple workflow event. technically a workflow event is a timed call to a function module, which takes the issuing event as the key to process a subsequent action. Because the wokflow is actually a call to a function module, the event handler is nothing else than a function module with a well defined interface structure.

Applications with cvhange documents always trigger workflow events If an application writes regular change documents (Änderungsbelege) to the database, then it issues automatically a workflow event. This event is triggered from within the function CHANGEDOCUMENT_CLOSE. The change document workflow event is always triggered, independent of the case whether a change document is actually written.

Workflow coupling can be done by utility functions In order to make use of the workflow for IDoc processing, you do not have to go through the cumbersome workflow design procedure as it is described in the workflow documentation. SAP provides a couple of utility functions, which register all entries that you need to chain your handler in a workflow.

Workflow cannot easily be restarted Triggering the IDoc from a workflow event has a disadvantage: if the send of the IDoc fails, the event cannot be repeated. Therefore you have find an own way how to make sure that the IDoc is actually generated, even in the case of an error. Practically this is not a very big problem. In most cases the creation of the IDoc will always take place. If there is a problem then the IDoc would be stored in the IDoc base with a respective status, so it will show in transaction WE05.

Outbound IDocs Based On Change Pointers

In order to have a protocolled way to send out IDocs via the ALE mechanism, SAP invented the concept of change pointers, which allow another jumping board to distribute IDocs.

Change pointers are records of modified fields ALE change pointers are entries in a change pointer table, which are written every time an application changes one or more fields out of a predefined list of relevant fields. So, change pointers are only created, if certain customizable fields of an application change. This change pointers are written from within the change document update, namely the function CHANGEDOCUMENT_CLOSE.

Cahnge pointers are processed by a collector ABAP The ALE processing reads all change pointers and calls the appropriate function module to generate the IDocs.

ALE/ IDOC Links

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/sapedi/idoc_abap.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm

http://www.allsaplinks.com/idoc_sample.html