1. Sergio Fabian Cannelli |
1
Master Software Developer SAP( ABAP-HANA-FIORI)
Haciendo Migracion a SAP S / 4HANA
Cómo ABAP 7.51 ayuda a migrar con éxito su código personalizado
Introducción ABAP 7.51
Con toda la innovación incluida en SAP NetWeaver 7.51, incluido el soporte avanzado para servicios
de datos básicos (CDS), ¿por qué SAP ya está entregando la versión 7.51 para ABAP y por qué
debería actualizarla? . ABAP 7.51 ofrece un modelo de programación mejorado que extiende el
CDS para incluir el desarrollo de aplicaciones transaccionales y analíticas y admite la gestión de
código personalizada. En este artículo se ofrece una descripción general de las características de
ABAP 7.51 y, mediante un ejemplo, muestra cómo funcionan conjuntamente para ayudarle a crear
sofisticadas aplicaciones transaccionales basadas en SAP Fiori.
Las innovaciones como la nube, las experiencias de los consumidores, la Internet de las cosas y las
redes sociales ya no son tendencias emergentes, sino que son una realidad empresarial. SAP S /
4HANA es un conjunto de productos, disponibles tanto en on-premise como en la nube, que llevan
estas innovadoras tecnologías a todos los rincones del negocio, desde sus principales capacidades
financieras y logísticas hasta su soporte integrado en compras, recursos humanos, Y gestión de
relaciones con los clientes.
La última versión del SAP S / 4HANA - SAP S / 4HANA 1610, entregado en octubre de 2016 - aporta
aún más innovación a los clientes, incluyendo una experiencia de usuario mejorada basada en SAP
Fiori 2.0 y capacidades de la cadena de suministro que soportan nuevas tecnologías tales como
Como aprendizaje automático y algoritmos predictivos. Lanzado en ABAP 7.51, SAP S / 4HANA 1610
presenta una oportunidad única para las empresas que ejecutan las implementaciones
tradicionales de SAP Business Suite , pasar a una suite de software de próxima generación diseñada
para competir en la era digital, ya que SAP Business Suite y SAP S / 4HANA utilizan La misma
tecnología SAP.
Entonces, ¿cómo hacer para llegar allí? ¿Y qué haces con la amplia gama de códigos personalizados
que subyacen a tus sistemas SAP Business Suite? Aunque no hay una ruta de actualización directa
de SAP Business Suite a SAP S / 4HANA, SAP S / 4HANA es una oferta completamente nueva desde
una perspectiva de licencia y despliegue. SAP ofrece herramientas de migración y conversión para
ayudar a los clientes a tener éxito con el proceso. Este artículo examina las innovaciones
entregadas con SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP 7.51 que permiten
una transición sin problemas desde un sistema SAP Business Suite tradicional - como SAP ERP 6.0,
EHP 8, que se ejecuta en SAP NetWeaver 7.5 - a SAP S / 4HANA 1610, con un enfoque especial en la
migración de su código personalizado.
2. Sergio Fabian Cannelli |
2
Master Software Developer SAP( ABAP-HANA-FIORI)
SAP S / 4HANA proporciona opciones de implementación tanto en la nube como en las
instalaciones, de modo que los clientes puedan tomar decisiones de implementación basadas en
sus requisitos de proyecto y necesidades de línea de tiempo únicos. Por ejemplo, los clientes que
ejecutan en plataformas de base de datos de los socios de SAP (que están soportados y
documentados adecuadamente en la Matriz de Disponibilidad de Productos de SAP) y buscan un
nuevo sistema de base de datos y una plataforma de datos general, primero MIGRAN a SAP HANA,
luego. Para preservar esta opción, estos clientes necesitan un software que está preparado para la
nube, así como capaz de funcionar ON-PREMISE como SAP S / 4HANA.
De la misma manera, para ayudar a los clientes a pasar de SAP Business Suite a SAP S / 4HANA a su
propio ritmo, SAP soporta plenamente SAP Business Suite hasta 2025. En la experiencia de SAP, los
clientes migran típicamente del 10% al 15% de su Lo que significa que los clientes que comiencen a
principios de 2017 pueden migrar completamente un LANDSCAPE tradicional SAP Business Suite
completo a SAP S / 4HANA al finalizar el mantenimiento de SAP Business Suite.
Código personalizado y el nuevo modelo de datos
SAP S / 4HANA
Tradicionalmente, el código personalizado se ha utilizado para cerrar la brecha entre las
aplicaciones estándar de SAP y las necesidades individuales de los clientes para optimizar las
operaciones comerciales. Una instalación típica de SAP ERP está rodeada por una gran base de
código personalizada escrita en ABAP que se ha acumulado durante décadas para soportar los
requisitos empresariales.
Por ejemplo, muchos clientes han escrito informes personalizados que se refieren a tablas SAP y
estructuras, dominios y elementos de datos. Muchos también han personalizado aplicaciones SAP
existentes utilizando técnicas de mejora tradicionales, como complementos de negocio (BAdI) o
puntos de ampliacion en la interfaz de usuario, como un campo de Web Dynpro y las extensiones
de tabla. Los clientes también han modificado el código donde faltaban los puntos de extensión
predefinidos, lo que significa que obtuvieron una clave de modificación de SAP Service Marketplace
para "desbloquear" y editar el objeto de origen - modificaciones que deben adaptarse y
reinsertarse en cualquier momento en que se aplique un paquete de soporte o mejora.
Al migrar a la versión on-premise de SAP S / 4HANA, los clientes necesitan analizar esta base de
código personalizada para ver qué aplicaciones y extensiones personalizadas son necesarias en SAP
S / 4HANA y luego adaptar ese código al modelo SAP S / 4HANA . SAP S / 4HANA viene con un
modelo de datos muy simplificado, lo que significa que el código personalizado que funcionaba en
SAP Business Suite ya no puede funcionar en SAP S / 4HANA sin modificaciones debido a cambios
en el código SAP subyacente que es Referenciado por ese código personalizado. Por ejemplo, SAP S
/ 4HANA elimina la necesidad de aggregates SAP S / 4HANA se ejecuta en la parte superior de la
plataforma de datos de SAP HANA, que agrega todos los totales y subtotales sobre la marcha
utilizando su arquitectura en memoria y basada en columnas. Además de eliminar aggregates,
muchos objetos de diccionario subyacentes (incluidas tablas, dominios y elementos de datos) se
3. Sergio Fabian Cannelli |
3
Master Software Developer SAP( ABAP-HANA-FIORI)
han simplificado en SAP S / 4HANA: artefactos de los que normalmente depende el código
personalizado.
Sin la adaptación al nuevo modelo de datos SAP S / 4HANA, es probable que el código
personalizado migrado falle. Lo más probable es que sea sintácticamente incorrecto, o genere
DUMPS de ejecución. Algunos de los códigos personalizados pueden seguir siendo válidos si ciertos
aspectos del modelo de datos no han cambiado, pero en general es necesario adaptar el código al
realizar la transición a SAP S / 4HANA. Afortunadamente, ABAP 7.51 viene con herramientas y
metodologías para permitir esta transición.
Conversión de código personalizado para SAP S /
4HANA
Como puede ver, el proceso general se divide en una fase de Preparación y una de Realización. En
la fase Preparar, el código personalizado se analiza en el sistema SAP Business Suite de origen. La
adaptación del código ocurre en la fase Realize en el sistema SAP S / 4HANA convertido, ya que se
4. Sergio Fabian Cannelli |
4
Master Software Developer SAP( ABAP-HANA-FIORI)
requiere el nuevo código SAP S / 4HANA y el modelo de datos simplificado para adaptar el código
personalizado. Tener en cuenta que una condición previa para la conversión a SAP S / 4HANA es
que su sistema SAP Business Suite de origen debe admitir Unicode y, como mínimo, debe estar
ejecutándose en SAP NetWeaver 7.0x e incluir SAP ERP 6.0. SAP S / 4HANA 1610 requiere, e incluye,
ABAP 7.51 como su fundamento.
Para soportar las fases de preparación y realización de la conversión, se recomienda un sistema de
análisis separado para alojar las herramientas de análisis y la funcionalidad relacionada, como la
Lista de simplificación, la Base de datos de simplificación y la Lista de trabajo de migración de
código personalizado. Desde este sistema, las herramientas de análisis pueden supervisar su
Landscape existente, y la configuración centralizada hace que sea fácil mantener el sistema de
análisis actualizado. SAP NetWeaver AS ABAP 7.51 es un ajuste ideal para el sistema de análisis -
además de proporcionar la última funcionalidad, es esencialmente sólo una Stack SAP NetWeaver
AS ABAP, por lo que la configuración es simple y directa.
La lista de simplificación , la base de datos de simplificación y la lista de trabajo de migración de
código personalizado desempeñan funciones clave durante el proceso de conversión. La Lista de
Simplificación es un documento técnico detallado (en formato PDF) que explica cómo la conversión
afectará las transacciones específicas y la funcionalidad de la aplicación y proporciona
recomendaciones para las adaptaciones necesarias, a la que acceden las herramientas de análisis,
contiene los objetos SAP documentados en la Lista de Simplificación que se han modificado o
eliminado para SAP S / 4HANA junto con las Notas SAP que describen los cambios. Lista de trabajo
de migración ,lista todos los objetos personalizados que se refieren a elementos de la base de datos
de simplificación y debe adaptarse a SAP S / 4HANA.
La fase de preparación
Al igual que con una actualización regular, se utiliza el Planificador de mantenimiento, un servicio
basado en la nube de SAP Solution Manager, para planificar e iniciar el proceso general de
conversión del sistema. El planificador de mantenimiento analiza el sistema de origen y se asegura
que todos los componentes correctos estén en su lugar para la conversión, guiándolo paso a paso a
través del proceso de conversión. Aquí, nos centramos en la parte de código y compatibilidad del
proceso, que se puede subdividir en tres pasos: eliminar el código obsoleto, comprobar la
compatibilidad de SAP HANA y SAP S / 4HANA y preparar su lista de trabajo de adaptación.
Eliminar código obsoleto
Para minimizar el esfuerzo de conversión y asegurar una transición sin problemas, primero evalúar
la base de código personalizado existente para determinar qué es realmente necesario en el
contexto de SAP S / 4HANA. En muchas instalaciones de clientes, el código personalizado ha crecido
significativamente a lo largo de los años, y algunos de ellos ya no son necesarios. Piense en
trasladarse a una nueva casa - por lo general no quiere mover todo. Algunos artículos son
necesarios, pero es mejor dejar atrás lo que ya no se necesita. Lo mismo ocurre con el código
personalizado. SAP Solution Manager proporciona acceso a herramientas y servicios, como la
herramienta de registro de procedimientos de uso basada en kernel de ABAP, para ayudarnos a
identificar el código personalizado que está potencialmente muerto y puede eliminarse.Una vez
5. Sergio Fabian Cannelli |
5
Master Software Developer SAP( ABAP-HANA-FIORI)
que haya eliminado cualquier código obsoleto, el siguiente paso es realizar comprobaciones sobre
el código personalizado restante para la conformidad SAP HANA y SAP S / 4HANA y, a continuación,
utilizar los resultados de estas comprobaciones como una lista de trabajo para adaptar su código
personalizado.
Compruebar la compatibilidad de SAP HANA y SAP S
/ 4HANA
La herramienta Inspector de código (transacción SCI), que se incluye con SAP NetWeaver AS ABAP,
proporciona variantes de comprobación para evaluar el código personalizado para compatibilidad
SAP HANA y SAP S / 4HANA y es ideal para realizar el trabajo de análisis del proceso de conversión.
Para administrar este trabajo y aprovechar las últimas comprobaciones incluidas con ABAP 7.51, el
Inspector de Código debe ejecutarse en el sistema de análisis SAP NetWeaver AS ABAP 7.51
mencionado anteriormente, desde el cual puede ejecutar sus controles en sistemas monitoreados,
(Versiones 7.0x y superiores), transfiriendo la entrada de los sistemas supervisados a través de una
capacidad de extracción a través de un canal de llamada de función remota (RFC).
La variante de comprobación FUNCTIONAL_DB del Inspector de Código identifica los errores
típicos al pasar a SAP HANA, como el uso de la interfaz ADBC, que puede contener código de
instrucción SQL específico de base de datos y operaciones de base de datos en tablas físicas , Otro
error comúnmente identificado al migrar desde otra plataforma de base de datos es suposiciones
inválidas sobre el orden de clasificación de los conjuntos de resultados. Aunque la mayoría de los
códigos personalizados se basan en Open SQL, que proporciona independencia completa de la base
de datos, algunas técnicas de programación ABAP heredadas asumen un determinado orden de
clasificación por defecto del conjunto de resultados y, por lo tanto, omite la cláusula ORDER BY, que
se requiere en SAP HANA, No se ordena por defecto como se define en el estándar SQL. El Inspector
de Código identifica estos errores, que se solucionan fácilmente haciendo los cambios necesarios
(como agregar la cláusula ORDER BY) en la herramienta de edición apropiada. Estos cambios deben
hacerse inmediatamente, durante la fase de preparación, para reducir la complejidad.
6. Sergio Fabian Cannelli |
6
Master Software Developer SAP( ABAP-HANA-FIORI)
El Inspector de Código también proporciona una variante de comprobación S4HANA_READINESS
que utiliza la Simplificación en Base de Datos para evaluar el código para los cambios que serán
necesarios para SAP S / 4HANA, como los cambios en el modelo de datos. Un cambio significativo
en el modelo de datos es la extensión del código maestro de materiales de 18 a 40 caracteres en
SAP S / 4HANA. Dado que los clientes a menudo utilizan sus propios números de código de
material, esto puede causar conflictos de tipo y longitud en una conversión, como la concatenación
de campos si el campo de destino no es suficientemente largo. Otro cambio importante del modelo
de datos es que muchas tablas físicas referenciadas por operaciones de escritura y lectura se han
eliminado en SAP S / 4HANA. Para las operaciones de lectura, SAP S / 4HANA ofrece una vista de
compatibilidad que calcula la salida deseada sobre la marcha, como los aggregates, pero las
operaciones de escritura tendrán que adaptarse - SAP S / 4HANA proporciona módulos de función
para este propósito, pero debe llamarlos Explícitamente en su código personalizado.
7. Sergio Fabian Cannelli |
7
Master Software Developer SAP( ABAP-HANA-FIORI)
El Inspector de Código proporciona una variedad de comprobaciones SAP S / 4HANA con la
variante de comprobación S4HANA_READINESS para identificar estos tipos de problemas de SAP S /
4HANA, como las comprobaciones de extensiones de campo y las comprobaciones de operaciones
de bases de datos. Aunque siempre existe la posibilidad de falsos positivos debido a la naturaleza
del código personalizado que no puede ser entendido por una herramienta, los chequeos
proporcionan información valiosa para analizar la situación particular e identificar dónde necesita
realizar cambios en la fase Realize.
Prepararse para las adaptaciones
Una vez que completamos los chequeos en el Inspector de Código y corregir cualquier error
identificado por los chequeos de SAP HANA, estará listo para prepararse para las adaptaciones
necesarias de SAP S / 4HANA. Mientras que debe crear manualmente el WORKLIST de cambios
identificados por los chequeos de SAP HANA, que tiende a ser bastante simple y sencillo, los
resultados de las comprobaciones de SAP S / 4HANA, que probablemente sean más extensas, se
compilan en la migración de código personalizado,el Worklist sirve como la guía de adaptación SAP
S / 4HANA en la fase Realize. Sin embargo, algunos cambios requeridos en SAP S / 4HANA están
actualmente fuera del ámbito de las inspecciones de Code Inspector. Para cubrir esta brecha, y para
asegurar que nada pasa por alto, SAP proporciona la transacción SYCM.
Incluido con SAP NetWeaver 7.5 y superior, SYCM es una pequeña transacción que se ejecuta en el
sistema de análisis centralizado, con capacidades de extracción que proporciona la entrada
8. Sergio Fabian Cannelli |
8
Master Software Developer SAP( ABAP-HANA-FIORI)
necesaria de los sistemas supervisados. SYCM proporciona una descripción general de cómo sus
objetos personalizados se relacionan con los elementos de simplificación de la base de datos .Por
ejemplo, si llama a un BAPI en su código personalizado de SAP Business Suite, pero este BAPI ya no
existe en SAP S / 4HANA o su interfaz se ha modificado de forma incompatible con SAP S / 4HANA,
aparecerá una entrada correspondiente en La pantalla de resumen SYCM. Desde allí, puede
navegar hasta el código correspondiente y los objetos de desarrollo o mostrar la Nota SAP que
documenta el elemento de simplificación listado.
SYCM sirve como punto inicial y punto de entrada para un análisis adicional del impacto y el
esfuerzo requerido para ajustar sus objetos personalizados para SAP S / 4HANA. Si bien SYCM es
útil en la fase Preparacion para estimar y planificar el esfuerzo de adaptación que se requerirá en la
fase Realizar, no debe reemplazar la Lista de trabajo de migración de código personalizado en la
fase Realizar: la lista de trabajo de migración de código personalizado debe servir como guía
principal , Con SYCM llenando cualquier vacío en un rol complementario.
La fase de realización
Una vez que esté preparado para adaptar su código personalizado para SAP S / 4HANA, estará listo
para ejecutar la conversión física. Utilizar la herramienta de mantenimiento del sistema Software
Update Manager para ejecutar los pasos de conversión física, como la migración de la base de
datos a SAP HANA, la actualización de todos los componentes de software relevantes (como el
núcleo ABAP y los componentes Basis) y la conversión de los datos. Con la conversión física
completa, es hora de la adaptación funcional del código, que tiene lugar en el sistema recién
convertido.
En primer lugar, adaptar sus modificaciones a los objetos estándar de SAP que también estarán
presentes en SAP S / 4HANA mediante las transacciones SPDD y SPAU, como lo haría al actualizar o
aplicar un paquete de soporte o paquete de mejora a SAP Business Suite. Tener en cuenta que con
ABAP 7.51, la transacción SPAU se ha mejorado para admitir operaciones masivas en los casos en
que desea restablecer las modificaciones y volver al estándar SAP.
A continuación, es el momento de trabajar a través de los objetos personalizados identificados por
el Inspector de Código que necesitan un ajuste para SAP S / 4HANA, debido a su dependencia de los
elementos de simplificación incluidos en la Simplificación Base de datos , que se enumeran en la
Lista de Trabajo de Migración Estos objetos personalizados se pueden ajustar simplemente
entrando en la herramienta de edición para cada objeto personalizado afectado y corrigiendo los
errores sintácticos y semánticos, como la adaptación de operaciones de escritura que hacen
referencia a tablas físicas que ya no existen. Recuerde utilizar la transacción SYCM para obtener una
descripción inicial de los objetos personalizados que corresponden a los elementos de la base de
datos de simplificación, ya que las comprobaciones de Inspector de código no cubren todos los
problemas relacionados con SAP S / 4HANA.
9. Sergio Fabian Cannelli |
9
Master Software Developer SAP( ABAP-HANA-FIORI)
Cuando la lista de trabajo está completa, el sistema está listo desde una perspectiva puramente
funcional. Aún tendrá que optimizar el rendimiento del sistema mediante el ajuste de consultas
críticas y sentencias SQL utilizando el SQL Monitor (transacción SQLM), que rastrea los tiempos de
ejecución de sentencias SQL y el programa, módulos de funciones o clases ABAP de origen. El
Monitor de SQL ofrece capacidades de despliegue lleva a la herramienta correspondiente para
solucionar cualquier problema de rendimiento identificado.
El modelo de programación ABAP 7.51
CDS es una capa para definir y consumir modelos de datos en el nivel de abstracción ABAP en la
parte superior de la base de datos SAP HANA. Introducido con SAP NetWeaver 7.4, EHP 05, el
modelo CDS está representado en ABAP como vistas de CDS. Estas vistas se definen mediante un
lenguaje de definición de datos basado en SQL (DDL) y pueden exponerse como servicios OData, sin
necesidad de escribir código SAP Gateway, para proporcionar aplicaciones SAP Fiori basadas en
SAPUI5 con fácil acceso a los datos representados en el modelo CDS . El paradigma CDS para el
desarrollo ABAP ha acelerado significativamente el desarrollo de aplicaciones SAP Fiori,
permitiendo el modelado semántico de datos y haciendo que sea fácil de escribir aplicaciones
analíticas y de informes.
¿Pero qué pasa con las aplicaciones transaccionales típicas que realizan operaciones de inserción,
actualización y eliminación? Técnicamente, se puede utilizar Open SQL para aplicaciones
transaccionales en el stack ABAP de 7.4 o 7.5. Puede extender las aplicaciones de SAP Fiori que
consumen CDS con aplicaciones SAPUI5 codificadas manualmente que acceden manualmente a los
servicios de GATEWAY SAP codificados que, a su vez, llaman a métodos ABAP codificados
10. Sergio Fabian Cannelli |
10
Master Software Developer SAP( ABAP-HANA-FIORI)
manualmente que ejecutan las sentencias Open SQL en consecuencia, Para cada una de estas
tareas, existe una herramienta de desarrollo correspondiente: SAP Web IDE para SAPUI5,
transacción SEGW para proyectos SAP Gateway y ABAP en Eclipse para implementar los métodos
ABAP que ejecutan los comandos Open SQL.
Aunque es técnicamente posible, este enfoque manual del desarrollo basado en CDS de
aplicaciones transaccionales requiere mucho tiempo y no aprovecha la abstracción de modelado
que es esencial para el desarrollo de CDS. Para ofrecer las ventajas del modelado de CDS y las
interfaces de usuario basadas en SAP Fiori a escenarios transaccionales, ABAP 7.51 amplía el
modelo de programa ABAP basado en CDS para integrar servicios transaccionales en el nivel de
CDS. La forma natural de hacerlo es proporcionar anotaciones significativas que puenteen el mundo
analítico de CDS y el modelo transaccional de Business Object Processing Framework (BOPF).
Modeling CDS para aplicaciones transaccionales
BOPF es un Framework de persistencia basado en modelos para el desarrollo personalizado ABAP.
Proporciona un Framework de aplicaciones de servicios y funcionalidades genéricas que los
desarrolladores pueden personalizar para satisfacer sus necesidades particulares, permitiendo un
desarrollo orientado a transacciones basado en una arquitectura de aplicación estable. El modelo
BOPF no es nuevo. Reside en el STACK ABAP como repositorio basado en ABAP y en tiempo de
ejecución y es utilizado por varias aplicaciones de SAP Business Suite, incluyendo soluciones más
recientes como SAP Transportation Management.
Un modelo BOPF consiste en un nodo raíz y nodos secundarios que representan un objeto de
negocio y sus campos relacionados. Por ejemplo, un pedido de cliente consistiría en un nodo raíz
que contiene la información de encabezado y los elementos de pedido de cliente como nodos
descendientes con 0 a n cardinalidad. Cada modelo BOPF expone un comportamiento determinado
basado en diferentes métodos, incluyendo validaciones para comprobar la consistencia de un
objeto de negocio, determinaciones para cambiar el estado y los atributos de un objeto de negocio
y acciones que realizan operaciones en un objeto de negocio. Técnicamente, estos métodos son
implementados por clases ABAP, por lo que se puede pensar en el modelo BOPF como un marco
basado en objetos. Los servicios centrales, como el control de transacciones, el compromiso con la
base de datos, el bloqueo y el almacenamiento en búfer son manejados dentro del Framework
BOPF, que protege los detalles de la implementación del desarrollador.
En ABAP 7.51, el vínculo semántico entre la definición del CDS y sus representaciones BOPF
correspondientes se establece mediante un conjunto de anotaciones bien definidas que se agregan
utilizando el editor DDL - la herramienta dentro de ABAP en Eclipse utilizada para definir vistas de
CDS - similar al modo que Se crean anotaciones para describir el uso de datos en la interfaz de
usuario, por ejemplo. Puesto que las anotaciones definen una cierta faceta de los datos de vista
subyacentes para fines de interfaz de usuario, analíticos o de búsqueda, es pensar en BOPF como
faceta transaccional de una definición de CDS.
11. Sergio Fabian Cannelli |
11
Master Software Developer SAP( ABAP-HANA-FIORI)
Ponerlo todo junto: un ejemplo
El desarrollo de CDS y BOPF se puede combinar fácilmente en la capa de interfaz de usuario, donde
las partes analíticas y transaccionales de una aplicación aparecen side by side en muchos
escenarios. Aquí, utilizando el conocido Modelo de Aprovisionamiento de la Empresa, recorreremos
el desarrollo de una aplicación de ejemplo que combina estos dos tipos de desarrollo en la interfaz
de usuario.
Desarrollo de la vista CDS
Nuestro primer objetivo es desarrollar una vista de CDS de factura de pedido de cliente que
contenga una lista de números de factura junto con los campos habituales, como ID de cliente,
nombre de empresa, fecha y hora de creación, moneda de transacción y importe bruto de la
factura.
La Figura 1 muestra el código fuente de la vista CDS (Zdev210_C_SlsOrdInv_Sol) que genera esta
lista, que se muestra en el editor DDL de ABAP en Eclipse. Esta vista es una vista de proyección
simple que se asigna a la vista base SEPM_I_CustomerInvoice_E, que tiene una asociación con una
vista de cliente para recuperar el nombre de la empresa. Puede mostrar todas las asociaciones e
información relacionada para la vista base presionando F2 (vea la Figura 2).
FIGURA 1
12. Sergio Fabian Cannelli |
12
Master Software Developer SAP( ABAP-HANA-FIORI)
FIGURA 2
La ejecución de la vista (pulsando F8) muestra una lista de los campos especificados y los datos
recuperados en un formato de tabla (ver Figura 3).
13. Sergio Fabian Cannelli |
13
Master Software Developer SAP( ABAP-HANA-FIORI)
CDS ofrece una variedad de funciones integradas para personalizar el conjunto de datos resultante,
incluyendo funciones de cálculo y opciones de extensibilidad para agregar campos. Por ejemplo,
puede utilizar los datos de CreationDateTime para determinar cuántos días se ha abierto una
factura determinada: calculando la diferencia entre la creación y la fecha y hora real en segundos
(función tstmp_seconds_between) y dividiendo por 86400 (el producto de 60 * 60 * 24) - y agregue
un campo (DaysOpen) para mostrar los resultados (ver Figura 4). La figura 5 muestra un campo
adicional convGrossAmount que se calcula mediante la función currency_conversion, que convierte
la moneda real en dólares estadounidenses.
FIGURA 4
14. Sergio Fabian Cannelli |
14
Master Software Developer SAP( ABAP-HANA-FIORI)
FIGURA 5
Creación de una aplicación basada en la vista de CDS
Una vez que la vista CDS esté completa, estamos listos para crear una aplicación SAP Fiori basada
en la vista CDS. Para esta tarea, utilizamos SAP Web IDE, el entorno basado en web de SAP para el
desarrollo de aplicaciones SAPUI5, que está disponible a través de SAP HANA Cloud Platform o
como una versión independiente ON-PREMISES.
15. Sergio Fabian Cannelli |
15
Master Software Developer SAP( ABAP-HANA-FIORI)
A continuación, generamos el proyecto de desarrollo de SAP Fiori y lo ejecutamos. El resultado se
muestra en la Figura 9. Muestra facturas de pedido de venta agrupadas por empresa y muestra
todas las columnas agregadas, como días abiertos promedio, importe bruto, importe convertido y
fecha de creación. Todas las capacidades de agrupación y clasificación están integradas en la
plantilla automáticamente, lo que significa que no es necesario escribir ningún código para ello.