cancel
Showing results for 
Search instead for 
Did you mean: 

SAP PI as JMS Provider - Queue Encryption

Former Member
0 Kudos

Hello -

The scenarios are SAP ECC(proxy) --> PI -->Legacy system (JMS) and Legacy system (JMS) ->PI ->SAP ECC (proxy).

We will be using SAP PI as JMS Provider, like ESB is there an option of Encrypting the Queues in PI?

Thanks and Regards,

Neha Singh

Accepted Solutions (0)

Answers (1)

Answers (1)

vadimklimov
Active Contributor
0 Kudos

Hi Neha,

What kind of encryption are you asking about? Is it transport layer encryption (e.g. usage of SSL to encrypt data transmission) or message layer encryption (encryption of the message content that is sent to a queue)? Or did you mean something different?

For transport layer encryption, you can use P4SEC (P4 SSL) port and underlying SSL based encryption mechanisms for the external system when establishing and using connection to SAP AS Java JMS Provider. You can find more details in Configuring the Use of SSL on the AS Java - Network and Transport Layer Security - SAP Library.

For message layer encryption, in PI, you can use SAP standard adapter module PGPEncryption (which is a part of secure connectivity add-on for PI) for encryption of message content prior to sending it to a JMS queue (see example of its usage described in ). Alternatively, you can also use 3rd party or custom developed adapter modules for message content encryption. Correspondingly, consumer (legacy system) will need to be capable of decrypting corresponding messages.

Apart from security considerations, I would also suggest paying attention to scenarios where built-in JMS Provider of the PI system is used: if it is high volume scenarios, you shall assure they will not have negative stability / performance impact on JMS Provider. Failing to do so and considering PI internal components heavily rely on JMS capabilities and use JMS Provider, its overload or breakdown due to sub-optimal usage in integration scenarios may have very negative impact on the entire PI system operations.

Regards,

Vadim