SAP ERP Central Component
Reglas de unicode: seguidas por ecc 6.0
Desarrollo ABAP bajo Unicode
Antes de Unicode, la longitud de un carácter era exactamente de un byte, lo que permitía conversiones implícitas o programación orientada a la disposición en memoria. Con Unicode, esta situación ha cambiado: Un carácter ya no es un byte, por lo que se deben agregar especificaciones adicionales para definir la unidad de medida para referencias implícitas o explícitas a (la longitud de) caracteres.
Los datos tipo carácter en ABAP siempre se representan con el estándar UTF-16 (también utilizado en Java u otras herramientas de desarrollo como Visual Basic de Microsoft); pero este formato no está relacionado con la codificación de la base de datos subyacente.
Un programa ABAP habilitado para Unicode (UP) es un programa en el que todas las verificaciones de Unicode son efectivas. Dicho programa devuelve los mismos resultados en un sistema no Unicode (NUS) que en un sistema Unicode (US). Para realizar las verificaciones de sintaxis relevantes, debes activar la bandera de Unicode en las pantallas del programa y los atributos de clase.
En un US, solo puedes ejecutar programas para los cuales se ha establecido la bandera de Unicode. En el futuro, la bandera de Unicode debe establecerse para todos los programas SAP para que puedan ejecutarse en un US. Si la bandera de Unicode está establecida para un programa, la sintaxis se verifica y el programa se ejecuta de acuerdo con las reglas descritas en este documento, independientemente de si el sistema es un US o un NUS. A partir de ahora, la bandera de Unicode debe establecerse para todos los programas y clases nuevos que se creen.
Si la bandera de Unicode no está establecida, un programa solo se puede ejecutar en un NUS. Los cambios sintácticos y semánticos descritos a continuación no se aplican a dichos programas. Sin embargo, puedes utilizar todas las extensiones de lenguaje que se han introducido en el proceso de conversión a Unicode.
Como resultado de las modificaciones y restricciones asociadas con la bandera de Unicode, los programas se ejecutan en sistemas Unicode y no Unicode con la misma semántica en gran medida. Sin embargo, en casos raros, pueden producirse diferencias. Por lo tanto, los programas diseñados para ejecutarse en ambos sistemas deben ser probados en ambas plataformas.
Otros Cambios
1. Declaraciones de bits
2. Agregar secuencias de campos
3. Bucles con VARY y VARYING
4. Creación de subrutinas
5. Guardar programas
6. Asignación de tipos para GET/SET PARAMETER
7. Declaraciones inalcanzables
8. Módulos de función con nombres de parámetros incorrectos
1. Declaraciones de bits
Anteriormente, el sistema verificaba para las declaraciones de bits SET BIT i OF f [TO g] y GET BIT i OF f [INTO g] si el campo f era de tipo carácter; los campos X, cadenas X y estructuras planas suelen considerarse como tipo carácter. Para los programas Unicode, esto ya no es útil, porque los tipos X y XSTRING ya no se consideran como tipo carácter y el acceso bit a bit a campos o estructuras de tipo carácter ya no es independiente de la plataforma. Por lo tanto, con estas operaciones en programas Unicode, el campo f debe ser de tipo X o XSTRING.
Para las operaciones de máscara de bits f O x, f Z x y f M x, anteriormente podías usar todos los tipos numéricos y, por lo tanto, todos los tipos de tipo carácter para el operando izquierdo f. En programas Unicode, el operando f ahora debe ser de tipo X o XSTRING.
2. Agregar secuencias de campos
Al agregar secuencias de campos, se aplican restricciones a las siguientes declaraciones en Unicode:
ADD n1 THEN n2 UNTIL nz [ SEGÚN selección ] DANDO m ...
ADD n1 THEN n2 UNTIL nz A m [ RANGO cadena ].
1. Los operandos n1, n2 y nz deben ser compatibles entre sí.
2. La distancia entre nz y n1 debe ser un múltiplo entero de la distancia entre n2 y n1.
3. Se produce un error de sintaxis o tiempo de ejecución si los campos n1, n2 y nz no están en una estructura. Esta estructura debe ser reconocible estáticamente o su área válida debe marcarse explícitamente usando la adición de RANGO.
4. En tiempo de ejecución, el sistema asegura que no se abandone el área del RANGO.
ADD n1 DESDE i1 DANDO m [ RANGO cadena ].
1. El campo n1 debe estar dentro de la estructura. La estructura debe definirse explícitamente utilizando la adición de RANGO si no es reconocible estáticamente.
2. Para esta variante, el sistema también verifica en tiempo de ejecución si n1 y los valores direccionados están dentro de la estructura.
3. Bucles
Los bucles con la adición VARY o VARYING también son
