Creation of BOR objects, Start and Stop events

Go to the transaction SWO1.

Enter a name for the Object type and click 'CREATE' button for creating the custom BOR
Object.Enter the details required for creating the BOR objects...

Create the Key fields and events of the BOR object.

For creating the Key fields place the cursor on the Key fields and Click on the Create Button

Create events for triggering the workflow and stopping the workflow.
For creating the event place the cursor on the EVENTS and Click the create button like Key
fields.
Create two events.
Enter the event name description etc and proceed further to create it.
Similarly create another event for ending the Workflow in the similar manner like that created
earlier.
Now, Generate the BOR object through the generate button
Release the EVENTS and subsequently release the BOR object.
Create a workflow for the generation of notification
whenever an error is reached in the Inbound Idoc.
Execute the transaction SWDD.
Click on the CREATE button for creating the workflow for error handling.
Choose the Step type to be inserted for the notification like here we are using Send Mail option
for sending a mail to the user whenever any error occurred.
Activate the Workflow and test it whether it is working as per the requirement.
After the successful completion it is required to attach the workflow with the event.
Go to the Header section (Denoted by CAP).

Enter the details of the event with which the workflow should be linked like the category, BOR
object type and the event with which that should be linked.
Enter here the BOR object that has been created and give the name of event created for
starting the workflow.
Click on the Binding Button for generating the binding between the event and the workflow.
Generate the binding and click OK button to save the binding.
Click on Activate / deactivate button for activating the linkage.
After the successful linkage the following sign will appear on the workflow.....
This shows that the workflow has been linked to the event and it will be triggered whenever
that particular event will be triggered.
generate a function module and attach it to the
process code
Go to SE37 transaction and copy a standard process code function module to a custom one.
Do no delete any parameters from the function module as the SAP standard program itself is
calling this.
In that function module do the required validation and whenever the validation fails set a
standard parameter 'WORKFLOW_RESULT' to 9999 from within the function module,
otherwise normally proceed to set the status to 53.
After the creation of function module it is required to attach it to the process code and
corresponding attached to the message type at the Partner Profile stage.
The process code is being created through the transaction WE42
Go to the change mode and click the New Entries button for creating new process code.

Enter the Process Code Name, description and choose the processing type as Processing by
function module. Click on the extension button of Identification.
The details for the of the Process Code after clicking the identification button will be
Whenever idoc arrives into the Destination system then the standard SAP triggers the Process
code attached to the Message type in the partner profile. The partner profile is being
maintained in the transaction WE20.

Since, it is and inbound scenario so the message type and the corresponding process code will
be maintained for the Inbound Parameters.
Click on Create Inbound Parameters button for creating new Inbound Message type and the
corresponding message type.
Enter the process code for the corresponding message type.

Click SAVE button for saving the changes.

Whenever the IDOC arrives into the target system, it checks the partner profile and finds the
corresponding process code. The process code is being linked with the function module
through which the IDOC is required to be processed.

Structural relationship between IDoc and EDI

Standard messages for SD

SAP R/3 uses IDoc as the intermediate data for transmitting information; whereas most of the
business applications use standards like EDIFACT/ ANSI X12 for transmitting business
information.
On higher level every message has header, detail and trailer section. Header giving
identification information, detail being the content of information and trailer giving the
summary information. The following diagram shows EDIFACT message ORDERS96A, IDoc
ORDERS05 and ANSI X12 850(i.e. Orders) version 3020 for basic Order message.
By observing the above three message structures we can see that for EDIFACT message the
Message header starts with UNB segments and includes all segments before LIN segment. For
IDoc it starts with EDI_DC40 i.e. control record and includes all the segments before E1EDP01.
And for ANSI X12 starts with ISA and includes all the segments before P01.
In the header section various identification information is specified. As EDIFACT and ANSI X12
message being delimited messages i.e. delimiters separate fields/segments. This information is
provided by EDIFACT-UNA and ANSI X12-ISA segment. Whereas in IDoc every field is positional
i.e. starts at fixed position and every segment is of fixed length.
Other important identification information required is sender and receiver of the message. It
is specified by EDIFACT-UNB segment, IDoc-EDI_DC40 segment and ANSI X12- ISA segment.
These segments also contain the date and time information of message transfer. In
addition they also identify the type of business information these messages represent for
example orders, order response or invoices etc.
The EDIFACT-UNH segment in addition contains the EDIFACT message version and release
number information like IDoc control header contains the IDoctype and extension information.
This segment also used to give messages sequence number; ANSI X12-ST segment serves the
same purpose.
After identifying the message is of type order in UNH segment; for representing the type and
function of the message in more detail EDIFACT-BGM and ANSI X12-BEG segment is used i.e.
which type of order it is Purchase order, rush order or cross dock order etc. Various qualifiers
used for this purpose. These segment are also used to provide customer message identifying
number i.e. purchase order number for inbound order. In IDoc E1EDK01 segment used store
SAP document number. This segment of IDoc also stores the currency code information
whereas EDIFACT CUX or ANSI X12 CUR segments used for this purpose
In EDIFACT and ANSI X12 DTM segment with different qualifiers are used to provide different
date time information for example document/message creation date or order date etc. In IDoc
E1EDK03 segment plays the same role.
Additional free form text information/instruction can be communicated by EDIFACT-FTX or ANSI
X12-NTE segment. IDoc uses E1EDKT1 with E1EDKT2 segment pair for this purpose.
While transferring the information the references to the vendor and customer document
numbers are important for example offer number, sales order number, purchase order number
etc. EDIFACT-RFF segments used for this purpose with different qualifiers. In IDoc E1EDK02
with qualifier 001 gives customer related identification number and E1EDK02 with qualifier 002
gives vendor related identification number of the business document. E1EDK02-DATUM field
provides the respective vendor /customer document date. EDIFACT and ANSI X12 uses DTM
segment for this purpose with RFF segment.
In business information the different parties involved in business are important e.g. supplier
party, buyer party or delivery party. This information is provided by EDIFACT-NAD ANSI X12-
N1..N4 segment with help of qualifier. In Idoc E1EDKA1 segment serves this purpose with
qualifier.
So on higher level we can see as below for header section.

The detail section of the EDIFACT, ANSI X12 Message or IDoc gives the item or product
information. In EDIFACT it start at LIN and ends before UNS; for ANSI X12 it starts from PO1
and ends before CTT. And for IDoc it starts from E1EDP01 and ends before E1EDS01 segment.
For every product / item in this business message these segments repeats.
IDoc E1EDP01 segment is used to give basic and most frequently used line item detail.
EDIFACT-LIN and ANSI X12 PO1 segment serves that purpose. These segments includes
information like product identification number, item serial number within series of articles.
Information regarding quantity of the product and unit used for measuring quantity is given by
EDIFACT-QTY segment. In IDoc it is stored in E1EDP01 segment and for ANSI X12 P01 segment
is used. Also price information is given by IDoc E1EDP01 and ANSI X12 P01 segment while
EDIFACT uses PRI segment for that purpose.
Date/time information related to item/product e.g. requested delivery date or shipment date is
provided by IDOC E1EDP03, EDIFACT & ANSI X12 DTM segment.
IDoc E1EDP19 segment is used to give additional identification information for the product
specified in E1EDP01 segment. EDIFACT PIA segment is used for that purpose. This information
is contained in the ANSI X12 PO1 segment additionally with respective qualifier.
For giving the more free format text description of the product or item IDoc E1EDPT1/E1EDPT2
segment pair is used. In EDIFACT FTX/IMD segment is used for that purpose. In ANSI X12 PID
segment is used.
So on higher level we can see following structural relation between detail level segments
The trailer section of the message is important to give summary information like total number
of products/item specified in detail section, total quantity or total price. These summary
segments serves to check the integrity of the message.
IDoc uses E1EDS01 segment with different qualifiers for give summary information. EDIFACT
has UNS segment to indicate start of summary section. It contains CNT with different
qualifiers for giving various control total values. Similarly ANSI X12 has CTT segment for this
purpose. EDIFACT UNT, UNZ segment used for ending the message giving the total number of
segments in the message and total number of messages in the interchange respectively. ANSI
X12 SE, GE, IEA segments serves the same purpose.
So in general trailer section will look like as follows.

With the help of above example I tried to explain the structural resemblance between R/3 IDoc
and EDIFACT/ANSI X12 standard messages used by various business applications. In addition
to different segments mentioned above there are various different segments in IDoc; and we
can easily map it to its representative segment in EDI standard messages.

CHANGE POINTER IN ALE IDOC

ALE Change Pointers :
Applications which write change documents will also try to write change pointers for ALE
operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified field's data element.Flag can be set with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.

Dispatching ALE IDocs for Change Pointers: The actual distribution of documents from
change pointers must be done by an
ABAP, which reads the change pointers and processes them. The standard ABAP
for that is RBDMIDOC.

Creating Change Documents for Custom tables

By Mydhili Maddala, IBM India
Introduction
Business data objects are changed frequently. It is often useful to log these
changes for objects that are critical. SAP Systems log changes to business data
objects in change documents. For standard business process like creation of
Purchase Order, creation of material, creation of delivery etc SAP provides
certain change document objects. Similarly, to keep track of the changes in any
custom tables, we need to implement change document system.
SAP Interface
Idea conceived
This abstract talks about the concept of the change document object for custom
tables. SAP does not automatically keep track of the changes done to a custom
table data. We need to define it manually and activate it. The concept of change
documents should be implemented only if it is really important that you keep
track of changes made to the object.
Idea Implemented
In our project, we got a requirement of providing this change document feature for a view
cluster which consists of four tables grouped together logically. When ever a change is done
to any of these four tables, the changes must be logged.
To meet this requirement, we created a change document object for the view
cluster using the transaction SCDO. All the changes get stored in CDHDR and
CDPOS tables.
Steps to implement Change Document functionality
1. Define the change document object
2. Check in the Dictionary, whether the data elements of the fields, which are
to be logged, are flagged appropriately.
3. Generate the update.
4. Program the appropriate calls in your program.
To define a change document object, proceed as follows:
1. Go to Transaction SCDO.
2. Choose the menu option Create.
3. Enter a name for the change document object, which is to be created. It
can be any name starting with "Y" or "Z”.
4. Choose Continue. A new window for inputting the associated tables
appears.
5. Enter a descriptive short text for the change document object. Make the
required entries for each table whose changes are to be logged in the
change document for this change document object.
6. After inputting all relevant tables, choose Insert entries. The new entries
are copied into the display.
7. Save your entries and then click on Generate push button.
The generation creates INCLUDE objects, which contain general and specific
data definitions and the program logic for the update function module.
After defining a change document, to integrate the change document object in
our program, we need to follow the below steps.
1. Include the generated program parts in your program code with an
INCLUDE statement.
2. When application changes are made, complete the change-relevant fields
as appropriate.
3. To create the change document, call the object-specifically generated
update program with a PERFORM statement using the name defined in
include program.

Creating Change Documents for Custom tables (Step-by-

step procedure)
By Mydhili Maddala, IBM India
Define Change Document Object
1. Go to SCDO transaction and click Create.
2. Enter a name for the change document object, which is to be created. It
can be any name starting with "Y" or "Z".
3. Choose Continue. A new window for inputting the associated tables
appears.
Enter a descriptive short text for the change document object. Make the required
entries for each table whose changes are to be logged in the change document
for this change document
object.
4. After inputting all relevant tables, choose Insert entries. The new entries
are copied into the display.
5. Click on Generate update prgram push
button
After clicking that push button, will get a pop-up button like

Say Yes, we will get another pop-up window, asking for Function
group andprocessing type
5. Then you will get a screen showing us , what all objects will get created
when we cerate a change document object. Click Save , we will get another
screen saying that, all the objects are created.
7. Include the generated program parts in your program code with an INCLUDE
statement
8. Also call the object-specifically generated update program with a PERFORM
statement using the name defined in the include program.
9. Any changes in the corresponding tables get logged in CDHDR and CDPOS
tables.
Table : CDHDR table
 Table : CDPOS table

Serialization of Messages
Use
Serialization plays an important role in distributing interdependent objects, especially when
master data is being distributed.
IDocs can be created, sent and posted in a specified order by distributing message types serially.
Errors can then be avoided when processing inbound IDocs.
Features
Interdependent messages can be serially distributed in the following ways:
• Serialization by Object Type
• Serialization by Message Type
• Serialization at IDoc Level
(not for IDocs from generated BAPI-ALE interfaces)
Serialization by Object Type
Use
Serialized messages can be of different types (for example, create, change or
cancel messages). All messages here relate to one special application object.
The messages can contain both master data and transaction data.
With object serialization the messages of a given object are always processed in
the correct order on the receiver system. Messages are posted in the receiver
system in the same order they were created in the sender system.
Features
The message (IDoc) to be transferred is assigned a consecutive number. This is
managed in the sending and receiving system for each object type and object
channel. An object channel contains a number of ordered IDocs and is defined
by an object type (BOR) and precisely one channel number which is a message
attribute. All messages are processed in an object channel in the target system in
the same order they were sent from the source system. A channel number is a
message attribute. It is generated in the function module
ALE_SERIAL_KEY2CHANNEL or assigned in the application program.
This number identifies the following:
• RFC transmission error
• The application document of a message is not yet posted (status code 53),
although the next message has already been received
In both cases the IDoc is waiting in inbound processing for its predecessor IDoc
and is accordingly assigned status code 66. Once the predecessor IDoc has
been posted, you have to then post the IDoc with status 66 using program
RBDAPP01.
All messages with the same channel number and object type are serialized when
the messages are processed.
The current number of each object channel is recorded. This process is takes
place in what is known as the registry. There is an outbound registry and an
inbound registry. Serialization must be activated in both registries (see
prerequisites).
Outbound Processing (Source System)
When outbound IDocs are processed, for each object channel (field CHNUM) a
unique serial number is assigned to each IDoc created (field CHCOU). This
number and the object channel are transferred with the IDoc in the SERIAL field.
A unique serial number is assigned to each message for the application object in
question.
Inbound Processing (Target System)
When inbound IDocs are processed, a unique serial number is generated for
each object channel (field CHNUM) and communication link. The ALE layer
determines whether a given IDoc can now be posted or whether other IDocs
have to be posted first. The serial number for each received IDoc is exactly one
whole number lower. Any gaps in the sequence will mean that IDocs are missing,
either because the transfer did not work, or because earlier IDocs were not
posted successfully.
In this case the IDoc is assigned status 66 and must be posted again with the
program RBDAPP01.
Objects are assigned to messages and channels by the application.
Transfer errors (IDoc sequence mixed up) and inbound posting errors (IDoc
cannot be posted due to Customizing errors) no longer affect the sequential
order, because serialization corrects these errors.
Further Information
• Serialization by Object Type: Procedure

Serialization Using Object Types: Procedure

Follow the steps below to set up serialization using object types:

1. In the SAP menu choose → IDoc

Interface/ALE → Development → BAPI → Serialization → Serialization Using
Business Objects → Determine Supported Business Objects (transaction
BD105). Enter all the business object types relevant for serialization.
2. In the SAP menu choose → IDoc
Interface/ALE → Development → BAPI → Serialization → Serialization Using
Business Objects → Assign Message Type to a Business Object (transaction
BD104). Assign the message types relevant for serialization to each business
object type.
3. In Customizing (IMG) activate the serialized distribution in both the sending
and receiving systems:
ALE Implementation Guide (transaction SALE)
Modeling and Implementing Business Processes
Master Data Distribution
Serialization for Sending and Receiving Data
Serialization Using Business Objects
Execute activities Activate Outbound Business Objects and Activate Inbound Business
Objects. Set the Serialization flag for the required business object types.

Serialization by Message Type

Use
IDocs can be created, sent and posted in a specified order by distributing
message types serially.
Object interdependency is important at the message type level.

Consider a purchasing info record with a vendor and a material. To avoid any
processing errors, the vendor and material must be created in the receiving system
before the purchasing info record.
Prerequisites
You have to activate serialized distribution of message types in both systems in
ALE Customizing.
ALE IMG (transaction SALE)
Model and Implement Business Processes
 Configure Master Data Distribution
Set-Up Data for Sending and Receiving Serialization
Serialization by Message Type
Features
Serialized distribution is only used to transfer changes to master data. IDoc
message types are assigned to serialization groups according to the order
specified for their transfer. Master data is distributed in exactly the same order. If
all the IDocs belonging to the same serialization group are dispatched
successfully, the sending system sends a special control message to the
receiving system. This control message contains the order IDocs are to be
processed in and starts inbound processing in the receiving systems.
Serialized distribution of message types is not a completely new way of
distributing master data; it uses existing ALE distribution mechanisms whilst
adhering to a specified order of message type. This distribution could also be
carried out manually using existing ALE programs. However, serialized
distribution automates the single steps and can schedule them in a batch job.
In the serialization menu selection criteria determine how certain parts of the
serialized distribution will be processed, for example, control message dispatch
and inbound processing. This includes sending the control message and the
inbound processing of the IDoc.

Serialization at IDoc Level

Use
Delays in transferring IDocs may result in an IDoc containing data belonging to a
specific object arriving at its destination before an "older" IDoc that contains
different data belonging to the same object. Applications can use the ALE
Serialization API to specify the order IDocs of the same message type are
processed in and to prevent old IDocs from being posted if processing is
repeated.
SAP recommends that you regularly schedule program RBDSRCLR to clean up
table BDSER (old time stamp).
Prerequisites
IDocs generated by BAPI interfaces cannot be serialized at IDoc level because
the function module for inbound processing does not use the ALE Serialization
API.
Features
ALE provides two function modules to serialize IDocs which the posting function
module has to invoke:
• IDOC_SERIALIZATION_CHECK
checks the time stamps in the serialization field of the IDoc header.
• IDOC_SERIAL_POST
updates the serialization table.
Error Handling
Procedure
ALE error handling makes use of the SAP Business Workflow technology in the
SAP system. SAP Business Workflow organizes and manages a work process
whereby tasks are assigned to individual agents. After completing a task, agents
are informed of subsequent work items in their inbox.
SAP Business Workflow is object oriented; ALE error handling objects are IDocs
and their methods and events.

If there is an error, only the first message from the return parameter is
copied to the text in the associated work item.
Error Handling Process

Example

The example below of an inbound error for a material master message shows the
steps in ALE error handling:
 • • The inbound function module passes message to the
ALE layer that an error has occurred.
• • ALE triggers the object event "inputErrorOccurred" from
the IDCOMATMAS category.
• • This event is linked to standard task number 00007947,
long name "MATMAS_inbound error"
• • A work item appears in the user’s inbox, the work item’s
short text is the first fifty characters of the error message
contained in the IDoc’s status record.
• • When the user processes the work item, the
IDOCMATMAS method "IDOC.InputForeground" is processed.
IDoc status record is displayed and the user can display the error message's
long text. If the user was able to remedy the error, the IDoc can be submitted
for updating. If the error cannot be remedied, the user can flag the IDoc for
deletion.
• • If the IDoc was either successfully submitted or flagged
for deletion, IDOCMATMAS’s event "inputFinished" is triggered
indicating that the task has been carried out.

Further Information

• Objects, Events and Tasks To Be Created

• Object Types and Events
• Creating a Standard Task
• Maintaining Inbound Methods
• Checking Consistency of Inbound Error Handling

ransaction Codes:
SALE – IMG ALE Configuration root
WE20 – Manually maintain partner profiles
BD64 – Maintain customer distribution model
BD71 – Distribute customer distribution model
SM59 – Create RFC Destinations
BDM5 – Consistency check (Transaction scenarios)
BD82 – Generate Partner Profiles
BD61 – Activate Change Pointers – Globally
BD50 – Activate Change Pointer for Msg Type
BD52 – Activate change pointer per change.doc object
BD59 – Allocation object type -> IDOC type
BD56 – Maintain IDOC Segment Filters
BD53 – Reduction of Message Types
BD21 – Select Change Pointer
BD87 – Status Monitor for ALE Messages
BDM5 – Consistency check (Transaction scenarios)
BD62 – Define rules
BD79 – Maintain rules
BD55 – Defining settings for IDoc conversion
WEDI – ALE IDoc Administration
WE11 – Delete IDOC
WE19 – IDOC 处理的测试工具
WE21 – Ports in Idoc processing
WE63/WE60 – IDoc documentation(生成 parser、C 等描述，给外部程序用)
SARA – IDoc archiving (Object type IDOC)
WE47 – IDoc status maintenance
WE07 – IDoc statistics
BALE – ALE Distribution Administration
WE05 – IDoc overview
BD87 – Inbound IDoc reprocessing
BD88 – Outbound IDoc reprocessing
BDM2 – IDoc Trace
BDM7 – IDoc Audit Analysis
BD21 – Create IDocs from change pointers
SM58 – Schedule RFC Failures
Basic config for Distributed data:
BD64: Maintain a Distributed Model
BD82: Generate Partner Profile
BD64: Distribute the distribution Model
Programs:
RBDMIDOC – Creating IDoc Type from Change Pointers
RSEOUT00 – Process all selected IDocs (EDI)
RBDAPP01 – Inbound Processing of IDocs Ready for Transfer
RSARFCEX – Execute Calls Not Yet Executed
RBDMOIND – Status Conversion with Successful tRFC Execution
RBDMANIN – Start error handling for non-posted IDocs
RBDSTATE – Send Audit Confirmations