IDoc

IDoc, short for Intermediate Document, is a SAP document format for business
transaction data transfers.[1] Non SAP-systems can use IDocs as the
standard interface (computing) for data transfer.[2] IDoc is similar to XML in
purpose, but differs in syntax. Both serve the purpose of data exchange and
automation in computer systems, but the IDoc-Technology takes a different
approach.
While XML allows having some metadata about the document itself, an IDoc is
obliged to have information at its header like its creator, creation time etc. While
XML has a tag-like tree structure containing data and meta-data, IDocs use a table
with the data and meta-data. IDocs also have a session that explains all the
processes which the document passed or will pass, allowing one to debug and
trace the status of the document.
Different IDoc types are available to handle different types of messages. For
example, the IDoc format ORDERS01 may be used for both purchase orders and
order confirmations.
IDoc technology offers many tools for automation, monitoring and error handling.
For example, if the IDocs are customised that way on a particular server, then a
user of SAP R/3 system creates a purchase order; this is automatically sent via an
IDoc and a sales order is immediately created on the vendor's system.
When this order cannot be created because of an application error (for example:
The price per piece is lower than allowed for this material), then the
administrator on the vendor's system sees this IDoc among the erroneous ones
and can solve the situation. If the error is in the master data at the vendor's
system, he can correct them and order the IDoc to be processed again.
Because of the flexibility and transparency of IDoc technology, some non-SAP
technologies use them as well.

Contents
[hide]

• 1Structure of the IDoc

• 2IDoc Transactions in SAP
• 3Error Handling
• 4References
• 5External links

Structure of the IDoc[edit]

An IDoc consists of

• Control record (it contains the type of IDoc, port of the partner, release of SAP
R/3 which produced the IDoc etc.)
• Data records of different types. The number and type of segments is mostly
fixed for each IDoc type, but there is some flexibility (for example an SD order
can have any number of items).
• Status records containing messages like 'IDoc created', 'The recipient exists',
'IDoc was successfully passed to the port', 'Could not book the invoice
because..'

IDoc Transactions in SAP[edit]

The following transactions can be used to create and process IDocs. The list does
not include any transaction required for the development of new IDoc types.
Please note that you get a comprehensive list of available transactions by using
area menu WEDI.

• WE02 - IDoc List report

• WE05 - IDoc List
• WE09 - IDoc Search for Business Content
• WLF_IDOC - IDoc Processing
This transaction is used to display and edit IDocs.

• WE19 - Test Tool for Idoc Processing

• WE20 - Partner Profile
This transaction determines a processing code based on the partner profile
identified by the control record of the IDoc.

• WE21 - Ports in IDoc processing

This transaction identifies an external port (RFC, File, ABAP-PI, etc.) that controls
the IDoc flow to an external system.

• WE30 - IDoc Type Development

• WE31 - Development IDoc Segment
• WE32 - Development IDoc View
• WE41 - Outbound process code
This transaction links an outbound processing code specified in a partner profile
to a function module.

• WE42 - Inbound process code

This transaction links an inbound processing code specified in a partner profile to
a function module.

• BD87 - Inbound processing

This transaction processes outbound IDocs.

Error Handling[edit]
SAP provides a standard report (WE02) or (WE05) to display and edit IDocs.
Unfortunately, the provided functionality is very basic; therefore, most customers
are forced to create their own custom solution. [citation needed].

ABSTRACT
Today IDocs are used in most SAP applications for transfer of
message(information) from SAP system to other systems and vice versa. Though
lot of documentation is available on IDocs it is difficult for a functional consultant
to understand such documents due to their technical nature. While a functional
consultant is not expected to know the IDoc concepts in its entirety, an effort has
been made to capture the minimum necessary information that one needs to be
aware of in order to handle project/support issues on IDocs.

OVERVIEW
IDoc is an SAP object that carries data of a business transaction from one system
to another in the form of electronic message. IDoc is an acronym
forIntermediate Document. The purpose of an IDoc is to transfer data or
information from SAP to other systems and vice versa. The transfer from SAP to
non-SAP system is done via EDI (Electronic Data Interchange) subsystems whereas
for transfer between two SAP systems, ALE is used.
IDoc can be triggered in SAP system or in EDI subsystem. This depends on the
direction in which IDoc is sent and is called as Inbound IDoc and Outbound IDoc
accordingly. In case of outbound flow, IDoc is triggered in SAP through document
message control which is then sent to EDI subsystem. EDI converts the data from
IDoc into XML or equivalent format and then sends the data to partner system
through Internet.
For inbound flow, EDI converts partner data and IDoc is created in SAP. After
successful processing of this IDoc, Application Document is posted in SAP.

EDI STANDARDS AND IDOC

“EDI is electronic exchange of business document between the computer systems
of business partners, using a standard format over a communication network”.
EDI stands for Electronic Data Interchange.

For transmission of information electronically, two widely used standards are

ANSI ASC X12 and EDIFACT. ANSI ASC X12 is a committee formed by
representatives of major organizations, government bodies and EDI software
companies which defines standards and guidelines for information interchange
over EDI. UN/EDIFACT stands for United Nations EDI for Administration,
commerce and Transport and was formed in 1985 using ANSI X12 and UNTDI
(United Nations Trade Data interchange) as base standards. ANSI X12 describes
business document as transactions and each transaction is represented by three
digit number e.g. 850 – Purchase Order, 855 - Purchase Order Acknowledgement.
EDIFACT describes business document as messages, represented by standard
names e.g. ORDERS for purchase order.

IDOC TERMINOLOGIES
IDOC (BASIC) TYPE
IDoc Types are based on the EDI standards and mostly on EDIFACT standards.
Basic Types (or IDoc Type) defines the structure of an IDoc. Each basic type
describes standard IDoc segments, format of data fields and their size. Basic Type
also defines number of segments and fields in an IDoc. All the fields that are
necessary for transmission of message for a particular business transaction are
mapped in different segments. It also defines the structure and relationship of
IDoc segments along with mandatory and optional segments.

IDOC EXTENSION
Basic type contains all the standard fields that are necessary for carrying out a
business transaction. However, if any additional values are to be sent to the
partner then we can make use of the IDoc Extension feature. IDoc extension is
extension of basic type and contains additional custom IDoc segments and fields
that are not available in standard basic type.
IDOC SEGMENTS
IDoc segments contain the actual data that is sent to or received from a partner.
These segments contain the actual values that are sent as part of IDoc
transmission.

PARENT AND CHILD SEGMENTS

IDoc segment is termed as Parent segment if it contains its own segments. The
dependent segments are called as child segments.

INBOUND/OUTBOUND IDOCS
IDocs sent outside the system are termed as Outbound IDocs and the ones that
are received into the system, are called as Inbound IDocs.
IDOC DIRECTION
This signifies the direction is which information is sent and is similar to
terminology used in mails. If information is sent outside the system then the
direction is outbox when it is received into the system then direction is inbox. In
SAP Outbox direction is represent by “1” i.e. outbox and Inbox direction is
represented by “2”.

PARTNER
Partner is the Business Partner with which the exchange of information is to take
place using IDoc. It can be a vendor or customer or any other system. Depending
on the direction of information in which the information is sent it plays a role of
either a “sending partner” or a “receiving partner”.

PARTNER TYPE
Partner type/role is used to identify partners within the sap systems. Partner type
is KU for customer, LI for vendor and LS for Logical System.
MESSAGE TYPE
IDoc processing involves transmission or receipt of document in the form of a
message, each of which represents a document in SAP. These documents can be
Order, Shipment Confirmation, Advance Shipping Notification, Goods Receipt, or
Invoice. Message type is associated with Basic IDoc Type (Basic Type) and defines
the kind of data or document that is exchanged with the partner.

PROCESS CODE
The process code contains the details of the Function Module that are used for
IDoc processing. Message Type can be linked to the Process code.

PORT
IDoc Port contains the information about the way data is sent between the source
or target system. The type of port defines the information contained within the
port. For port type “Internet” Port will contain IP address of the target system. For
port type “file”, directory or file name information is maintained. “tRFC” port
contains information about the RFC destination of the target system. For IDoc
transmission using ALE “tRFC” ports are used.

PARTNER PROFILE MAINTENANCE

PARTNER PROFILE (WE20)

Partner profile must be maintained for all the business partners to whom we
want to send or receive the IDocs. The TCODE for maintaining the partner profile
is WE20.

Double clicking on the Partner will show the following screen:

Partner profile contains parameters for Inbound and Outbound processing of

IDocs. For each message type we can maintain, inbound/outbound options,
message control, post processing options and contact information within Inbound
and outbound parameters.

OUTBOUND OPTIONS (OUTBOUND PARAMETERS)

This involves sender/receiver port, Output mode and relation to IDoc type i.e.
Basic Type and extension.

MESSAGE CONTROL (OUTBOUND PARAMETERS)

This contains application for which IDoc will be created e.g. EF for Purchase order,
the message type of the application that will trigger the IDoc and Process Code
that will convert SAP document to an IDoc. For example, if PO is to be sent to the
Vendor AXXXXZ, then in the outbound option of the partner AXXXXZ we need to
maintain the message type ZXX1 and link it to the Process Code ME10. So when
message type ZXX1 is triggered in the PO then an IDoc will be created for the
partner vendor AXXXXZ.

Process Code is linked to the Function Module in SAP that converts application
data into an IDoc. Standard function modules are provided by SAP for this
conversion however these can also be customized as per business needs.
Change Message Indicator indicates whether the IDoc is sent as a notification of
change. For example, Purchase Order change messages are sent to vendor using
EDI standard message type 860.

Separate message type should be triggered in the purchase order for PO change.
Additional line with change message type must be added in the Message control
tab with change message indicator on.
INBOUND OPTIONS (INBOUND PARAMETERS)

For inbound options process code is maintained in the Inbound screen only. IDoc
processing can be triggered by background program and triggered immediately.

POST PROCESSING (INBOUND/OUTBOUND PARAMETERS)

In the post processing option we can maintain the workflow details of the users or
positions to which an error notification will be sent if an IDoc processing fails.
TELEPHONY (INBOUND/OUTBOUND PARAMETERS)
We can also maintain the contact details in the telephony option.

EDI STANDARD (OUTBOUND PARAMETERS)

EDI standard screen contains the details of the Standard EDI terminology used for
the IDoc transmission.

For example, Message Type 850 is an EDI standard for Purchase Order IDoc and is
linked to IDoc Message Type Orders.

IDOC STRUCTURE AND RECORDS

STRUCTURE
IDoc structure is divided into Control Record, Data Records and Status records.
These records are stored in the transparent tables in SAP. These are EDIDC, EDID4
and EDIDS.

CONTROL RECORD (EDIDC)

It contains information such as IDoc number, direction, IDoc Status, Basic Type,
Message Type, Partner (Sender/Receiver), date and time of creation/update,
Interchange File or ISA number,etc.
DATA RECORD (EDID4)
It contains the details of the IDoc segments.
IDoc segment has fields that contain the data necessary for posting the
documents.
STATUS RECORDS (EDIDS)
IDoc Status defines the processing status of the IDoc. IDoc statuses are used to
track the IDoc and its various processing states. Status Numbers represents IDoc
status. Current status of the IDoc is present in Control record.

Initial Status numbers are 64 for inbound and 03 for outbound. Successful status
is 53 for inbound and 16 for outbound IDocs.
SENDING AND RECEIVING IDOCS
TRIGGERING AN OUTBOUND IDOC
Outbound IDocs can be triggered from the output message types of Purchase
Orders, deliveries, Material Documents, invoices, etc. The following figure shows
that once the output ZXX1 of PO XXXXXXX1 is processed an IDoc
“000000XXXXXXXXX1” is added/created.

The relationship between the IDoc and the application document can be found in
two ways:
1. Relationship tab of IDoc
2. Relationship tab of Application Document, e.g. PO, SO, Material Document, etc.

The initial status of this IDoc will be 30, which after successful processing will
convert into status 16.

A successful outbound IDoc will pass through all the above statuses in reverse
order (01-03-18-06-12-16). Each status represents an IDoc validation step. If an
IDoc passes all the validations it would reach status 16. These different validation
steps for outbound IDocs are explained below:
01: IDoc generation successful
30: IDoc is ready to be processed by IDoc Processing job
03: IDoc data is passed to the Port
18: IDoc successfully triggered EDI subsystem
06: IDoc data translated to EDI format
12: IDoc is dispatched successfully to the partner
16: Partner has received the IDoc successfully

IDoc can possibly fail at any of the above steps during validation.

RECEIVING AN INBOUND IDOC

The initial status of an inbound IDoc is 64 and successful status is 53.

Different validation steps for inbound IDocs are explained below:

50: IDoc received successfully in the system
64: IDoc is ready to be processed by IDoc processing job
53: Application document created and saved successfully. The document number
can be found by expanding the status node 53

An inbound IDoc goes through all the above statuses in reverse order (50-64-53).

IDOC PROCESSING
AUTOMATIC/IMMEDIATE PROCESSING
In this case, IDoc are processed immediately as they generated or added in the
system. The check “Transfer IDoc immediately” is selected in Outbound Options
and “Trigger Immediately” is selected in Inbound Option. These checks are
generally used when the real time information exchange is necessary between
two systems.

MANUAL PROCESSING
IDocs can also be manually processed using the TCODE BD87 in SAP.

PROCESSING VIA BACKGROUND JOB

IDoc processing by background is the most preferred way of processing the IDocs.
Following Programs are used from processing the IDocs using background job:
RBDAPP01 - Inbound IDocs
RSEOUT00 - Outbound IDocs

REPROCESSING IDOCS

On the basis of IDoc statuses different programs can be used for reprocessing of
failed IDocs. These are given below:
TESTING AND EDITING IDOCS
If an IDoc contains error in the data then such IDocs can be edited using TCode
WE02 or WE05. When an IDoc is edited the original IDoc information(backup) is
saved in a New IDoc under status 70 (for inbound) / 33 (for outbound). These IDoc
stays in the system for reference only and cannot be processed. The status of the
edited IDoc becomes 69 (inbound) and 32 (outbound). These IDocs can then be
processed using BD87 transaction or batch jobs.

Debugging of IDocs can be done using by copying the IDocs using TCodeWE19.
WE19 is a test tool for Idocs processing. WE19 copies the existing idoc and creates
a new IDoc which can then be modified as per testing needs. The newly generated
IDoc can also be processed using BD87.

CONVERTING IDOC STATUS

Report RC1_IDOC_SET_STATUS can be used to change the status of IDoc. Status
changes are generally needed to move an IDoc to status 68 – no further
processing
SEARCHING IDOCS IN SAP
TCODE WE02/WE05: GENERAL SEARCH
IDocs can be displayed in system via TCODE WE02 and WE05. If IDoc number is
not known then search can be made on the basis of IDoc Date, Direction, BASIC
TYPE, MESSAGE TYPE, and PARTNER NUMBER.Partner number can be found in
the Output Messages of the documents.
IDoc search can also be made on the basis of ISA or Transfer file Reference.

TCODE WE09: SEARCHING DATA IN IDOC SEGMENTS

If we are looking for specific information within the IDocs Segments then this can
be found using TCODE WE09. This is useful if you are searching for a particular
information in similar kind of IDoc within IDoc segments. For example, if you want
to search a particular Purchase Order number e.g. 100000001 in multiple IDocs
which lies in Segment E1EDK01 of an IDoc under field BELNR. Then the search can
be executed in the following manner.
IDOC VALIDATIONS, COMMON IDOC ERRORS AND SOLUTION

Though, the IDoc failure may not be related to any of the above mentioned
reasons, the best way to find the IDoc error is to compare the existing IDoc with
the good example. Good example IDoc can be easily searched with any of the
IDoc search methods as described above.

DOCUMENTATION FOR IDOC TYPES

IDoc documentation can be found using TCODE WE60 and can be helpful to
obtain information of the IDoc Type or its particular segment. It also provides
information such as mandatory and optional segments, minimum and maximum
number of segments, etc.
GENERAL INFORMATION FOR COMMON IDOC MESSAGE TYPES
The following list gives the Basic Type and Message Type combination for
common idocs
ARCHIVING/DELETION OF IDOCS FROM DATABASE
As IDocs grow older they are archived and deleted from the database. Archived
IDocs can be viewed using TCODE SARI in Achieve Explorer using archiving object
as IDoc. Following are the few programs that are used for archiving and deletion
of IDocs from database.
276004 Views Products: sap_erp_logistics_materials_management Topics: enterp
rise_resource_plannin
 Overview SAP Interfaces

The Business API (BAPI) is an interface that allows you to call the methods of
these SAP Business Objects. A-Synchronous Description Interface MethodsIDoc
Intermediate Document (IDoc)interface is an SAP standard format for exchanging
data betweenSAP systems and between an SAP system and an external
application.Nov 7, 2012
Skip to end of metadata
• Created by Brandon Jacobson, last modified by Werner Daehn on Jan 15, 2013
Go to start of metadata
Summary
DataServices is a technical integration tool, so it has to support the interfaces the
users believe is best suited for a given task.
When dealing with SAP you have to ask yourself different kind of questions:

• What technical method to connect to SAP? ABAP, RFC or the underlying database.
• What object to use from SAP? Tables, Function Modules, Extractors, IDOCs, BW
InfoSource/DataSources.
• Reading or Loading data?

Not all objects can be used with all methods, the following table provides an
overview
 ABAP via RFC in a regular underlying
dataflow dataflow database

SAP Table (Read) yes yes (use DS 4.1 RFC yes/no (only
transport method transparent
for larger amounts tables)
of data)

SAP Function Modules yes (no table yes (function needs no

(Read/Load) parameters) to be RFC enabled
in SAP)

Extractors (Read) yes (use only yes no

if needed)

IDOCs (Read/Load) no reading (in a no

realtime
job)/loading

BW no yes no
InfoSource/DataSource
(Load)

BW OpenHub (Read) no yes no

SAP Set-Hierarchies yes no no

(Read)

Most of the restrictions are natural, like you cannot simply load a SAP table, data
has to go through the regular validation rules and might end up in multiple tables
at the end.
Or BW provides interfaces to read/load data, hence we show BW to the end users
like any other database with tables.
The fact that you cannot use table parameters of SAP function modules in an
ABAP dataflow is a technical restriction, one that hurts occasionally.
And sometimes you might have multiple options, e.g. loading Sales data via BAPIs
or IDOCs? Both have pros and cons. Or BW objects are nothing else then SAP
tables, so could theoretically be used that way.
 But one is obvious, connecting to the underlying SAP database directly is very
limited and hence the exception.

• Direct SQL
• ABAPs
• RFC ReadTable
• Extractors
• RFC-BAPI
• IDOCs

o Overview SAP Interfaces

o Connecting to SAP
o Reading via ABAP
o Reading R3 Hierarchies
o Reading via RFC Read Table
o Using Extractors as Source (Data Services 4.0)
o Calling RFCs-BAPIs
o Reading SAP BW
o Loading BW
o Receiving IDOCs
o Sending IDOCs
o Function Example READ_TEXT
o SAP NetWeaver Process Orchestration vs. SAP Data Services
o Loading BW(DS4.0 BW7.3)
o List of ERP Suite Extractors for DataServices
• favourite
6 Child Pages
Page: Direct SQLPage: ABAPsPage: RFC ReadTablePage: ExtractorsPage: RFC-
BAPIPage: IDOCs
Oracle® Application Server Adapter for SAP R/3
User's Guide HomeSolution ContentsIndex
10g Release 2 (10.1.2) Area
B14061-03

Previous Next

A Configuring SAP for Inbound and Outbound Processing

During inbound (client) processing, IDocs are transferred to the interface and
stored in the R/3 System. The document data is generated in a second step, also
in the course of a workflow.

Outbound processing in SAP involves event handling. An event in SAP is defined as

an occurrence of a status change in an object. Events are created when the
relevant status change occurs. The following topics describe how to enable
inbound and outbound SAP processing.

• Configuring SAP Inbound Processing

• Configuring SAP Outbound Processing

Configuring SAP Inbound Processing

SAP inbound processing requires the upstream system to transfer an IDoc to

the IDoc interface through the R/3 System port. For this reason, you do not have
to specify a port in the inbound partner profiles; the IDoc interface only must
recognize the upstream system as a port. A port definition, which provides a
unique ID for the upstream system, must be available for the port. The technical
parameters of this port definition can (and usually are) overwritten by the
upstream system.

If the upstream system is recognized, then the IDoc is saved in the database. If a
partner is defined with the corresponding message in partner profiles, the IDoc is
then processed further. This is done independently in the second step. This
ensures that the external system can receive the data quickly and reliably
(automatically).

You must perform the following steps to configure SAP for inbound IDoc
processing:

1. Configure a logical system.

2. Configure a distribution model.
3. Define an inbound partner profile.

Configuring a Logical System

In any distributed environment, each participating system must have a unique ID

to avoid confusion. In SAP, the name of the logical system is used as the unique
ID. This name is assigned explicitly to one client in an SAP system.

Defining a Logical System

To define a logical system:

1. Run the sale transaction.

Description of the illustration ale_saletransaction.gif

The Display IMG window is displayed.

 Description of the illustration ale_inbound1.gif

Perform the following steps:

a. Expand Sending and Receiving Systems.

b. Expand Logical Systems.
c. Select Define Logical System.
2. Click the IMG - Activity icon.

A message window is displayed. It indicates that the table is cross-client.

Description of the illustration ale_imgmessage.gif

3. Click the check mark icon to continue.

The Change View "Logical Systems": Overview window is displayed.

 Description of the illustration ale_inbound2a.gif

4. Click New Entries.

The New Entries: Overview of Added Entries window is displayed.

Description of the illustration ale_inbound4a.gif

5. Enter the Logical System, for example, ORACLETDS, in

the Log.System column and provide a description in the Name column.
6. Click Save.
 The Prompt for Workbench request dialog box is displayed.

Description of the illustration ale_inbound4.gif

7. Click the Create Request icon.

The Create Request dialog box is displayed.

Description of the illustration ale_inbound5.gif

8. Enter a name and description for your request and click Save.

The logical system you configured, for example, ORACLETDS, is now added
to the list.
 Description of the illustration ale_logicalsysdisplay.gif

Configuring a Distribution Model

A distribution model is used to describe the ALE message flow between logical
systems. Business objects are distributed to connected recipients according to a
unique distribution model that can contain rules of varying complexity depending
on the type of business objects involved.

Defining a Distribution Model

To define a distribution model:

1. Run the bd64 transaction.

Description of the illustration ale_nbd64.gif

The Display Distribution Model window is displayed.

 Description of the illustration ale_distmodel1.gif

2. Click Distribution Model from the menu bar.

Description of the illustration ale_distmodel2.gif

3. Select Switch processing mode.

The Display Distribution Model window is switched to Change Distribution

Model.
 Description of the illustration ale_distmodel3.gif

4. Click Create model view.

The Create Model View dialog box is displayed.

Description of the illustration ale_inbound7.gif

5. Enter a model view name in the Short text field and a name in
the Technical name field, which also serves as a description.
6. Click the check mark icon to enter the information.

You are returned to the main Change Distribution Model window. The
distribution model you configured is now added to the list.
 Description of the illustration ale_distmodel4.gif

7. Click Add message type.

The Add Message Type dialog box is displayed.

Description of the illustration ale_inbound8.gif

Perform the following steps:

a. In the Sender and Receiver fields, enter the logical system you
configured, for example, ORACLETDS.

You can click the icon to the right of each field to browse from a list
of logical systems.

b. In the Message type field, enter the message type you want to use,
for example, MATMAS.

You can click the icon to the right of each field to browse from a list
of available message types.

8. Click the check mark icon to enter the information.

You are returned to the main Change Distribution Model window.

9. Click Save.
Defining a Partner Profile

Partner profiles are a prerequisite for data exchange. This involves defining who
can exchange messages with the SAP system and using which port.

Defining a Partner Profile

To define a partner profile:

1. Run the we20 transaction.

Description of the illustration ale_we20.gif

The Partner profiles window is displayed.

 Description of the illustration ale_pprofile1.gif

2. In the left pane, expand Partner type LS and select the logical system you
configured from the list, for example, ORACLETDS.
 In the right pane, the Partn.number field refers to the name of the logical
system.

Description of the illustration ale_pprofile2.gif

3. Click Save.
4. From the Inbound parameters table, click the Create inbound parameter
icon.

The Partner profiles: Inbound parameters window is displayed.

 Description of the illustration ale_inbound11.gif

5. In the Message type field, enter the message type you want to use, for
example, MATMAS.

You can click the icon to the right of each field to browse from a list of
available message types.

The Inbound options tab is selected by default.

6. In the Process code field, enter the process code you want to use, for
example, MATM.
 You can click the icon to the right of each field to browse from a list of
available process codes.

7. In the Processing by function module area, select one of the following

options:
• Trigger by background program.

In this case the adapter writes IDocs to the SAP database, which is
processed immediately.

• Trigger immediately.

In this case, the adapter waits for the SAP system to process IDocs.
This can take anywhere from 1 to 15 minutes.

Click Save.

Configuring SAP Outbound Processing

Event creation must be implemented by you or by SAP. An event is created from

specific application programs (the event creator) and then published systemwide.
Any number of receivers can respond to the event with their own response
mechanisms. An event is usually defined as a component of an object type.

SAP pseudo events are not processed by the SAP Event manager, but are called
from an ABAP program or Remote Function Call (using the Destination
parameter).

Related Concepts and Terminology

The following topic lists and defines specific terminology related to SAP and SAP
event handling.

Client and Server Programs

RFC programs for non-SAP systems can function as either the caller or the called
program in an RFC communication. There are two types of RFC programs:

• RFC Client
• RFC Server
The RFC client is the instance that calls the RFC to run the function that is
provided by an RFC server. The functions that can be called remotely are called
RFC functions, and the functions provided by the RFC API are called RFC calls.

SAP Gateway

The SAP Gateway is a secure application server. No connections are accepted

unless they have been preregistered previously from the SAP presentation Client.
A server connection presents itself to the Gateway and exposes a Program
Identifier. If the Program Identifier is found in the list of registered Program IDs,
the Gateway server then offers a connection to the server, which "Accepts" a
connection. This ProgramID is then linked with an RFC Destination within SAP,
which enables SAP Function Modules and ALE documents (IDocs or BAPI IDocs) to
be routed to the destination. The RFC Destination functions as a tag to mask the
Program ID to SAP users.

An RFC server program can be registered with the SAP gateway and wait for
incoming RFC call requests. An RFC server program registers itself under a
Program ID at an SAP gateway and not for a specific SAP system.

In SAPGUI, the destination must be defined with transaction SM59, using

connection type T and Register Mode. Moreover, this entry must contain
information on the SAP gateway at which the RFC server program is registered.

Program IDs and Load Balancing

If the Gateway Server has a connection to a particular server instance and

another server instance presents itself to the gateway, then the gateway offers
the connection and then begins functioning in Load Balancing mode. Using a
proprietary algorithm, the Gateway sends different messages to each server
depending on demand and total processing time. This may cause unpredictable
results when messages are validated by schema and application.

When configuring multiple events in the Oracle Application Server using a single
SAP program ID, SAP load balances the event data. For example, if multiple
remote function calls or BAPIs use the same program ID (for example,
ORACLETDS) and multiple SAP listeners are configured with this progamID, then
SAP sends one request to one listener and the next to another listener, and so on.
There is a load-balancing algorithm present in the SAP Gateway Server. This
mechanism is proprietary to SAP application development and might work by
comparing total throughput of the connection, the number of times in wait state,
and so on. This means one connection might receive nine messages and a second
connection might receive one message. If five of the nine messages are rejected
for schema validation and the one message on the other connection is rejected
for schema validation, you might suspect that you are missing SAP event handling
messages.

Load balancing in server (inbound to adapter from SAP) situations is handled by

connecting multiple instances of the adapter to the SAP system. The SAP system
will then load balance the connections. You cannot tune this performance.

Load balancing in client (outbound from adapter to SAP) situations is handled only
by the SAP application design. If your system supports a Message Server, then you
can load balance in client situations. If you have only one application server, you
cannot load balance except by application server tuning, such as maximum
number of connections permitted or time of day limits on connections.

The SAP system default limit is 100 RFC (communication) or adapter users. Each
user takes up more than 2 MB of memory on the application server of the SAP
system, and more or less on the adapter depending on the workload.

Connection Pooling

A connection pool is a set of client connections to a specific destination. The pool

may automatically create new connections to the specified remote system or
return an already existing connection. It also provides methods to return a
connection back to the pool when it is no longer needed.

A connection pool can check which connections are no longer in use and can be
closed to save system resources. The time period after which the pool checks the
connections as well as the time after which a connection will time out can be
configured by the calling application.

A pool is always bound to one user ID and password, meaning that all connections
taken from this pool will also use these credentials. An SAP connection is always
bound to an SAP user ID and an SAP Client number.
If you log on with a pool size that is set to 1, no connection pool is created (1
userid – 1 process thread). If you log on with a pool size that is greater than 1, a
pool is created with a size of n, which is the number you specified.

For more information about connection pooling, see the SAP JCO API
documentation.

Registering Your Program ID in SAPGUI

To enable your SAP system to issue the following calls or interfaces to the SAP
event adapter, you must register your program ID under an RFC destination.

• Remote Function Calls (RFC)

• Business Application Programming Interfaces (BAPI)
• Intermediate Documents (IDoc)

The RFC destination is a symbolic name (for example, ORACLETDS) that is used to
direct events to a target system, masking the program ID. The Program ID is
configured in both SAPGUI and the event adapter.

Registering Your Program ID

To register your program ID:

1. Launch the SAP GUI and log in to the SAP system.

2. Select Tools, Administration, Network, and then RFC destination.
3. Run the SM59 transaction.

The Display and maintain RFC destinations window is displayed.

 Description of the illustration iway_sapu_tcpipconnect.gif

4. Select TCP/IP connections and click Create.

The RFC Destination window is displayed.

 Description of the illustration iway_sapu_rfcddestination.gif

Provide the following information:

a. In the RFC destination field, enter a name, for example, ORACLETDS.

The value you enter in this field is case sensitive.

b. In the Connection type field, enter T for destination type TCP/IP.

c. In the Description field, enter a brief description.
5. Click Save from the tool bar or select Save from the Destination menu.

The RFC Destination ORACLETDS window is displayed.

 Description of the illustration iway_sapu_iwaydest.gif

Perform the following steps:

a. For the Activation Type, click Registration.

b. In the Program field, enter ORACLETDS.
6. Click Save from the tool bar or select Save from the Destination menu.
7. Ensure your event adapter is running.
8. Verify that the SAP system and OracleAS Adapter for SAP are
communicating.
9. Click TestConnection.

Testing the SAP Event Adapter

In the SAP Server, the SE37 transaction enables you to send an RFC (Remote
Function Call) or a BAPI (Business Application Programming Interface) to any RFC
destination. For more information on RFC destination, see Registering Your
Program ID in SAPGUI.

Testing the SAP Event Adapter by Sending an RFC or a BAPI Manually

To test the SAP event adapter:

1. In the Function Builder, select a function module, for

example, RFC_CUSTOMER_GET.
 Description of the illustration iway_sapu_functionbuilder.gif

2. To choose single test, press F8 and click the Single Test icon or
choose Function module, select Test and then Single Test.
3. Enter an RFC target system, for example, ORACLETDS.
4. Enter input data for the particular RFC modules, for example, AB*.
5. To execute, press F8.

The Test Function Module: Initial Screen window is displayed.

 Description of the illustration iway_sapu_testfunctionmod.gif

6. Enter data into the SAP GUI and click Execute.

The function name and input data are transferred through RFC to create an
XML document on the Oracle Application Server with the parameters input
in SAPGUI.

Application Link Embedding Configuration for the Event Adapter

The SAP event adapter receives IDocs (Intermediate Documents) from SAP. To
configure an SAP system to send IDocs to the SAP event adapter, use the ALE
(Application Link Embedding) configuration to:

1. Register your program ID in SAPGUI.

2. Define a port.
3. Create a logical system.
4. Create a partner profile.
5. Create a distribution model for the partner and message type.
6. Test the SAP event adapter.
Defining a Port

A port identifies where to send messages. This port can be used only if an RFC
destination was created previously.

Defining a Port

To define a port:

1. In the ALE configuration, choose Tools, Business Communications, IDocs

Basis, IDoc, and then Port Definition.

You can also run the WE21 transaction.

The Creating a tRFC port window is displayed.

Description of the illustration iway_sapu_defineport.gif

2. In the left pane under Ports, select Transactional RFC and click Create.
3. Select Generate port name.

The system generates the port name.

4. Enter the IDoc version you want to send through this port.
5. Click the destination you created, for example, ORACLETDS.
 6. Save the session, making note of the system-generated RFC port.

Creating a Logical System

One type of partner is a logical system. A logical system manages one or more RFC
destinations.

Creating a Logical System

To create a logical system called ORACLETDS:

1. In the ALE configuration, enter the area menu selection SALE transaction.
2. Select SAP Reference IMG.
3. Expand the following nodes: Basis Components, Application Link Enabling
(ALE), Sending and Receiving Systems, Logical Systems, and Define Logical
System.
4. Click the check mark beside Define Logical System.

The Change View "Logical Systems": Overview window displays a list of

logical systems and their names.

Description of the illustration iway_sapu_iwaylog.gif

5. Click New entries.

 The New Entries: Overview of Added Entries window is displayed with
Log.System and Name columns for new log system.

Description of the illustration iway_sapu_newentries.gif

6. Type an entry for Log System, for example, ORACLETDS.

7. In the Name column, enter a name (description) for the partner profile.
8. Click Save to save the session.

Creating a Partner Profile

A partner profile is a definition of parameters for the electronic interchange of

data with a trading partner using the IDoc interface.To communicate with a
partner using the IDoc interface, you must create a partner profile.

Creating a Partner Profile

To create a partner profile:

1. In SAP GUI, choose Tools, Business Communication, IDoc Basis, and

Partner profile.

You can also run the WE21 transaction.

 The Partner profiles: Outbound parameters window is displayed and shows
fields for specifying details for the partner profile.

Description of the illustration iway_sapu_partnerprofile.gif

Perform the following steps:

a. Select Partner type LS (Logical system).

b. Press F5 (Create).
2. For Type, enter USER.
3. For Agent, enter the current user ID, or you may select another agent type.
4. Under the outbound parameter table control, select Create outbound
parameter.

Partner type is LS, and the Message type is DEBMAS, which is the IDoc
document type.

5. Leave Partn.funct blank.

6. Click the Outbound options tab.

Provide the following information:

 a. Depending on your performance requirements, click Transfer IDoc
Immed or Collect IDocs.
b. For the IDoc, enter a message type, for example, DEBMAS.
c. Enter a receiver port, for example, A000000036.
7. Click Save to save the session.

The Partner profiles summary window is displayed. It contains information

for the logical system that you created.

Description of the illustration iway_sapu_savedsession1.gif

Collected IDocs

When using collected IDocs on any platform during inbound processing (service
mode), if the DOCNUM field does not have a unique document number for each
IDoc, the system creates an IDoc for each header record in the collected IDoc file
and duplicates the data for each IDoc.

Make sure the DOCNUM field is included in the EDI_DC40 structure and that each
IDoc has a unique sequence number within the collected IDoc file.
Creating a Distribution Model for the Partner and Message Type

You must create a distribution model for the partner and message type you
designated.

Creating a Distribution Model

To create a distribution model called ORAMOD:

1. In SAP GUI, choose Tools, AcceleratedSAP, Customizing, and then Project

Management.

You can also run the BD64 transaction.

The Display Distribution Model window is displayed.

2. Select Create model view.

If required, switch the processing mode to edit within Distribution

Model/Switch Processing Mode.

3. Enter a short text string and a technical name for your new model view.
4. Click Save.

The Distribution Model Changed window is displayed, showing a tree

structure of the distribution model.
Description of the illustration iway_sapu_distributemodel.gif

Perform the following steps:

a. In the Distribution Model tree, select a new model view.

b. On the right, select Add message type.

The Add Message Type box is displayed. It contains fields for specifying the
sender and receiver of the message, as well as the message type.

Description of the illustration iway_sapu_addmessagetype.gif

Provide the following information:

c. In the Sender field, provide the sender that points to the SAP system,
which sends the IDoc, for example, I46_CLI800.
 In this case, the sender is an SAP 4.6B system.

d. In the Receiver field, provide the logical system, for example,

ORACLETDS.
e. In the Message type field, provide the type of IDoc, for example,
DEBMAS.
5. Click the check mark icon.
6. Click Save.

The Change Distribution Model window displays the new model view to use
to send message type, DEBMAS, from the I46_CLI800 SAP system to the
ORACLETDS logical system.

Description of the illustration iway_sapu_changedistmodel.gif

You are now ready to test the connection to the logical system.
Testing the SAP ALE Configuration

In the SAP Server, the BD12 transaction enables you to send IDocs to any logical
system, for example, to an event adapter.

Testing the SAP ALE Configuration

To test the SAP Application Link Embedding (ALE) configuration:

1. In the Send Customers window, enter the IDoc message type, for example,
DEBMAS in the Output type field.

Description of the illustration iway_sapu_sendcustomers.gif

2. In the Logical system field, enter the logical system, for example,
ORACLETDS.
3. Click Run.

The SAP event adapter receives the IDoc in XML format. No response is
expected from the event adapter.

A confirmation window is displayed.

 Description of the illustration iway_sapu_testcomplete.gif

Previou Nex Copyright © 2006, Oracle. All rights reser

HomeSolution ContentsIndex
s t ved. Area

what is variant in sap

But if the selection data is saved as a variant, then anyone having basic
knowledge of SAP can run the report. Instead of entering the same values in
selection criteria input fields each time you execute a report, you can create
a variant. Using variants reduces both data entry time and system processing
time.Nov 16, 2012

Definition of Variants
You can adapt the mass processing function and the order information system in
a very flexible way, to meet the requirements of your company and its individual
users. You can put together user-dependent report variants, report transactions,
and variant transactions to provide every user with the exact range of functions
required.

Techniques Used
Report variants
With a report variant (see Variant Maintenance), you can specify default values
for fields, hide fields or make them unavailable for input on the initial screen of a
program. You can use report variants to schedule in the background or to define a
report transaction. For technical reasons, only the display and input availability of
the selection criteria can be influenced for the program. The display and input
availability of other fields (for example, the parameters for mass processing or the
list category) can only be controlled via a transaction variant. Conversely, the
selection criteria cannot be influenced in the transaction variant.

In the technical settings in variant maintenance of the report PPIO_ENTRY, you

can specify defaults for the following values:
Order category (production and process order)
Transaction for which an authorization check should be carried out, if this variant
is selected in a different transaction
Lists that can be selected (for example, components, operations, and so on)
Functions that can be selected (for example, close)
Mass processing active
Old ALV output
Choose the variant maintenance function (transaction SE38). Enter the report
PPIO_ENTRY, select Variant and choose Change. Enter the desired variant and
choose Change. Make the necessary settings in the areaTechnical Settings.

You can use the report PPIO_ENTRY_VARIANT_DISPLAY to display an overview of

variants and their technical settings. For example, you can view information about
which output list, which overall profile, and which layout have been chosen as
presettings.
If no overall profile has been defined, the system uses the overall profile from the
user specifications (in other words, from the SET/GET parameter IOC) or the last
overall profile that was used.
If no layout has been entered, the system automatically uses the default layout or
the standard layout (if no default layout has been entered for this list).
Report transactions
A report transaction is used to call up a report variant of a program (see Report
Transaction). You can insert a transaction in the menu or add it to the favorites
list.
Transaction variants
With a transaction variant (see Transaction Maintenance and Variant Transaction)
you can also hide fields or specify default values for them (for example, the
parameters for mass processing, list category, production order selection,
planned order selection or process order selection).
Variant transaction
A variant transaction is used to call up a transaction variant (see Transaction
Maintenance and Variant Transaction). You can insert a transaction in the menu
or add it to the favorites list. A variant transaction can, for example, be added to a
user's favorites menu or role menu.

Example
The following example shows you how to create a customized transaction for
reprinting time tickets.
Defining a report variant
Using transaction SE38, you define the report variant Z_LV01 for program
PPIO_ENTRY. When you do this, you preset the following:
The operation list is the only list that can be selected.
The object Operations is predefined for the List field.
The Mass Processing Active indicator is set.
Selection fields that are not needed are hidden.
Print and Print mode, as mass processing functions, are preset for immediate
execution. You define that these fields are blocked for entry.
Defining a report transaction
Using transaction SE93, you define the report transaction Z_LV01_T for report
variant Z_LV01 of program PPIO_ENTRY.
Defining a transaction variant
Using transaction SHD0, you define the transaction variant Z_LV01_01 for report
transaction Z_LV01_T. You hide the Production orders and Planned orders fields.
Defining a variant transaction
Using transaction SE93, you define the variant transaction ZLV01 for transaction
variant Z_LV01_01 of report transaction Z_LV01_T. This variant transaction can be
added to a user's favorites menu or role menu, for example.
Execution in the Order Information System and Mass Processing
The central program for mass processing and the order information system is
PPIO_ENTRY. Examples have been set up in the standard system to demonstrate
the use of the options described above:

Mass Processing
Variant Transaction for production order: COHV
transaction Logistics → Production → Shop Floor Control →Control → Mass
Processing
Transaction for process order: COHVPI
Logistics → Production – Process → Process Order →Tools → Mass
Processing
Report variant Report: PPIO_ENTRY, Variant : SAP&HVOM or SAP&HVOMPI
Order Information System
Report Transaction for production order: COOIS
transaction Logistics → Production → Shop Floor Control →Information
System → Order info system
Transaction for process order: COOISPI
Logistics → Production – Process → Process Order →Tools → Mass
Processing
Report variant Report: PPIO_ENTRY, Variant : SAP&COOIS or SAP&COOISPI
Collective Release
Variant Transaction: CO05N
transaction Logistics → Production → Shop Floor Control →Control → Collective
release
Transaction Transaction: COHVOMRELEASE, transaction variant: CO05
variant
Report COHVOMRELEASE
transaction
Report variant Report: PPIO_ENTRY, Variant : SAP&RELEASE
Print
Variant Transaction: CO04N
transaction Logistics → Production → Shop Floor Control →Control → Print
Variant Transaction: COHVOMPRINT, transaction variant: CO04
transaction
Report COHVOMPRINT
transaction
Report variant Report: PPIO_ENTRY, Variant : SAP&PRINT
Collective Availability Check
Variant Transaction: COMAC
transaction Logistics → Production → Shop Floor Control →Control → Collective
availability check
Report variant Report: PPIO_ENTRY, Variant: SAP&AVAILCHK
Missing Parts List
Variant Transaction: CO24
transaction Logistics → Production → Shop Floor Control →Information
System → Missing parts information system
Report variant Report: PPIO_ENTRY, Variant: SAP&MPART

Pick List
Variant Transaction: CO27
transaction Logistics → Production → Shop Floor Control → Goods
Movements → Material Staging → Pick
Report variant Report: PPIO_ENTRY, Variant: SAP&PICK or SAP&PICKPI

How to use SAP variant

Variants allow you tosave your selection parameters in the input screen.

It minimizes the need to enter selection parameters each time you run a SAP
report.
Variants can be storted for ANY SAP REPORTas long as the Save Button is
available in the SAP Menu bar for the report.

Note: Many a transactions may be proctected due to security reasons by your

administrator and save button may not be available

Create a Variant

1. Enter the values for selection criteria while you are in any SAP report.
2. Once all selection criteria are populated , Click the Save button

1. Enter a Variant Name

2. Type Meaning (description) of the variant
Click the Save Button.

Retrieve a Variant
Click the Get Variant Button

1. Highlight the Variant you wish to use

2. Click the Check Mark
The report will be populated with the Selection Criteria.

Delete a Variant
While in ANY SAP Report Select GoTO > Variants > Delete

1. Highlight the Variant you want to delete

2. Click Okay
In the next SAP pop-up

1. Select the "only in current client" radio button. (All Clients option will delete
the variant across ALL clients)
2. Click Continue

Variant is deleted.

Your Feedback & Ideas are very important to us. Please share your
suggestions here

© Copyright - Guru99 2016

Batch Job

Definition - What does Batch Job mean?

A batch job in SAP is a scheduled background program that usually runs on a
regular basis without any user intervention. Batch jobs are provided with more
allocated memory than the ones that are done in the foreground. They are used
to process high volumes of data that would normally consume long-term memory
if run in the foreground, as well as for running programs that require less user
interaction.

Techopedia explains Batch Job

One of the advantages of running large programs as batch job is that more servers
can dedicate more work processes in night mode, when there are few interactive
users. The number of batch jobs during the day could be restricted to fewer
servers and numbers as needed.
If a batch job creates an output that is to be printed, faxed or emailed, the output
is transferred to the spool management in the R/3 system.
To create a new batch job, one can use transaction SM36. This involves defining
the job name, job class and target server if needed. However, it is recommended
that users avoid choosing the target server when creating the batch job, and allow
the background system to determine the server as and when needed instead.
Batch jobs can also start processing based on specific events and results. SM36
also provides a batch job wizard.
Hi

The jobs can be either scheduled as immediate or periodic.

To schedule a back ground job follow the below steps:

1. Use Transaction SM36.

2. Assign a job name.

3. Set the job’s priority, or “Job Class”:

High --- Class A

Medium --- Class B

Low ---Class C
4. Here you can specify,when the job is to start by choosing Start Condition. If
you want the job to repeat, or be periodic, check the box at the bottom.

Else click on the immediate and save this.

5. Now,define the job’s steps by choosing Step.

Here you need to give the ABAP program that has been used and the name of
the variant thats being used.

6. Save the fully defined job to submit it to the background processing

system.(You need to click save button on the main screen i.e SM36)

7. When you need to modify, reschedule, or otherwise manipulate a job after

you've scheduled it the first time, you'll manage jobs from the Job Overview.

8. Release the job so that it can run.

The job, even those scheduled for immediate processing, can not run without first
being released.So,do remember to release.

Hope its useful,

Sravani