Skip to Content
Introduction

Fields in ABAP Data Dictionary have several attributes, with the options of user-defined Data Elements and Domains. However, with ever-increasing prominence of XML in messaging, it will be interesting to see how the Built-in Data Type attributes of XML correspond to ABAP Data Type attributes. Currently, not all the attributes in XML Data Types are available in ABAP as equivalents.

Particularly, for ABAP Proxy generation, I wonder if in future SAP comes up with new ABAP Data Dictionary attributes corresponding to the attributes in XML Data Types. Of course, in SAP’s point of view, this may not be of much interest. However, preserving the XML Data Type attributes help in transparent data handling and storage in database. Here are my thoughts on retaining the XML Data Type attributes in the generated Proxy ABAP Data Dictionary.

XML Data Types’ Attributes

length

Currently, this is equivalent to the ABAP Built-in Field length or the Domain length, except for STRING ABAP Data Type.

minLength

There is no ABAP equivalent corresponding to this attribute. As this relates to the storage in database, it should be related to the ABAP Domain, assuming that Built-in Fields in ABAP structures will not have several attributes. In the Domain attributes in ABAP Dictionary, a new field may have to be created in the existing DD01L table or a related DD* table.

Then, if a value for this attribute is specified, a new Domain will be created with the minLength value, and a new Data Element referencing it. This Data Element will be used in the generated Proxy Data Dictionary.

maxLength

Similar to the minLength attribute.

pattern

There is no ABAP equivalent corresponding to this attribute. There is an unused MASK field in intended for Domains in table DD01L, probably used in conjunction with another unused MASKLEN field. Perhaps this can be revived or a new field can be introduced in table DD01L for the “pattern”.

Then, if a value for this attribute is specified, a new Domain will be created with the pattern value, referencing the relevant Domain created, to be used in the generated Proxy Data Dictionary.

enumeration

Currently, this is equivalent to the possible values in the ABAP Domain.

whiteSpace

There is no ABAP equivalent corresponding to this attribute. Like the “pattern” attribute, this relates to the value / input mask. In the Domain attributes in ABAP Dictionary, a new field may have to be created in the table DD01L or a related DD0* table. Possible values for this attribute will have to be space, “preserve”, “replace”, and “collapse”.

Then, if a value for this attribute is specified, a new Domain will be created with the whiteSpace value, along with a new Data Element, to be used in the generated Proxy Data Dictionary.

totalDigits

Currently, this is treated similar to the “length” attribute in ABAP, as applied to numeric fields, generated with ABAP Data Type “DEC”.

fractionDigits

Currently, this is treated similar to the “decimals” attribute in ABAP, as applied to numeric fields, generated with ABAP Data Type “DEC”.

maxInclusive

This could have been incorporated into the possible values in the ABAP Domain. However, the ABAP Domains have single values and inclusive ranges, and do not support the “<” and “>” qualifiers, as shown in the table DD07L. In any case, the possible values are not supported for STRING Data Types. So, a new field may have to be created for this in the table DD01L or a related DD0* table.

Then, if a value for this attribute is specified, a new Domain will be created with the maxInclusive value, along with a new Data Element, to be used in the generated Proxy Data Dictionary.

maxExclusive

Similar to the maxInclusive attribute.

minInclusive

Similar to the maxInclusive attribute.

minExclusive

Similar to the maxInclusive attribute.

Summary

During ABAP Proxy generation, it helps to minimize generating several new Data Dictionary objects. For this, a search may be made to find a field with matching attributes in the current ABAP Proxy generation, with the objective of using the same Data Element and / or Domain instead of creating new ones. If few attributes are specified, there need not be a corresponding new Data Element and / or Domain.

In addition, methods need to be developed for validating the values as per the attributes in the Domain.

To summarize, the idea of retaining the XML Data Type attributes in ABAP Data Dictionary may or may not become important. If it becomes important, then the above could be one of the possible ways.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply