Skip to Content
Author's profile photo Prateek Raj Srivastava

B2B Add-On PGP module – Learning and POV

SAP released the new B2B Add-On package couple of months back and we have some really informative and descriptive articles about the features and configurations. I must admit that SAP has done a really nice job in terms of documentation available with the download and here on SCN.

We got lucky with the timing and got a chance to use this Add-On to achieve encryption while communicating with external vendors. Although the implementation process went pretty well, there were still some learning which I wanted to share through this blog.


Several Encryption algorithms are supported by PGP module. Here is the list: AES_128, AES_192, AES_256, BLOWFISH, CAST5 (default), DES, 3DES. For the Encryption, it is a pre-requisite to have you the keys generated and stored. The guide referred above have links to create the keys as well. I have some observations based on the documentation:

  • If you generate a key using GPG as mentioned in this link, don’t assume that all the algorithm supported by GPG will also be supported by PGP module. e.g. CAMELLIA128 is supported by GPG but not by PI PGP module.
  • If an unsupported algorithm is used in PI, PI ignores the algorithm and uses the default CAST5 instead. There is no error raised. However, the good thing is that you still see it in as an Audit Log entry


  • Page 14 of the document says “If the JVM doesn‟t have unlimited JCE policy, the algorithms which uses more than 128 bit won‟t be supported”. I tried with AES_128 and it didn’t work with the limited JCE files. As soon as we imported the unrestricted version, it started working.
  • When encryption algo you mention in the channel (other than the default algo) is not supported, no error is generated and the default algorithm is used


  • When the private key is incorrect or not loaded properly, the error received gives you an idea but isn’t friendly enoughPrivateKeyError.jpg
  • The PGP module is intelligent enough to throw appropriate error in case you use provide public key name instead of private key or vice-versa.

Compression Algorithms

PGP supports three compression alogirthms – ZIP, ZLIB and BZIP2. ZLIB is the default algorithm used if you don’t specify the parameter applyCompression in the module chain. We performed some tests to evaluate these compression algorithms. We encrypted a text file 169 MB in size using PGP modules and here are the results.






Of Original













The observations were:

  • BZIP2 provides significant higher compression ratio as compared to ZLIB or ZIP
  • BZIP2 is slightly slower in compressing the files than ZLIB and ZIP.
  • BZIP2 can be comparatively more CPU resource intensive (couldn’t test this).
  • Based on the resource utilization capabilities and speed, we decided to stay with the default ZLIB compression.
  • For achieving more compression ratio with low frequency high volume (size) scenarios, BZIP2 may be used.


In all, I like the PGP adapter module and definitely the fact that it is free. 🙂

  • SAP uses OpenPGP libraries within their new PGP module. This helped in adding all the features and capturing all the exceptions.
  • One thing I didn’t like was the way certificates are stored. I would have preferred NetWeaver Administrator based certificate management instead of still relying on the old methods.
  • Audit log when it traverses through the module is pretty neat and descriptive. Even with minimal parameters you see nice details.


I would like to thank my colleague Jean Patoine who helped me throughout.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Vishnu Prasad K
      Vishnu Prasad K

      Hi Prateek Raj Srivastava,

      A good descriptive blog for PGPEncpytion module. Maybe you could check with the latest SP/patch for PGP module to update this blog accordingly. Also you have not mentioned anything about the PGPDecryption module since the blog heading is about PGP Module itself.

      I would like to point out that using the NWA key storage based mechanism to store the PGP related keys is not straight forward and is cumbersome as it uses X.509 certificate and PCKS format.

      In future, a similar feature might be available.