Using bgRFC for IDoc Inbound Processing
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.
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.
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.
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.
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.
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
Maintenance of partner profile (transaction WE20)
Assign the inbound group to the inbound partner profile. For queued processing assign a rule for the parameter RULE_NAME.
SAP Note 1793313 – ALE: IDoc inbound processing using bgRFC as standard
SAP Note 1872637 – Delays posting inbound IDocs (status 64) which have been configured to trigger immediately
SAP Note 1333417 – Performance problems when processing IDocs immediately
I got a problem with Inbound IDoc keep hang as an yellow idoc in WE02, status 64, with no issue as checked.
And everytime I have to BD87 to reprocess this Idoc then it works fine.
Any above workaround I can apply to my case, please suggest.
Thanks a lots.
Did you select the trigger immediately option in the partner profile? If yes, there might be an issue with the bgrfc scheduler.
Yeah that's first thing I think about. Setup in WE20 included this step already.
So where can I do a check if anything wrong with background scheduler, mate?
That’s hard to analyze remotely. I would recommend to open a SAP incident for component BC-MID-RFC-BG.
Thanks a lot for the post. I am doing a prototype .
Along with the configuration do we need do any programming or code changes in our FM for this to work. Please suggest.
Thanks in Advance.