N.B. Данные параметры адаптера доступны и корректно работают в зависимости от версии, SP и PL компонент системы. Просьба не ругать авторов, если ваша версия компонент ниже требуемого

N.B. Минимальная версия SP указана ниже для каждой версии NetWeaver. Отражён минимальный SP, который содержит указанную функциональность. Функциональность может быть доступна только начиная с определённого PL в рамках указанной или последующих SP. Детали применимости -- см. релевантные ноты

You use PI REST receiver channel with configured Custom Error handling and module property setAppErrorOnCustomMessage is set to true.

You observe that the fault message mapping is not triggered and error is thrown because the normal mapping is executed.

The fault mapping is not executed, because not all the needed fault interface information is set for the XI ApplicationError response message.

When the property setAppErrorOnCustomMessage is with value true, following two module parameters has been provided for the 'rest' module to define the fault interface information:

• Parameter name: faultInterface
• Parameter value: name of the response fault interface for the fault mapping

and

• Parameter name: faultInterfaceNS
• Parameter value: response fault interface namespace

You are using REST receiver channel and want to invoke HTTP/2 enabled endpoints.

Currently supported by REST adapter HTTP Clients (SAP HttpClient and Apache HTTP Client 4.x) do not support HTTP/2.

From NetWeaver 7.50 SP20, REST adapter has updated the Apache HTTP Client to version 5.0.2, which supports HTTP/2. To enable the HTTP/2 support in REST adapter, add the following module parameter for the module with key 'rest':

• Parameter name: useSAPHttpLibrary
• Parameter value: apache_http2

Save and activate the changes.

Some implementations that support both HTTP/1.x and HTTP/2, may require forcing use of HTTP/2. You can configure this if you add the following module parameter for the module with key 'rest':

• Parameter name: http2.version
• Parameter value: force

Save and activate the changes.

If you want to use the Expect HTTP request header, you should enable it (for any HTTP Client and HTTP version). To enable this header, add the following module parameter for the module with key 'rest':

• Parameter name: http.expectContinue
• Parameter value: true

Save and activate the changes.

Currently the support for TLSv1.2 for REST adapter is enabled only in SAP NetWeaver 7.50 with JVM 1.8 which supports TLSv1.2 by default. The lower NetWeaver releases are working JVM 1.6 which supports maximum TLSv1.1.

The recommended SSL implementation in SAP NetWeaver is based on IAIK library which has introduced TLSv1.2 support with SAP Note 2284059. In order REST adapter to support TLSv1.2 for lower NetWeaver versions, with SAP Note 2229837 the JVM SSL implementation has been replaced with IAIK SSL implementation. Due to configuration and infrastructure restrictions IAIK SSL implementation in REST adapter is ignoring TLSv1.2 configuration even if configured and supported by the SSL provider.

This SAP Note introduces program correction that allows REST adapter to configure and use TLSv1.2. By default if no configurations are made, REST adapter relies on the default IAIK SSL settings, meaning that it will try to perform handshake using maximum supported by him version. You can configure following module parameters to control underlying SSL provider:

1. Configuration of the min/max supported SSL/TLS version - both parameters should be defined in order configuration to take effect:

• Parameter Name: maxSSLVersion

• Parameter Value: one of following values

• Parameter Name: minSSLVersion

• Parameter Value: one of following values

Available values:

• SSL30
• TLS10
• TLS11
• TLS12

2. Checks for the CA flag of the intermediate and root certificates when required:

• Parameter Name: validateBasicConstraints
• Parameter Value: true or false (default: false)

You use PI and have REST sender or receiver channel that has configured conversion of the request/response message from JSON to XML. When the JSON document contains illegal XML 1.0 symbols then you observe errors like: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0xxxxx) in text to output (in xml 1.1, could output as a character entity)

The reson for the upper error is that the JSON document contains symbols that are not allowed by XML 1.0 specification (https://www.w3.org/TR/xml/#charsets). With SAP Note 2378808 is introduced an ability for REST adapter to convert XML1.0 to XML 1.1 documents, but it may turn out that later mapping programs may fail due to limitation of the PI Mapping Runtime to work with XML 1.1 documents.

With this SAP Note a new ability of the REST adapter to escape non-XML 1.0 symbols from the JSON payload has been introduced. To activate the escape of non-XML 1.0 symbols from payload you can specify the following parameters of the 'rest'/'sap' modules in the module configuration tab of the REST channel:

Activate the escape of the non-XML 1.0 symbols from JSON payload:

• Parameter name: escapeNonXML10Symbols
• Parameter value: true or false (default is false)

Specify the character used to escape the non-XML 1.0 symbols:

• Parameter name: escapeSequence
• Parameter value: any allowed XML 1.1 character sequence (default value is empty string "")

Specify if the REST adapter should escape restricted symbols (as defined in https://www.w3.org/TR/xml/#charsets)

• Parameter name: escapeRestricted
• Parameter value: true or false (default is false)

You use REST Poller channel with inbound data type JSON and enabled options for Message Split. You receive a JSON response message, which starts with top level array like:

example:

[
   {
      "object1": "value1",
      "arrayObject": [{"innerObject1":"innerValue1"}]
   },
   {
      "object2": "value2",
      "arrayObject": [{"innerObject2":"innerValue2"}]
   }
]

As a result, you may observe the following error:

Fatal error while processing inbound message. com.sap.aii.adapter.rest.ejb.parse.InvalidJSonContent: Invalid JSON message content used; Message: "A JSONObject text must begin with '{' at character 1 of [{....

By design the REST Poller channel expects a top-level JSON Object for the option 'Message Split' and cannot handle message with top-level JSON Array.

With this SAP Note new module property is introduced. It allows you to wrap the inbound JSON message with JSON Object, which name you have specified. You can configure the following module parameter:

• Parameter Name: addTopLevelJSONObject
• Parameter Value: name

Note that the name you specify as a value will be used for name of the top-level JSON Object (ex. {"name": original JSON message}) The JSONPath expression you have configured in "Array Containing Messages" field should contain the new top-level array name. Valid JSONPath expressions for the above example are:

1. Split by top-level array: $.name or name (both configuration are correct)

result message1:

{
   "object1": "value1",
   "arrayObject": [{"innerObject1":"innerValue1"}]
}

result message2:

{
   "object2": "value2",
   "arrayObject": [{"innerObject2":"innerValue2"}]
}

2. Split by inner array: $.name[0].arrayObject or name[0].arrayObject (both configuration are correct)

result message1:

{"innerObject1":"innerValue1"}

You are using REST receiver channel and have configured OAuth 2.0 Resource Owner Password Credentials Grant flow. Your partner server does not support Authorization Basic HTTP Header and there is no configuration which to exclude this header.

As per specification: The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password.

With this SAP Note a new module parameter is defined to the REST receiver channel that allows you to specify how the user authentication is requested from the partner authorization server:

• Parameter name: Oauth20AutorizationServerRequestType
• Parameter value: header or query or none (default: header)

Use the default value header and the fields Authorization Server Username and Authorization Server Password will be used for creation Basic Authorization HTTP Header.

Use value query and the fields Authorization Server Username and Authorization Server Password will be used for client_id and client_secret in the OAuth query string. Do not use field Resource Owner Client ID. This will cause to have the client_id twice in the query string.

Use value none and the fields Authorization Server Username and Authorization Server Password will be ignored and no Basic Authorization HTTP Header will be sent.

You are using PI REST receiver channel and you connect to the partner server using SSL via proxy. You observe that after applying SAP Note 2686163 the partner server reject some of the requests.

The reason for this behavior is that with SAP Note 2686163, the partner server port is always added to the HTTP Host header even if the port s the default for the used URI scheme (for example port 80 for HTTP and 443 for HTTPS).

With this SAP Note a new module parameter has been introduced that allows the default schema port to not be added to the HTTP Host header. To enable this feature, open Modules tab of the REST receiver channel, and add following module parameter:

• Parameter Name: doNotSendDefaultPort
• Parameter Value: true or false (default is false - the port will be added to the Host header)

You use PI REST receiver channel and have configured conversion of the JSON result and custom error handler that uses the response HTTP result. After you have applied SAP Note 2420418 you observe that when the custom error handling is triggered, the generated response message might be not always correct and might lead later to problems during mapping.

With SAP Note 2420418 the HTTP result is converted using the configuration for the regular JSON response message and later merged with the custom error message. This may lead, for example, to following problems:

• Missing data from the HTTP response - if the HTTP result JSON message is in format like {"xxx1":"yyy1", "xxx2", "yyy2", ....}. Then the result XML message contains only the first element of the JSON message that is, yyy1
• If there is a wrapper XML element configured in the JSON conversion section, the generated HTTP result message is wrapped with this XML element and embedded into the custom error message. This might not be the expected format and may lead later to mapping errors.

With this SAP Note two new module parameters that allow more stricter control are introduced.

Option to skip result conversion even there is such defined for the regular response messages:

• Parameter Name: skipCustomResultConversion
• Parameter Value: true or false (default: false)

Option to merge the converted XML HTTP result message without the wrapping element if such is defined for the JSON conversion:

• Parameter Name: mergeHTTPResultWithoutWrapper
• Parameter Value: true or false (default: false)

You have a synchronous scenario and use REST Sender to REST Receiver channels with defined custom dynamic headers in the request message. In some specific customers scenarios you have to add the custom headers of the request message as XI Dynamic Configuration headers of the response message. After you have applied SAP Note 2179229, you observe that only HTTP response headers are added to the XI response message as XI Dynamic Configuration headers and the request custom headers are missing.

The upper error is side-effect from SAP Note 2179229.

With this SAP Note a new property setRequestXIDynamicHeaders is introduced in the REST Receiver channel. It is a property of the 'rest' module and you have to set it to true in case there are custom headers of the request message required to be set as XI dynamic headers of the response message. Default value is false.

You would like to be able to configure preemptive authentication for your REST Adater scenarios.

In general, preemptive authentication means that the server expects that the authorization credentials will be sent without providing the Unauthorized response. This reduces the load on network and the server itself. You can configure your requests to use or omit the preemptive authentication.

With this SAP Note a new module parameter for REST adapter bean module is implemented, which allows the REST adapter to enable or disable preemptive authentication:

Parameter name: useAuthPreemptive

Parameter value: true \ false (default: false)

You are using PI with configured REST Receiver channel. You observe that when enable http.expectContinue there is no way to omit the Expect Continue header for smaller messages.

Current implementation of the REST Adapter does not have configuration for specifying the message size over which should add the Expect Continue header.

With this SAP Note a new module parameter is introduced for REST Receiver channel. This parameter allows you to specify a message request size over which the header Expect Continue is sent.

Parameter name: http.enableExpectContinueOver

Parameter value: number of bytes (default is 0)

When using this parameter there is no need to enable http.expectContinue separately.

You use Process Integration (PI) and you configure a REST receiver channel, which sends HTTPS request to partner server.

The current implementation of the REST receiver channel uses SSL/TLS implementation from JDK to establish outgoing secure connection. This does not conform with SAP recommendations to use IAIK as default SSL implementation.

With this SAP Note the REST receiver chanel is enabled to use IAIK SSL implementation with the following module property of the 'rest' adapter module:

• Property Name: useJDKSSF
• Property Value: true \ false (default: false)

If this property is set to true, then the old implementation based on JDK SSL is used. Otherwise, the new implementation based on IAIK SSL is used.

You are using REST Sender channel configured request messages in XML format. You notice that an XML prolog such as <?xml version="1.0" encoding="UTF-8" standalone="yes"?> is added to the request payload by default.

This SAP Note corrects Side Effects from SAP Note 3006086 and SAP Note 3027046.

With this SAP Note, the adding of the XML prolog to the request payload becomes optional with the default being that no prolog is added.

To add the XML declaration to both the request and response XML messages, you can specify the following parameters of the 'rest' module in the module configuration tab of the REST Sender channel:

• Parameter name: addXMLDeclaration
• Parameter value: true (default is false)

Additionally, if the prolog is added, the standalone segment of set to "yes" by default. To modify the value of standalone="yes" to standalone="no" for both the request and response XML messages, you can specify the following parameters of the 'rest' module in the module configuration tab of the REST Sender channel:

• Parameter name: setStandaloneNo
• Parameter value: true (default is false)

You are using SAP Process Orchestration and REST Sender adapter. You configured Error Handling for the adapter and you used {message_result} for the response.

You observe that if {message_result} contains characters not valid for JSON (e.g. blank space) they are returned with the response as they are. If the response is configured and expected to be in a particular format (e.g. JSON) that causes invalid format of the response.

Program error

With this change there is a new REST Sender adapter module parameter provided. Applying the configuration below with return {message_result} URL encoded and because of that it will be a valid content if JSON response format is expected.

• Parameter: encodeMessageResultValue
• Value: true

You use Process Integration (PI) and you configure a REST receiver channel with no custom error handling of the response, which sends the payload to the partner server. If the partner server responds with non-200 HTTP code, the original response payload is lost.

When non-200 HTTP response is received by the REST receiver channel, an exception is thrown resulting in the creation of XI Application Error message and the original response payload is lost.

The issue is solved with a program correction in REST adapter that creates XI Application Error message with payload from the original response if there is any. With this SAP Note a new module parameter for REST adapter bean module is implemented, which allows the REST adapter to create XI Application Error message with payload from the original response:

• Parameter name: useResponseErrorMessage
• Parameter value: true or false (default: false)

Note: Use this parameter only for scenarios including synchronous XI messages with Quality of Service BestEffort. For asynchronous XI messages with Quality Of Service ExactlyOnce it could have misleading behavior! If you need to see the server non-20x responses in asynchronous cases, then check configurations from SAP Note 2310654 which allow REST adapter to trace them into the asynchronous request XI message audit log for information purposes.

If the upper parameter is set to true, an XI Application Error message with payload from the original response displays. The request message also is set to XI Application Error, which leads to DLVD state of the message.

You are using SAP PO and have configured REST Sender Channel with Input Message Format Character Set: Manual Value. You are observing that even different Character Set Name is configured the XML payload always try to be read as utf-8. You may observe following error:

Fatal error while processing inbound message. com.sap.aii.af.lib.mp.module.ModuleException: java.lang.RuntimeException: org.xml.sax.SAXParseException; lineNumber: #; columnNumber: ##; Invalid byte 2 of 3-byte UTF-8 sequence

Current implementation of the Rest Sender Channel parse all incoming XML payload with utf-8 by default.

With this SAP Note is introduced new module parameter, that allows you to enforce the REST Sender channel to use the configured character encoding for the incoming XML payload.

• Parameter: readXMLWithConfiguredEncoding
• Value: true (default: false)

You use PI and have configured REST receiver channel for asynchronous interface. Despite the asynchronous nature of the communication it may happen the partner server to rertun non-202 HTTP codes in case of processing errors on server side.

Due to asynchronous nature of the interface no XI response message is produced or expected, which could lead to loss of information about the processing errors returned by the partner server.

With this SAP Note a new module property for the 'rest' module has been introduced that allows partner server non-202 error responses to be traced in message audit log for further analysis.

To enable message audit log traces for the non-202 error responses open for edit the REST channel, go to Module tab, and add following property with module key 'rest':

• Property Name: traceResponse
• Property Value: true or false (default: false - no responses will be traced)

You have configured a REST Sender channel, which sends XML response to the partner server. If the XML payload from the response XI message contains DOCTYPE definitions, they are removed by the REST Adapter, when sending the response to the partner server.

For security reasons (avoiding XML injection), the DOM transformer is configured to ignore DOCTYPE XML entities and produce the response XML document without them.

With this SAP Note a new module parameter for sender REST adapter bean module has been introduced, which allows DOM transformer to include the DOCTYPE entities into the request XML document:

• Parameter name: includeDTDsInOutput
• Parameter value: true or false (default: false)

If parameter is set to true, the DOCTYPE entities are included into the request XML document.

You are using SAP Process Orchestration and REST adapter channel configured with conversion from XML to JSON. You upgrade your system to SAP NetWeaver 7.50 SPS25 or upper and you observe the JSON output is changed:

Input value of XML element: *01/01/2021*
Output value of JSON element after conversion(before update to NW 7.50 SP025): *01\\\/01\\\/2021*
Output value of JSON element after conversion(after update to NW 7.50 SP025): *01/01/2021*

Program error

With this Note the old behavor is returned. With the current change also is provided the option to use the new output format in the REST adapter. To use the output format without the escape character a new channel module parameter is added:

• Parameter: setEscapeForwardSlashAlways
• Value: false

If the value is not configured or have a different value than false (case insensitive) the value is considered as true

You use Process Integration (PI) and you configure REST sender channel with JSON Output Message Format, and selected option Convert XML Payload to JSON. You observe that the converted JSON message contains an Array object with an empty element like [""], but the expected conversion is empty Array [].

The current implementation of the REST Adapter does not allow you to have empty JSON Array with no elements after conversion.

With this SAP Note a new module parameter for REST sender channel is introduced:

• Parameter name: setIgnoreEmptyArrayValues
• Parameter value: true or false (default: false)

It allows you to remove the empty element of a JSON Array type Object after conversion from XML to JSON.

While you use REST receiver channel, the outer element of the XML could be removed from the converted JSON message, but cannot remove any other XML tag.

The current implementation of the REST Adapter does not allow you to remove any other XML elements, except the root element, while you convert it to JSON message.

With this SAP Note a new module parameter called setIgnoredElements for the REST receiver channel is introduced.

It takes the String values defining the XML tag, which should be removed from the JSON message after converting the XML payload. If you have to remove more than one element, use comma as separator (example: one, two). Don't use quotes in the value field.

You use PI REST receiver channel, which is configured to follow HTTP redirects.

You observe that when HTTP response is received with HTTP status code 301, 302 or 307 and a Set-Cookie header, the Set-Cookie header information is not included into the redirected HTTP call.

Current implementation of REST Adapter does not transfer any the cookie information in the redirected HTTP call.

With this SAP Note a new module parameter called transferCookieOnRedirect is introduced for REST receiver channel.

It takes boolean values defining if the given header Set-Cookie from the response should be transferred to Cookie header of the redirected HTTP call. The default value is false and the cookie is not transferred.

You have a REST receiver or REST sender with poll channel and the URL it calls returns an HTTP 301, 302 or 307 responses, expecting that the request will be redirected as per the HTTP specification for further processing. For example many load-balancers are implemented to use this mechanism. However, you observe that in PI REST adapter the redirect HTTP responses are treated as error responses and an exception is thrown so that the message fails instead of proceeding.

The HTTP redirect response support client side (i.e. for REST receivers and REST senders with poll) was missing before this SAP Note. As per the HTTP specification, this are valid responses and should be managed accordingly. In correspondence to this, the new functionality is implemented in the following way:

• All HTTP 310, HTTP 302 and HTTP 307 responses are automatically proceeded for GET and HEAD HTTP requests, as per the specification;
• For all the other supported by the REST adapter HTTP request types (POST, PUT, DELETE) proceeding the processing of the redirect response are also proceeded by default. Since the specification states that a user confirmation should be possible for these request types, a new module parameter is added ProceedRedirects with default value true. If this parameter is missing or has any other value than false, all redirects will be proceeded further.

The parameter can be set as a module parameter of sap.com/com.sap.aii.adapter.rest.app/RESTAdapterBean module for REST receiver channels and of CallSapAdapter module for REST sender channels with poll.

Your PI system must have a version with the functionality available. There are no further steps in case you need to proceed with HTTP redirect responses in all cases.

In case you do not want to proceed with redirects for any reason, you need additionally perform the following manual actions for REST receiver channels in the module chain:

• Module: sap.com/com.sap.aii.adapter.rest.app/RESTAdapterBean
• Parameter: ProceedRedirects
• Value: false

In case you do not want to proceed with redirects for any reason, you need additionally perform the following manual actions for REST sender channels with poll in the module chain:

• Module: CallSapAdapter
• Parameter: ProceedRedirects
• Value: false

You use PI REST Adapter and need to configure REST receiver channel with PATCH HTTP operation, but there is no option for such HTTP method.

The current implementation of PI REST Adapter uses SAP HttpClient library which does not support PATCH method. In order to use PATCH method you should configure the REST receiver channel to use Apache HttpClient library as described in SAP Note 2483432.

With this SAP Note a new module parameter called overrideHttpMethod is introduced for REST receiver channel. It takes string values defining the HTTP method which should be used for the call. By default if no configurations are made the method configured in the channel will be used. You can configure following module parameter to use PATCH method:

• Parameter Name: overrideHttpMethod
• Parameter Value: PATCH

You use REST Poller Channel or REST Receiver Channel with configured Basic Authentication. And the configured user and/or password are containing some non-ASCII symbols. You observe that after the REST executes request call, the server is returning 401 Unauthorized and in the request sent you can find that the base64 encoded authorization header does not match the expected one.

Current implementation of the REST Adapter does encode the credentials using ISO-8859-1 encoding.

With this SAP Note a new module parameter called useUTF8CredentialsEncoding is introduced for REST receiver and REST Poller channel. It allows you to specify which credential encoding to be used UTF-8 or ISO-8859-1:

Parameter Name: useUTF8CredentialsEncoding Parameter Value: false (for encoding with ISO-8859-1) / true (for encoding with UTF-8) (default: true)

You use REST Adapter and configure REST receiver channel to use Apache HTTP library (as per SAP Note 2483432). As a result, the sent HTTP request does not contain Content-Length header, and the partner server returns: HTTP/1.1 411 Length Required

The Apache HTTP library, which the REST Adapter is using, by default sends requests with chunked transfer encoding, and without Content-Length header.

With this SAP Note the default transfer is changed to content length based. If you want to use chunked transfer, then a module parameter of the REST adapter module is available for configuration:

• Parameter name: httpChunkStream
• Parameter value: true or false (default is false) - defines if chunked stream is used or not.

You are using PI REST receiver channel that uses HTTP proxy. You observe that the calls to some hosts does not require HTTP proxy for example for OAuth 2.0 authentication calls.

Current implementation of the REST adapter does not allow to define for which host HTTP calls should pass through proxy.

With this SAP Note a module parameter is introduced to the REST receiver channel that allow to define for which hosts a HTTP proxy will not be used. If you want to define a list of hosts for which HTTP proxy will not be used you have to add following module parameters to the REST receiver channel:

• Parameter key: http.nonProxyHosts
• Parameter value: <list of hostnames>. The host names have to be separated by the '|' symbol. Wildcard symbol '*' is acceptable. Example: localhost|*.sap.com|10.*

You are using REST Receiver Channel with dynamic URL. You noticed that the space character is encoded with a + sign in the REST Adapter instead of a %20 sign. You have already deployed SAP Note 3018477 but you notice that white space characters in the URL path are still encoded with the + sign.

The white spaces were previously encoded as a %20 sign only for query objects after the '?' sign in the URL.

With this SAP Note an encoding of white space characters with a %20 sign is introduced for the entire length of the URL.

To activate the encoding of white space characters with a %20 sign you can specify the following parameters of the 'rest' module in the module configuration tab of the REST Receiver channel:

• Parameter name: enablePercentEncoding
• Parameter value: true or false (default is false)

You are using REST Receiver Channel and the URL is dynamically built using placeholder patterns and you have set Module Parameter EncodeURL to false. You observe that dynamic URL is incorrectly generated, containing strings like {amp{}er{}sand}.

This behavior is side effect of SAP Note 2954026.

With this SAP Note the upper behavior is corrected.

To improve the behavior of replacing placeholders and encoding them, a new Module Parameter is introduced: EncodeURLPath.

• Parameter name: EncodeURLPath
• Parameter value: true or false

Default value: false, the placeholders before the “?” symbol are not encoded. If set to true placeholders are encoded.

Note: To avoid unexpected results we strongly recommend building the URL Pattern in a stricter way. For example: when encoding is enabled, we recommend using {placeholder1}?{placeholder2} instead of just one placeholder that contains the “?” symbol. This configuration will make it easier to distinguish the Query Part that must be encoded from the URL Path. Having “?” in your placeholder may lead to an unexpected result.

You have a REST receiver or REST sender with poll channel and the URL it calls has a query string to be constructed in a dynamic or static way. After having applied SAP Note 2138435 you observe that the dynamically constructed parts of the query string are encoded in UTF-8, while the static are not. There is no way to decide to not encode query strings.

There are several standards that affect URL query strings encoding – RFC 3986 (now considered to be obsolete) and HTML specification (http://www.w3.org/html/wg/drafts/html/master/#form-submission). There are many discussions and decisions whether the URL encoding should be UTF-8 or ISO-8859-1, however all the contemporary browsers encode in UTF-8, which is considered now to be the recommendation. That is the reason why the implementation for PI REST adapter uses also UTF-8 encoding, which should be understood by any server.

Another guideline followed is the recommendation to either encode (the preferred option) or do not encode all the parts of the query string.

With the change of this note all the query string parts are encoded in UTF-8 character encoding by default. For all the cases when the URL encoding is not desired for some reason, a new module parameter is added, EncodeURL with default value true, that can be configured by communication channel. If this parameter is missing or has any other value than false, all parts of the URL query string will be encoded in UTF-8. If its value is set to false, no part will be encoded.

There is no option to encode only some parts and leave others not encoded as it contradicts the contemporary standards. The parameter can be set as a module parameter of sap.com/com.sap.aii.adapter.rest.app/RESTAdapterBean module for REST receiver channels and of CallSapAdapter module for REST sender channels with poll.

Your PI system must have a version with the functionality available. There are no further steps in case you need to have the recommended way of URL encoding.

For REST receiver channels in the module chain:

• Module: sap.com/com.sap.aii.adapter.rest.app/RESTAdapterBean
• Parameter: EncodeURL
• Value: false

For REST sender channels with poll in the module chain:

• Module: CallSapAdapter
• Parameter: EncodeURL
• Value: false

You use SAP Process Orchestration (PO) and REST Receiver channel. You configure the channel as selecting Support Attachments with type multipart/form-data. You would like to serialize in multipart/form-data the message payload without having any attachments.

Feature enhancement

After that, it will be possible to configure the following channel module parameter for module key rest (sap.com/com.sap.aii.adapter.rest.app/RESTAdapterBean).

• multipartEnforced : true this parameter will force to REST adapter to encode the content of the request as multipart/form-data although it has no attachments
• multipartEnforcedContentDisposition: form-data;name="<any_required_name>" this parameter will overwrite the name with the provided value

You use SAP Process Orchestration (PO) and REST Receiver channel. You configure the channel Error Handling (e.g. HTTP Status Code does not match 200) and configure the message content to use an element of the response (e.g. {http_result}). You observe that some non-latin characters are corrupted in the response.

In case of error response from Partner and if there is no charset encoding in the response, the charset was set to ISO-8859-1 by default. After that, before the message was put in the messaging system, the content was formatted with UTF-8 and that causes the non-latin characters to become unreadable.

After that, it will be possible to configure the following channel module parameter for module key rest (sap.com/com.sap.aii.adapter.rest.app/RESTAdapterBean).

• useDefaultCharsetForCustomHandling: true. This parameter will prevent the characters to become unreadable.

You use SAP Process Orchestration (PO) and REST adapter configured with conversion from JSON to XML. If there is a "." (dot) in the key (e.g. employee.address), the converted value in XML contains only the last part of the initial value (in this example address).

Program error

After that add the following module parameter for module key rest:

Parameter name: setIgnoreNamespaces

Parameter value: false (default: true)

This setting will keep the whole key name after conversion.

You are using REST Sender channel and you already have applied SAP Note 2990782. You notice that in case on an asynchronous scenario, the error format is not as expected.

The REST Sender channel takes into account the conversion options configured in the channel to determine the error format for errors such as HTTP 401, 403, 500. However, the error format may not be as expected for asynchronous scenarios.

With this SAP Note, we introduce the option to specify whether XML or JSON format should be used in case of an error.

To select the preferred error handling format, you can specify the following parameters of the 'rest' module in the module configuration tab of the REST Sender channel:

• Parameter name: errorFormat
• Parameter value: XML (default) or JSON

Your using REST Receiver channel in XML format. You notice that an XML declaration such as

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 

is added to the payload by default.

A well-formated XML document begins with an XML declaration. However, some customer scenarios may require the XML declaration to be omitted.

With this SAP Note a new functionality of the REST Receiver channel to omit the XML declaration has been introduced.

To omit adding the XML declaration to the XML message, you can specify the following parameters of the 'rest' module in the module configuration tab of the REST Receiver channel:

Parameter name: omitXMLDeclaration

Parameter value: true (default: false)

You are using REST Poller channel and you would like to receivebinary data as zip, PDF or image, but only XML and JSON Data Formats are available.

The Binary Data Format suits best the requirements of your scenario.

With this SAP Note, a new functionality of the REST Poller channel to use Binary Data Format has been introduced.

To activate the use of Binary Data Format, you need to add following parameters of the 'rest' module in the module configuration tab of the REST Poller channel:

• Parameter name: binaryContent
• Parameter value: true (default is false)

With upper configuration the received HTTP body is used as it is, without any conversions, to construct a XI message main payload.

You use REST Poller channel and have configure Incremental Requests. The default behavior of the REST Poller channel after restart is to use incrementalToken initial value and not the one saved before restart.

There could be scenarios that the upper behavior is not wanted as the partner server relies the last provided incrementalToken value to be used for message selection and providing the initial value could lead to data inconsistencies.

With this SAP Note a new module property is introduced:

• Property Name: deleteIncTokenOnRestart
• Property Value: false (default: true)

If this property is set to false the incrementalToken value would not be deleted after restart of the channel and will be used for the next call.