Need Answer on ALE Service Layer

In my cusomized outbound program i am using a function module MASTER_IDOC_DISTRUBUTE to generate the IDOCS. I am passing the both sender and reciever values to the function module MASTER_IDOC_DISTRUBUTE then distribution model in BD64 is not required. if we are not passing the both sernder and reciever to the MASTER_IDOC_DISTRUBUTE, the MASTER_IDOC_DISTRUBUTE will pick both the sender and reciever from the ALE Distribution model (ALE Service Layer) . What my doubt if i pass both sender and reciver need it won't execute distribution model in the BD64. In this situation If i need a filters and converstion for the recievers then i should use the diribution model. In this situaion if i pass both sender and reciever to the MASTER_IDOC_DISTRUBUTE does the ALE Service Layer ( Conversions & Filtters ) will execue?

Hi,
>>>>But I don't know how to achieve this. I guess using Distribute Model,
yes of course
>>>> If so, a client for edi subsystem(non-sap system) need be defined in SAP R3 system. I doubt about this.
yes a logical system for example
>>>>Another problem is how to define a client for non-sap system in SAP R3 sytem.
logical system
Regards,
michal
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions">XI / PI FAQ - Frequently Asked Questions</a>

Similar Messages

Ale Service Layer error 29

Hi All,
Plz help me in this issue, I had made the Ale connection to transfer Data, once I had done it successfully, after that I had deleted and made again, this time I am able to transfer the data, in both the clients it is showing traffic light green, however in the target client after two seconds it is converted in Red with "error in ALE service layer 29, unable to find recipient "MATFET", last time I had given MATMAS, since I am getting this error I had added MATFET also, still I am getting this error.
In Patner profile : Inbound client( Sender): MATMAS, SYNCH
In Patner profile : Outbound client( Reciver): SYNCH
In Patner profile : Inbound client( Reciver): MATMAS
Every thing is in green, no errors, in profiles and distribution model, everything is successfully created except this Traffic light and error in the receiving client.

Hi All,
According to the suggestion I drilled down the issue in BD87 and found this information.
Could not determine recipients for message type &
Message no. B1003
Diagnosis
An IDoc of message type MATFET was passed to the ALE layer, but the three receiver fields in the header record were not filled. In this case the ALE layer tries to determine the receivers from the entries in the distribution model. There are no entries available in the distribution model for the above message type.
Procedure
Define the receivers in your distribution model for this message type or deactivate distribution for these message types.
One more thing In BD87 if I go to sender client then there is node for sender system and in the receiving client there is node for receiving system, is this correct ? or both the systems should be reflected in both the systems?

ALE service layer

Hi,
Can any boby tell me what the ALE service layer do in ALE.

Hi,
This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems.
Processing in the ALE layer consists of the following steps.
Receiver determination. If the receivers are not known, they are determined from the customer distribution model. If a receiver is not found, processing ends. For each receiver identified in this step,
the following steps are executed.
1)IDoc filtering. If an IDoc filter is specified in the distribution model for a receiver, values in the filter are compared against the values in the IDoc data records. If a data record does not
meet the filter criteria, it is dropped.
2)Segment filtering. For each sender and receiver combination, a set of segments that are not required can be filtered out.
3)Field conversion. Field values in data records are converted by using the conversion rules specified for the segment. Values can be converted to global values or converted to specific values for the receiver. For example, storage location 0001 can correspond to storage location 1000 in the receiving system. The rules specified here are also available in the EIS (Executive Information System) module.
4)Version change for segments. Segments are version−controlled. A new version of a segment always contains fields from the preceding version and fields added for the new version. Thus, the segment can communicate with a back−level system by blanking out the new fields. Read
the version specified in the Seg. Release in IDoc Type field of the partner profile to determine the version of the segment to be generated.
5)Version change for IDocs. IDocs, like the segments, are also version−controlled. A new version of an IDoc always contains segments of the preceding version and segments added in the new version. Thus, the IDoc can communicate with a back−level system by deleting segments that do not exist in the version specified. The version is determined from the Basic Type field of the partner profile.
6)Communication IDocs generated. The final IDoc generated for a receiver after all the conversions and filtering operations is the communication IDoc. One master IDoc can have
multiple communication IDocs, depending on the number of receivers identified and the filter operations performed. Communication IDocs are saved in the SAP database. At this point, a tangible IDoc that can be viewed by using monitoring tools has been created in the system.
The IDoc gets a status record with a status code of 01 (IDoc Created).
7)Syntax check performed. The IDoc goes through a syntax check and data integrity validation. If errors are found, the IDoc gets a status code of 26 (Error during Syntax Check
of IDocOutbound); if no errors are found, the IDoc gets a status code of 30 (IDoc Ready for DispatchALE Service).
8)IDocs dispatched to the communication layer. In the ALE process, IDocs are dispatched using the asynchronous RFC method, which means that the sending system does not wait for data to be received or processed on the destination system. You read the setting in the Output
Mode field of the partner profile to determine the timing of the dispatch. If the mode is set to Transfer IDoc Immed., IDocs are immediately transferred to the communication layer; if not,
they are buffered until the next run of dispatch program RSEOUT00. After IDocs have been transferred to the communication layer, they get a status code of 03 (Data Passed to Port OK). This status does not necessarily mean that IDocs have been dispatched to the destination
system.

Status 29:error in ale service layer

i have written a stand-alone program in ale to transfer materials to inbound system.idoc got genereated but i am getting staus record as 29...
what to do if i get an status 29:error in ale service layer

Hi Pavan ,
Goto to transaction WE05 put the Idoc Number generated or enter the message type .Under the Status 29 there would be error description .
Check that out .

Hi need help in ALE service !

If i want to create the Ale service for only one client which will act as both server and receiver then what r the steps ?

The code works for me.
Put a e.printStackTrace(); inside the catch block to see what exceptions are thrown (if the code isn't working then ignoring exceptions is the worst thing you could do when trying to find out what's wrong):    } catch (IOException e) {
        e.printStackTrace();
    }- Marcus

Design - service layer

Example model:
Manager - > Employee - > Result
Manager has a list of employees . Employee has a list of results. Each entity is " heavy " entity.
I need to create a service layer for getting objects from my module.
this service layer will used by other modules in the product.
The issue that i want to get an ideas and reference is how to define the interface.
How do i define what to fetch with the object? Do you have specific API for fetching different objects graph.
For example:
getManager
getManagerWithEmployes
getManagerWithEmployesAndResults
Thank you

AvihaiMar wrote:
Example model:
Manager - > Employee - > Result
Manager has a list of employees . Employee has a list of results. Each entity is " heavy " entity.So the above are your business domain.
>
I need to create a service layer for getting objects from my module.
this service layer will used by other modules in the product.
The issue that i want to get an ideas and reference is how to define the interface.
How do i define what to fetch with the object? Do you have specific API for fetching different objects graph.
For example:
getManager
getManagerWithEmployes
getManagerWithEmployesAndResults
It depends on the business requirement or the uses cases ( senarios ); for example if an actor is interacting with the system, the actor wants to view all current managers who has less then 5 employee or how has employee with salary above 100 etc..
or another senario which is an actor want to generate reports which shows all managers with there employee; then the actor go further to look into details for each employee( salary, age, gender)
so there is on specific api but rather you start to build your api based on uses cases i.e senarios ( write them down) so start with some rough senarios and
then move into defining your business service interfaces then try to implement the interfaces.
After a while, you discover that you need different senarios ( business requirement changes), then you go back and do the same as above ( iteration ) senarios, interfaces then implementation
Hope this make sense to you
Regards,
Alan Mehio
Lodon, UK

Need help in ALE configuaration !

Please send me an example of how to create an ALE configuaration with in one client !

HI,
What is ALE?
ALE stands for Application Link Enabling and is a remote connection technology allowing the decentralization of business processes by connecting decentralized systems together.
Using ALE, it is fairly easy to synchronize several SAP systems so that they contain the same data objects at anytime. These objects may be master data (customers, vendors, GL accounts, cost centers, ...) or transaction data (FI documents, purchase orders, ...). To enable the synchronization, ALE supports not only mass transfer of data between systems but also selective data transfers of objects changed since the last transfer.
How does it work?
Viewed from a high level perspective, the process is straight and simple: a sender system selects the data that needs to be distributed, packs it in a standard format and sends it to one or several receiving systems. When a receiving system gets the data, it unpacks the standard format and records the data.
In fact, 3 layers are involved in this process:
An application layer which selects and records data in R/3.
A distribution layer which filters and converts data.
A communication layer which ensures the actual communication of records generated in a standard format.
The senders and receivers are determined thanks to a so-called distribution model which defines the transfer rules (who sends what to who?). The definition of the distribution model must be known by all systems involved (either as sender or receiver) and must consequently exist on all those systems.
The Intermediate Document (IDoc)
The data transferred using ALE must have a SAP standard format to be understood from all partners in the communication. This format is the Intermediate Document (IDoc) which represents an intermediary structure between raw SAP data and EDI formats. This structure is not constant, it depends on the data to be transferred and SAP provides the structures for most SAP standard objects such as customers master data, sales orders, ...
An IDoc with a specific structure is said to have a specific type. The IDoc type is nothing more than a version of a specific IDoc structure designed to contain data for a specific object type. For example, the IDoc type DEBMAS05 is the fifth version of a structure that represents a customer master data. The management of versions for IDocs structures is necessary because the objects evolve with time and tend to become more and more complex with new data fields or tables being added regularly.
The conversion of raw data forth (for the sender system) and back (for the receiver system) to the IDoc format is also ensured by SAP standard function modules as long as you transfer standard objects. For non standard objects (enhancements), you must define your own IDoc structure and write your own conversion function modules.
RFC connections
The data communication between the SAP servers may be done by several ways. The 2 most common ways are the transactional RFC and the file. The RFC connection is used to make a direct connection between servers while the file interface speaks for itself, it uses a file containing the IDocs from the sender system as input in the receiver(s) system(s).
The selection of a communication method is made though the ports configuration as we will see in the next section. For the purpose of this article, we are going to choose the most efficient method: the transactional RFC method. To set it up, we first need to define the RFC destinations of the partner systems.
An RFC destination may be seen as a set of settings necessary to connect to a system using the RFC protocol. These settings include the address and type of the partner system along with connection information such as the user ID and password to use.
The RFC destinations of all partners systems must be defined on all systems to include in the distribution model. The transaction to use for this purpose is SM59.
Definition of the communication ports
The communication ports determine the type of data communication that must occur between systems. When the communication is to use the RFC protocol, transactional RFC ports must be created specifying the RFC destinations of the partner systems. Use transaction WE21 for this purpose.
Partners profiles
In SAP, all partners systems involved in a distribution model have a profile. There exist several profile types such as customers profiles, vendors profiles, ... but this distinction between profiles is generally not necessary and you will create in most cases your partners profiles using a generic Logical System type.
Before entering the settings of the logical systems partners, you have to create them in customizing. Also, each system in the distribution model must be assigned in its own system its own logical system that represents it. This assignment is done at client level and not at system level. This is not easy to explain nor to understand so let's take a simple example. Let's consider we have a simple distribution model made up of a sender system (S01) and a receiver system (R01). We need to transfer data from S01 / client 100 to R01 / client 200. In both the systems, we will define the logical systems S01_100 and R01_200. But in sender system S01, the logical system S01_100 will be assigned to the client 100 while in the receiver system R01, it will be R01_200 that will be assigned to client 200. With such a configuration you see it is even possible to transfer data between two clients from the same system.
A partner profile is used to determine a lot of important settings that will be involved in the data transfer. These settings vary depending on the role of the partner system (sender / receiver) and are defined per message type. A message type is more or less a version independent IDoc type. It is mainly a convenient way of defining settings and identifying IDocs using a criterium independent of the partner system.
For a sender partner system (inbound parameters are filled in), following important settings are set per message type in the partner profile:
A process code used to indicate which function module will be used to convert the IDoc data to SAP data.
The time of input of the IDoc: as soon as the IDoc is created in the system or on request (using program RBDAPP01).
The post processing agent who will have to treat the data input errors if need be. The post processing agent may be either a user or any other HR organizational unit.
For a receiver partner system (outbound parameters are filled in), following settings are specified in the partner profile:
The receiver port to which the data will be sent.
The sending method: one IDoc at a time or by packets.
The IDoc type that will be sent to that partner. For a given message type, the IDoc type sent may vary depending on the receiver system. Indeed you may have different versions of SAP in your system landscape.
Definition of the distribution model and data filtering
We have already seen that the distribution model is used to decide who sends what to who. But, as you guessed, there is a little bit more to be said about it and the way to manage it.
The distribution model is maintained in a central transaction (BD64) which lets you access the most useful environmental settings necessary to set up the model. Before creating the model, you must first decide on which system you are going to create it. Indeed the model must exist in all partners systems and two possibilities exist to achieve this.
Either you create the model on each system manually (with the same model technical name), which is feasible only with few systems and/or simple models. Either you create it in a specific system (usually the source system) and distribute it to the other systems thanks to the distribution command in the BD64 transaction menu.
If we want to copy the customers master data from the production system to the other systems in the maintenance line for example, we may create the distribution model on the production system and distribute it to all partners systems.
The actual creation of the model requests that you mention a technical name for the model (unique identifier in the systems landscape), a sender system, a receiver system and message types to exchange between those systems. You may afterwards add more sending and receiving systems in the model as well as more message types.
For each message type defined between a sender and a receiver, you may set filters on specific fields of the message type so that IDocs be generated only when these specific values are matched. For example, you may decide to send only customers of a specific account group. These filters are set by selecting the 'no filter set' text under message types in BD64.
There exists also another kind of filters which are segments filters. They do not filter IDocs creation based on values like we have just seen but filter unconditionally segments of created IDocs which must be excluded from the transfer (transaction BD56).
This article will help you understand the basics of ALE and IDocs via a simple do-it-yourself example. We will create a custom IDoc in one SAP system and then post some business data through it to another SAP system. Business data will be picked up from custom data dictionary tables.
ALE Application Link Enabling is a mechanism by which SAP systems communicate with each other and with non-SAP EDI subsystems. Thus it helps integration of distributed systems. It supports fail-safe delivery which implies that sender system does not have to worry about message not reaching the source due to unavoidable situations. ALE can be used for migration and maintenance of master data as well as for exchanging transactional data.
The messages that are exchanged are in the form of IDocs or Intermediate Documents. IDocs act like a container or envelope for the application data. An IDOC is created as a result of execution of an Outbound ALE. In an Inbound ALE an IDOC serves as an input to create application document. In the SAP system IDocs are stored in the database tables. They can be used for SAP to SAP and SAP to non-SAP process communication as long as the participating processes can understand the syntax and semantics of the data. Complete documentation on IDOC is obtained by using transaction WE60.
Every IDoc has exactly one control record along with a number of data records and status records. Control record has the details of sender/receiver and other control information. Data records contain the actual business data to be exchanged while the status records are attached to IDoc throughout the process as the IDoc moves from one step to other.
Now, let us understand the ALE Configuration by means of an example scenario below:
The Scenario
Data from custom tables (created in customer namespace) is to be formatted into an IDoc and sent from one SAP R/3 system to another using ALE service. We need to have two instances of SAP R/3 systems or we can simulate this on two clients of the same SAP R/3 system.
Create three tables as shown below.
Creating Custom IDoc type and Message type
All the objects created should be present on both source as well as target system(s).
1. Create segments Transaction WE31
Create a segment ZRZSEG1
Add all fields of table ZCUSTOMERS to it
Save the segment
Release it using the menu path Edit -> Set Release
Similarly create two more segments given below
Seg. ZRZSEG2 to hold all fields of table ZSOHEADERS
Seg. ZRZSEG3 to hold all fields of table ZSOITEMS
2. Create Basic IDoc type Transaction WE30
Create a Basic type ZRZORDER
Add the created segments in the hierarchy shown
Maintain attributes for each of the segments
Save the object and go back
Release the object using the menu path Edit -> Set Release
3. Create/Assign Message type Transactions WE81/WE82
Go to WE81
Create a new Message type ZRZSO_MT
Save the object
Go to WE82 and create new entry
Assign the message type ZRZSO_MT to the basic type ZRZORDER
Also specify the Release Version
Save the object
Thus we have defined the IDoc structure which will hold the data to be transferred. In the [1] next part of the article we will understand the outbound settings, i.e. the settings to be done in the source system.
Outbound Settings
Define Logical Systems and Assign Client to Logical System Transaction SALE
Go to Define Logical System (See the figure)
Define a new logical system to identify the local system and save it
Now, go to Assign Client to Logical System (See the figure)
Add a new entry
Specify the client, previously created logical system and other attributes
Save the entry
Define a new logical system to identify the partner system and save it
Maintain RFC Destinations Transaction SM59
Create a new RFC destination for R/3 type connection
Specify the target host on Technical settings tab
Provide the Logon credentials on the Logon/Security tab
Save the settings
To verify the settings, Click on Test connection or Remote logon
Define Ports Transaction WE21
We need to define a tRFC port for the partner system
Click on Transactional RFC node
Create a new port
Provide a description
Specify the name of the target RFC destination
Save the object
Maintain Distribution Model Transaction BD64
Click on Change
Create a new model view
Provide a Short text and Technical name to the model view
Add message type
Specify sender and receiver systems
Also, specify the message type that we created previously
Save the Distribution model
Generate/Create Partner Profile Transactions BD82/WE20
To generate Partner profiles automatically you may use BD82 or go to BD64 and use the menu path Environment -> Generate partner profiles
Otherwise, you may use transaction WE20 to create a partner profile
On selection screen, specify the model view, target system and execute
The result log will be displayed on the next screen
To verify the partner profile go to WE20
Check the partner profile for the target system
Distribute Model View Transaction BD64
Select the Model View
Go to menu path Edit -> Model View -> Distribute
Result log will be displayed on the next screen
Outbound IDoc Generation Program
Create an executable program ZRZ_ORDER_IDOC in SE38. Below, I have described the program logic:
Fetch the data from the DDic tables ZCUSTOMERS, ZSOHEADERS and ZSOITEMS as per the selection criteria
Fill the control record structure of type EDIDC
Specify message type, Basic IDoc type, tRFC Port, Partner number and Partner type of the receiver
Fill the data records
Define structures like the IDoc segments
Fill the structures with fetched data
Pass the segment name and the above structure to the appropriate fields of EDIDD type structure
Append the EDIDD structure to the EDIDD type internal table
Now, call the function module MASTER_IDOC_DISTRIBUTE and pass the IDoc control record structure and data record table
Commit work if return code is zero
Function module returns a table of type EDIDC to provide the details about generated IDoc
Display appropriate log
You can [2] download sample code for the above program here.
Thus we have completed sender side configuration required for ALE. In the [3] next part we will see how to configure the receiving system to be able to receive and post the inbound IDoc.
Inbound IDoc Posting Function Module
In the receiving system, create a function module Z_IDOC_INPUT_ZRZSO_MT using SE37. Below, I have described the logic for the same.
Add Include MBDCONWF. This include contains predefined ALE constants.
Loop at EDIDC table
Check if the message type is ZRZORDER. Otherwise raise WRONG_FUNCTION_CALLED exception
Loop at EDIDD table
Append data from the segments to appropriate internal tables
For example: append data from ZRZSEG1 segment to the internal table of type ZCUSTOMERS
Update the DDic tables from internal tables
Depending on the result of the update, fill the IDoc status record (type BDIDOCSTAT) and append it to the corresponding table.
Status 53 => Success
Status 51 => Error
You can [3] download the sample ABAP code for the above function module here.
Inbound Settings
Define Logical Systems Transaction SALE (Please refer to Outbound Settings discussed in [4] previous part)
Assign Client to Logical System Transaction SALE (Please refer to Outbound Settings discussed in [5] previous part)
Maintain RFC Destinations Transaction SM59 (Please refer to Outbound Settings discussed in [6] previous part)
Define Ports Transaction WE21 (Please refer to Outbound Settings discussed in [7] previous part)
Generate/Create Partner Profile Transactions BD82/WE20 (Please refer to Outbound Settings discussed in [8] previous part)
Assign Function Module to Logical message Transaction WE57
Create a new entry
Specify name of the Function Module as Z_IDOC_INPUT_ZRZSO_MT
Also, specify Type as F, Basic IDoc type as ZRZORDER, Message type as ZRZSO_MT and Direction as 2 (Inbound)
Save the entry
Define Input method for Inbound Function Module Transaction BD51
Create a new entry
Provide Function Module name as Z_IDOC_INPUT_ZRZSO_MT
Specify the Input method as 2
Save the entry
Create a Process Code Transaction WE42
Create a new Process Code ZPCRZ
Select Processing with ALE Service
Choose Processing type as Processing by function module
Save the entry
On the next screen, select your function module from the list
Save the changes
Now you will be taken to the next screen
Double-click on Logical message
In the Assignment to logical message, specify the message type ZRZSO_MT
Save the changes
Send and receive data
On the sender system, execute the IDoc Generation Program. Check the status of IDoc using transaction WE02.
Check the status of the IDoc in the receiver system using transaction WE02. You can also check the contents of DDic tables to make sure that the records have been created in the receiver system.
Thus to summarize we have learned how to:
*& Report ZRZ_ORDER_IDOC *
REPORT ZRZ_ORDER_IDOC .
PURPOSE OF REPORT *
Generats an Idoc for Customer Master, Sales Master
and Sales item table.
TABLES : ZCUSTOMERS, "Cutomer Header
 ZSOHEADERS, "Sales Header
 ZSOITEMS. "Sales Items
DATA : S_CTRL_REC LIKE EDIDC, "Idoc Control Record
 S_ZRZSEG1 LIKE ZRZSEG1, "CUSTOMER Header Data
 S_ZRZSEG2 LIKE ZRZSEG2, "SALES HEADER Data
 S_ZRZSEG3 LIKE ZRZSEG3. "SALES Detail Data
DATA : T_ZCUSTOMERS LIKE ZCUSTOMERS OCCURS 0 WITH HEADER LINE.
DATA : T_ZSOHEADERS LIKE ZSOHEADERS OCCURS 0 WITH HEADER LINE.
DATA : T_ZSOITEMS LIKE ZSOITEMS OCCURS 0 WITH HEADER LINE.
DATA : T_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE."Data Records
DATA : T_COMM_IDOC LIKE EDIDC OCCURS 0 WITH HEADER LINE.
"Generated Communication IDOc
CONSTANTS :
C_ZRZSEG1 LIKE EDIDD-SEGNAM VALUE 'ZRZSEG1',
C_ZRZSEG2 LIKE EDIDD-SEGNAM VALUE 'ZRZSEG2',
C_ZRZSEG3 LIKE EDIDD-SEGNAM VALUE 'ZRZSEG3'.
CONSTANTS: C_IDOCTP LIKE EDIDC-IDOCTP VALUE 'ZRZORDER'.
Selection Screen
SELECT-OPTIONS : S_KUNNR FOR ZCUSTOMERS-KUNNR OBLIGATORY,
 S_VBELN FOR ZSOHEADERS-VBELN.
PARAMETERS : C_MESTYP LIKE EDIDC-MESTYP DEFAULT 'ZRZSO_MT',
 "Message Type
 C_RCVPRT LIKE EDIDC-RCVPRT DEFAULT 'LS',
 "Partner type of receiver
 C_LOGSYS LIKE EDIDC-RCVPRN DEFAULT 'Y901',
 C_RCVPOR LIKE EDIDC-RCVPOR DEFAULT 'A000000226',
 C_SNDPRN LIKE EDIDC-SNDPRN DEFAULT 'LSSENDS',
 C_SNDPRT LIKE EDIDC-SNDPRT DEFAULT 'LS'.
"Destination System
***START-OF-SELECTION
START-OF-SELECTION.
PERFORM GENERATE_DATA_RECORDS.
PERFORM GENERATE_CONTROL_RECORD.
PERFORM SEND_IDOC.
*& Form generate_data_records
FORM GENERATE_DATA_RECORDS .
PERFORM FETCH_ZCUSTOMERS.
PERFORM FETCH_ZSOHEADERS.
PERFORM FETCH_ZSOITEMS.
PERFORM ARRANGE_DATA_RECORDS.
ENDFORM. " generate_data_records
*& Form fetch_zcustomers
FORM FETCH_ZCUSTOMERS.
SELECT *
FROM ZCUSTOMERS
INTO TABLE T_ZCUSTOMERS
WHERE KUNNR IN S_KUNNR.
IF SY-SUBRC NE 0.
 MESSAGE E398(00) WITH 'No Customers Found'.
ENDIF.
ENDFORM. " fetch_zcustomers
*& Form fetch_zsoheaders
FORM FETCH_ZSOHEADERS.
SELECT *
FROM ZSOHEADERS
INTO TABLE T_ZSOHEADERS
WHERE VBELN IN S_VBELN
 AND KUNNR IN S_KUNNR.
IF SY-SUBRC NE 0.
 MESSAGE I398(00) WITH 'No Sales orders found'.
ENDIF.
ENDFORM. " fetch_zsoheaders
*& Form fetch_zsoitems
FORM FETCH_ZSOITEMS.
IF NOT T_ZSOHEADERS[] IS INITIAL.
 SELECT *
 FROM ZSOITEMS
 INTO TABLE T_ZSOITEMS
 FOR ALL ENTRIES IN T_ZSOHEADERS
 WHERE VBELN = T_ZSOHEADERS-VBELN.
 IF SY-SUBRC NE 0.
 MESSAGE I398(00) WITH 'No Sales order items found'.
 ENDIF.
ENDIF.
ENDFORM. " fetch_zsoitems
*& Form generate_control_record
FORM GENERATE_CONTROL_RECORD .
S_CTRL_REC-RCVPOR = C_RCVPOR. "Receiver Port
S_CTRL_REC-MESTYP = C_MESTYP. "Message type
S_CTRL_REC-IDOCTP = C_IDOCTP. "Basic IDOC type
S_CTRL_REC-RCVPRT = C_RCVPRT. "Partner type of receiver
S_CTRL_REC-RCVPRN = C_LOGSYS. "Partner number of receiver
S_CTRL_REC-SNDPRT = C_SNDPRT. "Sender Partner type
S_CTRL_REC-SNDPRN = C_SNDPRN. "Sender Partner Number
ENDFORM. " generate_control_record
*& Form send_idoc
FORM SEND_IDOC.
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
 EXPORTING
 MASTER_IDOC_CONTROL = S_CTRL_REC
 TABLES
 COMMUNICATION_IDOC_CONTROL = T_COMM_IDOC
 MASTER_IDOC_DATA = T_EDIDD
 EXCEPTIONS
 ERROR_IN_IDOC_CONTROL = 1
 ERROR_WRITING_IDOC_STATUS = 2
 ERROR_IN_IDOC_DATA = 3
 SENDING_LOGICAL_SYSTEM_UNKNOWN = 4
 OTHERS = 5.
IF SY-SUBRC <> 0.
 MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ELSE.
 COMMIT WORK.
 LOOP AT T_COMM_IDOC.
 WRITE:/ 'IDoc Generated - ', T_COMM_IDOC-DOCNUM.
 ENDLOOP.
ENDIF.
ENDFORM. " send_idoc
*& Form arrange_data_records
FORM ARRANGE_DATA_RECORDS .
DATA: W_INDEX1 LIKE SY-TABIX,
 W_INDEX2 LIKE SY-TABIX.
SORT T_ZCUSTOMERS BY KUNNR.
SORT T_ZSOHEADERS BY KUNNR VBELN.
SORT T_ZSOITEMS BY VBELN POSNR.
LOOP AT T_ZCUSTOMERS.
 S_ZRZSEG1-KUNNR = T_ZCUSTOMERS-KUNNR.
 S_ZRZSEG1-NAME1 = T_ZCUSTOMERS-NAME1.
 S_ZRZSEG1-ORT01 = T_ZCUSTOMERS-ORT01.
 S_ZRZSEG1-LAND1 = T_ZCUSTOMERS-LAND1.
 T_EDIDD-SEGNAM = C_ZRZSEG1.
 T_EDIDD-SDATA = S_ZRZSEG1.
 APPEND T_EDIDD.
 CLEAR T_EDIDD.
 CLEAR W_INDEX1.
 READ TABLE T_ZSOHEADERS WITH KEY KUNNR = T_ZCUSTOMERS-KUNNR BINARY SEARCH.
 IF SY-SUBRC = 0.
 W_INDEX1 = SY-TABIX.
 LOOP AT T_ZSOHEADERS FROM W_INDEX1.
 IF T_ZSOHEADERS-KUNNR NE T_ZCUSTOMERS-KUNNR.
 EXIT.
 ENDIF.
 S_ZRZSEG2-VBELN = T_ZSOHEADERS-VBELN.
 S_ZRZSEG2-KUNNR = T_ZSOHEADERS-KUNNR.
 T_EDIDD-SEGNAM = C_ZRZSEG2.
 T_EDIDD-SDATA = S_ZRZSEG2.
 APPEND T_EDIDD.
 CLEAR T_EDIDD.
 CLEAR W_INDEX2.
 READ TABLE T_ZSOITEMS WITH KEY VBELN = T_ZSOHEADERS-VBELN BINARY SEARCH.
 IF SY-SUBRC = 0.
 W_INDEX2 = SY-TABIX.
 LOOP AT T_ZSOITEMS FROM SY-TABIX.
 IF T_ZSOITEMS-VBELN NE T_ZSOHEADERS-VBELN.
 EXIT.
 ENDIF.
 S_ZRZSEG3-VBELN = T_ZSOITEMS-VBELN.
 S_ZRZSEG3-POSNR = T_ZSOITEMS-POSNR.
 S_ZRZSEG3-MATNR = T_ZSOITEMS-MATNR.
 S_ZRZSEG3-NETWR = T_ZSOITEMS-NETWR.
 S_ZRZSEG3-ZMENG = T_ZSOITEMS-ZMENG.
 T_EDIDD-SEGNAM = C_ZRZSEG3.
 T_EDIDD-SDATA = S_ZRZSEG3.
 APPEND T_EDIDD.
 CLEAR T_EDIDD.
 ENDLOOP.
 ENDIF.
 ENDLOOP.
 ENDIF.
ENDLOOP.
ENDFORM. " arrange_data_records

Error in ALE Service While Creation of Vendor Master

hi,
I am using a scenario where a third party system is sending vendor master data to a R/3 system The file is picked up by the file adapter(sender) and mapped to IDOC format, using Idoc adapter (receiver). A Vendor is then created by posting the CREMAS03 IDOC into the R/3 system.
Everything goes fine till the Idoc comes into the R/3 system. There in BD87(Idoc Status Monitor), getting the "Error in ALE Service" error. When expanded further the specific error is that of "Cross-system company code xxxx does not exist". What is generally the cause of this error and how would I resolve it?
For those of you who have attended TBIT 40, this scenario is Example 1 - Creation of Vendor Master Data.
Any help would be appreciated?
regards,
SK

one more thing
if you want to be sure that you're using the right data
try to set your system to send the vendor data out
first - send it from BD14
and then you'll know which fields do you need
if you do that take a look at segment E1LFB1M
and check for BURKS
Regards,
michal

Status record 65 error in ale service

HI Experts,
               I have an issue when I tried to send a cost center idoc from one system to another. The company code for the record is 0093 in the sender system; however when the idoc gets created, in the idoc the value of the company code becomes SAH001. I dont know why this happens.
This is the record to in the corresponing table table- which is to be sent from sender to Receiver. The company code ie company code field value is 0093 .
The RFC/LS connections have been done and checked. I am able to send the cost center group data correctly. While sending the cost center I am encountering the following error:-
For an example
Content of created Idoc in sender
Company code field |   SAH001
The company code info is now SAH001. I wonder why ?
So when we send the idoc to recceiver, we get the same company code and I get an error that company code doesnt exist.
Content of idoc in receiver
Company code field |   SAH001
I want to display 0093.
Please tel me what is error and how to rectify?
Thanks & regards
Mathi

hI,
Testing inbound idoc :
Once you configured everything then goto WE19 Transaction :
Give message type or idoc type and execute .
now here you need to fill the Mandatory data in each segment,once you done then
idoc->edit control record -> here you need to fill sender and receiver details.
now you should get green color ,if you get red color then config issue.
now click on start inbound -> now you will get idoc number.
if you want to debug then click on inbound function module -> enter FM -> select call in debug mode and enter.
now cursor will go debug mode
http://www.photographybykevin.net/sap/idoc_overview.pdf
Testing Outbound idoc :
Once you done all configuration ..
Let me say example like invoice ,you need to send invoice from SAP R/3 to other system.
create invoice at VF01 -> Here customer should configure in Parter profile ,once you create invoice ,it creates the idoc.
debugging Outbound IDOC :
keep the break point in form routine above as i said
Create invoice or invoice list
when you maintain output type in invoice or invoice list -
Now click on Further data ->select peridoc scheduling-> back and save it.
Run RSNAST00 Program
Output application : V3
Object key : Invoice or invoice list number
Output type : RD00 or LR00
Medium = 6(EDI) ,A (ALE)
when you execute the program and it will goto debugging.
See the below status codes :
See table TEDS1 for all status codes via SE16 in SAP. Outbound ALE Status Codes
Successful Transmission:
03 - Successful outbound transmission
12 - Dispatch OK
IDoc being processed:
01 - IDoc created
30 - IDoc ready for dispatch (ALE service) (Program RSEOUT00 needs to be executed)
ALE Error Messages:
02 - Error passing data to port
04 - Error within control information on EDI subsystem
05 - Error during translation
25 - Processing despite syntax errors (outbound)
29 - Error in ALE service
32 - Resubmit edited intermediate document (DO NOT USE)
Syntax Error Messages:
26 - Error during syntax check of IDoc (outbound) Inbound ALE Status Codes
IDoc Processed Successfully:
50 - IDoc added
53 - Successful posting
IDoc ready for processing:
64 - IDoc ready to be passed to application. The IDoc will be passed to the application by program RBDAPP01.
Errors in IDoc Processing:
51 - Error - application document not posted
56 - IDoc with errors added (You should never see this error code)
60 - Error during syntax check of IDoc (inbound)
61 - Processing despite syntax error (inbound)
63 - Error passing IDoc to application
65 - Error in ALE service - indicates partner profiles are incorrect
69 - IDoc was edited
Regards,
Nagaraj

IDOC: Error in ALE Service

Hi All,
I have created a new outbound idoc type ZSLSRPT and assigned it to a partner profile with type LI in we20. I tried running my customized program for idoc outbound and the status shows Error in ALE Service, Entry in outbound table not found.
Am I missing something with the partner definition? Do I need to configure the vendor output type in NACE? Please help.
Thanks,
Kenny

Hi Kenny,
Have you setup the distribution model (BD64) for the corresponding message type?
Also check this link for your reference.
http://help.sap.com/saphelp_nw04/helpdata/en/52/16adef543311d1891c0000e8322f96/content.htm
Regards,
Ferry Lianto

MM SUS Vendor Replication Error: Error in ALE Service

Dear Experts,
We are implementing MM SUS (SRM 5.0). As a part of this we need to replicate vendors from ECC to SUS system via XI. We have created a Reduced Message Type Z_CREMAS_SUSMM and had set up the partner profile in WE20 with SUS logical system as destination and specifing the Message Type, and port of the XI system
We executed the transaction BD14 for replication, it is resulting in error 29 : Error in ALE Service : Entry in Outbound table not found.
Please provide inputs to overcome this problem
Thank you,
Regards,
Ravi

Hi Ahmed,
Thanks for your reply. We have configured as per SAP configuration guide(plan driven procurement). As per this we had set up partner profile for SUS logical system and define the outbound parameters with receiver port of XI system.
If you feel one more partner profile need to be setup for XI system then please advise us for necessary configuration.
Thanks
Ravi

Vendor Master Replication Error from ECC to SUS : Error in ALE Service

Dear Experts,
We are implementing MM SUS (SRM 5.0). As a part of this we need to replicate vendors from ECC to SUS system via XI. We have created a Reduced Message Type Z_CREMAS_SUSMM and had set up the partner profile in WE20 with SUS logical system as destination and specifing the Message Type, and port of the XI system
We executed the transaction BD14 for replication, it is resulting in error 29 : Error in ALE Service : Entry in Outbound table not found.
Please provide inputs to overcome this problem
Thank you,
Regards,
Ravi

Hi,
Check
Re: Idoc Error Status "Entry in outbound table not found "
Looks like some issue with the partner profile set up for the sender or receiver of the EDI message in WE20.
Set up them again and When these have been set up try reprocessing your IDocs from BD87

Oracle ADF Business Service Layer Technologies

Hello,
We are building an online shopping mall/site that is expected to receive order volume of 50-60 thousand orders per week. So obviously, data traffic generated by the site will be pretty heavy. The technology set we are supposed to use is Jdeveloper 10g with ADF. Currently ADF business service layer offers following set of technologies. The question is which of following technologies meets these four criterias the BEST? (1) Security, 2)24x7 Reliability and Maintenace overheads (3)Speed /Performance of the server response to client requests (4) integration with Oracle database.
Please advise. Any technet/metalink oracle document that compares these various business layer technology would be great indeed.
Business service technologies that I am talking about is mentioned below
Enterprise JavaBeans (EJB) Session Beans
Since most J2EE applications require transactional services, EJB session beans are a logical choice because they offer declarative transaction control. Behind the EJB session bean facade for your business service, you use plain old Java objects (POJOs) or EJB entity beans to represent your business domain objects. JDeveloper offers integrated support for creating EJB session beans, generating initial session facade implementations, and creating either Java classes or entity beans. You can also use Oracle TopLink in JDeveloper to configure the object/relational mapping of these classes.
JavaBeans
You can easily work with any Java-based service classes as well, including the ability to leverage Oracle TopLink mapping if needed.
Web Services
When the services your application requires expose standard web services interfaces, just supply Oracle ADF with the URL to the relevant Web Services Description Language (WSDL) for the service endpoints and begin building user interfaces that interact with them and present their results.
XML
If your application needs to interact with XML or comma-separated values (CSV) data that is not exposed as a web service, this is easy to accomplish, too. Just supply the provider URL and optional parameters and you can begin to work with the data.
ADF Business Components.
These service classes are a feature of the ADF Business Components module, and expose an updateable dataset of SQL query results with automatic business rules enforcement.
Thanks
Ruchir

So the quote says "technologies Oracle recommends to J2EE developers" which is correct - if you are an experience Java EE developer the TopLink/JPA/EJB stack should be your choice however if you are coming from a 4GL/Enterprise developer background then the recommendation is here:
http://download.oracle.com/docs/html/B25947_01/intro002.htm#sthref21
For enterprise 4GL developers building new web applications, Oracle recommends using JavaServer Faces for the view and controller layers, and ADF Business Components for the business service implementation. This combination offers you the same productive J2EE technology stack that over 4000 of Oracle's own enterprise 4GL developers use every day to build the Oracle E-Business Suite. Since its initial release in 1999, several thousand external customers and partners have built and deployed successful Oracle ADF-based applications as well. Both now and in the future, Oracle and others are betting their business on Oracle ADF with ADF Business Components.
And yes ADF BC can be exposed as EJB - but this is usually only used for remote deployment of ADF BC when they are on another server than the UI code - for example when using Swing.

Idoc error 29 - Error in ALE service

Hi All,
I have this error 29 - Error in ALE service when the idoc is created (No global company code is assigned to the company code).
This message comes after 01 - IDoc created
Any idea why this is happening? I have created conversion rule to convert the company code.
Help needed uegently.
Thanks!

Hi,
Status 29 generally occurs when the Partner Profile has not been configured.
Check if the Message type is configured on the outbound side.
Thanks
Krithika

IDoc ready for dispatch (ALE service)

Hello All,
My IDoc gets generated with the status 30: IDoc ready for dispatch (ALE service).
I want to trigger the IDoc automatically [status 03 (Data passed to port) and the signal light displayed to Green colour.]
Also, I checked the partner profile (WE20). In the outbound parameters, I went to the appropriate message type & there the output mode is set to 2 (send immediately).
Please let me know if there is any configuration setting that I need to check.
Thanks & Regards,
Saurabh Buksh

Hello,
could you please check whether there is any process or program that is locking the status of the idoc you are trying to process via BD87?
Once I got the same error and I solved by just closing up a report (RC1_IDOC_SET_STATUS) that i was using in order to change the idoc status.
Regards
Antonio

Need Answer on ALE Service Layer

Similar Messages

Maybe you are looking for