on 11-24-2015 5:27 PM
Hi All,
I have observed we can send idocs via Idoc_AAE adapter if we use port trfc and can send idocs via HTTP_AAE adapter via port typ xml http.
I would like to know the preferred adapter and on which basis we will select http_aae or Idoc_aae adapter?
BR,
Rashmi
Hello Rashmi,
HTTP_AAE is used is there is any additional requirement of security in terms of certificate, for example SSL. In that case we generally use the port number as 443.
In case of IDoc_AAE you cannot use SSL.
Regards,
Souvik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That discussion is not relevant at all to Rashmi's query. That discussion between myself and Florian is regarding a different matter altogether.
Rashmi,
In general, I'd suggest the following approach to determine which to use:-
If the backend system is an AS ABAP server, use IDoc_AAE because tRFC is an SAP-specific technology provided by an ABAP system.
However, sometimes IDocs are integrated with non-ABAP systems. In such cases, a common approach is transferring a SOAP-XML representation of the IDoc. In this case, it is possible to use HTTP_AAE or SOAP.
Rgds
Eng Swee
IMHO, I don't think it has anything to do with SSL. Both ECC and PI would be within your company's landscape so there is no reason for SSL. You can read up on SSL to know what it's about and you would probably agree why SSL is not required for this case.
I cannot answer why the CREMAS to GRC in your landscape is using HTTP_AAE. I too feel it does not make sense. But this is something you should probably ask your team lead or whoever designed that interface. Maybe there is something written in the tech spec?
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.