Conceptos del SDK de SAP ABAP - AWS SDKpara SAP ABAP

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Conceptos del SDK de SAP ABAP

Esta sección cubre los conceptos básicos de AWS SDK para SAP ABAP.

Clases de API

A cada uno Servicio de AWS se le asigna un acrónimo de tres letras oTLA. El servicio está representado por una interfaz en el formato /AWS1/IF_<TLA>. A esto lo llamaremos interfaz de servicio. La clase de API está en el paquete /AWS1/API_<TLA>. La interfaz de servicio consta de un método para cada AWS operación (llamaremos a estos métodos métodos de operación). Para ver una lista completa de los AWS SDK para SAP ABAP TLA de módulos, consulte AWS SDK para SAP ABAP Lista de módulos.

Cada método de operación tiene algunos argumentos IMPORTING y, como máximo, un argumento RETURNING. A menudo, estos argumentos son objetos con constructores complicados y un conjunto extenso de métodos GET…(). En muchos casos, los objetos contendrán objetos anidados, referencias recursivas, tablas de objetos, tablas de tablas, etc. Esto se debe a que Servicios de AWS están transmitiendo estructuras XML y JSON profundas, que no se pueden representar mediante un conjunto plano de argumentos.

El RETURNING argumento es siempre una clase, incluso si la clase contiene solo un atributo.

Objetos adicionales

Además de contener la clase de API principal, cada paquete de API contiene varios objetos de repositorio y diccionario de datos relacionados.

  • Una clase para cada objeto de tipo de estructura.

  • Una clase para cualquier tipo de datos primitivo que aparezca en una tabla. Por ejemplo, si un servicio devuelve una tabla de cadenas, la API de ABAP la representará como una tabla de objetos, donde cada objeto es una clase de contenedor que encapsula una cadena. Esto sirve para que la clase de contenedor pueda ocultar los detalles de la representación de una cadena nula que no se pueda representar de forma nativa en ABAP.

  • Una clase de excepción para cualquier error específico definido por el servicio.

  • Elementos de datos para cada tipo de datos primitivo. Cada tipo de datos tiene su propio elemento de datos para poder documentarse automáticamente.

  • Objetos adicionales para el procesamiento interno, como las transformaciones XSLT para realizar la serialización directa e inversa del contenido en archivos XML y JSON.

Establecimiento de estructura de clases

La mayoría de AWS los datos, enviados y recibidos por el servicio, se representan mediante el AWS SDK como clases. Estas clases representan estructuras de datos y ocultan los detalles internos del almacenamiento. En concreto, las clases ocultan la forma en que el SDK representa que este campo no tiene ningún valor.

Para cada campo de una clase de estructura, hay tres métodos.

GET_field( )

El método GET_field( )

  • Devuelve el valor del campo, o

  • Si el campo no tiene ningún valor, devuelve un valor predeterminado, que se puede establecer como parámetro opcional.

Por ejemplo, fíjese en el siguiente código que imprime la restricción de ubicación de un bucket.

DATA(lo_location) = go_s3->getbucketlocation( iv_bucket = CONV string( gv_bucket ) ). WRITE: / 'Bucket Location: ',    lo_location->get_locationconstraint( ). 

Si el bucket no tiene ninguna restricción de ubicación (como en el caso de us-east-1), GET_LOCATIONCONSTRAINT( ) devolverá la cadena vacía. Puede anular este comportamiento y especificar el valor deseado si el campo no tiene ningún valor.

DATA(lo_location) = go_s3->getbucketlocation( iv_bucket = CONV string( gv_bucket ) ). WRITE: / 'Bucket Location: ',    lo_location->get_locationconstraint( iv_value_if_missing = 'assuming us-east-1' ). 

Ahora el programa escribirá Bucket Location: assuming us-east-1 si el resultado de getbucketlocation() no devuelve una ubicación.

Es posible pedirle al método GET( ) que devuelva un resultado específico si falta por completo el valor solicitado; consulte el siguiente ejemplo de código.

data(lo_location) = go_s3->GETBUCKETLOCATION( new /AWS1/CL_S3_GET_BUCKET_LOC_REQ( iv_bucket = gv_bucket ) ). write: / 'Location constraint: ', lo_location->GET_LOCATIONCONSTRAINT( 'NopeNopeNope' ).

En este caso, si no hay ninguna restricción de ubicación, GET_LOCATIONCONSTRAINT( ) devolverá NopeNopeNope.

HAS_field( )

El método HAS_field( ) es una forma de averiguar si el campo tiene un valor o no. Consulte el siguiente ejemplo.

if NOT lo_location->HAS_LOCATIONCONSTRAINT( ).    write: / 'There is no location constraint'. endif.

Si se sabe que un campo determinado siempre tiene un valor, no habrá ningún método HAS_field( ).

ASK_field( )

El método ASK_field( ) devuelve el valor del campo o genera una excepción si no tiene ningún valor. Esta es una forma cómoda de procesar varios campos y abandonar la lógica y adoptar un enfoque diferente si alguno de los campos no tiene valor.

TRY.    WRITE: / 'Location constraint: ', lo_location->ask_locationconstraint( ). CATCH /aws1/cx_rt_value_missing.    WRITE: / 'Never mind, there is no location  constraint'. ENDTRY.

Tenga en cuenta que /AWS1/CX_RT_VALUE_MISSING es una excepción estática y recibirá una advertencia si decide no atraparla.

Prácticas recomendadas

En general, puede usar el método GET_field( ), ya que trata una cadena nula como una cadena vacía y es la que más se parece a ABAP de las tres opciones. Sin embargo, no permite distinguir fácilmente entre situaciones en las que el campo tiene un valor en blanco y en las que no tiene ningún valor. Si su lógica empresarial depende de distinguir los datos que faltan de los datos en blanco, los métodos HAS o ASK le permiten gestionar estos casos.

Matrices

Las matrices se representan como tablas de objetos estándar de ABAP.

Una matriz JSON puede contener valores nulos, como la siguiente matriz: [‘cat’, ‘dog’, null, ‘horse’]. Esto se conoce como matriz dispersa. Se representa en ABAP como una tabla interna de referencias a objetos y el valor null se representa en la tabla como un valor null de ABAP verdadero. Al recorrer en iteración una tabla dispersa, debe comprobar los valores null para evitar acceder a un objeto null y obtener una excepción CX_SY_REF_IS_INITIAL. En la práctica, las matrices dispersas son poco frecuentes en los servicios de AWS .

Para inicializar una matriz de objetos, es conveniente utilizar los nuevos constructos de ABAP 7.40. Fíjese en este lanzamiento de una instancia de Amazon EC2 con varios grupos de seguridad asignados:

ao_ec2->runinstances(     iv_imageid                   = lo_latest_ami->get_imageid( )     iv_instancetype              = 't2.micro'     iv_maxcount                  = 1     iv_mincount                  = 1     it_securitygroupids          = VALUE /aws1/cl_ec2secgrpidstrlist_w=>tt_securitygroupidstringlist(                                     ( NEW /aws1/cl_ec2secgrpidstrlist_w( 'sg-12345678' ) )                                     ( NEW /aws1/cl_ec2secgrpidstrlist_w( 'sg-55555555' ) )                                     ( NEW /aws1/cl_ec2secgrpidstrlist_w( 'sg-99999999' ) )                                                                                                        )     iv_subnetid                  = ao_snet->get_subnetid( )     it_tagspecifications         = make_tag_spec( 'instance' ) )

Mapas

Los mapas JSON se representan en ABAP como Hashed Tables en que cada fila de la tabla tiene solo dos componentes.

  • KEY: una cadena que es la UNIQUE KEY de la tabla.

  • VALUE: un objeto que contiene el valor.

Un mapa es uno de los pocos casos en los que el SDK de AWS usa una estructura verdadera, en lugar de una clase. Esto es necesario porque las tablas con hash ABAP no pueden tener una referencia a un objeto como campo clave y las claves del AWS mapa siempre son cadenas no nulas.

Funciones de nivel superior

Lo Clases de API descrito en la sección anterior refleja con precisión las API de AWS servicio y las representa como clases ABAP conocidas. En algunos casos, el SDK también incluye funciones de nivel superior que se basan en las clases de API para simplificar determinadas operaciones. Las funciones de nivel superior se incluyen para mayor comodidad del programador y no sustituyen a las clases de API de nivel inferior.

Si el SDK incluye funciones de nivel superior para un módulo, se incluyen en el mismo transporte y se puede acceder a ellas a través de una clase de fábrica denominada. /AWS1/CL_TLA_L2_FACTORY La clase de fábrica incluye métodos para crear varios clientes de nivel superior para el módulo, que se documentan junto con el resto de la API en la documentación de la API.