Length limitation for parameterized mappings

[engswee]

Introduction

Usage of Parameterized Mapping Program is a common design technique that increases the possible applications of a mapping program as well as its flexibility. Below are some of the use case of parameterized mapping programs.

• Enable different constant value for different environment (instead of hard-coding the values in mapping based on environment identifier)
• Enable changing of mapping value via configuration change in Integration Directory object instead of design change of ESR object
• Reuse of same mapping program in different integration scenario

The actual value of each parameter is configured in the Interface Determination step in Integration Directory. Although the configuration tool (whether Swing or NWDS) allows the possibility to configure a value of any length, one of the less known fact is that there is a length limit to the configured value. Although the limit is not listed in SAP's online library, as far as I recall, the limit was 255 on a PI 7.11 dual stack system.

Recently, I've come across some issues during deployment of an iFlow that contained a parameterized mapping. Searching for the error on SCN did not reveal much but after some troubleshooting it was traced back to the limitation of the parameterized mapping. It seems that on a single stack system (PO 7.4), the limit is even shorter at 98.

In this blog, I will share my experience of troubleshooting this issue and verifying the length limitation of parameterized mappings.

Troubleshooting the Issue

Below are the symptoms of the issue.

During deployment of the iFlow from NWDS, the runtime cache failed to update.

Checking the trace by right-clicking and selecting View Deployment Trace does not reveal further information.

Therefore, I checked the cache status instead and it shows that there is an error with Interface Determination object.

By right-clicking and selecting More Details, it reveals the error log for the issue.

In short, the following error indicates that there was an issue with the parameter related to blank padding.

Failed to set the parameter 6 of the statement >>UPDATE XI_AF_CPA_PAR_MAP SET INF_DETER_ID=?, ALL_IN_ONE_ID=?, PARAM_TYPE=?, PARAM_CATEGORY=?, PARAM_NAME=?, PARAM_VALUE=? WHERE OBJECT_ID=?<<: Cannot assign a blank-padded string to a parameter with JDBC type >>VARCHAR<<.

The configured value of the parameter did contained white spaces in between but it was less than 255 characters, so that prompted me to guess that the length limit might have changed.

In order to confirm this, I tried to reduce the length of the configured value iteratively (1 character at a time) until the iFlow could be deployed. From the iteration, I found that deployment would only succeed when the value at position 99 was non-blank.

Verifying the Limitation

To further verify the limitation, I created a simple integration scenario consisting of a parameterized message mapping. An importing parameter is added to the mapping and used in the following mapping logic.

When the mapping is executed in ESR with an input value of longer than 99 for the parameter, the full value of the parameter is accessible during the testing.

The iFlow is then configured with the following input value to the parameter which is longer than 99 characters.

When the interface is executed end-to-end, the target payload is truncated after position 98. This confirms that even though the parameter can be configured with values of any length, the actual value is truncated during deployment and it is the truncated value that is used during runtime.

Conclusion

With this simple troubleshooting and verification exercise, I can conclude that on a PO 7.4 single stack system:

• Parameterized mapping have a length limit of 98 characters even though the configured value is longer than that
• If the configured value is longer than 98 characters, deployment of the iFlow/ICO will fail is there is a blank space at the 99th position

I am not sure if this limitation is same on other systems, i.e. dual stack, different database system. However, the approach here can be used to similarly verify the limitation on any particular system.

As a conclusion, when designing integration scenarios with parameterized mapping, take into consideration the potential length of the configured parameter value so that it will not cause any issues during deployment or runtime.