2008

What is Idoc-overview

An IDoc is a container that can be used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure used in SAP to store application data. This feature enables SAP to rearrange its internal structure without affecting the existing interfaces.

An IDoc represents an IDoc type and IDoc data, depending on the context in which the word IDoc is used. An IDoc type defines the structure and format of the data being exchanged. For example, the IDoc type INVOIC01 defines the format of an invoice document. IDoc data can be seen as an instance of an IDoc type.

IDoc Types

IDocs types are based on EDI standards (ANSI X12 and EDIFACT). They are closer to the EDIFACT standards than to ANSI X12. The size and format of data elements in an IDoc type are derived from these standards wherever applicable. The IDoc format is compatible with most EDI standards.

An IDoc structure consists of several segments, and segments consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments, the arrangement of the segments, and optional versus mandatory segments. Segments define a set of fields and their formats.

An IDoc is an instance of an IDoc type. Each IDoc is assigned a unique number for tracking and future reference. An IDoc serves as a focal object for tracking the state of the process that generated it. An IDoc consists of the following three types of records.

Parts of Idoc

One control record
One or many data records
One or many status records Control record. There is only one control record per IDoc. The control record contains all the control information about an IDoc, including the IDoc number, sender and receiver information, and other control information such as the message type it represents and IDoc type. The structure of the control record is the same for all IDocs and is defined by SAP. The field values, of course, can be different.
Data record. An IDoc can contain multiple data records, as defined by the IDoc structure. Segments translate into data records. Data records store application data such as purchase order header information, purchase order details lines, and other relevant information.
Status record. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process as the IDoc achieves different milestones. A status code, date, and time are assigned at every milestone.

In the outbound process, after the IDoc is passed from SAP to the subsystem, the status records are generated by the subsystem and passed back to SAP. For the inbound process, SAP generates the status records because after an IDoc is generated, it stays in the system. Status records help you determine the status of the process and whether an IDoc is in error.

Multiple Messages per IDoc Type

A message represents a specific type of document that is transmitted between two partners. Orders, order responses, order acknowledgments, invoices, and shipment notices are examples of messages. An IDoc type in SAP can be used to represent several messages or business documents. Of course, the messages must be logically related.

For example, in the figure , an IDoc type represents all possible information about an employee. This IDoc type is being used to send two separate messages to two separate applications. One message is the Employee Salary Information; the other is the Employee Security Information. The difference between the two messages is the set of segments used.

SAP uses a single IDoc type for several logically related messages. For example, the Orders IDoc type (ORDERS02) is used for several messages, such as Order (ORDERS), Order Response (ORDRSP), and Order Change (ORDCHG).

See complete course about ALE IDOC'S HERE.

Related Posts about EDI:

EDI outbound process
EDI Process components AND part two Business Processing using EDI

What is inbound EDI Process

The inbound process simply reverses the steps of the outbound process. The inbound process receives an EDI document (such as a purchase order response, sales order, or payment information) from a business partner (such as a vendor, a customer, or a bank) and creates SAP documents from it. Figure at the bottom of the post shows the inbound process at a very high level.

The inbound process consists of five steps.

1.The EDI transmission is received : EDI documents are received from a business partner via the VAN. These documents are in one of the EDI standard formats. The documents are deposited in a common repository for the subsystem. This part of the process is not part of the SAP EDI architecture.

2 .The EDI document is converted into an IDoc:The EDI−specific headers and trailers are stripped off, and the document is converted into an IDoc format suitable for SAP applications. The process is carried out at the EDI subsystem level.

3. The IDoc is transferred to the SAP layer : The IDoc created in Step 2 is stored in a text file at the operating system layer. The subsystem starts an inbound program in the SAP layer. This program reads the IDoc file and creates an IDoc in the SAP repository for further processing.

4. The application document is created : The IDoc received from the subsystem is passed to a posting program. This program creates an application document such as a sales order, purchase order acknowledgment, invoice, or shipment notice.

5. The application document can be viewed: The application document created via EDI is the same as any document created manually in the system: The document can be viewed using standard application transactions. For example, if an incoming sales order was created via EDI, you could view the sales order document via transaction VA03.

Exception Handling via Work flow :

Exceptions can occur at any point during either the outbound or inbound process. They are caused by technical problems (such as network connectivity failures or file system problems), data−related problems (such as data that is formatted incorrectly or missing), or a combination of both.

Workflow provides a very sophisticated method for managing the exception−handling process. Based on the type of error, workflow can be configured to identify the persons responsible for handling the problem, notify them in a timely manner, and provide a mechanism for making the necessary correction. After the problem is fixed, the process can be restarted from the point of failure.(27.2)

EDI Outbound Process

Here i am going to present the overview of EDI process in SAP. The SAP EDI process comprises two distinct processes. The outbound process sends documents from the SAP system to a business partner (vendor, customer, bank). Figure below shows the outbound process at a very high level. The outbound process consists of six steps.

1.The application document is created: The first step in the outbound process involves creating an application document such as a purchase order or sales order and saving it in the database tables. This step is no different from the way in which these documents are normally created. It is the following steps that have relevance to EDI. The document is created and leaves some hooks for the EDI process to begin.

2.The IDoc is generated : The application document just created is now formatted to an IDoc format. At this point you can think of IDoc as yet another format in which the application document has been represented. For example, think of how a date can be stored in different formatsimagine a date as a document with three components: day, month, and year.

In one case, you represent it as MM/DD/YYYY, a standard American way of representing a date. To make it meaningful for a German partner, you have to represent it as DD.MM.YY. IDocs follow a similar concept of representing information in different ways. The data in the application document format is suitable for the application modules, screens, and internal programs.

3.The IDoc is transferred from SAP to the operating system layer : The IDoc created in Step 2 resides in the SAP database repository. This IDoc document must be passed down to the operating system layer for processing by the EDI subsystem. In Step 3, the IDoc is transferred to the operating system as a text file. The document is still in an IDoc format. The only difference is the medium of storage.

4.The IDoc is converted to EDI standards : The IDoc format is an SAP proprietary format. For EDI purposes, the document in IDoc format has to be converted into an EDI standard format. Third−party software called a translator carries out the transformation process and reports status back to the SAP system.

SAP refers to these translators as EDI subsystems, and has certified several subsystems for connectivity to SAP. SAP takes no responsibility for translation. Thus, from SAP's perspective, after the IDoc is delivered to the subsystem, SAP does not have control over the process, but it maintains the status reported by the EDI subsystem.

5.The EDI document is transmitted to the business partner : After the document is converted to an EDI standard format, it is transmitted to a trading partner based on the partner's EDI settings. This step is not part of the SAP EDI architecture, but is mentioned here to describe the complete process from a business perspective.

6.The EDI subsystem reports status to SAP : When an IDoc is under the control of the EDI subsystem, the subsystem can optionally report the state of processing at various milestones back to the SAP system. This mechanism is always recommended because it provides complete visibility of the process from within SAP, and the user does not have to be involved with the intricacies of the EDI subsystem.(26.2)

Related Posts :

EDI Process components AND part two
Business Processing using EDI Introduction to EDI
EDI converter for SAP EDI standards

EDI Architecture

SAP provides the application logic, application data, and format for the data contents for EDI. Third−party software vendors supply the other pieces. EDI−enabled applications in SAP are capable of generating IDoc (Intermediate Document) data from an SAP document or reading IDoc data and creating application documents.

The application must understand the syntax and semantics of the data in the IDoc format. In the case of outbound processes, a separate selection program reads application data and creates an IDoc, as shown in Figure below. Similarly, for inbound processes, a posting program reads IDoc data to create an application document.

In the standard SAP system, several EDI−enabled applications in various modules are capable of generating and processing IDoc data, but all EDI documents are not supported. It is very likely that SAP supports the business process but not the creation or processing of IDocs. However, with every release of SAP, the list of supported IDocs grows considerably.

Note An application that is not EDIenabled can be enabled by developing the selection and posting programs and IDoc structures. SAP provides a comprehensive set of tools for developing IDocs and programs.

Related Posts :

EDI Process components AND part two Business Processing using EDI Introduction to EDI EDI converter for SAP EDI standards
EDI Tools for SAP
EDI performance factors

EDI Process Components part two

This post is in continuation with EDI Process components part one .
Transaction : A transaction is the electronic equivalent of a business document. A transaction is usually divided into three areas: header area, detail area, and summary area. The header area consists of segments that apply to the entire document, and is usually mandatory.

For example, in a purchase order, vendor number and vendor address are part of the header segments. The detail area contains document details. The items being ordered and their quantities are considered detail segments. The summary area consists of data that summarizes the entire document, and the total amount and taxes are part of the summary segments.

Segment : A segment is equivalent to a record in a document. A data segment has the following attributes: a unique ID, a name, a flag indicating whether it is optional or mandatory, and a number of occurrences. A group of segments can be combined to form a loop, which can also be mandatory or optional, and can be nested as well.
Segments are contained in a segment directory .

A segment consists of a sequence of logically related data elements. Data elements are separated by a data element separator and can be mandatory or optional. Some data elements are conditional, or mandatory, in certain situations.

Data Elements : Data elements are the smallest unit of information in a transaction and are defined in the data element dictionary (X12.3). A data element is identified by a data element reference number, a data type, and a minimum and maximum length.

UN/EDIFACT (United Nations EDI for Administration, Commerce, and Transport) was formed in 1985, using the ANSIX12 and UNTDI (United Nations Trade Data Interchange) as the base standards. The purpose of the standard was to develop an international standard to meet the needs of a global economy.

Most companies are moving toward adopting EDIFACT because of its international recognition. EDIFACT is quite similar to ANSI X12, with some minor differences in terminology and layout.

EDIFACT calls business documents messages and represents them by a name such as ORDERS for a purchase order, whereas ANSI X12 calls them transactions and represents them by a number such as 850 for a purchase order.

EDIFACT uses different terminology for fields. Conditional fields of EDIFACT are the same as optional fields in ANSI X12.

EDIFACT uses the same segment in multiple places, whereas ANSI has a specific use for each segment.

EDIFACT has additional segments that apply to international trade.

Application Programs

Application programs are responsible for generating and processing data in business documents. These application programs are part of the application suite commonly referred to as ERP (Enterprise Resource Planning). ERP systems meet a broad range of a company's business needsSAP R/3 is an example. Most ERP vendors recognize the business needs for EDI and thus enable their software to support EDI processes. An ERP system must do the following:

Support standard EDI transactions in the business area of interest. For example, if the focus of a company is shipping and distribution, the software must support basic shipping transactions.

Make the data necessary for EDI messages readily available.
Document the EDI processes and functionality.
Be flexible enough to incorporate business requirements within the existing process.
Provide support for enhancing existing transactions.
Contain easily configurable and manageable systems.
Contain a sufficient number of control points to meet business needs.
Exhibit a disciplined approach for controlling the flow of documents within the organization, from error handling to the approval process.
Be integrated with EDI translation software vendors.
Provide system limits and performance measures if a company expects a large volume of EDI.
transactions.(22)

EDI Process Components

An EDI process is a transfer of one or a sequence of electronic messages.It involves senders, receivers, language, content, and a medium. In EDI, the senders and receivers are called trading partners, and the X12 or EDIFACT standards supply a common language for formatting the information content of common messages.

Software tools called translators enable trading partners to converse in a standard language, and application programs (such as SAP R/3), coupled with networking facilities such as the Internet or a commercial VAN (Value−Added Network), supply the messaging medium.

Trading Partners Parties involved in a business transaction are called trading partners. The trading partners can be any combination of organizations or business types. For example, customers and vendors are trading partners.

Business Documents A business document is a legal document that defines the transaction conducted between trading partners. The legal boundaries for these transactions are defined by trade agencies, trading partners, and the ISO (International Standards Organization). The trading partners are bound by the terms and conditions of these documents. Numerous business documents are in existence today. Examples of some typical business documents follow.

Requests for quotes
Purchase orders
Purchase order changes
Purchase order acknowledgments
Invoices

EDI Messages

The formation of common standards has many advantages.
Standardization allows representation that can be easily processed by a computer system.
Standardization allows companies to exchange information that is independent from the application software.
Third−party applications can provide EDI translation and thus relieve the application of having to keep up with evolving standards.(19.2)

Business Process using EDI

In the process of buying and selling goods, partners exchange business documents at various times. These documents record the process of creating and executing a contract for sales of goods or services.

While many of these documents help to meet legal requirements, they are also all significant factors in the efficiency of processing a particular sales transaction. Well−run businesses pay a lot of attention to optimizing these business processes, and EDI frequently plays a major role in efforts to improve speed and efficiency.

Many modern business process designs are feasible only because of the existence of EDI technology.

Documents Exchanged with Customers :

Between a customer and a supplier, it is the customer who typically drives the EDI requirements. The following are key business documents exchanged between a customer and supplier.

The customer requests price catalogs.
The customer requests quotes.
The customer places blanket purchase orders.
The customer authorizes delivery against its blanket orders.
The customer places an order.
The customer expects an order acknowledgment.
The customer expects a delivery schedule.
The customer wants to know the status of the order.
The customer might cancel an order.
The customer might change an order.
The customer expects an order.
The customer requires a shipment notification.
The customer receives goods.
The customer notifies the supplier that goods have been received.
The customer wants authorization to return goods.
The customer wants to return goods damaged in transit.
The customer is an international customer.
The customer receives an invoice.

Documents Exchanged with Carriers :

A carrier is a party who undertakes the transportation of goods. The following documents are exchanged during the transportation process.

The shipper requests a carrier pickup.
The carrier responds with a pickup date.
The carrier prints a bill of lading.
The carrier informs the receiving party of the shipment.
The receiver tells the carrier where to unload the goods.
The shipper requests tracking for a particular shipment.
The carrier informs the shipper of the status of the shipment.
The carrier bills the shipper through an invoice.
The carrier receives payment.(17.2)

EDI introduction

EDI is the electronic exchange of business documents between the computer systems of business partners, using a standard format over a communication network. EDI is also called paperless exchange.

Why do we need EDI ?

Business scenario :

A customer who wants to purchase an item creates a purchase order and then faxes or mails it to the vendor.
The vendor receives the purchase order and manually keys in a sales order.
The vendor's system generates a confirmation date that is sent back to the customer via fax or mail.
The vendor then ships the goods via a carrier. The carrier delivers the products to the customer.
When the goods are shipped, the vendor invoices the customer.
The customer makes the payment by check, and the vendor deposits the check in the bank.
Finally, funds are transferred from the customer's account to the vendor's account.

This simple scenario requires the exchange of various documents between several business partners at different times.

A business process is a series of actions or functions that bring about a business result, and as such there are some inherent problems with this scenario. They are

Is highly inefficient and laborious ·
Cannot be tracked easily ·
Gives no visibility into the process ·
Has a very long lead time ·
Includes redundant data entry at various points.

The electronic exchange of business documents in a standard format gave birth to what is now known as EDI.

Benefits of the EDI Process :

1.Reduced data entry errors: EDI does not involve data entry at multiple points. In the traditional process, a sender creates a purchase order on the system, prints the order, and then faxes or mails it to a trading partner. The receiver then rekeys the same information on his or her computer. The process is prone to data entry errors. This procedure is repeated when invoicing takes place. With EDI, data goes directly from one computer to another without involving a human being.

2· Reduced processing cycle time : The biggest advantage is the reduced processing time of the complete cycle. As soon as orders are entered into the system, they can be processed on the receiving side in seconds. There is a considerable savings in the processing time of document transfer.

3. Availability of data in electronic form : Data from EDI is in electronic form, which makes it easy to share across the organization.

4· Reduced paperwork : The entire EDI process can be handled without using a single piece of paper.

5· Reduced cost : Time is money. Any savings in time is directly linked to savings in money. The initial cost of an EDI setup is certainly higher compared to the paper process, but over a long period it is very cost−effective.

6·Reduced inventories and better planning : Companies do not have to keep a safety stock for the time taken with order processing. Changes to planning schedules can be communicated instantaneously. MRP (Material Requirements Planning) can take into account a shipment in transit as soon as an Advance ship notice (EDI 856) transaction is received.

7·Standard means of communication : Because EDI enforces standards on the contents of data,uniform naming standards and field sizes have emerged. Such consistency leads to clearer communication and less ambiguity.

8·Better business processes : Compared to traditional methods of exchanging business documents, EDI is certainly a better way of communicating with your trading partners. Companies are willing to share information and participate in inter−organizational issues. This environment enhances supply−chain management.

9·Competitive advantage: In many cases, companies that have implemented EDI have an advantage over their competitors, especially when dealing with government agencies or large corporations. (15.1)

Related Posts :

EDI converter for SAP and EDI standards
BADI IMPLEMENTATION PART TWO
IMPLEMENTATION OF SCREEN ENHANCEMENTS USING BADI

Syntax Check for LOAD part two

Previously we have discussed regarding syntax check for LOAD part one . This post is in continuation with that post.

Variant 7

LOAD REPORT prog PART 'SELC' INTO itab.

Effect

Loads the description of the selection variables ( SELECTOPTIONS and PARAMETERS ) into the internal table itab . itab must have the Dictionary structure RSELC .

Variant 8

LOAD REPORT prog PART 'STOR' INTO itab.

Effect

Loads the initial values of the global data into the internal table itab . The line width of itab determines where the line break occurs. Ideally, itab should contain exactly one field of the type X .

Variant 9

LOAD REPORT prog PART 'LITL' INTO itab.

Effect

Loads the literal table into the internal table itab . The line width of itab determines where the line break occurs. Ideally, itab should contain exactly one field of the type X .

Variant 10

LOAD REPORT prog PART 'SYMB' INTO itab.

Effect

Loads the symbol table into the internal table itab . itab must have the Dictionary structure RSYMB .

Variant 11

LOAD REPORT prog PART 'LREF' INTO itab.

Effect

Loads the line reference into the internal table itab . itab must have the Dictionary structure RLREF .

Variant 12

LOAD REPORT prog PART 'SSCR' INTO itab.

Effect

Loads the description of the selection screen into the internal table itab . itab must have the Dictionary structure RSSCR .

Variant 13

LOAD REPORT prog PART 'BASE' INTO itab.

Effect

Loads the segment table into the internal table itab . itab must have the Dictionary structure RBASE .

Variant 14

LOAD REPORT prog PART 'INIT' INTO itab.

Effect

Loads the initial values of the local data into the internal table itab . The line width of itab determines where the line break occurs. Ideally, itab should contain exactly one field of the type X .

Variant 15

LOAD REPORT prog PART 'DATP' INTO itab.

Effect

Loads the data descriptions of the parameters and local field symbols into the internal table itab . itab must have the dictionary structure RDATA .

Variant 16

LOAD REPORT prog PART 'TXID' INTO itab.

Effect

Loads the index of the text elements (assignment of text keys to data control blocks) into the internal table itab . itab must have the dictionary structure RTXID .

Variant 17

LOAD REPORT prog PART 'COMP' INTO itab.

Effect

Loads the description of the components of the (internal) structures used in the program into the internal table itab . itab must have the dictionary structure RDATA .

Runtime errors

· LOAD_REPORT_PART_NOT_FOUND : An invalid identification was specified under part .
· LOAD_REPORT_PROGRAM_NOT_FOUND : The specified program prog does not exist.
· LOAD_REPORT_TABLE_TOO_SHORT : The specified internal table is too narrow.(88).

Related Post

Syntax for Insert data into Table and Insert part two and Leave

FILTER DEPENDENT BADI IMPLEMENTATION PART TWO
SAP ABAP FILTER DEPENDENT BADI IMPLEMENTATION

Syntax Check for Load

Basic form

LOAD REPORT prog PART part INTO itab.

Effect

Loads the specified part of the generated version of the program prog into the internal table itab (for analysis purposes only).

The return code value is set as follows:

SY-SUBRC = 0 The load for the program prog exists and is current.

SY_SUBRC = 4 The load for the program prog does not exist.

SY-SUBRC = 8 The load for the program prog exists, but is not current. In some cases, this SY-SUBRC may mean that the program load has been destroyed. You can resolve this by generating the program. With PART 'LREF' , SY-SUBRC = 8 means that the line reference table is incorrect for the program. With PART 'CONT' , it means that the reference part of the internal table is empty.

itab has been filled only if SY-SUBRC = 0 .

Variant 1

LOAD REPORT prog PART 'HEAD' INTO itab.

Effect

Loads the program header into line 1 of the internal table itab . itab must have the Dictionary structure RHEAD .

Variant 2

LOAD REPORT prog PART 'TRIG' INTO itab.

Effect

Loads the event control blocks into the internal table itab . itab must have the Dictionary structure RTRIG .

Variant 3

LOAD REPORT prog PART 'CONT' INTO itab.

Effect

Loads the processing control blocks into the internal table itab . itab must have the Dictionary structure RCONT .

Variant 4

LOAD REPORT prog PART 'DATA' INTO itab.

Effect

Loads the static data descriptions into the internal table itab . itab must have the Dictionary structure RDATA .To find the data description for a data index i, proceed as follows:

0 <= i < 14 ="="> i+1 Index in data_itab
2^14 <= i < 15 ="="> i+1 - 2^14 Index in
datv_itab
2^15 <= i < 16 ="="> i+1 - 2^15 Parameter index
(2^14 = 16384, 2^15 = 32768)

Variant 5

LOAD REPORT prog PART 'DDNM' INTO itab.

Effect

The names of the dictionary structures used in the program are set in the internal table itab . itab must have the dictionary structure RDDNM .

Variant 6

LOAD REPORT prog PART 'DATV' INTO itab.

Effect

Loads the variable data descriptions into the internal table itab . itab must have the Dictionary structure RDATA .To find the data description for a data index i, proceed as follows:

0 <= i < 14 ="="> i+1 Index in data_itab
2^14 <= i < 15 ="="> i+1 - 2^14 Index in
datv_itab
2^15 <= i < 16 ="="> i+1 - 2^15 Parameter index
(2^14 = 16384, 2^15 = 32768)(87)

Related Post

Syntax for Insert data into Table and Insert part two and Leave
SAP ABAP BADI PART ONE

ABAP BADI PART TWO
ABAP BADI PART THREE

Syntax Check for Leave

LEAVE TO LIST-PROCESSING

LEAVE TO LIST-PROCESSING.

Addition

... AND RETURN TO SCREEN scr.

Effect

Switches from "dialog processing" (module pool, screens) of the current transaction to "list processing". You can then use all the usual list layout commands ( WRITE , SKIP , ...).

After leaving the current screen, the list formatted in this way is displayed implicitly or explicitly by LEAVE SCREEN . Here, all list programming options are possible, e.g. line selection, F keys ,windows.

LEAVE LIST-PROCESSING continues with "Processing Before Output" ( PBO ) of the screen which controls the list processing.

After switching to list processing mode with SET PF-STATUS ... ,you are recommended to define a GUI (Graphical User Interface) of type List or List in dialog box .

Addition

... AND RETURN TO SCREEN scr.

Effect

LEAVE LIST-PROCESSING continues with "Processing Before Output" ( PBO ) of the screen scr.

Using LEAVE LIST-PROCESSING to leave list processing explicitly is only necessary in exceptional cases; normally, the standard F keys (F3 Back and F15 Exit ) are sufficient.

LEAVE TO SCREEN

LEAVE TO SCREEN scr.

Effect

Leaves the current screen and processes the screen scr . If scr = 0, processing in CALL mode continues after the CALL SCREEN statement. Otherwise, you branch to the transaction selection screen.

LEAVE TO TRANSACTION

LEAVE TO TRANSACTION tcod.

Addition

... AND SKIP FIRST SCREEN

Effect

Terminates the current processing and starts the (new) transaction tcod .

Examples

Start Transaction SM02 :

LEAVE TO TRANSACTION 'SM02'.

Restart current transaction:

LEAVE TO TRANSACTION SY-TCODE.

Addition

... AND SKIP FIRST SCREEN

Effect

Processes the first screen of the transaction in the background. If possible, the fields on this screen are filled with values from the SAP memory . Therefore, you should set the desired values with SET PARAMETER . If an error occurs when processing the initial screen (due to incorrect or imcomplete parameter values), this is reported and you must correct or complete the input manually on this screen.(86.5).

Related Post

Syntax for Insert data into Table and Insert part two

ABAP BADI PART FOUR

BADI PART FIVE

ABAP BADI PART SIX CALLING BADI AND ITS USES

BADI INTRODUCTION

Syntax for Insert Continued

Previously we have discussed regarding syntax for Insert data into table part one and part two.We have also learned regarding inserting data into a internal table. Here is the continuation for that.

Insert a program

Basic form

INSERT REPORT prog FROM itab.

Effect

Inserts the program prog from the internal table itab into the library. The internal table itab contains the source code; the lines of the table cannot be more than 72 characters long. The program attributes (type, date, ...) are set by the system, but you can change them manually or in the program (table TRDIR ).

Runtime errors

1 · INSERT_PROGRAM_INTERNAL_NAME : he program name prog is reserve internally; it begins with '%_T' .

2· INSERT_PROGRAM_NAME_BLANK : The program name prog must not contain any blanks
characters.

3· INSERT_PROGRAM_NAME_TOO_LONG : The program name prog is too long; it cannot be more than 8 characters long.

4· INSERT_REPORT_LINE_TOO_LONG : One of the source code lines is longer than 72 characters.

INSERT - Insert text elements

Basic form

INSERT TEXTPOOL prog ...FROM itab ...LANGUAGE lg.

Effect

Assigns the text elements in the internal table itab to the program prog and the language lg and inserts them in the library. The line structure of the table itab is described in the section Text elements .

Example

The following program uses the internal table TAB to set the text elements of the program PROGNAME .

DATA: PROGRAM(8) VALUE 'PROGNAME',
TAB LIKE TEXTPOOL OCCURS 50 WITH HEADER
LINE.
TAB-ID = 'T'. TAB-KEY = SPACE. TAB-ENTRY =
'Sales'.
APPEND TAB.
TAB-ID = 'I'. TAB-KEY = '200'. TAB-ENTRY = 'Tax'.
APPEND TAB.
TAB-ID = 'H'. TAB-KEY = '001'. TAB-ENTRY = 'Name
Age'.
APPEND TAB.
TAB-ID = 'S'. TAB-KEY = 'CUST'. TAB-ENTRY =
'Customer'.
APPEND TAB.
TAB-ID = 'R'. TAB-KEY = SPACE. TAB-ENTRY = 'Test
program'.
APPEND TAB.
SORT TAB BY ID KEY.
INSERT TEXTPOOL PROGRAM FROM TAB LANGUAGE
SY-LANGU.

The internal table should be sorted by the components ID and KEY to enable faster access to the text elements at runtime. However, this is not obligatory. The component LENGTH (see text elements ) for the length of a text element does not have to be set explicitly. In this case - as in the example - the actual length of the text element is used.

The value of LENGTH cannot be smaller than the text to which it applies. If your length specification is too short, it is ignored by INSERT and the actual length is used instead. On the other hand, larger values are allowed and can be used to reserve space for texts that may be longer when translated into other languages.

Related Post

Syntax for Insert data into Table

LESSON 1 DATA PORTS IN IDOC

LESSON 2 DEFINING PARTNER PROFILE FOR IDOC

LESSON 3 PARTNE RPROFILES AND PORTS IN IDOC

LESSON 4 CONVERTING DATA INTO IDOC SEGMENTS

Syntax for Insert into a Internal Table

Variant 1

INSERT [wa INTO|INITIAL LINE INTO] itab [INDEX idx].

Effect

Inserts a new line into an internal table.

If you specify wa INTO , the new line is taken from the contents of the explicitly specified work area wa .

When using INITIAL LINE INTO , a line containing the appropriate initial value for its type is inserted into the table.

If you omit the specification before itab , the new line is taken from the header line of the internal table itab .

INDEX idx specifies the table index before which the line is inserted into the table itab . If the table has exactly idx - 1 entries, the line is appended to the table.

Within a LOOP , on an internal table, you do not have to specify the insertion point with INDEX idx . The source table is then inserted before the current LOOP line in the target table.

The return code value is set as follows:

When specifying the insertion point with INDEX idx :

SY-SUBRC = 0 The entry was inserted.
SY_SUBRC = 4 Index specification too large.

The entry was not inserted because the table has fewer than idx - 1 entries.

Return code value If the insertion point is not specified, the is set to 0.

Inserting lines within a LOOP ... ENDLOOP structure affects subsequent loop passes.

Invalid index specifications (for example, idx <= 0), result in a runtime error. Example

Insert values into a table of whole numbers:

DATA: VALUE TYPE I,
ITAB TYPE I OCCURS 100 WITH HEADER LINE.
ITAB = 5.
VALUE = 36.
INSERT ITAB INDEX 1.
INSERT VALUE INTO ITAB INDEX 2.
INSERT INITIAL LINE INTO ITAB INDEX 2.

The table ITAB now contains three lines with the values 5, 0 and 36.

Variant 2

INSERT LINES OF itab1 [FROM idx1] [TO idx2] INTO itab2 [INDEX idx3.

Effect

Inserts the internal table itab1 or a section of itab1 into the internal table itab2 .

As with variant 1, INDEX idx3 is to specifies the table index before which you want to insert in the target table itab2 .

Within a LOOP , on an internal table, you do not have to specify the insertion point with INDEX idx3 . The source table is then inserted before the current LOOP line in the target table.

By specifying FROM idx1 or TO idx2 , you can restrict the line area from which the source table itab1 is taken. If there is no FROM specification, the line area begins with the first line of itab1 . If there is no TO specification, the line area ends with the last line of itab1 . This means that the whole table is inserted, if neither a FROM nor a TO is specified.

Return code value

The is set as for variant 1.

You can use DESCRIBE TABLE itab1 LINES ... to determine the size of the table itab1 before or after the INSERT statement and thus establish how many lines were actually inserted into the
table.

Inserting lines within a LOOP ... ENDLOOP structure affects subsequent loop passes. Invalid index specifications (for example, idx <= 0), result in a runtime error. Performance

Inserting a line into an internal table incurs index maintenance costs which depend on the insertion point.

For example, inserting a line in the middle of a 100-byte wide internal table with 200 entries requires about 90 msn (standardized microseconds). If you want to insert the contents of one internal table into another internal table, you incur index maintenance costs only once with the variant INSERT LINES OF ... . Compared with a LOOP which inserts the lines of the source table oneby- one into the target table, this represents a distinct improvement in performance.
Inserting a table of 500 lines with a 100-byte line width in the middle of a similar size table can thus be amde up to 20 times faster.(84.4)

Related Post

Syntax for Insert data into Table
LESSON 5 DEVELOPING OUTBOUND IDOC FUNCTION

LESSON 6 CREATION OF IDOC DATA

Insert Data into Table Syntax Part two

This Insert data into table is in continuation with previous post .

Variant 2

INSERT dbtab. or
INSERT *dbtab. or
INSERT (dbtabname) ...

Additions

1. ... FROM wa
2. ... CLIENT SPECIFIED

Effect

These are the SAP -specific short forms for the statements explained under variant 1.

· INSERT INTO dbtab VALUES dbtab. or
· INSERT INTO dbtab VALUES *dbtab. or
· INSERT INTO (dbtabname) VALUES wa.

When the command has been executed, the system field SYDBCNT contains the number of inserted lines (0 or 1).

The return code value is set as follows:

SY-SUBRC = 0 Line successfully inserted.
SY_SUBRC = 4 Line could not be inserted, since a line with the same key already exists.

Example

Add a line to a database table:

TABLES SAIRPORT.
SAIRPORT-ID = 'NEW'.
SAIRPORT-NAME = 'NEWPORT APT'.
INSERT SAIRPORT.

Addition 1

... FROM wa

Effect

The values for the line to be inserted are not taken from the table work area dbtab , but from the explicitly specified work area wa . The work area wa must also satisfy the conditions described in variant 1. As with this variant, the addition allows you to specify the name of the database table directly or indirectly.

If a work area is not explicitly specified, the values for the line to be inserted are taken from the table work area dbtab if the statement is in a FORM or FUNCTION where the table work area is stored in a formal parameter or local variable of the same name.

Addition 2

... CLIENT SPECIFIED

Effect

As for variant 1.

Variant 3

INSERT dbtab FROM TABLE itab. or
INSERT (dbtabname) FROM TABLE itab.

Additions

... CLIENT SPECIFIED
... ACCEPTING DUPLICATE KEYS

Effect

Mass insert: Inserzts all lines of the internal table itab in a single operation. The lines of itab must satisfy the same conditions as the work area wa in variant 1.

When the command has been executed, the system field SYDBCNT contains the number of inserted lines.

If the internal table itab is empty, SY-SUBRC and SY-DBCNT are set to 0 after the call.

Addition 1

... CLIENT SPECIFIED

Effect

As for variant 1.

Addition 2

... ACCEPTING DUPLICATE KEYS

Effect

If a line cannot be inserted, the processing does not terminate with a runtime error, but the return code value of SY-SUBRC is merely set to 4. All the remaining lines are inserted when the
command is executed.

The return code value is set as follows:

SY-SUBRC = 0 All lines successfully inserted. Any other result causes a runtime error .(82.6)

Related Post

LESSON 10 SENDING IDOC VIA STANDARD R3 SYSTEM

LESSON 11 IDOC OUTBOUND TEIGGER PART TWO

Syntax for Insert in data base table

Variants

1. INSERT INTO dbtab VALUES wa. or INSERT INTO (dbtabname) VALUES wa.

2. INSERT dbtab. or INSERT *dbtab. or INSERT (dbtabname) ...

3. INSERT dbtab FROM TABLE itab. or INSERT (dbtabname) FROM TABLE itab.

Effect

Inserts new lines in a database table .

You can specify the name of the database table either in the program itself in the form dbtab or at runtime as the contents of the field dbtabname . In both cases, the database table must be defined in the ABAP/4 Dictionary . If the program contains the name of the database table, it must also include a corresponding TABLES statement.

Normally, lines are inserted only in the current client. Data can only be inserted using a view if the view refers to a single table and was defined in the ABAP/4 Dictionary with the maintenance status "No restriction".

INSERT belongs to the Open SQL command set.

You cannot insert a line if a line with the same primary key already exists or if a UNIQUE index already has a line with identical key field values.

When inserting lines using a view , all fields of the database table that are not in the view are set to their initial value - if they were defined with NOT NULL in the ABAP/4 Dictionary . Otherwise they are set to NULL .

Since the INSERT statement does not perform authorization checks , you must program these yourself.

Lines specified in the INSERT command are not actually added to the database table until after the next ROLLBACK WORK .Lines added within a transaction remain locked until the transaction has finished. The end of a transaction is either a COMMIT WORK , where all database changes performed within the transaction are made irrevocable, or a ROLLBACK WORK , which cancels all database changes performed within the transaction.

Variant 1

INSERT INTO dbtab VALUES wa. or INSERT INTO (dbtabname) VALUES wa.

Addition

... CLIENT SPECIFIED

Effect

Inserts one line into a database table.

The line to be inserted is taken from the work area wa and the data read from left to right according to the structure of the table work area dbtab . Here, the structure of wa is not taken into account. For this reason, the work area wa must be at least as wide (see DATA ) as the table
work area dbtab and the alignment of the work area wa must correspond to the alignment of the table work area.

Otherwise, a runtime error occurs. When the command has been executed, the system field SYDBCNT contains the number of inserted lines (0 or 1).

The return code value is set as follows:

SY-SUBRC = 0 Line was successfully inserted.

SY_SUBRC = 4 Line could not be inserted since a line with the same key already exists.

Example

Insert the customer Robinson in the current client:

TABLES SCUSTOM.
SCUSTOM-ID = '12400177'.
SCUSTOM-NAME = 'Robinson'.
SCUSTOM-POSTCODE = '69542'.
SCUSTOM-CITY = 'Heidelberg'.
SCUSTOM-CUSTTYPE = 'P'.
SCUSTOM-DISCOUNT = '003'.
SCUSTOM-TELEPHONE = '06201/44889'.
INSERT INTO SCUSTOM VALUES SCUSTOM.

Addition

... CLIENT SPECIFIED

Effect

Switches off automatic client handling. This allows you to insert data across all clients even when dealing with clientspecific tables. The client field is then treated like a normal table field which you can program to accept values in the work area wa that contains the line to be inserted.

The addition CLIENT SPECIFIED must be specified immediately after the name of the database table.

Example

Insert the customer Robinson in client 2:

TABLES SCUSTOM.
SCUSTOM-MANDT = '002'.
SCUSTOM-ID = '12400177'.
SCUSTOM-NAME = 'Robinson'.
SCUSTOM-POSTCODE = '69542'.
SCUSTOM-CITY = 'Heidelberg'.
SCUSTOM-CUSTTYPE = 'P'.
SCUSTOM-DISCOUNT = '003'.
SCUSTOM-TELEPHONE = '06201/44889'.
INSERT INTO SCUSTOM CLIENT SPECIFIED VALUES
SCUSTOM.

Initialization Syntax Check

Basic form

INITIALIZATION.

Effect

Processing event.

Executed before the selection screen is displayed.The parameters (PARAMETERS ) and selection criteria (SELECT OPTIONS ) defined in the program already contain default values (if specified). You can assign different values here and also change the database-specific selections.

In contrast to R/2 , this event is also executed during background processing.

Example

Define the last day of the previous month as the key date:

PARAMETERS QUAL_DAY TYPE D DEFAULT SYDATUM.

INITIALIZATION.

QUAL_DAY+6(2) = '01'.

QUAL_DAY = QUAL_DAY - 1.

INITIALIZATION is executed in the following steps:

Specify default values for the selections. Execute the event INITIALIZATION. Import variant (if used to start the report).

On SUBMIT , the values specified for each WHERE clause are also transferred, if necessary. Execute the event AT SELECTION-SCREEN OUTPUT , if it occurs in the report (unlike INITIALIZATION , this event is always executed for PBO of a selection screen). Display selection screen.

Transport the screen fields containing user input to the report fields. Continue with START-OF-SELECTION .

Since INITIALIZATION is only executed once when you start the report, it is not suitable for screen modifications such as suppressing individual parameters (LOOP AT SCREEN , MODIFY SCREEN ) because these changes would disappear again when the user pressed ENTER. The correct event for screen modifications is AT SELECTION-SCREEN OUTPUT .(80.5)

SAP WORK flow in sales and distribution 1
SAP WORK flow in sales and distribution 2
SAP WORK flow in sales and distribution 3

Syntax for Infotypes

Basic form

INFOTYPES nnnn.

nnnn between 0000 and 0999: HR master data info types
nnnn between 1000 and 1999: HR planning data info types
nnnn between 2000 and 2999: HR time data info types
nnnn between 3000 and 8999: Not yet used
nnnn between 9000 and 9999: Customer-specific info types

Additions

1. ... NAME c
2. ... OCCURS occ
3. ... MODE N
4. ... VALID FROM begin TO end

Effect

Declares the HR info type nnnn . Creates an internal table as follows:

DATA BEGIN OF Pnnnn OCCURS 10.

INCLUDE STRUCTURE Pnnnn.

DATA END OF Pnnnn VALID BETWEEN BEGDA AND

ENDDA.

Example

INFOTYPES: 0000, 0001, 0002.

Addition 1

... NAME c

Effect

c is a name

c is a name up to 20 characters long. Creates an internal table as follows:

DATA BEGIN OF c OCCURS 10.
INCLUDE STRUCTURE Pnnnn.
DATA END OF c VALID BETWEEN BEGDA AND ENDDA.

Example

INFOTYPES: 0005 NAME VACATION, 0006 NAME ADDRESS.

Addition 2

... OCCURS occ

Effect

occ is a number for the OCCURS value. Creates an internal table as follows:

DATA BEGIN OF c OCCURS m.
INCLUDE STRUCTURE Pnnnn.
DATA END OF c VALID BETWEEN BEGDA AND ENDDA.

Example

INFOTYPES 0003 OCCURS 1.

Addition 3

... MODE N

Applies only to the HR logical databases PNP and PCH .

Effect

The info type tables are not filled by GET PERNR (logical database PNP ) or GET OBJEC (logical database PCH ). The effect of the INFOTYPES statement is then the same as the data declaration of an internal table .

Example

INFOTYPES: 2001 MODE N, 2002 MODE N, 2003 MODE N.

Addition 4

... VALID FROM begin TO end.

... VALID FROM begin TO end.

Effect

This addition should only be used with the logical database PNP .

GET PERNR retrieves only those info type records which are valid within the time range ( begin and end ) specified. begin and end are dates with the format YYYYMMDD.

Example

INFOTYPES: 0007 VALID FROM 19910101 TO 19911231.

Note

Each info type has a formal description in the ABAP/4 Dictionary as table Pnnnn .

If you enter SHOW INFOTYPES nnnn in the editor command line, the system displays information about the info type nnnn .

If you enter SHOW INFOTYPES * , you see a list of all info types.

Work flow for MM PART 5

Syntax for Include

INCLUDE prog

Basic form

INCLUDE prog.

Effect

Includes the program prog in the main program for syntax check and generation purposes. Include programs are used to divide very large programs into smaller more manageable units. They also allow you to create common program components.

Example

INCLUDE LSPRITOP.

The whole of an INCLUDE statement must appear on one line where it is the only statement allowed. The include program must consist of complete statements (and comments). You can use the service report RSINCL00 to generate reference lists for include programs.

INCLUDE STRUCTURE

Basic form

INCLUDE STRUCTURE rec.

Effect

When you define a structure rec (with DATA or TYPES ), this statement copies the components of the structured data type subRec to the structure rec . Since you can define nested data structures (i.e. structures with sub-structures) starting from Release 3.0, you should use INCLUDE STRUCTURE only if you want to introduce types in a program first and nested structures in a later step.

A data definition DATA: BEGIN OF rec.
INCLUDE STRUCTURE subRec.
DATA: END OF rec.

is equivalent to

DATA rec LIKE subRec.

You are recommended to use the second formulation. Even if the structure rec to be defined contains additional components, instead of

DATA: BEGIN OF rec,
...
INCLUDE STRUCTURE subRec.
DATA: ...
END OF rec.

you should use

DATA: BEGIN OF rec,
...
rec LIKE subRec,
...
END OF rec.

so that subRec can be referenced as a sub-structure of rec .

Although " INCLUDE STRUCTURE subRec. " breaks up the substructure subRec into its components, the alignment of subRec is retained. This means that padding fields may be inserted before the first and/or before the last component of subRec in rec .

INCLUDE TYPE

Basic form

INCLUDE TYPE subRec.

Effect

When you define a structure rec (with DATA or TYPES ), this statement copies the components of the structured data type subRec to the structure rec .

Since you can define nested data structures (i.e. structures with sub-structures) starting from Release 3.0, you should use INCLUDE TYPE only if you want to introduce types in a program first and nested structures in a later step.(78.8).

Work flow for MM PART 6
Work flow for MM PART 7

Syntax Check for IMPORT part two

We have all ready discussed regarding syntax of IMPORT key word and this post is the continuation of it .

Variant 2

IMPORT f itab FROM DATABASE dbtab(ar) ID key.

Additions

1. ... TO g (for each field f to be imported)
2. ... MAJOR-ID maid (instead of ID key )
3. ... MINOR-ID miid (together with MAJOR-ID maid )
4. ... CLIENT h (after dbtab(ar) )
5. ... USING form

Effect

Imports data objects (fields, field strings or internal tables) with the ID key from the area ar of the database dbtab

The return code value is set as follows:

SY-SUBRC = 0 The data objects were successfully imported.

SY_SUBRC = 4 The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.

Example

Import two fields and an internal table:

TABLES INDX.

DATA: INDXKEY LIKE INDX-SRTFD,F1(4),
F2 TYPE P,BEGIN OF TAB3 OCCURS 10, CONT(4),
END OF TAB3.

INDXKEY = 'INDXKEY'.

IMPORT F1 F2 TAB3 FROM DATABASE INDX(ST) ID

INDXKEY.

The structure of fields, field strings and internal tables to be imported must match the structure of the objects exported to the dataset. In addition, the objects must be imported under the same name used to export them. If this is not the case, either a runtime error occurs or no import takes place.

Exception: You can lengthen or shorten the last field if it is of type CHAR , or add/omit CHAR fields at the end of the structure.

Addition 1

... TO g (for each field f to be imported)

Effect

Takes the field contents stored under the name f from the database and places them in g .

Addition 2

... MAJOR-ID maid (instead of ID key )

Addition 3

... MINOR-ID miid (together with MAJOR-ID maid )

Effect

Searches for a record with an ID that matches maid in the first part (length of maid ) and - if MINOR-ID miid is also specified - is greater than or equal to miid in the second part.

Addition 4

... CLIENT h (after dbtab(ar) )

Effect

Takes the data from the client h (only with client-specific import/export databases).

Example

TABLES INDX.
DATA F1.
IMPORT F1 FROM DATABASE INDX(AR) CLIENT '002'
ID 'TEST'.

Addition 5

... USING form

Effect

Does not read the data from the database. Instead, calls the FORM routine form for each record read from the database without this addition. This routine can take the data key of the data to be retrieved from the database table work area and write the retrieved data to this work area schreiben; it therefore has no parameters.(76)

The previous post of the blog deals with SAP XI ADAPTER CONCEPT.

ERP implementation process and advantages
ERP advantages and erp project launch

XI Adapters verses Proxies

It is important to understand that proxies and adapters are the two alternatives for connecting XI to an application system.

Typically for an existing system (any external system or even ‘traditional’ SAP systems that only communicate via RFC and IDoc), the interface semantics cannot be changed. Also in many cases a specific, proprietary wire protocol must be used. This is exactly the scope of adapters.

This is also the premise of ‘outside-in’ integration or ‘a posteriori’ integration . In the case of new SAP applications (ABAP or Java) the interface development process has changed. The interface is designed centrally in the Integration Repository.]

From the interface definition a proxy is generated in ABAP or Java. The proxy is deployed on the application system, and the business application is built around it. This is the premise of inside-out integration (integration by design).

A proxy is a fragment of code in ABAP or Java which serves 2 purposes:

1 . Convert the data structures (ABAP or Java) into XML messages and vice-versa Establish connectivity with the XI Integration Server A proxy hides such technical details from the application developer.

2 . It is important to note that for proxy communication, no specific adapter configuration is required.

However from the technical aspect, the proxy runtime itself resides on the adapter framework. The point is that there is no protocol conversion necessary for communicating with XI using proxies.

Connectivity with SAP applications :

The choice of adapters vs proxies comes into play when connecting SAP applications .

Before WebAS 6.20 the only connectivity option in/out of SAP system is RFC/BAPI/IDoc.

Starting with the WebAS 6.10 the native HTTP connectivity has been added to the basis layer .

Starting with the WebAS 6.20, each application system has its own local integration engine and is
therefore able to connect to XI via proxies over HTTP / SOAP with attachments (XI protocol).

Where is the adapter in SAP ?

The following diagram illustrates the position of adapters of sap.

XI Adapters hosted on J2EE

All R/3 systems and under can communicate using RFC and IDoc only. Therefore the RFC/IDoc adapter is necessary to integrate these systems with XI Even SAP systems based on WebAS .20 and above, still rely heavily on RFC/IDoc interfaces and therefore the adapter is necessary The RFC adapter enables you to use the functions of the Integration Engine in existing SAP system landscapes. It is used by SAP systems to connect to the Integration Engine by using the RFC interface. It supports SAP systems as of version 3.1x.

Many Mainframe applications interface via flat files over FTP or at the OS level. Some rely on a messaging tool such as IBM MQSeries (WebSphereMQ), based on JMS.

The file/FTP adapter enables you to exchange data with the Integration Server by means of a file interface or an FTP server.

The JDBC adapter enables you to connect database systems to the Integration Server. The adapter converts database content to XML messages and the other way around.

Database content can be read with any SQL statement. A special XML format is defined for content coming from the Integration Engine. This format enables SQL INSERT, UPDATE, SELECT, DELETE, or stored procedure statements to be processed. A message is always processed in exactly one database transaction.

The JDBC adapter connects to databases directly by handling SQL statements or procedures. Therefore it is not appropriate let’s say to connect to the database underlying an R/3 system The JMS adapter enables you to connect messaging systems to the Integration Engine.

JMS adapter is typically used to connect to a JMS provider such as IBM WebSphere MQ (MQSeries) or Sonic MQ.

The SOAP adapter enables you to exchange SOAP messages between remote clients or Web service servers and the Integration Server Any interface which is exposed as a web service can be accessed via the SOAP adapter You use the marketplace adapter to connect the Integration Server to marketplaces. It enables messages to be exchanged by converting the XI message format to the marketplace format MarketSet Markup Language (MML) and the other way around.

The RNIF (RosettaNet Implementation Framework) Adapter supports RosettaNet, a standard used for data communication in the High-Tech industry.

The RNIF Adapter is based on the RosettaNet Implementation Framework (RNIF) version 2.0.
SMTP (simple mail transfer protocol) is used to interface with most mail servers by sending and receiving emails.

The SAPBC adapter enables the coexistence of the SAP Business Connector and SAP XI .

Adapters not hosted in the J2EE Adapter Engine :

The adapters are implemented in ABAP and reside directly on the Integration Server (ABAP stack) are of this category. They are two types as given below.

The IDoc adapter comprises two parts, namely an adapter at the Integration Server inbound channel, and an adapter at the Integration Server outbound channel.

The plain HTTP adapter gives application systems the option of communicating with the Integration Engine and exchanging business data using a plain HTTP connection. Depending on the receiver system, outbound messages can be enhanced with certain information.

Their configuration is done centrally in the ID (as for all adapters) but the monitoring does not go through the RWB. There are specific ABAP transactions to monitor these adapters.

Regarding the connectivity to SAP systems please note that the RFC adapter is hosted by the J2EE adapter engine, while the IDoc adapter is hosted by the ABAP stack of the Integration Server.

Subscribe to: Posts ( Atom )