Extension field storage limit in PDI solutions

Problem Statement

The extension fields created via SDK or KUT are stored per BO node combination in the backend table. Currently there is a limit set to a maximum of 744 for storing extension fields which means that a user is not allowed to create extension fields greater than 744 on a tenant for a BO node combination. This limit is applicable across all solutions and solution types. This is majorly a problem area for XBOs, as a tenant might have multiple solutions built on the same standard BO node and thus the probability of exceeding the limit is high, as these would be stored in the same database table.

Due to this limitation, the Lifecycle Management processes involving activation of PDI add-ons were impacted and as a result failed leaving the user clueless on how and where the extension field limit exceeded. The only solution to this problem was to delete some of the extension fields on that particular BO node or move them to other nodes. This involved SAP intervention as deletion of extension fields is not supported in maintenance mode.

This was a pain point to the user as it involved adaptations by the partner, support from SAP and data loss on the delivered extension fields.

Solution:

To address the problem, a guard rail restriction   “Maxed out table Space” is developed, which is applicable to all solution types and extension fields created via SDK and KUT on BO node for a tenant. This solution can be mainly divided into two categories:

1.      Warnings:

Warning messages are raised when the sum of all extension fields on a BO reach 50%, 80% and 100% of the maximum limit to make the developer aware of the limit in advance so that the coding/design of the add-on can be done in an optimized way in order to avoid the maxed out table space issues.

These warnings are shown on the Consistency check of the solution on the Save action of the BO file. The warnings are shown for the below limits:

• Extension fields on a tenant reach 50% of the max limit.
• Extension fields on a tenant reach 80% of the max limit.
• Extension fields on a tenant reach 100% of the max limit.

2.      Errors:

The second category  ensures that error messages are shown on activation of solutions where the limit is about to reach the maximum value and thus the activation process is stopped. This way it is ensured that the maximum limit is not reached after the solution is successfully activated and deployed in target tenant.

To achieve the above functionality, a new calculation rule is introduced in the Lifecycle Management process of the add on which calculates the total fields (SDK extension fields + KUT fields present for a BO, node combination across all solutions and solution types) on a tenant and checks if it exceeds the maximum limit.

2.1  Calculation rule:

Variant 1: If the solution is a patch solution, a simple check is executed.

Total fields = Extension fields for all PDI solutions on the BO node + KUT fields on that BO node.

Total fields > = 744, error thrown on activation of XBO.

Variant 2: If solution is an original solution without a patch namespace existing on that tenant, the below check is executed.

Total fields = (2 * original solution extension fields) + KUT fields + other solutions (solutions other than original) extension fields.

If Total fields > = 744, error is thrown on activation of BO.

This is required to keep a buffer for fields that might be created as part of the first patch creation process. The details on why this is required is explained below:

E.g.: If an original solution has 400 extension fields, and if the above special handling is not done the activation/assembly would go through for the original solution as the total fields in this case would be 400 < maximum limit. However, on first time patch creation 400 more fields will be created as part of the patch creation process (original namespace 400 fields copied to patch namespace). This process would fail in between because the total fields tried for creation would be greater than the maximum limit.

2.2 The above check would be included in the below Lifecycle Management processes:

2.21 Activation Process for In Development solutions:

For solutions that are “In development” every activation on the solution would check if the extension field limit for all BO nodes in the solution are below the maximum limit. If yes, then the activation goes through. However, if the limit exceeds the maximum limit then the activation is stopped and the developer is required to make changes by deleting the extension fields and adapting the add-on code.

For original solutions that do not have a patch existing in the system, the total limit will be calculated as per the logic mentioned in section Calculation rule.

2.22 Assembly Process

The activation process describe above is also called during the Assemble and Download of PDI solutions. Thus, the process is stopped if the limit of the fields exceeds the maximum limit as per the calculation rule defined in the section 2.1.

In case of Split Assemble feature, the Split activate would follow the calculation rule as described in 2.21

2.23 First time patch creation

For the first-time patch creation, the issue of exceeding the extension field will not occur because the assembly would have taken the buffer in advance for the patch namespace. Ref Calculation rule 2.1, variant 2.

2.24 Deployment process (For solutions assembled in 1802)

The deployment process now contains a new check that is performed before the solutions are imported to the target tenant. It checks the total extension fields. If the limit is exceeded, deployment is stopped at an earlier stage during compatibility checks.

The total extension field calculated for the deployment process = Extension fields in zip file of add on + existing extension fields on the system (for a BO node).