ALE triggering ABAP program instead of iDoc

Question

Is it possible to have ALE trigger an ABAP program instead of an iDoc?
We need to send changes in Master Data to a system that can't handle iDoc, but does know what to do with SOAP.

Answer 1

We're talking about an All-in-One system on NetWeaver 700 and ECC 6.0. My company has developed an Add-On for Business One and now they want to develop a similar Add-On for All-in-One. That Add-On should integrate an Open Source system into an SAP system, or at least make the flow of data seem seamless.
I should be very careful with my comments, as I'm not really understanding enough about your requirements. I must admit key words changes in master data and ALE triggered my initial comment.
On second thought it might actually be worthwhile to think about other alternatives. E.g. you could look at the technique SAP uses for BW extractors, which might also be suitable.
I might just be able to hook into the Change Doc system by defining new Change Doc and Change Pointer Types.
Well, per my comment above, maybe you don't even need change pointers. However, if you do, you can mostly rely on existing change documents unless you're dealing with some odd or custom object.
Am I right if I think that IDocs handle those Change Pointers from some kind of scheduled background job?
Part of the setup for change pointers for a specific message type is to define which function module is used for evaluating the change pointers. All change pointers are then evaluated via transaction BD21, program RBDMIDOC, which can also be scheduled in the background.
but we only need less than 5% of the information contained in an iDoc
Well, in theory SAP offers some options: You can filter segments via ALE, use reduced message types or define IDoc views. However, depending on the technique this sometimes requires that the actual application (function module creating the IDocs) has to support it (because it's additional API calls that have to be present).
Defining new IDoc types isn't that attractive to us.
Though I do understand such statement in specific cases, it's hard to relate to it on a general level. I.e. in the latter case it's often more driven by strange company policies than by good design choices.
Anyhow, in the end I'm tempted to think that change pointers with IDocs are one option among many. In your specific case however it sounds as if there's possibly other techniques that might be more suitable. So I'll stop for now before I tell you too much crap pushing you in a wrong direction...