SAP Netweaver / ABAP                  Notas técnicas / Tips / Tutorials

Tutorial ABAP Objects: Parte 1

Conozca el universo de la programación orientada a objetos en SAP implementada con ABAP Objects. En este “tip”, el primero de la serie de Tutoriales de ABAP Objects, veremos conceptualmente cómo se implementa el paradigma de objetos en el mundo SAP. En los próximos artículos se tratarán en detalle ejemplos de programación paso a paso, y otras características del entorno.

La programación orientada a objetos (POO) es una filosofía de diseño y desarrollo de software donde el modelo informático es un reflejo de las entidades del mundo real. A diferencia de los lenguajes tradicionales, donde existen procedimientos por un lado y datos por el otro, la POO permite a los programadores representar cada entidad del problema como un objeto “encapsulado” que contiene tanto sus datos y cómo los “comportamientos” gestionan sobre ellos.

 

Valiéndose de un lenguaje y entorno que respete los principios de la teoría de objetos, los objetos se crean a partir de una definición ”abstracta” de los mismos, denominada “clase”, que describe sus características y comportamientos. Los objetos concretos luego serán  “ejemplares” o “instancias” de esa "plantilla" abstracta que es la clase. Por ejemplo, clases y objetos típicos del entorno de negocios son "Clientes", "Materiales", "Ordenes de compra", etc.

La teoría de objetos se estructura alrededor en un conjunto de propiedades y paradigmas conceptuales (que exceden el alcance de este artículo), implementados luego en los distintos entornos de programación. Existen, numerosas y probadas ventajas asociadas a la programación orientada objetos que incluyen el encapsulamiento de la complejidad, la reusabilidad del código, la modularidad, entre otros.

La programación orientada a objetos representó una verdadera revolución en el universo del desarrollo de software, impulsando a programadores, analistas y arquitectos de sistemas a re-aprender su forma de concebir código y aplicaciones. En una primera instancia, lenguajes como C++, y luego JAVA, se convirtieron en los entornos de programación OO más emblemáticos.

En el mundo SAP, el instrumento que disponemos en ABAP para trabajar de acuerdo a este paradigma son los "ABAP Objects".

La introducción de ABAP Objects en el Release 4.6 representó un avance fundamental para incorporar técnicas de programación contemporáneas en un lenguaje tradicionalmente procedural. Sin embargo, la plena materialización del paradigma de objetos en el mundo SAP, llegó recién a partir de la versión 6.10, con el advenimiento del Web Application Server como sucesor de SAP Basis.

El concepto de ABAP Objects representa dos cosas distintas en el mundo SAP. Por un lado, designa a la concepción de toda la plataforma de ejecución como un nuevo paradigma de trabajo. Por otro lado, designa a la nueva extensión del lenguaje ABAP.

El propósito de este “tip”, el primero de la serie de Tutoriales de ABAP Objects, es entender  conceptualmente cómo se refleja el paradigma de objetos en el mundo SAP. No es el propósito de este tutorial definir en detalle la teoría de objectos en su vasta dimensión, sino discutir su implementación en el universo de ABAP Objects.

En los próximos artículos se tratarán en detalle ejemplos de programación paso a paso, y otras características del entorno.

Los paradigmas de Orientación a Objetos en ABAP Objects

Como se dijo anteriormente, el lenguaje ABAP y el entorno de programación SAP, logra a partir de una nueva versión con extensión orientada a objetos, el diseño de nuevas aplicaciones, basadas en la teoría de objetos.

Comparado con otros, ABAP no es un lenguaje “puro” orientado a objetos. El runtime de ABAP soporta tanto el modelo de programación procedural como el de ABAP Objects en cualquier programa ejecutable, módulos o funciones.

Esto permite la utilización de nuevas técnicas basadas en ABAPsin necesidad de re-escribir todo el código.

Propiedades de un paradigma orientado a objetos:

Son precisamente las propiedades del paradigma de objetos lo que le otorga su singularidad y todas las ventajas de modularidad cuando se plasman en la programación.

abap-objects-propiedades

Encapsulamiento: Es el término que define formalmente la fusión dentro del mismo objeto de sus datos y métodos (comportamiento). Los objetos son tratados como “caja negra”, de manera que sólo sus métodos pueden actuar sobre sus datos, brindando independencia en la implementación de los mismos..

Abstracción: Permite a un objeto comunicarse y desconocer el forma en que se lleva a cabo el mensaje.

Polimorfismo: Capacidad que tienen objetos de distintas clases de responder a un mismo método y obtener diferentes reacciones.

Herencia: Se produce cuando una clase (la subclase) comparte la estructura (atributos) y el comportamiento (métodos) definidos en una o más clases (superclases). (Nota: En ABAP sólo está permitida la herencia simple.)

Obviamente, estas propiedades se ven reflejadas en la implementación de POO que hace ABAP Objects.

Es interesante contrastar las capacidades de ABAP Objects con las de otros lenguajes OO populares, en términos de cómo se ciñe al modelo POO.

Cuadro de diferencia entre los lenguajes de programación orientado a objetos:

 

Características

ABAP

JAVA

C++

Se permite herencia múltiple

No

No

Si

Es un lenguaje puro orientado a objetos

NO

SI

NO

Liberación de objetos de forma automática

SI

SI

NO

Existe el concepto “interfaz”

SI

SI

NO

Heredan de la clase OBJECT

SI

SI

NO

Manejo de parámetros opciones de forma explicita

Si

NO

NO

Los programas se ejecutan sobre…

Application Server ABAP

Procesador virtual JMV (Java Virtual Machine)

Sobre el sistema operativo

 

Describiremos a continuación las principales sentencias que se utilizan en ABAP para trabajar con objetos.

A – Clases en ABAP Objects

En la programación orientada a objetos, la única unidad de estructuramiento son las clases. En lugar de trabajar sobre datos y procedimientos, como en un lenguaje convencional, trabajamos con objetos que encapsulan y auto-contienen  sus datos y la forma de gestionar sobre los mismos.

Las clases son una definición abstracta de objetos. Esto significa que la definición o declaración de un objeto es la clase. Luego, los objetos propiamente dichos serán "ejemplares" de una clase cualquiera. Esta acción de crear un objeto a partir de una clase se llama instanciar, por eso se conocen a los objetos como instancias de una clase.

Las propiedades o atributos de una clase en una clase conforman las características de los objetos. Estos atributos están definidos por las componentes de la clase que describe el estado (los datos).

Tipos de clases: Globales Vs. Locales

Las clases en ABAP Objects pueden ser declaradas globalmente o localmente. Así como existe una manera de definir un Function Group o un Function Module desde el ABAP Workbench para ser usados en la programación ABAP tradicional, también es posible definir las clases globales y las interfaces en el ABAP Workbench mediante el Class Builder (Transaction SE24). Estas clases son almacenadas centralmente en pools de clases en la biblioteca de clases dentro del repositorio de SAP.

Todos los programas ABAP en un sistema SAP pueden acceder a las clases globales. Las clases locales son las que se definen dentro de un programa ABAP. De esta manera, las interfaces y las clases locales pueden ser usadas solamente en el programa en donde están definidas. Cuando se usa una clase en un programa ABAP, el sistema primero busca una clase local con el nombre especificado. Si no se encuentra ninguna, busca una clase global.

 

Definición de una clase local

La definición completa de una clase en ABAP Objects consiste en una sección de declaración, y otra de implementación, ambas iniciadas con la sentencia CLASS.

 

Sentencia para la declaración de una clase local:

CLASS <class> DEFINITION.

ENDCLASS.

 

 

Sentencia para la implementación de una clase local:

CLASS <class> IMPLEMENTATION.

ENDCLASS.

 

B - Componentes de una clase

Los componentes de una clase conforman su contenido, y se declaran en la parte declarativa del código. Definen las propiedades de los objetos de esa clase.

Cuando la clase se define, cada componentes se asocia a una de las tres posibles secciones de visibilidad: público, protegido o privado. Las secciones de visibilidad definen la interfaz externa de la clase.(ver apartado sobre visibilidad más abajo)

Todos los componentes son visibles dentro de la clase, y comparten el mismo espacio de nomenclatura, por lo que cada componente debe tener un nombre unívoco dentro de su clase.

Se implementan en ABAP dos tipos de componentes en una clase, aquellos que existirán en cada uno de los objetos o instancias de clase, adquiriendo valor separadamente uno para cada objeto, y aquellos que existen sólo una vez para la clase entera, independientemente de la cantidad de instancias, denominados componentes ESTATICOS. A los primeros, en cambio, se los llama componentes específicos de instancia.

Las componentes de una clase son los atributos, los métodos, los eventos, los tipos y las constantes.

B-1 Atributos

En ABAP los atributos son los campos internos de DATOS definidos para la clase. Pueden declararse a partir de cualquier tipo de dato válido en ABAP. En cada instancia de clase los atributos reflejarán el estado del objeto (es decir, los datos del objeto). Respetando la clasificación general enunciada para los componentes de clase, tendremos dos tipos de atributos: los específicos de instancia, y los estáticos.

 

  • Atributos dependientes de instancia. El contenido de estos atributos define el estado propio e individual de cada objeto en cada instancia de clase. Se declaran usando la sentencia DATA.
  • Los atributos ESTATICOS. Definen el estado de la clase válido para todas las instancias de la mismo. Existen, por lo tanto, sólo una vez para la clase, y son accesibles durante todo el runtime de la clase. Todos los objetos pueden acceder a sus atributos estáticos de su clase, y si se cambia un atributo estático en un objeto, el cambio es visible en todos los demás objetos de la clase.

B– 2 Métodos

Las funcionalidades asociadas a los objetos se definen a través de los métodos, que de esa forma determinan el comportamiento de los objetos. Los métodos son procedimientos que definen el comportamiento de un objeto, su funcionalidad asociada. Se utilizan para acceder a los atributos privados de una clase, como también modificarlos mediante una interfaz con parámetros que les permite recibir valores y devolver valores después de la llamada.

En ABAP, un método se define en la parte declarativa de la clase y luego se implementa en la parte de implementación. Nuevamente, por ser componentes de clase, cabe la misma diferenciación en métodos dependientes de instancia, y estáticos.

  • METODOS dependientes de la instancia: Se declaran usando la sentencia METHODS y pueden acceder a todos los atributos de una clase y desencadenar algún evento de la misma.
  • Métodos estáticos (independientes de instancia): Se declaran usando la sentencia CLASS-METHODS. Sólo pueden acceder a los atributos estáticos y desencadenar eventos estáticos.

 

Declaración de métodos

Métodos dependientes de instancia

 

METHODS <meth>

IMPORTING.. [VALUE(]<ii>[)] TYPE type [OPTIONAL]..

EXPORTING.. [VALUE(]<ei>[)] TYPE type [OPTIONAL]..

CHANGING.. [VALUE(]<ci>[)] TYPE type [OPTIONAL]..

RETURNING VALUE(<r>)

EXCEPTIONS.. <ei>..

 

Para declarar métodos estáticos se usa se usa la siguiente sentencia:

CLASS-METHODS <meth>..

IMPORTING.. [VALUE(]<ii>[)] TYPE type [OPTIONAL]..

EXPORTING.. [VALUE(]<ei>[)] TYPE type [OPTIONAL]..

CHANGING.. [VALUE(]<ci>[)] TYPE type [OPTIONAL]..

RETURNING VALUE(<r>)

EXCEPTIONS.. <ei>..

 

Implementación de métodos

 

Cuando se implementa un método no es necesario  especificar los tipos de datos de los parámetros, debido a que se encuentran ya se encuentran definidos en la declaración. En un método se pueden declarar tanto las variables locales, como también usar las sentencias RAISE <exception> y MESSAGE RAISING para controlar los errores.

 

METHOD <meth>

IMPORTING..[VALUE(]<ii>[)]

EXPORTING..[VALUE(]<ei>[)]

CHANGING.. [VALUE(]<ci>[)]

RETURNING VALUE(<r>)

EXCEPTIONS.. <ei>..

ENDMETHOD.

 

Nota: Los métodos estáticos sólo pueden trabajar con los atributos estáticos de la clase.

 

Llamadas al método

Las llamadas al método dependerán de dónde se lo invoque:

  • En la parte de implementación de una clase se pueden llamar directamente métodos de la misma clase simplemente usando su nombre.

CALL METHOD <meth>.

 

  • Desde fuera de la clase, sólo se llama a los métodos cuya visibilidad nos permite hacerlo.

CALL METHOD <cref>-><meth>.

A partir de 6.10 se puede llamarlo así: <cref>-><meth> directamente, sin la palabra clave CALL METHOD

donde <cref> es una variable de referencia cuyo valor apunta a una instancia de la clase.

 

  • Los métodos visibles estáticos también pueden ser llamados

CALL METHOD <class>=><meth>.

A partir de 6.10 se puede llamarlo así: <class>=><meth>

donde <class> es el nombre de la clase.

 

En un método los pasajes de parámetros de entrada son opcionales; dentro del método se declaran con el tipo IMPORTING. En cambio los de salida, no son optativos y se utiliza como tipo a EXPORTING o RETURNING. En el caso de RETURNING sólo se admite un único parámetro de salida y se puede combinar únicamente con parámetros declarados como IMPORTING. El caso de CHANGING también puede ser opcional.

 

B-3 Constructores

Los constructores son un tipo especial de métodos y su definición e implementación es igual que cualquier otro método. Son llamados automáticamente por el sistema (cuando se crea un objeto, es decir, cuando se crea una instancia, mediante la sentencia CREATE OBJECT),  para fijar el estado inicial de un nuevo objeto o clase (constructor estático). Los constructores, tanto si están parametrizados como si no lo están,  para ser implementados deben estar declarados explícitamente, y en su declaración se puede contemplar el manejo de errores.

Declaración de constructor:

  • El constructor dependiente de instancia

METHODS CONSTRUCTOR

IMPORTING..[VALUE(]<ii>[)] TYPE type [OPTIONAL].

EXCEPTIONS..<ei>.

 

  • El constructor estático, no contiene parámetros y es llamado una vez por cada clase

CLASS-METHODS CLASS_CONSTRUCTOR.

 

Implementacion de un constructor:

  • Dependiente de la instancia

METHOD CONSTRUCTOR.

ENDMETHOD.

  • Independiente ó estático.

METHOD CLASS_CONSTRUCTOR.

 

 

B-4 Eventos

Un evento es una acción que se ejecuta dinámicamente. Son usados por los objetos o las clases para desencadenar métodos en otros objetos o clases, llamados por los usuarios.  Son semejantes de los métodos, sin embargo solo poseen parámetros de salida pasados por el disparador y el método manejador los recibe como entrada.

Cuando un evento es disparado por un disparador de evento (trigger), el correspondiente método manejador de eventos (event handler methods) es ejecutado en todas las clases registradas por ese manejador (son los objetos registrados; clases es en el caso que sea estatico pero es poco común. Puede haber 2 objetos de una misma clase en el cual el primero está registrado/subscripto al evento de un tercer objeto pero el segundo no), el cual determina los eventos  que deben reaccionar.  La relación entre el disparador y el método manejador de eventos se realiza en tiempo de ejecución.

 

Lanzamiento de un evento

RAISE EVENT <evt>.

 

Declaración de un método manejador de eventos para la misma o diferente clase

FOR EVENT <evt> OF <class>.

 

Vinculo entre el disparador y el manejador (trigger y handler):

SET HANDLER.

 

Clasificación de eventos

 

  • Eventos dependientes de instancia: Son declarados con la sentencia EVENTS <evt> y solo pueden ser desencadenados en un método dependiente de instancia.

 

  • Eventos estáticos o independientes de instancia: Se declaran con la sentencia CLASS-EVENTS y solo pueden desencadenarse por un método estático de la clase.

 

B-5 Tipos y Constantes

Los tipos se datos se declaran dentro de la clase por única vez y se realiza utilizando la sentencia TYPES.

 

Las constantes permiten que dar a un objeto de dato interno un valor fijo durante su declaración y éste no puede ser modificado. La sentencia usada es CONSTANTS.

 

B-6 Visibilidad

Los componentes de una clase se pueden declarar en tres áreas de distinta visibilidad: Cuando la clase se define, cada componentes se asocia a una de las tres posibles secciones de visibilidad: público, protegido o privado. Las secciones de visibilidad definen la interfaz externa de la clase.

CLASS <class> DEFINITION.

PUBLIC SECTION.

PROTECTED SECTION.

PRIVATE SECTION.

ENDCLASS.

 

Tipos de visibilidad:

  • Public section: Permite que los componentes pueden ser accedidos por todos los usuarios de la clase, métodos de la clase y además por cualquier clase que herede de ella.
  • Protected section: Los componentes solo logran ser accedidos por los métodos de la clase y de las clases que heredan de ella
  • Private section: Los componentes sólo serán accedidos por métodos de la misma clase.

 

Todos los componentes son visibles dentro de la clase, y comparten el mismo espacio de nomenclatura, por lo que cada componente debe tener un nombre unívoco dentro de su clase.

C- Objetos

 

Los objetos son entidades tangibles de una clase que residen dentro de un contexto de una sesión interna (área de memoria de un programa ABAP).

 

Características de un objeto:

  • El estado, los valores concretos (datos) asignados a los atributos.
  • El comportamiento, se define por los procedimientos que puede realizar un objeto.
  • La identidad es una propiedad de un objeto que lo diferencia del resto, como es el nombre.

Creación de un objeto

La sentencia CREATE OBJECT <cref> crea una instancia de una clase. La variable referenciada <cref> contiene la referencia al objeto.

 

Acceder a los componentes de un objeto

Para acceder a un componente de un objeto dependerá del tipo de componente y desde dónde se quiere invocar. Se detallas las 3 maneras distintas de lograrlo.

 

Los programas ABAP sólo pueden acceder a los componentes de las instancias de un objeto usando las variables referenciadas <cref>.

 

  • Para acceder al atributo attr: class->attr.
  • Para llamar al método meth: CALL METHOD cref->meth.

 

Para los componentes estáticos (dependientes de clase) se puede usar tanto el nombre de la clase como la variable referenciada.

 

  • Para acceder al atributo estático attr: class=>attr.
  • Para llamar al método estático meth: CALL METHOD class=>meth.

 

Dentro de una clase se puede acceder también a los componentes individuales mediante la referencia a sí mismo ME:

 

  • Para acceder al atributo attr en la propia clase: me->attr. (también se acepta sólo attr)
  • Para llamar al método meth en la propia clase: CALL METHOD me->meth.

 

Tiempo de vida de un objeto

Un objeto solo puede seguir existiendo siempre y cuando haya una referencia a un objeto ó cuando un objeto maneja el evento de otro objeto (handler). De lo contrario el objeto es borrado de la memoria automáticamente.

 

Referencias

Las variables de referencia permiten acceder a los objetos. En vez de crear variables de referencia con referencia a una clase, se las puede definir con referencia a una interfaz. Este tipo de variables únicamente puede contener referencias a objetos de clases que implementan la interfaz correspondiente.

Se la define mediante la adición TYPE REF TO <intf>.

Si se desea crear una nueva instancia de la clase que implementa esta interfaz, se lo debe hacer mediante la sentencia:

CREATE OBJECT <iref> TYPE <aclass>, donde <iref> es una variable de referencia a interfaz y <aclass> la clase que implementa a <intf>

Si la instancia ya existe se puede hacer la siguiente asignación entre la variable de referencia a clase y la variable de referencia a interfaz:

<iref> = <cref>.

Cuando se quiere acceder a un componente definido en la interfaz <intf> mediante la variable de referencia a clase <cref> se lo debe hacer mediante la siguiente forma:

<cref>-><intf~compi>

Pero cuando se accede mediante <iref> se lo hace a través de la forma:

<iref>-><compi>.

 

Definición de una referencia a un objeto:

… TYPE REF TO <class>.

 

D- Herencia de clases

La herencia se realiza entre dos clases (una superclase y una subclase). La subclase heredará los componentes públicos y privados de la superclase, logrando el mismo comportamiento. Teniendo la posibilidad de extender o limitar ese comportamiento para proveer una acción requerida.

Cabe aclarar que aunque hereda los componentes privados, éstos NO son visibles dentro de la subclase. Es decir, no puede hacer referencia directamente a atributos privados y alterarlos. Se van a poder manipular únicamente si en la superclase hay métodos public o protected que lo permiten.

abap-objects-herencia

 

El nodo raíz de todos los árboles de herencia en ABAP Objects es la clase predefinida vacía OBJECT.

 

 

Definición para una herencia:

CLASS <subclass> DEFINITION INHERITING FROM <superclass>.

 

Nota: Los atributos estáticos sólo existen una vez y son visibles en todas las clases del árbol de herencia.

 

Debido a que los constructores no se heredan, hay existen dos maneras de implementarlo que dependerá de si existe dependencia ó no a una instancia.

 

Constructores dependientes de instancia

Un constructor dependiente de instancia de una subclase solo se ejecutara si todos los constructores dependientes de la superclase son llamados.

Llamado al constructor de la superclase.

CALL METHOD SUPER->CONSTRUCTOR EXPORTING…

 

Constructores estáticos

Se ejecuta de la misma manera que los constructores dependientes de la instancia solo varia en la declaración de la implementación.

 

Llamado al constructor de la superclase.

CLASS_CONSTRUCTOR.

 

Clases y métodos abstractos y finales

Las  sentencias METHODS y CLASS mediante las adiciones ABSTRACT y FINAL permiten definir tanto a los métodos como a las clases de forma abstracta o final.

 

Diferencias:

  • Un método abstracto solo se puede definirse en una clase abstracta y puede ser implementado en sus respectivas subclases.
  • Las clases abstractas no pueden ser instanciadas. Son utilizadas para la declaración de métodos no abstracto, pero al menos debe contener un método abstracto.

 

  • Un método final es la manera de proteger métodos para no ser redefinidos por las subclases.
  • Las clases finales no pueden tener subclases, debido a que son las que finalizan el árbol de herencia.  De forma implícita todos sus métodos son “final”.

 

E- Interfaz

El objetivo de una interfaz es establecer relaciones entre clases sin usar herencia, ya que a veces no hay una super-clase adecuada para establecer una relación de herencia.

Una interfaz no puede instanciar objetos, sin embargo pueden definirse atributos static y final. Se utiliza principalmente para la definición de métodos abstractos, por lo cual la implementación se realiza en otras clases. Todos los componentes son visibles para las clases en donde se implementan los métodos definidos.

 

Definición de interfaz

INTERFACE <intf>.

ENDINTERFACE.

Implementación de la  interfaz (la implementación debe estar dentro de una clase que usa esta interfaz)

METHOD <intf~imeth>.

ENDMETHOD.

 

Referencias a interfaces

Las variables de referencia permiten acceder a los objetos. En vez de crear variables de referencia con referencia a una clase, se las puede definir con referencia a una interfaz. Este tipo de variables únicamente puede contener referencias a objetos de clases que implementan la interfaz correspondiente.

Se la define mediante la adición TYPE REF TO <intf>.

Si se desea crear una nueva instancia de la clase que implementa esta interfaz, se lo debe hacer mediante la sentencia:

CREATE OBJECT <iref> TYPE <aclass>, donde <iref> es una variable de referencia a interfaz y <aclass> la clase que implementa a <intf>

S la instancia ya existe se puede hacer la siguiente asignación entre la variable de referencia a clase y la variable de referencia a interfaz:

<iref> = <cref>.

Cuando se quiere acceder a un componente definido en la interfaz <intf> mediante la variable de referencia a clase <cref> se lo debe hacer mediante la siguiente forma:

<cref>-><intf~compi>

Pero cuando se accede mediante <iref> se lo hace a través de la forma:

<iref>-><compi>.

 

F- Exception

Es una situación que ocurre durante la ejecución de un programa que interrumpe o cambia su normal comportamiento. La idea fundamental es que tales situaciones puedan ser manejadas de alguna forma. Las excepciones son representadas por una instancia de una clase “excepción”. Los atributos de tal objeto van a contener información acerca de la situación ocurrida.

Una excepción puede ser “levantada” con la sentencia RAISE EXCEPTION. Cuando esto ocurre, el sistema busca un manejador adecuado que se haga cargo y en el caso de no encontrarlo, se produce un error en tiempo de ejecución. Este manejo se puede llevar únicamente a cabo si la sentencia que podría ocasionar que se levante la excepción, se encuentra encerrada por el bloque TRY-ENDTRY. Específicamente, el manejo de la excepción se realiza con la sentencia CATCH que se encuentra dentro del bloque.

TRY.

SENTENCIA_X.

CATCH cx_exc_1 INTO ref_exc_1.

CATCH cx_exc_2 INTO ref_exc_2.

CLEANUP.

ENDTRY.

“SENTENCIA_X” puede ser una subrutina, un modulo de función, el método de un objeto o algo que pueda lanzar una o más excepciones. Cada “cx_exc_i” es una clase excepción que puede ser lanzada dentro de “SENTENCIA_X”. “ref_exc_i” es una instancia de la clase “cx_exc_i” o de alguna. Lo que se encuentra dentro del bloque CLEANUP se produce cuando el sistema no encuentra un manejador para la excepción que fue levantada. Si SENTENCIA_X levanta la excepción cx_exc_3 y no existe un CATCH para la misma, se ejecutará las instrucciones que se encuentren en el bloque CLEANUP.

Estos conceptos definen las generalidades de la implementación del paradigma orientado a objetos en el mundo SAP a través de ABAP Object. En el próximo tip de la serie de tutoriales, abordaremos un ejemplo concreto.


n_Celeste-Coopa - Especialista ABAP

Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, Netweaver, R/3, Fiori,S4/HANA y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA

 

 

Copyright © 2024 Teknoda Tech Portal & Training. Todos los derechos reservados.
Joomla! es software libre, liberado bajo la GNU General Public License.