Even though this blog will primarily be about SAP XI/PI, I would be remiss if I didn’t mention other SAP integration topics. So, my first technical blog will be about my single biggest gripe regarding the broader field of SAP integration. Namely, the perils of IDOC immediate processing!
I discovered both SAP ALE (which stands for Application Link Enabling and pronounced by its individual letters– “A, L, E”) and the golden beverage of the same name in 1998. I was in college at the time. One of my collegiate peers was dabbling in ALE (the drink, not the SAP technology) and had a knowledge on the topic vastly superior to mine. One night, he brought home a variety of ales from a local brewpub. Over time, I got to know ale very well (maybe a little too well?) and have been hooked ever since.
My introduction to SAP ALE was similar. I was in college and a colleague of mine introduced me to ALE. He was on the master data distribution team on a very large SAP implementation. His job was to ensure that the SAP ALE settings were correct in the entire SAP landscape. He taught me the basics of ALE in a few hours. Over time, as I learned more about SAP ALE, I developed a fondness for it that rivaled my fondness for it alcoholic counterpart.
ALE and ale are a lot like. Neither take a large up front investment (a few transactions for ALE, a few bucks for ale), but both require a fair amount of learning appreciate fully. To truly understand ALE, you need to understand all its parts: water, malt, hops, and yeast, and how they interact. Like SAP ALE, too much ale will leave one’s head swimming.
And just like you wouldn’t want to drink mass quantities of ale and immediately take a $150,000 Ferrari out for a spin, you don’t to immediately process mass quantities of IDOCs on your productive SAP instance. The number one problem I see at clients using ALE/IDOCs is setting the partner profile to process the IDOC immediately.
The trouble with immediate IDOC processing comes when a large number IDOCs are received at the same time. What constitutes a “large number of IDOCs?” Well, that depends on your SAP system. Problems usually occur when more IDOCs come in than you have foreground work processes. When more IDOCs arrive than your system has resources not only can you affect the system’s online users (hey, there are only so man foreground work processes to go around), you also run the risk of having some of the inbound IDOCs fall into the dreaded “double 64” status. IDOCs that cannot be processed due to limited resources are given an additional 64 status record and are left unprocessed by the system. The only way to handle these IDOCs is to process them manually (via BD87 or BD20) or by a background job (RBDAPP01).
A much better way to handle IDOC processing IDOCs is to collect the IDOCs and then process via a background job (RSEOUT00 for outbound IDOCs, RBDAPP01 for inbound IDOCs). This greatly reduces the load on the system and won’t cause your system to bite the dust in high-load situations. Moreover, there are performance tuning options available on RSEOUT00 and RBDAPP01 that will allow your IDOC processing to really sing! I will probably cover advanced settings for those programs in later blogs. I know–you can hardly wait!
In short ALE is great technology, but it is an asynchronous (i.e. batch) technology. There is very little reason why immediate IDOC processing is ever acceptable. In most cases an RBDAPP01 job that is scheduled every 5 of 10 minutes is more than fast enough for the business. If a 5 minute maximum (remember only the IDOCs that came in right after the prior job wait 5 minutes, the average wait time is 2:30) lag is not acceptable, a synchronous interface, based on BAPIs, RFCs, or web services should be considered.
