-
Notifications
You must be signed in to change notification settings - Fork 1
HTTP_AAE adapter module parameters
N.B. Данные параметры адаптера доступны и корректно работают в зависимости от версии, SP и PL компонент системы. Просьба не ругать авторов, если ваша версия компонент ниже требуемого
N.B. Минимальная версия SP указана ниже для каждой версии NetWeaver. Отражён минимальный SP, который содержит указанную функциональность. Функциональность может быть доступна только начиная с определённого PL в рамках указанной или последующих SP. Детали применимости -- см. релевантные ноты
Описанные ниже параметры ведутся через табличную настройку, скрытую за опцией Set Additional Parameters.
| Parameter | Default | Note | Direction | NW 7.31 | NW 7.40 | NW 7.50 |
|---|---|---|---|---|---|---|
| appendFormParamInPayload | false | 2519625 | Sender | SP022 | SP017 | SP005 |
| LogHostDetail | false | 2295686 | Sender | SP016 | SP011 | SP002 |
| ChangeContentType | false | 2203472 | Sender | SP017 | SP012 | SP000 |
| treatNSWithHTTP | false | 1958747 | Sender/Receiver | SP005 | SP002 | SP000 |
| IgnoreCharset | false | 2172535 | Receiver | SP014 | SP009 | SP000 |
| logHostDetails | false | 2295686 | Receiver | SP016 | SP011 | SP002 |
| preferredContentTypeHeader | false | 2284713 | Receiver | SP013 | SP008 | SP001 |
| appendUrlInPayload | false | 1915961 | Receiver | SP009 | SP004 | SP000 |
| URLEscaping | false | 2112188 | Receiver | SP012 | SP007 | SP000 |
| epiLog | <empty> | 2030486 | Receiver | SP012 | SP007 | SP000 |
| proLog | <empty> | 2030486 | Receiver | SP012 | SP007 | SP000 |
| treatRespSuccess | false | 1952605 | Receiver | SP004 | SP002 | SP000 |
| returnContentType | false | 2033044 | Receiver | SP010 | SP005 | SP000 |
| useIAIKSSL | false | 2609930 | Receiver | SP023 | SP018 | SP012 |
| httpsProtocols | SSL | 2393811 | Receiver | SP014 | SP009 | SP002 |
| setAuth | false | 1958104 | Receiver | SP005 | SP002 | SP000 |
| allowCircularRedirects | false | 2161789 | Receiver | SP014 | SP009 | SP000 |
| includeNamespace | false | 2508664 | Receiver | ※ | ※ | SP006 |
| DisplayTargetURL | false | 2295686 | Receiver | SP016 | SP011 | SP002 |
| queryPath | false | 1982331 | Receiver | SP006 | SP005 | SP000 |
| DynamicURLOption | false | 2296781 | Receiver | ※ | ※ | SP004 |
| socketTimeout | 300000 | 1806023 | Receiver | SP007 | SP002 | SP000 |
| connectionTimeout | 300000 | 1806023 | Receiver | SP007 | SP002 | SP000 |
| httpReqXXXX | - | 1873519 | Sender\Receiver | SP008 | SP003 | SP000 |
| httpRespXXXX | - | 1873519 | Sender\Receiver | SP008 | SP003 | SP000 |
| urlXXXX | - | 1873415 | Sender\Receiver | SP008 | SP003 | SP000 |
PI HTTP_AAE Adapter is being used in the business scenario for message processing. During processing, it is noticed, that, the HTTP_AAE adapter messages are going into delivering status for long time as the adapter doesn't set any socket timeout on HTTP connection. In case of network issues this could lead to a problem where connection will not be closed for indefinite time and wait until the processing gets completed.
Advance development
We introduce two timeout parameters:
-
connectionTimeout: Determines the timeout in milliseconds until a connection is established. A timeout value of zero is interpreted as an infinite timeout. This parameter expects a value of type java.lang.Integer. If this parameter is not set, connect operations will time out after 10 secs (i.e., 10000 milliseconds)
-
socketTimeout: Defines the socket timeout (SO_TIMEOUT) in milliseconds, which is the timeout for waiting for data. A timeout value of zero is interpreted as an infinite timeout. This parameter expects a value of type java.lang.Integer. If this parameter is not set, read operations will time out after 5mins (i.e., 300000 milliseconds).
In the channel configuration of HTTP_AAE Sender/Receiver Adapter, HTTP Request/Response header parameters has been configured. During runtime, the HTTP Header Fields will be checked and XI dynamic header values will be copied into HTTP headers.
As per the current implementation, only 6 Request/Response header parameter can be configured. If more than 6 Request/Response header parameters are required to set, the corresponding values cannot be fetched from the channel configuration.
Advance Development
The HTTP_AAE code has been enhanced so that more than 6 Request/Response header parameters can be configured in the HTTP_AAE adapter(Sender/Receiver) channel configuration.
In order to configure more than 6 Request/Response header parameters, 'Additional Parameter' table should be used. In order to make the channel configurations consistent at sender & receiver, the 'Key' (in the Key/Value pair) should be same both the sides.
Http Request Header and Http Response Header parameters must be configured with a prefix "httpReq" and "httpResp" respectively.
In the channel configuration of HTTP_AAE Sender/Receiver Adapter, HTTP URL parameters has been configured for the Destination. At runtime these HTTP URL parameters are mapped to their respective dynamic headers in the corresponding URL parameter fields.
As per the current implementation, only 6 URL parameter can be configured. If more than 6 URL parameters are required to set in the URL (i.e. in the path), the corresponding values cannot be fetched from the channel configuration.
Advanced Development
Now the HTTP_AAE code has been enhanced so that more than 6 URL parameters can be configured in the HTTP_AAE adapter(Sender/Receiver) channel configuration.
In order to configure more than 6 URL parameters, 'Additional Parameter' table should be used. In order to make the channel configurations consistent at sender & receiver, the 'Key' (in the Key/Value pair) should be same both the sides. URL parameters must be configured with a prefix "url".
PI HTTP_AAE receiver Adapter is being used in the business scenario for message processing. During processing, it is noticed, that, the HTTP_AAE adapter messages are failing with improper HTTP header value format of Content-Type. This is because of RFC-7230 specification.
Currently, the HTTP header of Content-Type looks like,
Content-Type: multipart/form-data;
boundary="----=_Part_6_706482103.1456227961952"
Recommended HTTP header of Content-Type,
Content-Type: multipart/form-data;boundary="----=_Part_6_706482103.1456227961952"
Advance Development.
As per the RFC-7230 specification, the HTTP header field value shouldn't be extended in multiple lines by preceding each extra line with atleast one space or horizontal tab (obs-fold). A sender MUST NOT generate a message that includes line folding (i.e., that has any field-value that contains a match to the obs-fold rule) unless the message is intended for packaging within the message/http media type.
For more details, please refer the link: https://www.rfc-editor.org/rfc/rfc7230.txt.
We introduced a parameter preferredContentTypeHeader. Please set the parameter with value true to activate the format of the HTTP header, Content-Type.
HTTP_AAE Adapter is being used at sender side in the business scenario for message processing. In the channel configuration when "Set Form" is checked, then there only one "Form Parameter" can be configured.
Bug Fix.
In Plain HTTP Adapter, there is a feature to configure multiple form parameter in the channel configuration for sender HTTP adapter, and the value of this parameter can be sent as the query string, and the same gets copied into the final payload. Currently this feature is only available in Plain HTTP adapter(ABAP) but not implemented in Java HTTP Adapter(HTTP_AAE).
Under the "General Tab" "Set Form" should be checked and the "Main Payload Parameter Name" should be configured in the textbox at the sender side configuration of HTTP_AAE adapter. Under the "Advanced Tab" set an additional parameter appendFormParamInPayload and set it to true.
In order to activate this feature, please add the parameter appendFormParamInPayload and set it to value true in the additional parameter table at sender side HTTP_AAE adapter configuration. Default value of this parameter is set to false to prevent the existing functionalities.
Multiple form parameters can be configured at the sender side configuration. Each and every parameter should be seperated by semicolon (;), for example: md1;md2;md3;md4.... and so on.
When Java HTTP adapter (HTTP_AAE) is used to process HTTP requests at receiver side, currently there is no option to configure for 'Prolog' and 'Epilog'. This feature is available in plain HTTP adapter (ABAP). So when you are migrating from PI 7.11 to PI 7.31 then you will be missing this feature.
Advance Development
PI 7.31 HTTP_AAE adapter has to be configured at receiver side.
Now the HTTP_AAE code has been enhanced so that you can configure both 'Prolog' and 'Epilog' in the channel configuration of HTTP_AAE receiver adapter.
In additional parameter table, please configure the below parameters:
- proLog
- epiLog
Both are case-sensitive. And by default their values are <empty>.
HTTP_AAE Adapter has been used in the business scenario for message processing. During message processing, it has been noticed that the information about IP Address / Hostname for the incoming/outgoing HTTP request is not logged in the Audit log or traces. Also, at the receiver side, the final target url which is being formed after adding the URL parameters and other query parameters is not logged in the traces.
Advance Development.
There is a requirements where the hostname and port for the incoming and outgoing HTTP request should be displayed in the Audit log as well as in the traces. Also, there is another requirement where the final modified URL should be displayed in the traces.
The HTTP_AAE code has been enhanced to achieve the following requirements:
- The hostname and port for the incoming/outgoing HTTP request will be logged in the Audit log as well as in the traces.
An advanced mode parameter LogHostDetail has been introduced. If this parameter is set to true, then the hostname and port detail for the incoming/outgoing HTTP request will be displayed in the Audit log and traces. The default value for the parameter LogHostDetail is false.
- The modified target URL will be displayed in the traces.
An advanced mode parameter DisplayTargetURL has been introduced. If this parameter is set to true, then the final target url which is being formed after adding the URL parameters and other query parameters will be logged in the traces. The default value for the parameter DisplayTargetURL is false.
HTTP_AAE Adapter has been used in the business scenario for message processing. During message processing, it has been noticed that there is no content type set for the incoming HTTP request to the HTTP_AAE sender. In plain HTTP adapter (ABAP), content-type of the incoming HTTP request is set to application/xml. After migrating from PI <7.11 to PI >7.31 this feature will be missing.
Advance Development.
There is a requirement where the incoming HTTP request to the HTTP_AAE sender should be set to application/xml.
The HTTP_AAE code has been enhanced so that the content-type of the incoming HTTP request is set to application/xml.
An advanced mode parameter ChangeContentType has been introduced. If this parameter is set to true, then the special characters will be masked. Else, normal execution continues i.e. the file will be sent to the receiving system without any modification.
The default value for the parameter ChangeContentType is false.
PI HTTP_AAE Adapter is being used in the business scenario for message processing. And ASMA properties have been configured in HTTP_AAE adapter channel for namespace. It is observed that the namespace is always comes with default one i.e., http://sap.com/xi/XI/System instead of http://sap.com/xi/XI/System/HTTP_AAE as it is for HTTP_AAE adapter.
Advance Development. ASMA properties has to be configured in order to observe the change.
We have code changes in PI HTTP_AAE adapter in order to include the namespace http://sap.com/xi/XI/System/HTTP_AAE. For this, you have to configure an advanced mode table parameter i.e., treatNSWithHTTP to true. By default the value is false.
HTTP_AAE Adapter has been used in the business scenario for message processing. During message processing, it has been noticed that, the parameter Character Encoding is set to UTF-8 (i.e. charset=UTF-8) in the header of the message even if it is not specified in the channel configuration. Due to the specification of this parameter in the header of the message, the url called by the HTTP post refuses the content and the message processing fails.
Advance Development
There is a requirement to avoid the parameter Character Encoding completely.
An advanced mode parameter IgnoreCharset has been introduced. If this parameter is set to true, then the character encoding will not be set in the header of the message. Else, normal execution continues i.e. the parameter charset is set to UTF-8 in case if it is not specified in the channel configuration.
The default value for the parameter IgnoreCharset is false.
HTTP_AAE Adapter has been used in the business scenario for message processing. During message processing, it has been noticed that when there is an empty file being processed from the HTTP_AAE channel, then the output received at the receiver is empty.
Advance Development
There is a requirement where the URL parameters should be appended with the payload as plain text in the output file whenever the payload of the file is found empty. Also, if there is some payload in the incoming file, then the URL parameters should not be added in the output file.
The HTTP_AAE code has been enhanced so that the URL parameters will be appended with the payload as plain text in the output whenever the payload is found empty. If there is some payload, then the URL parameters will not be added in the output file.
An advanced mode parameter appendUrlInPayload has been introduced. If this parameter is set to true, then whenever the payload is found empty, the URL parameters will be appended with the payload as plain text in the output file. Else normal execution continues i.e. empty file will be sent to the receiving system without any modification.
The default value for the parameter appendUrlInPayload is false.
HTTP_AAE Adapter has been used in the business scenario for message processing. While configuring the HTTP_AAE receiver channel, it has been noticed that there is no option available to mask the special characters of message content. This feature is available in plain HTTP adapter (ABAP). So after migrating from PI <7.11 to PI >7.31 this feature will be missing.
Advance Development.
There is a requirement where the special characters available in the message content should be masked.
The HTTP_AAE code has been enhanced so that the special characters can be masked by following the below mentioned rules:
- Separate individual form elements, including their data, by using the ampersand (&).
- Separate the name and data of a form element by using an equals sign (=).
- Replace blanks in the entered data (for example, in multiple words) by using a plus sign (+).
- Rewrite all characters with the (enhanced) ASCII values 128 to 255 (hexadecimal 80 to FF) by using a hexadecimal character sequence, starting with a percentage sign (%) and followed by the hexadecimal value of the character.
- All characters that occur in these rules as control characters (&, +, =, and %) are also rewritten by using a hexadecimal character sequence in the same way as higher value ASCII characters.
An advanced mode parameter URLEscaping has been introduced. If this parameter is set to true, then the special characters will be masked. Else normal execution continues i.e. the file will be sent to the receiving system without any modification.
The default value for the parameter URLEscaping is false.
HTTP_AAE Adapter has been used in the business scenario for message processing. During message processing, it has been noticed that when the HTTP request is sent from an external application to the Sender HTTP_AAE Adapter and it returns either 203, 204, 205, 206 or 207 response code, then the HTTP request fails with an exception. Stack trace for the same can be seen in the HTTP body.
Program Error
This issue has been resolved by code changes.
An advanced mode parameter treatRespSuccess has been introduced. If this parameter is set to true in the advanced mode table, the response codes 203, 204, 205, 206 or 207 will also be treated as successful response.
When Java HTTP adapter (HTTP_AAE) is used to process HTTP requests at receiver side in Synchronouse, currently we are not carrying forwarding the content-type of the response message to the sender. Instead the default content-type is being set by XI protocol. In some scenarios, it is required to carry forward the content-type of the response message to the sender as it is.
Program Error
HTTP_AAE receiver channel has to be configured and a synchronous HTTP request has to be sent to the receiver channel.
Now HTTP_AAE receiver can also carry forward the content-type of the response message back to the sender as it is. For this an additional table parameter returnContentType has to be set with value true. Default value is false.
Currently HTTP_AAE adapter supports TLSv1.2 in SAP NetWeaver 750 only with JVM 1.8 which supports TLSv1.2 by default. Lower SAP NetWeaver release uses JVM 1.6 for SSL/TLS connections which supports TLSv1.1.
Advanced Development
With this SAP Note the HTTP_AAE receiver chanel is enabled to use IAIK SSL implementation. To use IAIK library for establishing HTTPS conenction to the target server use an additional parameter useIAIKSSL and set the value to true.
- Parameter Name: useIAIKSSL
- Parameter Value: true or false (default: false)
If this parameter is set to true, then the IAIK library will be used to establish connection to the target server. Otherwise the old implementation based on JDK SSL will be used.
HTTP_AAE Adapter is being used in the business scenario for message processing at receiver side. When HTTP request is sent over HTTPS, then by default PI HTTP_AAE adapter considers only SSL while getting the instance of SSL context. This works fine for older JVM versions as they supported only SSL earlier, but with the release of JVM 7 and JVM 8 SSL support was extended to TLSv1.1 and TLSv1.2.
With the release of JVM 7 and JVM 8 (JDK1.7 & JDK1.8) JVMs have extended their support to TLS1.1 and TLS1.2 in the latest updates of JDKs (1.7 & 1.8). Hence PI HTTP_AAE adapter should also extend its support to TLS1.1 & TLS1.2.
PI HTTP_AAE adapter should be configured at receiver side to process HTTP requests in HTTPS with latest JDK environments.
This issue has been resolved by code correction.
Please set the required SSL/TLS value using an additional parameter httpsProtocols under the advanced tab of the HTTP_AAE receiver channel configuration. If the parameter is not found then the default value SSL is used.
This additional parameter httpsProtocols should be assigned one of the following values:
- httpsProtocols = TLSv1
- httpsProtocols = TLSv1.1
- httpsProtocols = TLSv1.2
Note: Support matrix for TLS is given below.
- JDK 6
- TLS v1.1 (JDK 6 update 111 and above)
- TLSv1 (default)
- JDK 7
- TLSv1.2
- TLSv1.1
- TLSv1 (default)
- JDK 8
- TLSv1.2 (default)
- TLSv1.1
- TLSv1
HTTP_AAE Adapter has been used in the business scenario for message processing. During message processing, it has been noticed that when the message is sent to the Receiver HTTP_AAE Adapter, then the message fails with exception ERROR_SENDING_HTTP_REQUEST. Stack trace for the same can be seen in the HTTP body.
Program Error
This issue has been resolved by code changes.
An advanced mode parameter setAuth has been introduced. If this parameter is set to true in the advanced mode table, the basic authentication will be performed when SSL is not enabled.
HTTP_AAE Adapter has been used in the business scenario for message processing. While message processing, it has been noticed that messages are failing with following error: ERROR_SENDING_HTTP_REQUEST-Message Processing Failed. Reason : com.sap.httpclient.exception.CircularRedirectException: Circular redirect to..
Advance development.
PI 7.31 HTTP_AAE adapter has to be configured at receiver side.
HTTP_AAE code has been enhanced so that the HttpClient parameter allow-circular-redirects can be enabled.
An advanced mode parameter allowCircularRedirects has been introduced. If this parameter is set to 'true', then the HTTPClent parameter “allow-circular-redirects” will be enabled. Else, normal execution continues i.e. circular redirects will not be allowed.
The default value for the parameter allowCircularRedirects is false.
When HTTP_AAE adapter is configured at receiver side and Query Parameter feature is activated, to add some extra query parameters to target URL, namespace details are not added automatically when Receiver Interface option is selected. This feature was available in plain HTTP adapter (ABAP) but missing in HTTP_AAE adapter (JAVA).
Programming error.
Use HTTP_AAE adapter at receiver side with Query Parameter option is active and Receiver Interface is selected.
A new parameter has been introduced to activate this feature includeNamespace whose value is false by default. To activate the feature, please set this parameter in additional parameter table with value true. Please check the attachments sections for parameter configuration in HTTP_AAE receiver channel.
HTTP_AAE Adapter is being used in the business scenario for message processing. During processing, it is noticed that HTTP request which is sent from receiver HTTP_AAE adapter, removes the string of the URL path (configured) starting from "?" if it doesn't contain any query parameters.
Currently this feature is not available in Java HTTP adapter(HTTP_AAE).
Special Development
Now the HTTP_AAE code has been enhanced so that it retains the URL path even though the it doesn't contain any query parameters. In order to have this feature, please configure an additional parameter queryPath to true. By default the value is false.
HTTP_AAE Adapter is being used at receiver side in the business scenario for message processing. During message processing, it has been noticed that the path which is configured in the receiver channel configuration is always static.
Advance development.
In Plain HTTP Adapter, we have a feature called Dynamic URL where the path configured in the receiver HTTP adapter channel will be replaced with the one which is configured in Dynamic Configuration. Currently this feature is only available in Plain HTTP adapter (ABAP) but not implemented in Java HTTP Adapter (HTTP_AAE).
Dynamic Configuration option (Adapter-specific Message Properties) should be enabled at both sender and receiver side configuration of HTTP_AAE adapter.
Technically, we have to add a record in DynamicConfiguration header with the below details: Considering the dynamic URL as /http/dynamic/url for example.
<SAP:DynamicConfiguration>
<SAP:Record namespace="http://sap.com/xi/XI/System/HTTP_AAE" name="TargetURL">/http/dynamic/url</SAP:Record>
</SAP:DynamicConfiguration>
Please refer the SAP note 1386621 for more details.
The record should contact the name as TargetURL and value (/http/dynamic/url) in the record should be the dynamic URL.
This enhancement can be used only when there is request to change the path of the target HTTP URL via Dynamic Configuration.
In order to activate this feature, please add the parameter DynamicURLOption with value true in the additional parameter table in both sender and receiver side HTTP_AAE adapter configuration.
When the parameter is enabled on both sender and receiver side, the incoming HTTP request which is coming via HTTP URL should contain the dynamic URL path as a URL parameter in HTTP URL as given below:
http://<host>:<port>/HttpAdapter/HttpMessageServlet?interfaceNamespace=<InterfaceNamespace-Name>&interface=<Interface-Name>&senderService=<Sender-Service>&senderParty=<Sender-Party>&receiverParty=<Receiver-Party>&receiverService=<Receiver-Service>&qos=<QOS>&path=<Dynamic-URL>
At the end of the HTTP URL an additional URL parameter (&path=) has to be added as shown above.
Note: Please DO NOT use any other URL parameter with name path. And please DO NOT use special characters like '=' , '?' as part of the dynamic URL. This is a limitation from PI HTTP_AAE adapter.