ALEAUD from ECC

[Former Member]

We are on -

ECC - 6.0

PI - 7.0 SP 07

Scenario:

Third party system sends information to PI (by consuming web-service hosted on PI) and Idoc ORDCHG is posted on ECC.

Requirement:

Third party system needs an acknowledgement saying that PI/ ECC has received the info.

Solution:

This is what I am going to suggest..

Configure ALEAUD, so that when we ORDCHG is received, ALEAUD is triggered and PI would send the info to Third party system.

Originally, I was thinking about sync-async bridge and BPM...

Any suggestions???

[Former Member]

Hi Every one,

Sorry. I should have mentioned this in my original post -

On the ECC, Idoc is kind of decided as the client already has powerful monitoring tools, that would send alerts/ trigger workflows to the support. I dont have much flexibility there.

Also I wanted to avoid BPM for the obvious reasons.I was looking at ALEAUD, as this can be achieved with minimum effort

Thanks,

-Naveen.

[rodrigoalejandro_pertierr]

if so, consider my previuos post.

Regards

[ambrish_mishra]

Hi Naveen,

Is the third party just looking for an acknowledgment or a synchronous response?

Your solution hinges on that point

In one of the orders (create/change) IDoc interface, this is how I did it....

In my case, I needed order response or error sent back to a JMS system. Requirement was real time but I wanted to avoid synchronous interface.

For success, ORD_RSP IDoc can be triggered automatically once a order is created or confirmed so success response went real time back to JMS queue.

If the order IDoc goes in error, we used a workflow object in the inbound processing of the IDoc and triggered an outbound proxy to PI with the error details to send back to sender system. This captured both standard and custom errors.

both the success response and error response interface were async but worked like real time.

Hope it helps!

Ambrish

[former_member802575]

Hi michal,

   naveen using ORDCHG stand Idoc bcz of that  reason i suggest above one .....other wise bapi is better option ... thanks for you suggestion .

Thanks,

srikanth

[former_member802575]

hi naveen,

what is your client requirement ? according  to your client requirement u can follow . they want application ack go for ALEAUD, they want any response from ECC to Third party system go for BPM.

Thanks,

srikanth

[MichalKrawczyk]

Hi srikanth,

>>>according  to your client requirement u can follow . they want application ack go for ALEAUD, they want any response from ECC to Third party system go for BPM.

he already mentioned that it's a sync call (sync WS) so both types of ack can be done with a BAPI

and not with ALEAUD or BPM - so why do we keep on pushing this?

Regards,

Michal Krawczyk 

[arkesh_sharma]

Hi Naveen,

Please check the below links for IDoc Acknowledgements:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/903a0abc-e56e-2910-51a8-9dc616df5...

http://scn.sap.com/message/10996798

http://scn.sap.com/thread/2123878

Thanks,

Arkesh

[MichalKrawczyk]

Hi Arkesh,

why do you think using ALEAUD is good for sync WS calls ?

have you done anything like that and it worked ?

Regards,

Michal Krawczyk

[arkesh_sharma]

Hi Michal,

For IDoc acknowledgements we normally use ALEAUD.

I never mentioned anywhere in my comment that it is a good approach.

It is one of the approach.

I had a BPM scenario in which I was suppose to trigger ALEAUD acknowledgements for every IDoc posted in ECC and send it back. There were few glitches involved with respect to ALEAUD.

I request you to please let us know the disadvantages of ALEAUD acknowledgments and also provide an alternative approach to ALEAUD acknowledgements.

[MichalKrawczyk]

Hi,

>>>For IDoc acknowledgements we normally use ALEAUD.

but not for sync scenarios right ? Naveen is asking how to deal with a sync scenario and aleaud

is not sync but async - so let's not continue on the aleaud but give him to better option (at least that's my idea)

>>>I request you to please let us know the disadvantages of ALEAUD acknowledgments and also provide an alternative approach to ALEAUD acknowledgements.

just one: don't use for sync scenarios

Regards,

Michal Krawczyk

[arkesh_sharma]

Thank You for your valuable feedback Michal.

I agree with you.

[rodrigoalejandro_pertierr]

in case you need to go for IDOC you need to agree with the client that the message will the send in async way but in a Near Real Time. in this case you will need to configure two separate interface, one for send the data to ECC and another one to send the ALEAUD information to the client.

Michal, what do you sugguest about it.

Regards

[rodrigoalejandro_pertierr]

in case you need to go for IDOC you need to agree with the client that the message will the send in async way but in a Near Real Time. in this case you will need to configure two separate interface, one for send the data to ECC and another one to send the ALEAUD information to the client.

Michal, what do you sugguest about it.

Regards

[MichalKrawczyk]

Hi,

>>>Originally, I was thinking about sync-async bridge and BPM...

not very good idea - why don't you use a BAPI to change the ORDER ?

which way you'd have the info immediately (as bapi is sync) and you don't need a BPM

try using the BAPI for sync interface,

Regards,

Michal Krawczyk