Skip to content

IDoc_AAE adapter module parameters

platinumICE edited this page Nov 21, 2023 · 1 revision

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
OrderedEOIOEnabled false 2234172 Sender SP018 SP013 SP001
IDocMsgTypeValidation true 2963247 Sender SP014
UseParentQueueId 🍪 2341291 Receiver SP015 SP010 SP004
FieldValidationEnabled 🍪 2036878 Receiver SP008 SP003 SP000
SkipControlRecordCheck 🍪 2350799 Receiver SP017 SP012 SP003
EnforceSAPRelease 🍪 3126809 Receiver SP017
SkipInitialConnectionCheck 🍪 2488614 Receiver SP018 SP013 SP007
MaxConnections 🍪 2189576 Sender/Receiver SP018 SP013 SP001
MaxWaitTimeSec 🍪 2189576 Sender/Receiver SP018 SP013 SP001
CleanupIntervalSec 🍪 2189576 Sender/Receiver SP018 SP013 SP001
ConnLifetimeSec 🍪 2189576 Sender/Receiver SP018 SP013 SP001

🍪 — see NWA IDOC Resource Adapter configuration

Note 2234172

Symptom

You are using the IDoc_AAE sender adapter to receive IDoc document lists (packages) with enabled qRFC, and you are using the same queue name with different IDoc types. For the different IDoc types you have configured different IDoc_AAE sender communication channels, and Integrated Configurations/Integration Flows, and for each channel you set different queue ID for the XI messages with quality of service (QoS) Exactly Once In Order (EOIO). The package processing fails with error similar to the following one:

Multiple EOIO contexts cannot be used within one transaction. Previous: <SC_1> Current: <SC_2>

Similar issue can occur in other scenarios when one IDoc package is split to several XI messages that are with QoS EOIO and have different queue IDs (e.g. set dynamically via a custom module).

Reason and Prerequisites

It was not possible to process EOIO XI messages with different queue IDs within the same transaction.

Solution

An enhanced processing is introduced that allows internal ordering of the serialization contexts, so that EOIO messages with several queue IDs (and therefore with multiple serialization contexts) can be processed within one transaction. This option is valid for IDoc lists sent to PI with qRFC, same queue ID and different IDoc types. Additionally, you need to enable the new processing with the property OrderedEOIOEnabled of the JavaIdocAdapter Resource Adapter. It can be configured at SAP NetWeaver Administrator -> Configuration -> Infrastructure -> Application Resources -> JavaIdocAdapter Resource Adapter -> properties OrderedEOIOEnabled set to true.

As of 7.31 SP18/7.40 SP13 and 7.5 SP01 it is also possible to enable the new processing per sender communication channel. The configuration can be done in tab Advanced -> Additional Parameters -> add property OrderedEOIOEnabled with value true.

IDocMsgTypeValidation

Symptom

You use the IDoc_AAE sender adapter to process list of IDocs with same IDoc type, but different IDoc message types. As a result, the following error appears:

com.sap.aii.af.idoc.exception.IDOCAdapterException: DIfferent Control Record values for Idoc : 0000000000000001 and : 0000000000000002 (example idoc numbers)

Reason and Prerequisites

Program error.

Solution

New parameter is introduced for IDoc sender channel.

To skip the IDoc message type validation in sender channel navigate to Advanced tab => Additional Parameters => Set Additional Parameters:

Parameter name : IDocMsgTypeValidation
Parameter value: false

Please, note that if you set invalid value, different from true or false, this value would be considered as false. The default value is true. Therefore, the IDoc message type is validated by default even the parameter is not set at all.

UseParentQueueId

Symptom

You have Integrated Configuration scenario with quality of service "Exactly Once In Order" and mapping split. The queue ID of the EOIO quality of service needs to be propagated to the receiver system using the IDoc_AAE receiver channel. The messages are delivered in the correct order to the receiving system, but are processed in different order as they have different sequence IDs.

Reason and Prerequisites

The queue ID (a.k.a. sequence ID) of a child message from split mapping has the following format: SUBSEQ_XXXX where XXXX is a 4-digit random number. The child messages from the mapping split reach the receiving system with this sequence ID. The child messages of 2 consecutive parent messages will have different sequence IDs and hence can be processed in different order.

Solution

The queue ID of the parent message is stored in the message system header if the message is being split using a split mapping. If the child messages are delivered to a business system using IDoc_AAE adapter, the parent sequence ID can be used as queue name during the delivery by the IDoc_AAE receiver channel. Note that the XI child message will keep its queue ID (SUBSEQ + 4-digit random number).

This SAP Note introduces a new UseParentQueueId setting to use the parent sequence/queue ID (if such is available) on channel level and also globally for the whole IDoc_AAE adapter. The global setting could be configured at SAP NetWeaver Administrator -> Configuration-> Infrastructure -> Application Resources -> JavaIdocAdapter Resource Adapter -> property UseParentQueueId. The communication channel specific setting can be added as additional property in the IDoc_AAE receiver communication channel -> tab Advanced -> check Set Additional Parameters -> in the table add UseParentQueueId and set value to true.

The default value for UseParentQueueId is false, i.e. the IDoc_AAE receiver adapter will use the queue id defined in the XI message as its queue id. The channel specific setting has higher priority over the global setting defined in the JavaIdocAdapter resource adapter. To restore the parent queue ID configure the property UseParentQueueId with value true.

FieldValidationEnabled

Symptom

You are using IDoc_AAE receiver adapter to send IDoc documents to SAP or external system. During the parsing of the IDoc-XML from the XI message payload to an IDoc document/list the processing fails with an error similar to the following one:

Error before sending due to IDoc parsing error: (7) IDOC_ERROR_PARSE_FAILURE: An IDocConversionException occurred while parsing IDocXML for type <IDoc_type>: state=READING_FIELD_VALUE_TAG, charPosition=..., lineNumber=..., columnNumber=...

The reason is that the IDoc-XML contains fields that are incompatible with the datatype defined in the IDoc metadata definition of the processed IDoc.

Reason and Prerequisites

The IDoc_AAE adapter uses the SAP Java IDoc Class Library to parse the IDoc-XML to IDoc document/list. The library did not offer the possibility to disable the IDoc document and segment field datatype checks. Based on note 2023782 the IDoc Library is now able to parse the IDoc-XML without checking the fields datatype.

Solution

This note introduces a new FieldValidationEnabled setting to enable/disable the field datatype checking during IDoc-XML parsing on channel level and also globally for the whole IDoc_AAE adapter. The global setting could be configured at SAP NetWeaver Administrator -> Configuration-> Infrastructure -> Application Resources -> JavaIdocAdapter Resource Adapter -> property FieldValidationEnabled. The communication channel specific setting is only available from 7.31 and can be added as additional property in the IDoc_AAE receiver communication channel -> tab Advanced -> check Set Additional Parameters -> in the table add FieldValidationEnabled and set value either true or false.

The default value for FieldValidationEnabled is true, i.e. the IDoc field datatype check is enabled during parsing. The channel specific setting has higher priority over the global setting defined in the JavaIdocAdapter resource adapter.

Note: If you disable the field datatype check the IDoc_AAE adapter may send IDoc documents with wrong or illegal field contents which may result in an unexpected behavior in the receiver system. Instead of switching off the IDoc field datatype checks it is recommended to correct the data beforehand, ideally already by the original data creator, and only send valid IDoc data according to the IDoc metadata definition.

SkipControlRecordCheck

Symptom

You use the IDoc_AAE receiver adapter to send IDoc documents in releases 7.31 and higher. The processing of the XI message fails with one of the following error texts:

  • Recipient Partner Type is not available
  • Recipient Partner Number is not available
  • Sender Partner Type is not available
  • Sender Partner Number is not available

The above errors do not occur in 7.3 scenarios.

Reason and Prerequisites

The information for the sender partner number (SNDPRN), sender partner type (SNDPRT), receiver partner number (RCVPRN) and receiver partner type (RCVPRT) is mandatory for the IDoc document control record. If an IDoc with missing information for the above fields is sent, errors can occur in the receiver system. Therefore an additional check to validate these fields before sending was added in 7.31 with SAP Note 1804960.

Solution

This SAP Note introduces a new SkipControlRecordCheck setting to omit the check for the sender/receiver partner number and type. The global setting could be configured at SAP NetWeaver Administrator -> Configuration-> Infrastructure -> Application Resources -> JavaIdocAdapter Resource Adapter -> property SkipControlRecordCheck. The communication channel specific setting can be added as additional property in the IDoc_AAE receiver communication channel -> tab Advanced -> check Set Additional Parameters -> in the table add SkipControlRecordCheck and set value to true.

The default value for SkipControlRecordCheck is false, i.e. the IDoc_AAE receiver adapter will check the existence of the sender/receiver partner number and type in the IDoc control record. The channel specific setting has higher priority over the global setting defined in the JavaIdocAdapter resource adapter. To disable the check, configure the property SkipControlRecordCheck with value true.

Note: If the check is disabled then the IDoc_AAE adapter can send IDoc documents with missing sender/receiver partner number and/or type that can result in errors in the receiver system. Ideally you should configure the scenario in such a way that these values are present in the IDoc document before the IDoc_AAE adapter sends it to the receiver system.

EnforceSAPRelease

Symptom

The value for SAP Release property configured in IDoc_AAE Receiver channel is not used when the IDoc metadata is loaded.

Always the last (with highest version) metadata is loaded as result.

Reason and Prerequisites Program error.

Solution

For backward compatibility and to avoid problems with working scenarios, a new property EnforceSAPRelease is added with default value false.

If 'SAP Release' property value from the channel configuration must be used, change the value to true on adapter or channel level:

NWA -> Application resources -> JavaIDocAdapter -> EnforceSAPRelease

or

IDoc_AAE channel configuration -> Advanced -> Additional Parameters -> *EnforceSAPRelease*

SkipInitialConnectionCheck

Symptom

IDoc_AAE receiver communication channels have the following error: Target Destination unavailable or Metadata Destination unavailable. The corresponding RFC destination exists and their connection parameters are correct. However, the target system is not available (e.g. is not started, is staring, etc.), which causes the above channel errors. When the target system is available again, the IDoc_AAE receiver channels have to be restarted in order their status to change from error to "started and running successfully".

Reason and Prerequisites

It was not possible to skip the initial ping check that the IDoc_AAE receiver channels perform on startup. Therefore, in case of temporarily stopped target system (e.g. staged startup of the PI system and the target system) the initial ping of the IDoc_AAE receiver channels fails and the channels are not started successfully. When the target system is started, the IDoc_AAE receiver channels have to be restarted manually to start processing messages.

Solution

An additional property SkipInitialConnectionCheck to omit the initial connection check (ping) for the IDoc_AAE receiver channels (for target and metadata destinations). The global setting could be configured at SAP NetWeaver Administrator -> Configuration-> Infrastructure -> Application Resources -> JavaIdocAdapter Resource Adapter -> property SkipInitialConnectionCheck. The communication channel specific setting can be added as additional property in the IDoc_AAE receiver communication channel -> tab Advanced -> check Set Additional Parameters -> in the table add SkipInitialConnectionCheck and set value to true. The channel specific setting has higher priority over the global setting defined in the JavaIdocAdapter resource adapter. To disable the ping, configure the property SkipInitialConnectionCheck with value true.

Note 2189576

Symptom

You have configured IDoc_AAE receiver channel in Default or Manual mode, or IDoc_AAE sender channel with enabled acknowledgment handling in Default or Manual mode. The IDoc_AAE adapter generated JCA Connection factory for each of these channels with the configured properties. The connection pooling properties are always set to default (-1). Even if they are changed directly in the JCA Connection factory, they are overwritten with the default values when the channel is changed.

The connection pooling properties are visible in SAP NetWeaver Administrator -> Configuration -> Infrastructure -> Application Resources -> select the JCA Connection Factory -> tab Connection Pooling. The value -1 means that the Maximum Connections are set to 100 and the Maximum Waiting Time for Connection (sec) is 60; and -1 for Cleanup Interval (sec) and Connection Lifetime (sec) means there will be no automatic connection cleanup. This means that the created connections will not be cleaned up even if they are not used anymore.

Reason and Prerequisites

It was not possible to configure connection pooling properties for the JCA connection factories created by the IDoc_AAE adapter.

Solution

Additional properties are provided in the channel configuration to maintain the pooling of the created JCA Connection Factories. You can configure the properties in the Advanced tab of the channels in the Additional Parameters table. The parameters are as follows:

  • MaxConnections: sets the maximum connections that can be kept in the pool;
  • MaxWaitTimeSec: sets the time interval in seconds, for which the channel can wait to obtain a free connection if all connections are busy;
  • CleanupIntervalSec: sets the time interval in seconds, in which a connection cleanup job is triggered;
  • ConnLifetimeSec: sets the time interval in seconds, for which a connection can stay idle in the pool before it is removed by the connection cleanup job

If you want to set one of the above parameters, always define the MaxConnections property. Additionally, if you want to maintain the connection cleanup, set both CleanupIntervalSec and ConnLifetimeSec.