Creation of BOR objects, Start and Stop eventsGo 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 buttonRelease 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 codeGo 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 WE42Go 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 purposeIn 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 ALEoperations. These are log entries to remember all modified data records relevant for ALE.Most applications write change documents. These are primarily log entries in thetables CDHDR and CDPOS.Change documents remember the modified fields made to the database by anapplication. They also remember the user name and the time when the modificationtook place.The decision whether a field modification is relevant for a change document istriggered by a flag of the modified field's data element.Flag can be set  withSE11 by modifying the data element.For the purpose of distributing data via ALE to other systems, you may want tochoose other fields, which shall be regarded relevant for triggering a distribution.Therefore R/3 introduced the concept of change pointers, which are nothing elsethan a second log file specially designed for writing the change pointers which aremeant to trigger IDoc distribution via ALE.So the change pointers will remember the key of the document every time when arelevant field has changed.Change pointers are then evaluated by an ABAP which calls the IDoc creation, forevery 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 anABAP, which reads the change pointers and processes them. The standard ABAPfor that is RBDMIDOC.

Creating Change Documents for Custom tablesBy 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 object2. 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 IndiaDefine 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 statement8. 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  UseSerialization 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.

FeaturesInterdependent 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  UseSerialized 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.              FeaturesThe 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 receivedIn 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 ProcessesMaster Data DistributionSerialization for Sending and Receiving Data  Serialization Using Business ObjectsExecute activities Activate Outbound Business Objects and Activate Inbound Business Objects. Set the Serialization flag for the required business object types.

Serialization by Message Type  UseIDocs 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.

PrerequisitesYou 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

FeaturesSerialized 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  UseDelays 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).PrerequisitesIDocs generated by BAPI interfaces cannot be serialized at IDoc level because the function module for inbound processing does not use the ALE Serialization API.FeaturesALE provides two function modules to serialize IDocs which the posting function module has to invoke:

        IDOC_SERIALIZATION_CHECKchecks the time stamps in the serialization field of the IDoc header.

        IDOC_SERIAL_POSTupdates the serialization table.

Error Handling   

ProcedureALE 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