Guía de programacion ABAP

Con esta guía se busca identificar una hoja de ruta que permita diseñar aplicaciones ABAP usando una
serie de reglas, las cuales nos permitirían llevar a cabo unos desarrollos mejor estructurados.

Reglas generales

Separación de componentes
Modelar la aplicación en componentes de software, en aplicaciones orientadas a servicios, es
importante separar la lógica de la capa de aplicación, la lógica de la capa de presentación, la lógica de la
capa de persistencia y la lógica para la comunicación con sistemas externos.

Mediante la separación de componentes se identifican las partes de una aplicación, en términos de

encapsulación y hacer de estas partes unidades cerradas, las cuales se comunican con otras unidades
cerradas por medio de interfaces. El dividir el software en estos componentes genera los siguientes
beneficios:

 Mayor estabilidad
 Fácil de entender
 Fácil de reusar
 Fácil de transportar
 Fácil de mantener
 Fácil de probar

Siguiendo el principio de separación por componentes esto permitiría llevar a cabo las pruebas unitarias
de manera más sencilla.

Ejemplo equivocado
La siguiente imagen muestra dos ejemplos de una aplicación ABAP que no sigue la regla de separación
por componentes:
Como se puede observar los dos ejemplos son los modelos de programación más extendidos en los
desarrollos ABAP. El hecho de que sea un diseño erróneo no significa que funcionalmente sea
inadecuado, lo que indica es que en este tipo de modelamiento la lógica de la capa de persistencia, de la
capa de presentación y de la capa de aplicación se encuentra mezclada en una sola unidad de desarrollo.

REPORT z_report1.

PARAMETERS p_carrid TYPE spfli-carrid.

DATA: gt_spfli_tab TYPE STANDARD TABLE OF spfli,

go_alv TYPE REF TO cl_salv_table,
go_alv_exc TYPE REF TO cx_salv_msg.

SELECT *
FROM spfli
INTO TABLE gt_spfli_tab
WHERE carrid = p_carrid.

IF sy-subrc = 0.
SORT gt_spfli_tab BY cityfrom cityto.
TRY.
cl_salv_table=>factory(
IMPORTING r_salv_table = go_alv
CHANGING t_table = gt_spfli_tab ).
go_alv->display( ).
CATCH cx_salv_msg INTO go_alv_exc.
MESSAGE go_alv_exc TYPE 'I' DISPLAY LIKE 'E'.
ENDTRY.
ENDIF.

En el reporte Z_REPORTE1 se observa que no hay división de componentes, para este reporte pequeño
la división de componentes no es que le dé un valor agregado, ya que el entender el programa no tienen
mayor problema debido a su tamaño, sin embargo, en la realidad los desarrollos suele ser mucho más
grandes, en los cuales toda la lógica se encuentra distribuida en todo el programa, quedando casi
imposible probar funcionalidades específicas de un programa. Si dividimos nuestro programa en
componentes podemos probar funcionalidades específicas y lograr hacer un desarrollo modular y esto
asegura que los errores al final se vean reducidos significativamente.

En el siguiente reporte denominado Z_REPORTE2 se demuestra que se puede dividir un programa en

componentes usando la técnica de subrutinas para modularizar el programa, el siguiente código permite
el desarrollo de pruebas unitarias de manera más sencilla lo cual permitiría que probemos porciones de
código haciendo que se puede codificar la prueba unitaria de forma adecuada.

REPORT z_report2.

SELECTION-SCREEN BEGIN OF SCREEN 100.

PARAMETERS p_carrid TYPE spfli-carrid.
SELECTION-SCREEN END OF SCREEN 100.

TYPES gty_spfli_tab TYPE STANDARD TABLE OF spfli.

DATA: gv_carrid TYPE spfli-carrid,
gt_table TYPE spfli_tab,
gv_arc TYPE sy-subrc.

START-OF-SELECTION.
PERFORM get_carrid CHANGING gv_carrid.
PERFORM get_table USING gv_carrid
CHANGING gt_table
gv_arc.

IF gv_arc = 0.
PERFORM sort_table CHANGING gt_table.
PERFORM display_table USING gt_table.
ENDIF.

* Capa de presentación
FORM get_carrid
CHANGING VALUE(cp_carrid) TYPE spfli-carrid.
CALL SELECTION-SCREEN 100.
IF sy-subrc = 0.
cp_carrid = p_carrid.
ENDIF.
ENDFORM.

FORM display_table
USING it_table TYPE gty_spfli_tab.
DATA: lo_alv TYPE REF TO cl_salv_table,
lo_alv_exc TYPE REF TO cx_salv_msg.
TRY.
cl_salv_table=>factory(
IMPORTING r_salv_table = lo_alv
CHANGING t_table = it_table ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lo_alv_exc.
MESSAGE lo_alv_exc TYPE 'I' DISPLAY LIKE 'E'.
ENDTRY.
ENDFORM.
* Capa de aplicación
FORM sort_table
CHANGING ct_table TYPE gty_spfli_tab.
SORT ct_table BY cityfrom cityto.
ENDFORM.

* Capa de persistencia
FORM get_table
USING ip_carrid TYPE spfli-carrid
CHANGING ct_table TYPE gty_spfli_tab
cp_arc TYPE sy-subrc.
SELECT *
FROM spfli
INTO TABLE ct_table
WHERE carrid = ip_carrid.
cp_arc = sy-subrc.
ENDFORM.

En el reporte Z_REPORTE2 se observa que ya existe una separación de componentes, sin embargo, se
puede hacer el anterior modelamiento usando una la técnica de programación orientada a objetos, la
cual permite llevar a cabo la separación de componentes mediante un diseño de clases, usando una
técnica cuyo enfoque está sustentado en la división del código.

Ejemplo correcto
La siguiente gráfica muestra una aplicación ABAP en la que se observa una separación de componentes
de manera adecuada:
Una vez identificados los componentes estos son implementados en clases, los componentes de la
gráfica agrupan el código necesario que normalmente se lleva a cabo en el desarrollo de aplicaciones
ABAP que son:

 La comunicación con una interfaz de usuario (UI)

 Lógica de la aplicación
 El acceso a datos persistentes
 La comunicación con sistemas externos

En ocasiones estos componentes pueden subdividirse cuando los componentes abarcan muchas
funcionalidades.

El siguiente código muestra el ejemplo de usar clases en la separación de componentes:

REPORT z_report3.

SELECTION-SCREEN BEGIN OF SCREEN 100.

PARAMETERS p_carrid TYPE spfli-carrid.
SELECTION-SCREEN END OF SCREEN 100.

CLASS lcl_program DEFINITION.

PUBLIC SECTION.
TYPES gty_spfli_tab TYPE STANDARD TABLE OF spfli.
CLASS-METHODS start_of_selection.
ENDCLASS.

CLASS lcl_presentation DEFINITION.

PUBLIC SECTION.
CLASS-METHODS:
get_carrid RETURNING VALUE(rp_carrid) TYPE spfli-carrid,
display_table CHANGING VALUE(ct_table) TYPE lcl_program=>gty_spfli_tab.
ENDCLASS.

CLASS lcl_application DEFINITION.

PUBLIC SECTION.
CLASS-METHODS
sort_table CHANGING table TYPE lcl_program=>gty_spfli_tab.
ENDCLASS.

CLASS lcl_persistency DEFINITION.

PUBLIC SECTION.
CLASS-METHODS
get_table IMPORTING ip_carrid TYPE spfli-carrid
EXPORTING et_table TYPE lcl_program=>gty_spfli_tab
ep_arc TYPE sy-subrc.
ENDCLASS.

CLASS lcl_program IMPLEMENTATION.

METHOD start_of_selection.
DATA: lv_carrid TYPE spfli-carrid,
lt_table TYPE gty_spfli_tab,
lv_arc TYPE sy-subrc.
lv_carrid = lcl_presentation=>get_carrid( ).
lcl_persistency=>get_table( EXPORTING ip_carrid = lv_carrid
IMPORTING et_table = lt_table
ep_arc = lv_arc ).
IF lv_arc = 0.
lcl_application=>sort_table(
CHANGING table = lt_table ).
lcl_presentation=>display_table( CHANGING ct_table = lt_table ).
ENDIF.
ENDMETHOD.
ENDCLASS.

CLASS lcl_presentation IMPLEMENTATION.

METHOD get_carrid.
CALL SELECTION-SCREEN 100.
IF sy-subrc = 0.
rp_carrid = p_carrid.
ENDIF.
ENDMETHOD.

METHOD display_table.
DATA: lo_alv TYPE REF TO cl_salv_table,
lo_alv_exc TYPE REF TO cx_salv_msg.
TRY.
cl_salv_table=>factory(
IMPORTING r_salv_table = lo_alv
CHANGING t_table = ct_table ).
 lo_alv->display( ).
CATCH cx_salv_msg INTO lo_alv_exc.
MESSAGE lo_alv_exc TYPE 'I' DISPLAY LIKE 'E'.
ENDTRY.
ENDMETHOD.
ENDCLASS.

CLASS lcl_application IMPLEMENTATION.

METHOD sort_table.
SORT table BY cityfrom cityto.
ENDMETHOD.
ENDCLASS.

CLASS lcl_persistency IMPLEMENTATION.

METHOD get_table.
SELECT *
INTO TABLE et_table
FROM spfli
WHERE carrid = ip_carrid.
ep_arc = sy-subrc.
ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
lcl_program=>start_of_selection( ).

El código fuente del programa Z_REPORT3 puede ser considerado muy excesivo, debido a que el
programa es pequeño, pero en un escenario real es donde se van a ver los beneficios de usar este tipo
de técnicas de diseño, ya que se va a tener siempre separados los componentes del programa y puede
llegar incluso hasta ahorrarse código fuente; con el beneficio adicional que las pruebas unitarias sobre el
código se pueden implementar fácilmente, mejorando por ende la calidad.

El principio KISS
El principio KISS se enfoca en hacer que el sistema se mantenga simple, consiste en no incluir
complejidad que haga que el desarrollo se torne difícil de entender y de mantener.

La mejor solución a un problema de software debe ser aquella que sea simple, mínima y fácil de
entender; estas características hacen que la solución sea fácil de entender, estable y mantenible.

Existen muchos programas que no usan el principio KISS esto se debe a que el programa no tuvo un
buen diseño desde el principio, o debido a un estilo de programación sin rumbo (Código espagueti); otra
razón es un programa con muchos mantenimientos durante mucho tiempo, haciendo que el desarrollo
se llene de complejidad que inicialmente no tenía, en este caso un desarrollo sufre cambios de
comportamiento que no estaban inicialmente, y debido a que no contaban con un buen diseño se van
volviendo engorrosos y el coste del mantenimiento se vuelve difícil, esto se observa cuando se inyectan
errores sobre porciones de código donde no existe una modularización y controles claros; el llevar a
cabo este tipo de mantenimientos hace que un código que debería ser sencillo se vuelva complejo.
Para desarrollar de acuerdo con el principio KISS, debe asegurarse desde el principio que la complejidad
del programa sigue siendo manejable. Reglas que apoyan este enfoque se relacionan con la estructura y
el estilo de los programas, en los comentarios y la complejidad (Evitar código complejo, con pocos
niveles de anidación).

Una técnica de ingeniería de software usada para mantener simple un programa se denomina
refactorización, la cual consiste en modificar el código fuente de tal manera que se torne sencillo sin
modificar su comportamiento. Mediante el uso de pruebas unitarias esta técnica se puede aplicar, ya
que al identificar un escenario de prueba y aplicarlo en un desarrollo se pueden encontrar soluciones
más simples en el código que se encuentra escrito. El objetivo de la refactorización es mejorar el
entendimiento del código fuente, cambiar su estructura, diseño y eliminar código muerto. La
refactorización es buena llevarla a cabo después de tener pruebas unitarias, ya que al usar esta técnica
es posible que se inyecten errores, los cuales se pueden evidenciar si ya se cuenta con un conjunto de
pruebas unitarias que verifiquen la integridad de la funcionalidad ajustada.

Correctitud y calidad
La mayoría de las organizaciones que desarrollan software profesional tienen normas de productos que
deben cumplirse. Estas normas de producto definen lo que se quiere decir con correctitud y la calidad
de un programa. SAP tiene muchas de esas normas, que los departamentos de desarrollo tienen que
cumplir. Las normas de los productos actuales que son más importantes para los desarrolladores son los
siguientes:

Accesibilidad
En el entorno de tecnología de la información, el término accesibilidad se refiere a la exigencia de que
cualquier persona, incluyendo y especialmente aquellos con impedimentos, pueden acceder y utilizar la
información de productos de tecnología. Para hacer productos como el software o sitios web accesibles
a todos los usuarios, deben ser creados y diseñados de forma que se puedan utilizar incluso si los
usuarios tienen una deficiencia en particular (por ejemplo, deficiencia visual, daltonismo) y debe ser
compatible con tecnologías como lectores de pantalla y ampliadores de pantalla.

Documentación
Como regla general, una norma de producto para la documentación define qué documentos tienen que
ser enviados al cliente con el producto y asegura que la documentación sea coherente, correcta,
actualizada.

Funcionalmente correcto
La correctitud funcional del software es generalmente vista como su cualidad más importante. El
software que no es funcionalmente correcto es generalmente inútil. Como regla general, una norma de
producto para la correctitud funcional requiere que un software se encuentre libre de errores, y define
la estabilidad de las interfaces y el comportamiento del programa durante las actualizaciones. Para
alcanzar estos objetivos, son obligatorias pruebas exhaustivas del software.
Globalización
Si el software es para ser utilizado en todo el mundo, una norma de producto para la globalización es
generalmente necesaria. Esto cubre los aspectos de la internacionalización y localización.

Internacionalización
Internacionalización comprende los aspectos técnicos de la globalización, como la compatibilidad con
Unicode, procesamiento de textos, visualización de la pantalla, la impresión, el intercambio de datos, las
zonas horarias, traducibilidad, y así sucesivamente, por lo que se establecen los requisitos técnicos para
la localización. La traducción de interfaces de usuario y otros textos es también, por supuesto, un
aspecto importante de la internacionalización.

Localización
La localización es necesario si el software para uso global tiene que ser adaptado a las condiciones (por
lo general de países específicos) locales, como los requisitos legales o procedimientos empresariales
particulares.

Desempeño
Incluso si un programa es funcionalmente correcto, es de poco o ninguna utilidad si no se puede
ejecutar en un tiempo razonable. Una norma de rendimiento asegura que este aspecto no se descuida.
Puede incluir, por ejemplo, las reglas para el acceso de base de datos eficiente y escalabilidad de la
lógica de la aplicación.

Seguridad
Donde la seguridad es crítica para el software, y esto es generalmente el caso de cualquier tipo de
software de negocios, una norma de producto para la seguridad expone todos los aspectos relevantes
para la seguridad de un producto, al señalar las lagunas de seguridad potenciales o los requisitos legales,
por ejemplo, y también contiene instrucciones para el cumplimiento de las normas.

Usabilidad
El término usabilidad se refiere a la adaptación de interfaces de usuario a las necesidades de los usuarios
finales y sus tareas. La usabilidad debe garantizar que los usuarios finales puedan realizar sus tareas de
manera eficiente y eficaz. Aspectos claves de usabilidad incluyen consistencia de interfaces de usuario,
facilidad de uso, interfaces de tarea- y en roles específicos intuitivos, adaptabilidad individual, tolerancia
de error, y así sucesivamente.

Aunque estas normas son en parte, requisitos legales, que esencialmente se derivan del objetivo
fundamental de garantizar la correctitud y la calidad del software que se suministra a los usuarios. Las
quías de programación son muy importantes al respecto. Muchas de las guías que figuran aquí fijan su
atención, directa o indirectamente, en una de las normas mencionadas, o se derivan de ellas. Apoyan y
garantizar el cumplimiento de dichas normas, lo que resulta en programas correctos y de alta calidad.
Las guías de programación en sí mismas, incluso podría decirse que están a la par con la unión de
estándares desarrollo.
Sin embargo, ya que no todos los posibles estándares de desarrollo pueden ser cubiertos por las guías
de programación, por ejemplo todas las reglas de desempeño o seguridad estándar que existan, se
propone la siguiente regla básica.

Regla básica: Cumplir con o verificar el cumplimiento de los estándares en productos

existentes
Adherirse a los estándares de los productos que existen en la organización, y garantizar la correctitud y
la calidad de los programas probándolos durante el desarrollo, para después terminar con todas las
herramientas de prueba a su disposición.

Es obvio que usted debe cumplir con los estándares. Sin embargo, a menudo se olvida que las
herramientas de análisis estáticos y dinámicos que están disponibles en el entorno ABAP pueden
proporcionar una ayuda inestimable para el cumplimiento de los estándares importantes, en particular
los estándares de correctitud funcional y desempeño. Por lo tanto, como parte de esta regla básica se
recomienda usar todas las herramientas disponibles que ayudan a garantizar la correctitud y la calidad
de los programas ABAP. Estas herramientas son:

 Realizar la comprobación de programa extendido (transacción SLIN) regularmente y corregir

todos los mensajes.
 Utilizar la herramienta “Inspector de código” (transacción SCI) regularmente utilizando la
variante de verificación estándar, y corregir todos los mensajes.
 Comprobar la usabilidad y la accesibilidad de los elementos de la interfaz mediante el uso de las
herramientas adecuadas (integradas en las herramientas de WorkBench y ABAP Test Cockpit).
 Cubrir todas las funciones de las unidades procesales mediante el uso de pruebas unitarias con
ABAP Unit (integrado en el ABAP Workbench, Code Inspector, y ABAP Test Cockpit).
 Cubre todas las funciones de sus aplicaciones mediante el uso de pruebas de escenarios con
eCATT (transacción SECATT).
 Comprobar el consumo de memoria de sus programas utilizando ABAP Memoria Inspector
(transacción S_MEMORY_INSPECTOR y la función de análisis de memoria integrado en el
depurador ABAP).
 Verificar el comportamiento en tiempo de ejecución y el rendimiento mediante el uso de la
herramienta de análisis de tiempo de ejecución ABAP (transacción SAT).
 Verificar la cobertura de la prueba mediante el uso de Coverage Analyzer (transacción SCOV e
integrado dentro del ABAP Unit Browser del Workbench ABAP).
 Estar pendiente de las notas de seguridad ABAP para proteger los programas y datos de ataques
del exterior.
 Documentar los programas y servicios que utilizan todos los medios disponibles: A partir de los
comentarios, esto comprende la documentación de simples elementos de datos, ayudas de
búsqueda, documentación de clases y métodos para las APIs, explicaciones de conceptos y
tutoriales en otros repositorios como SAP Knowledge Warehouse, o en Internet, por ejemplo, en
SAP Devleoper Community (SCN, http://scn.sap.com)
 ABAP Test Cockpit (ATC) integrado en ABAP Workbench y el sistema de transporte de SAP apoya la
ejecución y evaluación de las pruebas más importantes. Algunas de estas pruebas también
comprueban el cumplimiento de algunas de los estándares de las guías de programación ABAP
discutidas.

Nota

Cuando tenga dudas, los estándares tienen prioridad sobre las guías y recomendaciones de esta
documentación. Si, por ejemplo, los aspectos de desempeño o de seguridad prohíben cualquiera de
las prácticas de programación que se presentan aquí, el cumplimiento del estándar tiene prioridad.

Buen ejemplo
La ejecución de pruebas unitarias para las clases del paquete SABAP_DEMOS_CAR_RENTAL_APPL y
mostrar los resultados en el ABAP Unit Browser del Object Navigator proporciona una cobertura de
prueba del 100%. Este paquete es enviado como un subpaquete para la capa de aplicación de una
aplicación de ejemplo pequeña, lo que, además de las pruebas unitarias, también muestra el
cumplimiento estricto de la separación por componentes.

Reglas específicas en ABAP

Las siguientes reglas-ABAP específicas se derivan de las propiedades técnicas especiales del lenguaje
ABAP, el entorno de ejecución ABAP, y su historia. Estas mismas reglas básicas rigen muchas de las
reglas más específicas discutidas en esta sección.

Objetos ABAP como un modelo de programación

ABAP es un lenguaje de programación híbrido que soporta tanto procedimientos y un modelo de
programación orientada a objetos. El modelo de programación por procedimientos se basa en la
modularización de los programas en los bloques clásicos de procesamiento (bloques de eventos,
módulos de diálogo, módulos de funciones y subrutinas). En Objetos ABAP, la clase reemplaza
conceptualmente el programa clásico y la modularización se implementa utilizando métodos. Desde un
punto de vista técnico, las clases siguen declaradas e implementadas en los programas.

Ambos modelos poseen la interoperabilidad, lo que significa que las clases pueden acceder en bloques
de procesamiento clásicos, a su vez los programas y procedimientos clásicos se puede llamar dentro de
los métodos. La naturaleza híbrida del lenguaje es debido principalmente a la compatibilidad hacia
abajo. Esto se debe a que ABAP tiene sus raíces en procedimientos, y la introducción del modelo de
programación orientada a objetos fue pensado para hacer programas enteros seguros y procedimientos
reutilizables (principalmente módulos de función) todavía se pueden utilizar.

Usar objetos ABAP

Usar objetos ABAP siempre que sea posible para desarrollos nuevos y demás. Bloques de procesamiento
clásicos sólo deben ser creados en casos excepcionales.
La necesidad de lograr la separación por componentes se realiza mejor apoyada por el uso de objetos
ABAP. Programación orientada a objetos - en particular los objetos ABAP en comparación con
procedimientos ABAP clásicos se adaptan mejor a la separación por componentes. Estas son las razones
del por qué:

Encapsulación de datos
Los objetos ABAP permiten un tipo avanzado de encapsulación de datos que se utiliza. En la
programación procedimental clásica, el estado de una aplicación se determina por el contenido de las
variables globales de un programa. En la programación orientada a objetos, el estado está encapsulado
en las clases o los objetos como instancias de clases. La distribución de los datos a través de las
diferentes secciones de visibilidad de una clase, público, protegido y privado permiten una clara
diferenciación entre los datos externos e internos. Incluso sin un profundo modelado orientado a
objetos, programas de aplicaciones se benefician de estas propiedades en términos de estabilidad y
facilidad de mantenimiento.

Instanciación explícita
Objetos ABAP permite múltiples instancias de una clase, mediante la creación de objetos explícitos con
la sentencia CREATE OBJECT. Cada instancia de una clase (objeto) tiene su propio estado que se
determinó a través de los valores de sus atributos. Se puede cambiar el uso de métodos de la clase.
Recolección automática de basura asegura de que todos los objetos que no necesitan se borran de la
memoria. Modelos usando procedimientos no ofrecen múltiples instancias. Por lo tanto funciones sin
estado deben aplicarse a los datos almacenados en repositorios separados.

Herencia
Objetos ABAP permite la reutilización de clases a través de la herencia, en las clases con
comportamientos especiales se derivan de las clases más generales. Sólo las diferencias se deben
implementar de nuevo. En el modelo de procedimiento, las funciones existentes solamente se pueden
utilizar tal como son, o nuevas funciones deben ser creadas.

Interfaces
En Objetos ABAP, los objetos pueden dirigirse mediante interfaces independientes. Esto significa que los
desarrolladores no tienen que preocuparse por los detalles de implementación de la clase detrás de la
interfaz. El proveedor de un interfaz puede cambiar las implementaciones subyacentes, sin tener que
modificar los programas que utiliza la interfaz. El modelo de procedimiento no tiene este concepto de
interfaces independientes.

Eventos
Objetos ABAP hace que sea más fácil de implementar flujos de programas basados en eventos. El
disparador de eventos no necesita saber nada acerca de los posibles manipuladores. Esto permite una
mayor flexibilidad que el enfoque de procedimiento, donde los programas son mucho más fuertemente
acoplados y el flujo del programa es por lo general mucho más estrictamente definido.
Sintaxis limpia
Objetos ABAP utiliza reglas de sintaxis limpia y reglas semánticas. ABAP clásico es un lenguaje que ha
evolucionado con el tiempo, y contiene varios conceptos obsoletos y superpuestos. La introducción de
objetos ABAP significa que las clases y métodos siempre están en un campo de sintaxis y semántica
claros, que era absolutamente resistente a los requisitos de compatibilidad hacia abajo. Esto significaba
que las construcciones del lenguaje más obsoletas y propensos a errores fueron sintácticamente
prohibidos en Objetos ABAP (dentro de las clases y métodos). Además, cualquier acceso cuestionables y
potencialmente incorrecta a la base de datos se comprueban más de cerca y también puede ser
prohibidos. La limpieza de sintaxis hace cumplir el uso del lenguaje ABAP en las clases,.

El acceso a las nuevas tecnologías

Objetos ABAP es a menudo la única manera de hacer frente a las nuevas tecnologías ABAP. Por ejemplo,
los controles de GUI, Web Dynpro ABAP, servicios de tipo en tiempo de ejecución (RTT), o Internet
Conexión Framework (ICF) sólo proporcionan interfaces basadas en clases. Si todavía se implementaran
los programas que utilizan estos servicios sobre una base puramente procedimental, esto daría lugar a
una mezcla innecesaria de modelos de programación y una mayor complejidad.

Por lo tanto la recomendación urgente de utilizar objetos ABAP tiene ambas cuestiones formales y de
contenido:

Como se describe en los puntos 1 a 5, el modelo de programación orientada a objetos es más adecuado
para mantener la complejidad del software manejable a través de principios, tales como la
encapsulación y herencia. Es cierto que un buen diseño orientado a objetos no es una tarea fácil, y hay
desarrolladores con experiencia sólo limitada en esta área, incluso hoy en día. Ante estos hechos,
cualquier persona que todavía está considerando la posibilidad de acercarse a un nuevo desarrollo en la
forma de procedimientos clásicos, debe tener en cuenta que el modelo de programación de
procedimientos orientado a eventos ABAP con sus eventos tampoco son fáciles de entender.

Puntos 6 a 8 describen los aspectos más formales. Estos puntos sugieren que los procedimientos deben
ser creados sólo como métodos, incluso en ausencia de un diseño orientado a objetos real. Módulos de
función y subrutinas deben crearse sólo en casos excepcionales, cuando Objetos ABAP no proporciona
actualmente ninguna alternativa.

Excepción
Las siguientes propiedades siguen desaparecidas en Objetos ABAP. Son necesarios para reemplazar
bloques de procesamiento clásicos con los métodos:

 Remote Method Invocation (RMI) como reemplazo de Remote Function Call (RFC)
 Un reemplazo para la llamada de los módulos de función de actualización (CALL FUNCTION IN
UPDATE TASK)
 Un reemplazo para la llamada de subrutinas durante COMMIT WORK y ROLLBACK WORK
(PERFORM ON COMMIT/ROLLBACK)
 Manipulación orientada a objetos de dynpros clásicos, incluyendo pantallas de selección como
un reemplazo para las transacciones de diálogo, CALL SCREEN y CALL SELECTION-SCREEN
  Generación dinámica de las clases como un reemplazo para la generación dinámica clásica
(GENERATE SUBROUTINE POOL)
 El apoyo directo de procesamiento en segundo plano como un reemplazo para la convocatoria
de programas ejecutables (SUBMIT VIA JOB)

En estos casos, los siguientes bloques de procesamiento clásicos todavía se pueden crear en nuevos
programas:

 Aún se requieren módulos de función para el RFC y la actualización y se recomiendan para la

llamada de dynpros clásicos y pantallas de selección.
 Aún se requieren subrutinas para PERFORM COMMIT/ROLLBACK y en los pool de subrutinas
generadas dinámicamente (GENERATE SUBROUTINE POOL)
 Aún se requieren módulos de diálogo y bloques de eventos para eventos de pantalla de
selección de grupos de funciones que envuelven los dynpros clásicos y pantallas de selección.
 El evento START-OF-SELECTION sigue siendo necesario en programas ejecutables que están
destinados para el procesamiento en fondo.

Dentro de este tipo de bloque de procesamiento, sin embargo, la ejecución debe delegarse de
inmediato a un método adecuado, esto no tiene que ser un método de una clase global, pero puede
estar situado en el programa principal asociado dentro del alcance de una clase local. Para asegurar que
el sistema implementa la misma comprobación más estricta en estos bloques de procesamiento como
en los métodos, las comprobaciones de declaraciones obsoletas (en el contexto OO) se pueden activar
en la verificación de programas ampliada.