CTLBS.COM

Important IDoc Transaction 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
WE21 – Ports in Idoc processing
WE60 – IDoc documentation
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) -> WE14
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
For testing you can use WE19

To find out which version of the basic type is best suited to your SAP system’s
release level, ALE → ALE Development → IDoc → IDoc Type Development→ IDoc Type for Message (transaction WE82).

For an overview of all the message types, go to Tools → ALE → ALE Development → Logical Messages (transaction WE81).

You can create new model views in Customizing. To do this, in the IMG, go to SAP NetWeaver → SAP Web Application Server → IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model and Distribute Views or call the distribution model directly via transaction BD64.

For your ALE scenarios, you create RFC destinations for all the partner systems in each system involved. To do this, select in the ALE Customizing IDoc Interface / Application Link Enabling (ALE) → Communication → Create RFC Connections or use transaction SM59.

Hint: If you give the RFC destination the same name as the logical target system, you can have the system carry out certain settings automatically later on.

In order to use ALE scenarios later on, the RFC must be assigned to a port. The sender uses the port to determine the communication channel to the recipient. You can create ports manually or – if the logical target system and the RFC destination have the same name – have the sender system create them.

Note: There are different types of port in SAP systems. ALE always uses RFC ports. In EDI scenarios, you can also use file ports in addition to RFC ports.

In the SAP system, you can set tRFC parameters for the relevant connection in table RFCDES (for connection types T, 3, I) (SM59):
• Suppress batch job in the event of communication errors (manual start with transaction SM58 required)
• Number of connection attempts
• Interval in minutes between repeated attempts to transfer data

For a model view to be distributed to all the partner systems, the sender system must contain outbound partner profiles for message type SYNCH for all the affected recipient systems. This message type is used only for determining the RFC destination for the target system. If the name of the logical target system and its RFC destination are the same, the sender system can automatically create a port with the appropriate RFC destination and generate the partner profiles for the message types of a model view. The authorization object for distributing model views is B_ALE_MODL.

IDOCS

For an overview of the segment structure of a basic type, see transaction WE30 (IDoc Type Development).

The structure of the basic types provided by SAP is documented in detail in SAP R/3 and mySAP ERM. To call this documentation, go to Tools → ALE → ALE Administration → Services → Documentation → IDoc Types and Segments or call transaction WE60.

The line type of the internal table is determined by the ABAP Dictionary structure type EDIDD.

•Regardless of how the IDoc was created, it is first saved to the sender system’s database (status value 01).
• If all the information required for sending has been obtained from the recipient, then the IDoc receives the status “ready for dispatch” (status value 30).
• If the outbound partner profiles specify that the IDoc is to be transferred immediately to the port stored in the relevant message type, then the IDoc is sent and receives a corresponding status (status value 03). However, it is also possible to send multiple IDocs bundled together at a later time.
• The IDoc is saved to the target system’s database (status value 50).
• If all information about further processing is known, the IDoc can be transferred to the application (status value 64).
• If the inbound partner profiles specify that the IDoc is to be transferred to the application immediately, the target system attempts to post the IDoc data (status value 62). If the inbound processing is successful, the IDoc receives status value 53.

All the Customizing settings you need for cross-system Customizing comparison and subsequent synchronization can be found with transaction SALE. In the menu, select IDoc Interface/Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Synchronization of Customizing Data.
You can call the relevant application transactions in SAP Easy Access via Tools → ALE → ALE Administration → Services → Customizing Data. Here you will find a program for matching Customizing tables in the sending and target systems, known as the “Customizing Cross-System Viewer” (transaction SCU0), and transaction for generating and further processing ALE transport requests for Customizing synchronization. The sending system creates IDocs of message type CONDA2 for the transport requests: these IDocs contain the core information about each request. Inbound processing of these IDocs controls the importing of request data in the target system: either a workflow is sent to the responsible
administrator requesting him or her to carry out the import, or the import is carried out automatically by a program executed in the background.

Synchronizing Customizing Settings with the SAP Solution Manager

There are standard ALE scenarios for distributing master data; these are documented in the SAP Library and in the IMG. You can use transaction SALE to find descriptions of how to set up certain master data distribution scenarios.

First, use this information to create a new view in the distribution model of one of the system’s involved. BD64

If RFC destinations already exist with the same names as the logical target systems, you can now have the system create the outbound partner profiles for the new model view. When it generates partner profiles, the system automatically creates an entry for the message type MATMAS and also an entry for message type SYNCH for each profile (ALE:Dummy Message Type for Determination of RFC Destinations). This message type is not used for generating IDocs: it is only used for determining the RFC destination of the relevant target system. The entry for message type SYNCH is a prerequisite for distributing model views.

Note: If your RFC destinations have different names to the target systems to which they lead, you need to first create the entry for message type SYNCH manually and then assign the RFC destination you require using the relevant port. After you have done this, you can have the system generate the remaining partner profiles.

Partners of the type “logical system” (LS) are always created for ALE scenarios.
The name of the partner is always the same as the logical system name.

In the outbound partner profile for a message type, store the following information:
• Receiver port: in ALE scenarios, the sending and target systems exchange data via RFC. You therefore need to use a port of the type “transactional RFC” in the outbound partner profiles for ALE scenarios; the RFC destination of this RFC leads to the target system, the partner in the profiles.
• Output mode: You can choose between Transfer IDoc Immed. and Collect IDocs.
• Package size: If you choose Transfer IDoc Immed., the IDocs are sent individually. If you choose Collect IDocs, multiple IDocs are collected in packages and sent together. Collecting IDocs to send together can improve performance. As a guideline, we recommended collecting between 20 and 100, depending on the size of the IDocs.
• Basic type: in this field, you need to enter the IDoc type that is compatible with the target system’s release level.
Note: If you select the Collect IDocs output mode, you need to execute the RSEOUT00 program to transfer the IDocs to the communication
layer. This program is usually scheduled as a periodic background job.
After you have created the outbound partner profiles for the target systems, you can distribute the new model view to these systems.

In the inbound partner profile for a message type, store the following information:
• Process code: the process code is a key that refers either to a function module or a workflow for processing the IDocs. The process code for message type MATMAS is MATM. If you double-click on the process code key, a screen appears containing the information as to which function module or which workflow is used for inbound IDoc processing. As a rule, function modules are used in ALE scenarios.
Note: There can be more than one process code for a message type (and, accordingly, more than one inbound function module
or workflow). For information about which process codes are assigned to which message types, see the Inbound process code
table (transaction WE42).
• Processing mode: you can choose between Trigger by background program and Trigger immediately. If you choose Trigger by background program, the IDocs are transferred to the ALE layer using the RBDAPP01 program. This program is usually scheduled as a periodic background job.
Figure 41: Processing Times You can define variants for the RSEOUT00 and RBDAP001 programs for collective background IDoc processing. You can find both programs in the IMG via transaction SALE, by going to IDoc Interface / Application Link Enabling (ALE) → System Monitoring → IDoc Processing → Dispatch Collected IDocs or Update IDocs in Receiver System.

You can check the current status of IDocs in SAP R/3 or mySAP ERM by using a status monitor. You can call this monitor with transaction BD87 or the menu path Tools → ALE → ALE Administration → Monitoring → IDoc Display → Status Monitor.

Sending and Requesting Master Data
The “Share Master Data” tool offers you a variety of application transactions for generating IDocs for distributing master data. You can find these transactions via menu path Tools → ALE → Master Data Distribution. You can also call all of the SMD transactions directly using transaction BALM.

You can send material masters directly using transaction BD10
In ALE scenarios, master data is normally sent from the maintenance system to the downstream systems. However, with cross-application master data (material, customer, vendor), it is also possible to retrieve data. Message type MATFET, for example, is used for fetching material masters. This message type is linked to the corresponding views in the distribution model (see figure). In the application menu, you can find transaction BD11 via Tools → ALE → Master Data Distribution → Cross-Application → Material → Get; the target system can use this transaction to request material masters from the sending system. Message type MATMAS is used for sending the material master IDocs.

CHANGE POINTERS
Note: To view the change documents, use the report RSSCD100. You can also call the change documents from the application transaction
in question. To view the change pointers, see the database table view BDCPV

You can evaluate change pointers by using the program RBDMIDOC. This program is usually scheduled as a periodic background job. You can start the program for testing purposes with transaction BD21

You can display the
assignment of message type and function module for evaluating the the change pointer with transaction BD60

Data Filtering and Reducing the Scope of Data

If you would like to use segment filtering in an ALE scenario, you should first check the structure of the basic type you are going to use to determine the keys for the segments you would like to delete. If, for example, you want the sales area data for the customer masters (basic type DEBMAS0x) to be created in the sales branch system, you can use segment filtering to delete segment group E1KNVVM (Master stomer master sales data) from all communications IDocs for message type DEBMAS and recipient “Sales”. The customer masters are then distributed
to sales without the sales area data.

You can set up segment filtering in the IMG with transaction SALE, via IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes→Master Data Distribution→Scope of Data for Distribution → Filter IDoc Segments.

Filter Objects
If you work with filter objects in ALE scenarios, you have to define conditions that need to be fulfilled for specific application data to be included in a communications IDoc. If the filter object corresponds to a required segment of the basic type in question, then a communications IDoc is only created if the condition is fulfilled.
In the example illustrated below, material masters (message type MATMAS) are distributed at regular intervals from the head office to sales and distribution and production. However, sales and distribution is only supposed to receive material masters for finished products whereas production requires the master records for the finished parts and the raw materials.

Note: Customers can enhance the list of filter objects provided by SAP with their own filter objects. The tables required for this can be found in the application menu along the path Tools → ALE → ALE Development → IDoc → Data Filtering.

Classification
If you would like to use classification as a filter method in an ALE scenario, you first need to carry out some basic settings in the class system itself. You need to mark one class type as the “distribution class type” and create at least one class for grouping your data in this class type. Then you can add the ALE-specific settings. You can activate the use of classification in an ALE scenario in the filter
object area of a model view (see above

Reduced Message Types
Some applications have such flexible programs for inbound and outbound processing that you can choose whether or not each optional segment field is to be transferred. To do this, you create what is known as a reduced message type in the customer namespace as a copy of a message type supplied by SAP; then you select the fields whose content you want to be transferred to a particular target system.