The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.
The process can be divided into the following sub-processes:
1. Outbound Processing
• Receiver determination
• Calling the generated outbound function module
• Conversion of BAPI call into IDoc
• Segment filtering
• Field conversion
• IDoc version change
• Dispatch control
2. IDoc dispatch
IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).
tRFC guarantees that the data is transferred once only.
3. Inbound Processing
• Segment filtering
• Field conversion
• Transfer control
• Conversion of IDoc into BAPI call
• BAPI function module call
• Determination of IDoc status
• Posting of application data and IDoc status
• Error handling
The sub-processes in inbound and outbound processing are described below:
Outbound Processing
On the outbound side first of all the receiver is determined from the distribution model.
Then the outbound function module that has been generated from a BAPI as part of the BAPI-ALE interface is called in the application layer (see also Example Programs with Asynchronous BAPI Calls [Seite 42]).
In the ALE layer the associated IDoc is filled with the filtered data from the BAPI call.The volume of data and time of the data transfer is controlled by the dispatch control.The outbound processing consists of the following steps:
Receiver determination
The receivers of a BAPI call are defined in the distribution model in same way as with synchronous BAPI calls.Before the BAPI or generated BAPI-ALE interface can be called, the receiver must be determined.
When the receiver is determined, the filter objects are checked against the specified conditions and the valid receivers are reported back.If the distribution of the data is also dependent on conditions, these dependencies between BAPIs or between BAPIs and message types are defined as receiver filters.For each of these receiver filters, before the distribution model is defined, a filter object is created whose value at runtimes determines whether the condition is satisfied or not.
For more information see Determining Receivers of BAPIs [Seite 35].Calling the generated outbound function module.If the receivers have been determined, you have to differentiate between local and remote receivers.
The BAPI can be called directly for local receivers. For remote calls the generated ALE outbound function module must be executed so that processing is passed to the ALE layer. The data for the BAPI call and the list of allowed logical receiver systems are passed to this function module.
Programming Notes:
After calling the generated function module the application program must contain the command COMMIT WORK.The standard database COMMIT at the end of the transaction is not sufficient. The COMMIT WORK must not be executed immediately after the call, it can be executed at higher call levels after the function module has been called several times.The IDocs created are locked until the transaction has been completed. To unlock them earlier, you can call the following function modules
:
DEQUEUE_ALL releases all locked objects
EDI_DOCUMENT_DEQUEUE_LATER releases individual IDocs whose numbers are transferred to the function module as parameter values.
Data Filtering
Two filtering services can be used - parameter filtering with conditions and unconditional interface reduction.
• Posting of application data and IDoc status
• Error handling
• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.
• With parameter filtering, table rows that have been filtered out are not included in the IDoc. For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.
For example, the field plant can be converted from a two character field to a four character field.Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.
If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types:
• Fields can be appended to a segment type
• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time: • IDocs can either be sent immediately or in the background.
This setting is made in the partner profile. • If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.
• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.
• With parameter filtering, table rows that have been filtered out are not included in the IDoc.
For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.
These are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field plant can be converted from a two character field to a four character field.
Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.
If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types: • Fields can be appended to a segment type
• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time:
• IDocs can either be sent immediately or in the background. This setting is made in the partner profile.
• If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.
RELATED LINKS
ALE PART THREE
Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm
MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions
The process can be divided into the following sub-processes:
1. Outbound Processing
• Receiver determination
• Calling the generated outbound function module
• Conversion of BAPI call into IDoc
• Segment filtering
• Field conversion
• IDoc version change
• Dispatch control
2. IDoc dispatch
IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).
tRFC guarantees that the data is transferred once only.
3. Inbound Processing
• Segment filtering
• Field conversion
• Transfer control
• Conversion of IDoc into BAPI call
• BAPI function module call
• Determination of IDoc status
• Posting of application data and IDoc status
• Error handling
The sub-processes in inbound and outbound processing are described below:
Outbound Processing
On the outbound side first of all the receiver is determined from the distribution model.
Then the outbound function module that has been generated from a BAPI as part of the BAPI-ALE interface is called in the application layer (see also Example Programs with Asynchronous BAPI Calls [Seite 42]).
In the ALE layer the associated IDoc is filled with the filtered data from the BAPI call.The volume of data and time of the data transfer is controlled by the dispatch control.The outbound processing consists of the following steps:
Receiver determination
The receivers of a BAPI call are defined in the distribution model in same way as with synchronous BAPI calls.Before the BAPI or generated BAPI-ALE interface can be called, the receiver must be determined.
When the receiver is determined, the filter objects are checked against the specified conditions and the valid receivers are reported back.If the distribution of the data is also dependent on conditions, these dependencies between BAPIs or between BAPIs and message types are defined as receiver filters.For each of these receiver filters, before the distribution model is defined, a filter object is created whose value at runtimes determines whether the condition is satisfied or not.
For more information see Determining Receivers of BAPIs [Seite 35].Calling the generated outbound function module.If the receivers have been determined, you have to differentiate between local and remote receivers.
The BAPI can be called directly for local receivers. For remote calls the generated ALE outbound function module must be executed so that processing is passed to the ALE layer. The data for the BAPI call and the list of allowed logical receiver systems are passed to this function module.
Programming Notes:
After calling the generated function module the application program must contain the command COMMIT WORK.The standard database COMMIT at the end of the transaction is not sufficient. The COMMIT WORK must not be executed immediately after the call, it can be executed at higher call levels after the function module has been called several times.The IDocs created are locked until the transaction has been completed. To unlock them earlier, you can call the following function modules
:
DEQUEUE_ALL releases all locked objects
EDI_DOCUMENT_DEQUEUE_LATER releases individual IDocs whose numbers are transferred to the function module as parameter values.
Data Filtering
Two filtering services can be used - parameter filtering with conditions and unconditional interface reduction.
• Posting of application data and IDoc status
• Error handling
• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.
• With parameter filtering, table rows that have been filtered out are not included in the IDoc. For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.
For example, the field plant can be converted from a two character field to a four character field.Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.
If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types:
• Fields can be appended to a segment type
• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time: • IDocs can either be sent immediately or in the background.
This setting is made in the partner profile. • If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.
• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.
• With parameter filtering, table rows that have been filtered out are not included in the IDoc.
For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.
These are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field plant can be converted from a two character field to a four character field.
Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.
If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types: • Fields can be appended to a segment type
• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time:
• IDocs can either be sent immediately or in the background. This setting is made in the partner profile.
• If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.
RELATED LINKS
ALE PART THREE
Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm
MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions
No comments :
Post a Comment