Using bgRFC for IDoc Inbound Processing

Technology Blogs by Members

Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!

Situation

The partner profiles (transaction WE20) define the conditions for the interchange of data in an ALE environment with a partner using the IDoc interface. There are two ways of posting IDocs in ALE inbound processing:

Trigger by background program

IDocs are received and saved in status 64. This IDocs will be processed using scheduled batch jobs for the report RBDAPP01.

Trigger Immediately (Default)

IDocs are received and saved in status 64. After the database commit, a second parallel process in which the application processes the IDoc is started. The result of this processing is then logged in the first process. So each IDoc requires at least 2 free dialog work processes. If no dialog process is currently free for application processing, report RBDAPP01 is scheduled for this IDoc and executed as a background process.

Problem

For a quick processing, the report RBDAPP01 must currently be scheduled at suitable frequency. On the other hand the "Trigger Immediately" option should not be used for high volume, noncritical messages as this can often lead to resource problems.

Approach

For immediate inbound processing additional options are provided that use bgRFC (background RFC). bgRFC offers quick processing of IDocs while using the available system resources in an ideal manner.

Transactional Processing

In the transactional processing, the inbound IDocs are processed in parallel. An asynchronous RFC call executes the further processing when using the priority "01" in another LUW. If no more resources are available to the RFC, a transactional bgRFC call carries out the processing. When you use the priorities "02" to "99", the transactional bgRFC call generally carries out the processing using the inbound destinations that are assigned to the priorities.

Queued Processing

During the queued processing, the inbound IDocs are processed depending on their queue names. Further processing happens independent of the chosen priority. It is generally carried out by a queued bgRFC call using the inbound destinations that are assigned to the priorities. IDocs with the same queue name are processed sequentially and queues with different names are processed in parallel.

Implementation

Definition of Inbound Destination (transaction SBGRFCCONF)

Create an inbound destinations. If no prefix is assigned, the system uses the automatic queue names with the prefix ALE_INB. Alternatively, you can define your own prefix that is then used for the creation of the queue name. Destinations with multiple prefixes cannot be used.

Definition of Inbound Groups (transaction WE20BGRFC)

Inbound groups later classify the inbound partner profiles that you use. Create the required number of inbound groups. Assign a priority between "01" and "99" to the groups. You can assign the same priorities to different groups.

Assignment of inbound destinations to inbound groups (transaction WE20BGRFC)

Assign the inbound destination for all used priorities.

Only for queued processing: Formation of queue names (transaction WE85_INBOUND)

You can view rules or store your own rules. You can find the required interface in the assigned function modules IDOC_QUEUE_INB_CONST_ALE_QUEUE or IDOC_QUEUE_INB_MESTYP