Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

ALE triggering ABAP program instead of iDoc

Former Member
0 Kudos

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.

11 REPLIES 11

Former Member
0 Kudos

Is it possible to have ALE trigger an ABAP program instead of an iDoc?

Of course: As you can imagine, the IDoc is also not coming out of nowhere, there is an ABAP program (function module) that generates it. You are absolutely free to define your own function module and and configure the system to trigger your custom function module for your interface.

We need to send changes in Master Data to a system that can't handle iDoc, but does know what to do with SOAP.

n general I'd say you have two options (assuming we're talking some ECC system and that you want to use change pointers).

You could still stick to the standard SAP container (i.e. IDoc) and simply send this IDoc as an XML message via SOAP protocol. This is standard SAP functionality and you might get away with just configuring the interface and no need for coding (on SAP side). E.g. see the help on [port type XML-HTTP|http://help.sap.com/saphelp_NW70EHP1core/helpdata/en/21/e9c975eb1911d6b2ea00508b6b8a93/frameset.htm].

The other option is to completely forsake the IDoc approach and create custom function modules for evaluating change pointers and triggering messages/web services or whatever approach you choose. Again the online help is really good, check out the step-by-step guide for [Distributing master data using the SMD tool|http://help.sap.com/saphelp_nw70ehp2/Helpdata/EN/78/2178da51ce11d189570000e829fbbd/frameset.htm]. Be aware though that this is probably quite some coding effort.

Also, I wouldn't really associate the latter solution with ALE, because if you bypass the IDoc generation, you probably also bypass features usually associated with ALE (customer distribution model, message filtering, etc.) unless you program them.

Based on your posting I strongly suggest though to do some further research what your receiving system expects and can do. SOAP and IDoc are not necessarily contradictory concepts, but sending an IDoc via SOAP doesn't necessarily mean that this is easy for your external application. Also, remember that the implementation effort in one system might go up, if you choose a simpler solution in the other system. Once you know all the capabilities and requirements you should be able to make the right choice.

Cheers, harald

Former Member
0 Kudos

Hello Harald,

Thank you for your response.

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.

An XML communication server, developed by us, is used as a "missing link" between both systems and it could perform the translation from an XML iDoc to some other XML format, but we only need less than 5% of the information contained in an iDoc. On the other hand, if we want to fully control the external system from within AiO, we need to send information which is not contained in any iDoc. Defining new iDoc types isn't that attractive to us.

The link you gave me is kind of interesting. I might just be able to hook into the Change Doc system by defining new Change Doc and Change Pointer Types. From there, it shouldn't be that hard to handle the Change Pointers, just like iDocs do. Am I right if I think that iDocs handle those Change Pointers from some kind of scheduled background job?

0 Kudos

HelloGervan,

You can send the Idoc to ABAP program, We have this facility using ABAP port. All you need to do is create a function moulde(make sure the import export parameters are as per the standars you may get this in F1 help in WE21for ABAP Port) and create ABAP Port in WE21 and assign the created function module to it. then you have add this port in WE20 partner profile. by doing this way once the Idoc is genereated by the standard program you have to execute RSEOUT00(don't need to run if you set send Idoc immediately ).

Regards

Naresh

0 Kudos

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...

0 Kudos

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.

Is it possible to define a new message type and link a function module to it, without actually defining and sending an iDoc for it?

0 Kudos

Is it possible to define a new message type and link a function module to it, without actually defining and sending an IDoc for it?

Absolutely: You could have a function module that reads change pointers, collects some data and somehow processes it (e.g. could trigger some remote function directly) and finally updates the change pointers by marking them as processed.

In a way it's completely up to you what you want to achieve. In theory you wouldn't even need to integrate it completely in the SAP change pointer framework. I.e. you could use the framework for generating the change pointers, but then possibly have a custom report that directly evaluates your change pointers (instead of using RBDMIDOC as a trigger for your custom function module). This way you could for example have more control by adding date parameters or whatever else you might need.

0 Kudos

I'm close to a possible solution.

Next question: Because we do not wish to interfere with the regular iDocs system, but still want to make as much use of the standard Change Documents system, would it be possible to have one Change Document (e.g. for object MATERIAL) generate two Change Pointers (e.g. for MATERIAL and ZMATERIAL)?

0 Kudos

would it be possible to have one Change Document (e.g. for object MATERIAL) generate two Change Pointers (e.g. for MATERIAL and ZMATERIAL)?

You can attach as many change pointers to a change document as you like as long as you make up new message types. From my perspective it's actual often practice to use a custom message type: If the change relevant fields that you configure via BD52 are differing from the default SAP configuration you can keep the standard configuration and just configure the ones relevant for your process for your custom message type. From my experience the customers often need to monitor just a small subset of the fields...

0 Kudos

Could you possibly give me some kind of step-by-step guide?

I've been trying to get this working for a while now, but I can't seem to get it working. And Google isn't that friendly either...

0 Kudos

Hang on, I just might have found something: the Change Pointers Position table... 😛

Let's see If I can hook into it...

0 Kudos

Could you possibly give me some kind of step-by-step guide?

Look at my first response to your original question, where I gave you the following hint: check out the step-by-step guide for [Distributing master data using the SMD tool|http://help.sap.com/saphelp_nw70ehp2/Helpdata/EN/78/2178da51ce11d189570000e829fbbd/frameset.htm]. It won't get better than that...