Often we come across the dilemma of which adapater should I use while integrating with SAP systems. Will try and discuss on the options available and what could be some of the points that one should consider before you zero in one of the adapters.
If you see the list of Adapters given by SAP, a quick seggregation can be done depending on the type of systems that these adapters are going to communicate with.

Now, one of the obvious systems with which XI is going to communicate will the SAP systems (SAP R/3 – 4.6C, 4.7, ECC 5.0, CRM, SRM etc etc). Now these systems could be on the sending side or on the receiving side or could be on both sides where R/3 is integrating with SRM / CRM …. or vice versa.
So, what are the options that SAP gives us to communicate with SAP systems.
1. IDOC Adapter
2. RFC Adapter
3. Proxy

Now, how do you choose the right one for a given scenario. One of the things that SAP strongly suggests is the usage of PROXIES.

Now, if you take a close look at the adapters specified here, the one thing that strikes right away is the usage of proxies. We know that proxy generation is possible only if your WAS is >= 6.20. So, that is one parameter that comes up straight away for the usage of proxies.
— Use Proxies only if the WAS version is >= 6.20.

We will also look into other reasons where we should go for a proxy.

Let’s take a case and discuss the same.
The immediate question that probably you are getting is :
I am on WAS 6.2 or higher and also at the same time either I have a standard BAPI / Remote enable function module for the given functionality on the application system. So, what should I do now?

In this case, there are 2 ways in which the implementation can happen.

1. Configure a RFC Adapter and call the BAPI / RFC. However the potential problem that I could see is that the RFC adapter existing on the Java stack communciating with the BAPI existing on the SAP application system.
2. The second option that I have got is to write a proxy on the SAP application system (which will be called by XI) and internally the proxy will call the BAPI.
At this point of time if your question is, as long as I am dealing with the latest versions of SAP systems, should I totally avoid using RFC Adapters – MY TAKE on this would be, YES. Do NOT use RFC Adapter, rather go ahead and use the proxy.
However, the problem could be that the pre-built meta data and the mapping that SAP delivers might not be useful as the BAPI is wrapped with a PROXY now. But as the proxy is also expected to have the same message interface as that of the BAPI, we might still be able use the pre-defined mapping. This is something that we need to try out and then decide how do I go about this interface.

But for whatever reasons, if you are not getting advantage of the pre-defined integration content, PROXY is the way to go.
Now, if you are dealing with SAP systems < 6.20, we do NOT have choice of PROXY anyway, so go ahead and use a RFC adapter.
Now, as far as the IDOC adapter is concerned I think the choice would be straight forward. Where ever there is a standard IDOC given by SAP (usually mapping also will be delivered for SRM / CRM system integrations), so go ahead and use the same.
The questions that you might be having now is that for a standard object if I have an IDOC as well as a BAPI, which one do I go for. My opinion would be its going to be dependent on the specific scenario that you are trying to develop. We can think of multiple variations of design for this case.
For Exapme

1. Send one IDOC at a time.

2. Club multiple IDOCS and send as a single IDOC.

3. Make one single RFC call, for each business transaction.

4. Avoid making multiple calls to the same BAPI / RFC, rather have a wrapper BAPI and send all the records in one time.

5. Use the PROXY and send all the data in one shot and make single calls to the BAPI from the PROXY on the application system – only if you can use PROXIES.

The biggest advantage of the proxy is that it always by passes the Adapter Engine and will directly interact with the application system and Integration engine – so it will and should give us a better performance.

So, there are the choices that you have while designing a SAP interface, so take a close look at the interface and identify your priorities for the interfaces. The parameteres could be some thing like PERFORMANCE, ERROR LOG, AUDIT LOG, MONITORING OF THE TRANSACTIONS INDIVIDUALLY. Do a comparison of the pros and cons of the choice of adapters that you have for the parameters for the specific interface and then make a call.

Initially, it might look alike – what’s the big deal, its a simple case of sending / receiving data from SAP – especially if you are coming from R/3 world, but bellive me, you have got good chances of landing up in trouble, if you don’t take care of your priorities of the interface.

Pre-requisite (refer installation guide for detailed procedure of pre-requisites):
1. You have installed the SAP cryptographic libraries as mentioned in the installation guide.
2. The Keystore and SSL services are enabled.

Following are the steps for installing the SSL certificates in the portal
Start the Visual Administrator. Navigate to the directory given below.
<Installation Drive>\usr\sap\<Instance Name>\JC<Instance Nr>\j2ee\admin\go.bat
1. Login to the Visual Administrator using the Administrator user id and password.
2. Navigate to the ‘Keystorage’ service as shown in the screen below.

3. In the ‘Views’ pane select service_ssl and click the ‘Create’ button to generate a certificate signing request (CSR). Screen as shown below will pop-up. Maintain the entries in the screen below.
4. Give an entry name. Select the store certificate checkbox.
5. Click on ‘Generate’ button.
6. Two entries will be created in ‘Entries’ pane as shown in the screen below.

7. Place the cursor on the private key pair entry in ‘Entries’ pane and click on ‘Generate CSR request’ and save the file with a ‘.csr’ extension. (Note – you will have to type the extension yourself, the visual administrator will not add it to the file). You have created a certificate signing request. The Certification Authority (CA) will be issuing a signed certificate against this .csr file.
8. Now send the .csr file created to the certificate signing authority. The CA will then send you the signed certificate.
9. After receiving the signed certificate change the extension of the file (if not already changed) to ‘.crt’ (different CAs send files with different extensions, please change the extension to .crt).
10. Place the cursor on the private key pair entry and click the Load button and load the signed certificate into the system.

This ends the process if the certificate sent by the CA also contains the intermediate certificate. If that is not the case the intermediate certificate needs to be installed separately as described in two additional steps (11 and 12) below:

11. Download the intermediate certificate from the web site of signing authority (The CA should be able to provide you with the URL for downloading intermediate certificate) and store it as a ‘.crt’ file.
12. Now place the cursor again on the private key pair entry and click the load button. This loads the intermediate certificate into the system.

This completes the procedure of loading the certificates in the system. The entire certificate chain of root certificate, intermediate certificate and client certificate is now installed successfully.

Now we need to configure the SSL service to use this newly installed cetrtificate:

The main Moto of this blog was which explains FTP Secure configuration.

FTPS (also known as FTP Secure and FTP-SSL) is an extension to the commonly used File Transport Protocol(FTP) that’s adds support for the Transport Layer Security(TLS) and the Secure Sockets Layer(SSL) cryptographic protocols.

FTPS should not be confused with the SSH File Transfer Protocol (SFTP), an incompatible secure File transfer sub system for the Secure Shell (SSH) protocol. It is also different from the Secure FTP, the practice of tunneling FTP through an SSH Connection.

Before configuring Communication channel, we have to deploy the certificates

1) SAP Java Cryptographic Toolkit has to be deployed in J2EE Engine.

2) Public key Certificate (SSL Certificate) which is provided by FTPS Server has to be deployed in J2EE Engine.

3) The CA certificate used to sign the server certificate must be added to the Trusted As key store view in J2EE Engine. (For PI7.1/7.0 no needs to deploy these toolkit and CA certificate. Because those will be already present in the Server itself).

Take basis people help to deploy required certificates in PI J2EE server.

FTPS (FTP Using/TLS) for control connection: The FTP control connection is protected using TLS/SSL (Transport Layer Security/Secure Sockets Layer).File transfer is unencrypted.

FTPS (FTP Using SSL/TLS) for Control and Data Connection:

All communication with the FTP server is encrypted and uses TLS/SSL.

3) In Command Order Specifies the sequence of commands used to authenticate and secure the connection. Retain the default setting. Only adjust the sequence of commands to match those expected of the FTP server if you encounter problems with the FTP connection.

AUTHTLS: Defines the authentication mechanism used for the current FTP session.

USER: Sends a User Logon ID to the Server

PASS: Sends a Password to the Server

PBSZ: Defines the largest buffer protection buffer size to be used for application-level encoded data sent or received on the data connection.

PROT : Defines the protection used for FTP data connections.

4) Use X.509 Certificate for Client Authentication, Set this indicator if the adapter, in contrast to the FTP server, is to use X.509 certificate and public-key cryptography to authenticate itself. The corresponding key/certificate pair must previously be saved in a keystore view of the J2EE server.

Give The Details in KeyStore and x.509 Certificate by selecting the help. If we already deployed the Certificates in J2EE Engine, help will be provided and we have to select from that as shown below.

Enter the Keystore and the X.509 Certificate and Private Key. To do this, you can use the input help.

Keystore contains certificates that are used for authentication and encryption.

5) An X.509 client certificate is a digital “identification card” for use in the Internet, also known as a public-key certificate. So public key Certificate has to be selected.

6) Final configuration looks like below.

The FTPS configuration for both sender and receiver communication channels is similar.