• PGPDecryption
• PGPEncryption

• https://www.kellton.com/kellton-tech-blog/encryption-decryption-data-pretty-good-privacy-sap-pgp-modules
• https://blogs.sap.com/2012/04/10/pgpdecryption-a-simple-how-to-guide/
• https://jaehoo.wordpress.com/2022/07/27/sap-pi-po-sftp-to-sftp-scenario-with-pgp-encryption-and-decryption/

You are using a sender Java IDoc (IDoc_AAE) communication channel that requires system and/or application acknowledgements.

Some limitations exist for the ALEAUD IDoc handling with XI acknowedgemnets, including:

• No extended information from the ALEAUD IDoc (e.g. text, parameters, etc.) is transmitted to the sender system.
• The correlation between the XI Acknowledgement / ALEAUD IDoc and the original referenced IDoc is based on XI Message ID, instead of IDoc number.

XI Acknowledgements contain header data for the referenced XI message. The correlation is done against XI Message Id. It is not possible to transfer other specific information contained in ALEAUD IDocs as no payload is added to the XI Acknowledgement.

Also if handling received ALEAUD IDocs it is not possible to correlate them to the exact IDoc document - rather than that the correlation happens on XI Message level, thus ALEAUDs are sent for all IDocs in an XI message instead of to the only corresponding IDoc document.

An enhanced handling of XI Acknowledgements in the Java IDoc Adapter is introduced:

1. IDoc_AAE sender channel - non IDoc_AAE Receiver channel

• One IDoc received (one IDoc document in one XI message): when acknowledgement is sent by the receiver adapter/system it is uniquely correlated to the IDoc document (as it is the only one in the XI Message) -> ALEAUD is created with a status corresponding to the XI Acknowledgement type and sent to the sender system
• Several IDocs received (n IDoc documents in one XI message): when acknowledgement is sent by the receiver adapter/system it is correlated to each IDoc document in the XI message to which the XI Acknowledgement refers -> multiple ALEAUDs are created with the same status corresponding to the XI Acknowledgement type and they are all sent to the sender system.

2. non IDoc_AAE sender channel - IDoc_AAE receiver channel

As each adapter the IDoc receiver supports system acknowledgements. If required XI Acknowledgements are sent for each IDoc document in the IDoc document list contained in the processed XI message. Additionally, the IDoc receiver adapter adds an "aleaud.xml" payload to the generated XI Acknowledgements that is visible in the message monitoring UIs - it contains information for the concrete IDoc number which it acknowledges. The payload contains a valid IDoc-XML of the ALEAUD (ALEAUD01) with the necessary information to be sent to the sender system. It is up to the sender adapter if this payload will be interpreted or not.

3. IDoc_AAE Sender channel - IDoc_AAE receiver channel

• System XI Acknowledgements sent by the receiver IDoc Adapter: For each IDoc document in the XI Message a separate XI Acknowledgement is sent with an additional "aleaud.xml" payload containing specific ALEAUD IDoc-XML information that is sent to the sender system.
• ALEAUD IDocs sent from the receiver system: Each ALEAUD IDoc document is converted to one or several XI Acknowledgements; for each type - MESTYP - and for each status a separate XI Acknowledgement is created containing a valid ALEAUD IDoc-XML payload (due to the separation each payload contains a 'flat' structure - exactly one E1ADHDR and one E1STATE segments). The sender adapter transmits each XI Acknowledgement with the contained payload to the sender system.

The following conversions between the XI Acknowledgement type and the ALEAUD status code are done during processing:

Conversion from XI Acknowledgement type to ALEAUD status code:

• System OK -> 50
• System Error Transient -> 56
• System Error Permanent -> 68
• Application OK -> 53
• Application Error -> 51
• Application not supported -> 50

Conversion from ALEAUD status code to XI Acknowledgement type:

• 50 -> System OK
• 52, 53 -> Application OK
• 51 -> Application Error
• other codes -> System Error Transient

REST adapter require multipart/form-data requests with additional key-value pairs for several scenarios.

The upper adapters construct such requests by serializing the XI message and its attachment to the desired format.

With this SAP Note new Adapter Framework modules that allow data attachments to be added to XI message based on fixed or dynamic configurations are introduced.

To use this module, you have to do the following configuration of your channel:

AF_Modules/FormDataBean

The following parameters are used for this module:

key.<ID>                       - the name for the Content-Disposition attribute
value.<ID>                    - the data body for the attachment
location.<ID>                - (optional) you can choose from two predefined values:
	"fixed" (default value) - it will get the "value.anyValue" parameter value and use it as it is.
	"headers" - it will get the "value.anyValue" parameter value and use it to match a Dynamic Header.
	The value of the matched Dynamic Header will be used as data body for the attachment.
	The required format for "value.anyValue" is: namespace#headerName

contentType.<ID>          - (optional) value of Content-Type attribute header
contentEncoding.<ID>   - (optional) value of Content-Transfer-Encoding attribute header

<ID> could be any word or number by your choice.

Module parameters

• key.0 = anyString
• value.0 = AttributeBody
• location.0 = fixed

--SAP_xxx_END
content-disposition: form-data; name="anyString"
AttributeBody
--SAP_xxx_END--