file content conversion in sap pi at receiver general

The problem lies in as we cannot directly embed binary data in XML tags due to different potential parsing problems of the XML parser ( ).

Now these systems could be on the sending side or on the receiving side or could be on both sides where R3 is integrating with SRM CRM.

One of the things that SAP strongly suggests 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.

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.

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.

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.

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.

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.

You have installed the SAP cryptographic libraries as mentioned in the installation guide.

The Keystore and SSL services are enabled.

Maintain the entries in the screen below.

Give an entry name.

Select the store certificate checkbox.

Click on Generate button.

Two entries will be created in Entries pane as shown in the screen below.

The Certification Authority (CA) will be issuing a signed certificate against this.csr file.

Now send the.csr file created to the certificate signing authority.

The CA will then send you the signed certificate.

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

Place the cursor on the private key pair entry and click the Load button and load the signed certificate into the system.

If that is not the case the intermediate certificate needs to be installed separately as described in two additional steps (11 and 12) below.

The entire certificate chain of root certificate, intermediate certificate and client certificate is now installed successfully.

It is also different from the Secure FTP, the practice of tunneling FTP through an SSH Connection.

Because those will be already present in the Server itself).

Only adjust the sequence of commands to match those expected of the FTP server if you encounter problems with the FTP connection.

The corresponding keycertificate pair must previously be saved in a keystore view of the J2EE server.

If we already deployed the Certificates in J2EE Engine, help will be provided and we have to select from that as shown below.

File Content Conversion In Sap Pi At Receiver General