Preguntas y respuestas frecuentes sobre SAP Netweaver: Parte I

Cualquier compañía o profesional vinculado a la comunidad SAP está llamado a comprender correctamente la tecnología SAP Netweaver, que materializa la visión de SAP para muchos años venideros. La riqueza de esta tecnología comporta, además de oportunidades y soluciones, cierta complejidad que es necesario esclarecer. En una serie de entregas, analizamos en estos tips algunas preguntas frecuentemente formuladas sobre SAP Netweaver, respondidas aquí en forma sintética y concreta.

Primera Parte

¿Es Netweaver un producto o una plataforma? Está orientada a los clientes SAP o a nuevos clientes?

¿En qué difieren los distintos releases del SAP Web Application Server?

A la hora de gestar un desarrollo Web, ¿qué diferencia hay entre las BSP’s (Business Server Pages) y una Web Dynpro? ¿Cúal debería usar?

¿Cúales son las herramientas o entornos de desarrollo para SAP Netweaver?

¿Significa SAP Netweaver que debemos reemplazar ABAP por JAVA?

Seguir leyendo este artículo >>

Cómo encontrar e implementar BADIS en programacion ABAP

Conozca algunos métodos de búsqueda de BADIS en SAP y aprenda la manera de implementarlas

No importa cuán abarcativo sea un software de gestión, las necesidades particulares de cada cliente y los requisitos de los distintos escenarios de negocios, puede generar  una necesidad de "customización" del software que excede la parametrización. Sin embargo, en un sistema de envergadura y misión crítica, esto no debería llevarse a cabo de cualquier manera. En el caso particular de SAP, es sabido que no se permite modificar el código fuente de un programa ABAP standard. 

Por ello, SAP proporciona recursos e instrumentos que permiten intromisiones "controladas" al código, a través del concepto de ampliaciones o Enhancements. La idea es expandir la funcionalidad dentro del sistema SAP para atender las necesidades adicionales del cliente, sin modificar el código fuente del programa standard.

Actualmente existen en SAP tres generaciones de ampliaciones:

El presente tip, está centrado en la Tercera generación, las BADI’s.

Se describirá qué es una BADI y luego mediante un ejemplo práctico, se detallarán los distintos métodos para buscar BADI’s en el sistema y se implementará  una de ellas.

I ) ¿Qué es una BADI?

Las BADI’s (Bussiness Add-ins) son las nuevas técnicas de ampliación del código estándar de SAP basadas en programación ABAP orientada a objetos que surgieron a partir de la versión 4.6C.

Las BADI’s tienen las siguientes características:

• Se pueden implementar más de una vez, a diferencia de los user-exit, que sólo tienen una implementación.
• Las BADI's poseen una arquitectura Multicapa (SAP, partners, soluciones de clientes, localizaciones, soluciones específicas para industrias, etc), a diferencia de los User Exits que son doble capa únicamente (SAP y soluciones de cliente).
• Se usan para ampliar menúes, código fuente y pantallas de transacciones standards

Las BADI’s contienen dos vistas: la definición y la implementación.

La definición se realiza mediante la transacción SE18. En ella se deben especificar los siguientes puntos:

• Definición de la interfaz: métodos y parámetros.
• Tipo de implementación: simple (sólo una implementación activa) o múltiple (más de una implementación activa).

Para implementar o ver las distintas implementaciones de una BADI dada, utilizar la transacción SE19.

II) Ejemplo Práctico

En este apartado, se describirán distintas maneras para encontrar BADI’s en el sistema y, además, se mostrará cómo implementar una BADI.

¿Cómo encontrar la BADI que necesitamos?

A continuación se presentarán cuatro métodos distintos que nos permitirán localizar las BADIs.

Método 1

Las BADIS se encuentran registradas en las tablas SXS_INTER, SXC_EXIT, SXC_CLASS y SXC_ATTR. SAP accede a dichas tablas mediante las vistas V_EXT_IMP y V_EXT_ACT. En cada llamada existente a una BADI, el sistema pasa por las tablas antes mencionadas. Por lo tanto, un método para encontrar la BADI que necesitamos se basa en el uso de la transacción ST05 (Performance Analysis).

Se realizará el siguiente procedimiento:

1. Desde la transacción ST05 marcar el flag “Table Buffer trace” y pulsar el botón “Activate Trace“.
2. Ejecutar (en otro modo) la transacción sobre la que se desea encontrar una BADI.
3. Volver a la pantalla de la transacción ST05 y hacer clic en el botón “Deactivate Trace” para finalizar el trace. Luego seleccionar el botón “Display Trace” donde se va a filtrar el Trace con los objetos: V_EXT_IMP y V_EXT_ACT (vistas).
4. Pulsar el botón “Copy (F8)” , Fill Operations: OPEN y “Enter”.

Resultado: se obtendrá un listado con todas las “interface class names” de las vistas V_EXT_IMP comenzando con IF_EX_*. Este es el prefijo estándar de SAP para las “BADI class interfaces“.

El nombre de la BADI se encuentra a continuación del prefijo IF_EX_. Por ejemplo, si el nombre de la interfase es IF_EX_ADDR_LANGU_TO_VERS, la BADI se llama ADDR_LANGU_TO_VERS.

Método 2:

Desde la transacción SE80, fijar un break-point en el método “ACT_IMPS_PER_FLT_VAL” de la clase “CL_BADI_FLT_DATA_TRANS_AND_DB” justo después del “SELECT” encabezado con el comentario “read BADI attributes”.

Luego ejecutar la transacción que se desea analizar. Por cada parada en el break-point del debugger, examinar los campos “exit_name” e “internal”.

Método 3

Desde la transacción SE24 (Class Builder) colocar un break-point en el CALL METHOD cl_exithandler=>get_class_name_by_interface que está dentro del método GET_INSTANCE de la clase CL_EXITHANDLER .

Luego, ejecutar la transacción o programa a verificar. En la variable exit_name se muestran los nombres de las BADI's que implementa el programa. Este método puede resultar engorroso porque detiene muchas veces la ejecución, pero ésto asegura que si una BADI existe se detendrá en ese punto. Lo que se está haciendo es poner un BREAK-POINT en el momento en que SAP verifica si una definición de BADI tiene alguna implementación activa; por lo tanto, aunque no exista ninguna implementación activa para esa BADI particular, el método detectará que existe una BADI en ese punto. Para ver si esa BADI está implementada o no, ir a la Transacción SE18 con el nombre de la BADI obtenida en la variable exit_name e ir a la opción de menú Implementaciones → Resumen.

Método 4

Obtener el paquete (Clase de desarrollo) de la transacción que se desea analizar mediante la transacción SE93. En la transacción SE18, en la búsqueda ampliada, buscar filtrando por el paquete anteriormente encontrado y el sistema devolverá todas las BADI’s relacionadas a ese paquete.

III) Implementando una BADI

En el siguiente caso práctico, se implementará una BADI que permita mostrar un mensaje cuando se estén modificando los datos de dirección de un banco determinado, mediante la transacción FI02.

A través del botón “Address” , se accede a la pantalla de datos de dirección. Luego de cambiar el país a US (Estados Unidos) o ES (España), seleccionar Aceptar y mostrar el mensaje deseado.

Para ello, se implementará la BADI ADDRESS_CHECK, en el método IS_ACTIVE_FOR_COUNTRY que permite ampliar la verificación del país.

Para implementar dicha BADI se siguen los siguientes pasos:

1. Acceder a la transacción SE19, ingresar el nombre de la BADI, ADDRESS_CHECK, en el campo BAdI Name y presionar el botón Create Impl.

2. Aparecerá la siguiente ventana donde se debe ingresar, en el campo Implementation Name, un nombre de implementación “Z*”. Presionar

3. En la siguiente pantalla se debe ingresar:

a. En el campo Implementation Short Text: una descripción corta.

b. En el campo Defined Filtres: los filtros con los cuales se va a ejecutar esa BADI. En el ejemplo se ingresaron los filtros ES, US. Es decir, la BADI a implementar sólo se ejecutará si el campo país contiene ES o US.

Esta tabla está habilitada porque en la BADI se definió que se debe hacer con una definición de filtros, es decir, el ckeckbox Filter-Dependen está seleccionado.

c. Finalmente Guardar .

Nota: La BADI ADDRESS_CHECK sólo permite una implementación activa.

4. Ingresar el código fuente solicitado. Para ello ir a la solapa INTERFACE, y hacer doble click sobre el método IS_ACTIVE_FOR_COUNTRY.

Aparecerá la siguiente pantalla, donde se ingresará el siguiente código fuente:

5. Por último, Guardar y Activar .

Para probar cómo funciona la implementación, seguir los siguientes pasos:

1. Acceder a la transacción FI02 e ingresar el país y el código del banco. Por ejemplo, AR(Argentina) y 001. Luego presionar ENTER.

2. En la siguiente pantalla seleccionar el botón Address .

3. En el campo Country, elegir US ó ES.

4. Y finalmente, al Aceptar aparecerá el mensaje esperado.

Tips relacionados:

Puede encontrar más información sobre ampliaciones en:

Qué diferencia a las BADIS de los USER EXITS?

Ampliaciones (Enhancements) a programas ABAP en ERP 6.0

Conceptos de ampliaciones

¿Qué recursos de ampliación al estándar se utilizan en su organización? ¿Han experimentado con BADIS ya?

IMPORTANTE

Copyright Agosto 2009. Teknoda S.A.

El modelo BSP (III): Un caso práctico de BSP Extensions

Cómo viéramos en detalle en tips anteriores, a partir de la versión 6.10, SAP sustituye el SAP BASIS System por el SAP Web Application Server. 

El SAP WAS, al igual que el BASIS que lo precede, provee el cimiento tecnológico sobre el cual se apoya el R/3 Enterprise, el sucesor de R/3, y la mayoría de los componentes de mySAP.com. En este rol, el SAP WAS funciona como el nuevo R/3 Kernel, implementando toda la arquitectura de conectividad, seguridad, acceso a bases de datos, y también la interfaz de programación.

Concebido para actuar en un mundo dominado por las aplicaciones “Web enabled”, la principal innovación del SAP WAS es que trae la funcionalidad Web completamente embebida, tanto desde el punto de vista de los protocolos de comunicaciones como del servicio de aplicaciones. En su personalidad “Nativa”, es decir, como kernel del R/3,  el SAP WAS continúa soportando el universo ABAP de versiones anteriores, pero introduce nuevas herramientas para desarrollo de aplicaciones Web fuertemente integradas a R/3.

Desde la primera versión del Web AS, (6.10) aparece el modelo de Business Server Pages  (BSP’s ) como una potente opción para construir aplicaciones Web que accedan dinámicamente a los datos de SAP.

Seguir leyendo este artículo >>

Ampliaciones: ¿Qué diferencia a las BADIS de los CUSTOMER EXITS y otros métodos?

Qué diferencia a las BADIS de los CUSTOMER EXITS o de otros recursos de Enhancement para evitar modificar el código ABAP estándar?.

No importa cuán abarcativo sea un software de gestión, las necesidades particulares de cada cliente y los requisitos de los distintos escenarios de negocios, puede generar  una necesidad de "customización" del software que excede la parametrización. Sin embargo, en un sistema de envergadura y misión crítica, ésto no debería llevarse a cabo de cualquier manera. En el caso particular de SAP, es sabido que no se permite modificar el código fuente de un programa ABAP standard.

Leer más...

ESA y Web Services en SAP Netweaver: Introducción

I. Web Services: Una primera mirada

Web Services es hoy uno de los conceptos que más atención concentra en la industria del software. Desde los proveedores líderes, hasta los emprendimientos más emergentes, todos lo incluyen en su agenda.  Los Web Services, probablemente, nos traen la promesa de establecer un nuevo modelo de programación, que suceda al paradigma cliente-servidor, donde, por fin, se reconcilien la idea de interoperabilidad con la flexibilidad para generar cambios en las aplicaciones.

Nos proponemos en esta serie de tips, clarificar el concepto de Web Services, para luego desarrollar las posibilidades que brinda SAP con su arquitectura orientada a servicios. Más allá de su definición formal y características técnicas, que desarrollaremos en este primer artículo, es importante entender cómo y porqué llegamos a este paradigma.

El contexto

Los procesos de negocio están compuestos por múltiples funciones aplicativas. Los escenarios de negocio cada vez más competitivos y complejos, han gestado la demanda de funcionalidad cada vez más elaborada, y una oferta de soluciones cada vez más especializada, alimentada por el suceso de las aplicaciones tipo ERP. Sin embargo, la realidad muestra que no es posible implementar toda esta funcionalidad utilizando una única tecnología. Una infraestructura moderna de software debería permitir integrar funciones desarrolladas interna o externamente, por múltiples proveedores y plataformas en un único proceso completo y efectivo.

Hasta hoy, la integración de software se apoyaba principalmente en la definición manual de interfaces, formato de mensajes, y la concordancia explícita entre los “socios” de negocio involucrados. Este enfoque, además de laborioso, genera enormes trabas en la flexibilidad de las interfaces obtenidas y su capacidad de adaptarse a los cambios.

La propuesta de los Web Services

El término Web Service define a la vez una entidad de software y un modelo de programación , que, basado en estándares abiertos y universalmente aceptados, permite combinar funcionalidad implementada en las más variadas plataformas.

En blanco y negro, un Web Service es una entidad ejecutable de software, totalmente encapsulada y “autosuficiente”, que puede ser detectada e invocada a través de una red para cumplir con un propósito determinado. El “consumidor” de un Web Service desconoce la complejidad interior de la misma, desconoce la plataforma y el lenguaje en el que está escrita, pero sí conoce el efecto concreto de su ejecución. La invocación del Web Service se realiza a través de protocolos de mensaje absolutamente estandarizados, y, por supuesto, los Web Services son reusables.

Los Web Services proveen un mecanismo para que las aplicaciones hablen unas con otras prescindiendo de la plataforma de cada una de ellas, y sin estar controladas por ningún proveedor. Una compañía podría, por ejemplo, diseñar un Web Service que permita verificar el historial crediticio de un cliente. Este Web Service podría estar disponible para ser “consumido” por cualquier aplicación interna o externa, sin importar si la misma corre en Linux, Windows, JAVA o ABAP.

Más de lo mismo?

Un primer análisis a la definición abstracta de Web Services parece NO encerrar nada demasiado nuevo. En cierta forma, parece que estuviéramos hablando de viejos conceptos: aplicaciones descompuestas, componentes reusables, complejidad encapsulada como caja negra, independencia de plataforma, interoperabilidad entre entornos heterogéneos, etc. De hecho, como mencionáramos anteriormente, no son éstas preocupaciones nuevas para los desarrolladores. La industria del software ha estado trabajando todos estos años sobre nuevos paradigmas para resolver las limitaciones del modelo procedural, aislado y propietario, de la década del 80. Innumerables tecnologías han ido surgiendo y permitiendo algunos progresos en este sentido.

Los lenguajes del ’90 trajeron API’s, funciones y librerías reusables. El desarrollo de las soluciones tipo ERP nos permitió tener software integrado, “out-of-the-box”, con mucha riqueza funcional. Luego, el paradigma cliente servidor nos trajo aplicaciones estratificadas en capas y distribuidas para aprovechar las mejores aptitudes de cada plataforma. Java y el modelo de objetos nos trajo la noción de portabilidad, componentización y abstracción. Paralelamente, Internet nos trajo el irreversible camino hacia la interfaz de usuario estandarizada, y la universalidad de las comunicaciones. También surgieron protocolos para implementar conectividad entre aplicaciones: RFC, CORBA/DCOM y otras soluciones propietarias. Sin embargo, ninguna de estas tecnologías por sí solas pudo sortear todos los obstáculos.

Porqué Web Services es diferente

Los Web Services son, en cierta forma, la evolución natural y predecible de este proceso. La principal diferencia con sus predecesores es que, por primera vez, y gracias a los estándares de la Web, existe una oportunidad concreta de aceptación y universalidad de estándares.

• La definición de Web Services es independiente de los lenguajes y las plataformas de desarrollo. Todos los principales “vendors” de aplicaciones soportan Web Services. Detrás de los Web Services hay varios comités de estandarización.
• Las definiciones de Web Services están expresadas en sintaxis XML, lo que hace sencillo desarrollar y ofrecer las herramientas para definir servicios basados en XML.
• Web Services, como su nombre lo sugiere, se ejecutan fácilmente sobre Internet, permitiendo escenarios absolutamente distribuidos.
• Casi cualquier lenguaje permite desarrollar Web Services, incluyendo JAVA, ABAP, C.

Para entender este proceso, resulta útil compararlo con la evolución que se diera los últimos años con las interfaces de usuario.

Desde que existe la Web, el mundo ha podido acceder a información y aplicaciones desde cualquier lado usando Web Browsers. La Web utiliza estándares para formatear y transmitir información desde y hacia el browser, basado en protocolos HTML y HTTP respectivamente. La amplia aceptación de estos estándar ha llevado a un crecimiento espectacular y ha reemplazado mayoritariamente los accesos propietarios.

La misma transformación que ocurrió en las interfaces de usuario a partir de la creación de los estándares HTTP y HTML es ahora posible masivamente para el intercambio entre aplicaciones. Los métodos propietarios para conectar e integrar aplicaciones serán reemplazados por métodos estándar basados en Web Services.

Enterprise Services y SAP Enterprise Services Architecture

Cualquier servicio, simple o complejo, implementado con las consignas de un Web Service puede ser considerado como tal. (Por ejemplo, eliminar un registro del sistema de órdenes). Sin embargo, preferimos la designación de Enterprise Services para definir a aquellos Web Services que, por su alcance y complejidad, conforman una solución completa a una necesidad de negocio. Por ejemplo, un Enterprise Service podría ser “cancelar el pedido de un cliente”. Este Enterprise Service seguramente involucrará la participación de muchos otros Web Services que verifican datos, eliminan registros de una o varias tablas, envían mensajes de aviso, impactan sobre el sistema finaciero, etc. etc.

ESA (Enterprise Services Architecture) es el “blueprint” de SAP para ayudar a los desarrolladores a adoptar e implementar un modelo de programación basado en Enterprise Services. Materializado a través de las herramientas y soluciones de SAP Netweaver, representa la nueva visión de SAP, alrededor de la cual apoyará toda su oferta de productos actual y futura.

II. WebServices : La definición Formal

La definición formal de un WS hecha por el World Wide Web Consortium es:

“Un web service es un software aplicativo identificado por un URI (*), cuya interfaz y vínculos pueden ser identificados, descriptos y descubiertos por artefactos XML y soporta interacción directa con otros software aplicativos utilizando mensajes basados en XML a través de protocolos basados en Internet.”

• Desde un punto de vista práctico, los XML web services son una categoría de componentes de software que proveen funcionalidad a través de Internet. Las características normalmente presentes en WS son:
• La interacción con los WS se produce utilizando protocolos estándar de Internet. Esto incluye los más conocidos como TCP/IP, HTTP; XML así como los nuevos estándar como Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) y Universal Discovery, Description and Integration (UDDI).
• Un WS no suele ser una aplicación completa sino que frecuentemente es un componente funcional que forma parte de una solución más amplia. De aquí se desprende que los WS están orientados inicialmente hacia la interacción entre programas.
• Los WS exponen su funcionalidad a través de interfaces bien definidas. Las mismas proveen a los programadores de detalles suficientes para utilizar la funcionalidad ofrecida por el WS. El lenguaje utilizado para esta descripción es WSDL.
• Los WS son publicados en un registro, que puede ser publico o privado dependiendo de la naturaleza del WS. El proceso de registrar y buscar un WS está definido por los estándar UDDI.

Estándares y Protocolos

Aunque los WS son una nueva tecnología, hacen uso de muchos estándares y protocolos ampliamente difundidos.

Publicación y búsqueda

UDDI (Universal Description, Discovery and Integration) es una iniciativa para producir un registro de WS. Básicamente, UDDI ofrece una guía de compañías que puede ser buscada por nombre, industria donde opera y región donde se ofrece el servicio. De esta forma, el programador conoce la existencia, propósito y ubicación del servicio.

Ejemplos de registros UDDI públicos:

Cada uno de estos registros contiene la misma información y son actualizados de manera consistente.

Las compañías pueden además establecer registros UDDI privados para listar los servicios disponibles dentro de su red privada.

Definición

Una vez que el WS ha sido descubierto necesitamos entender qué interacciones soporta. El Web Service Description Language (WSDL) es el estándar para definir WS. WSDL es un formato XML que contiene información sobre cada mensaje que puede ser enviado al servicio y la clase de respuesta retornada. WSDL provee la base para un contrato que indica al cliente como se comportará el WS.

Messaging

Una vez que hemos accedido a la definición del WS podemos enviar mensajes al servicio para acceder a su funcionalidad. Simple Object Access Protocol (SOAP) ha sido adoptado como el mecanismo para enviar mensajes entre clientes y WS. SOAP se basa en XML y no está ligado a ningún lenguaje ni plataforma.

Ejemplos de Web Services

El tipo más común de WS provee acceso programado a la información, por ejemplo, control de stock, tasas de tipo de cambio, horarios de arribo de vuelos y traducción de idiomas. Esta información puede ya estar a disposición de las personas electrónicamente a través de páginas web, documentos o sistemas propietarios. Sin embargo, en estos formularios la información puede ser complicada de manipular desde la programación. Con WS la información viene publicada utilizando interfaces bien definidas y se accede por medio de protocolos estándar y representaciones de datos. Cualquier dispositivo o programa, sin importar la plataforma o lenguaje de programación, puede comunicarse con el WS a través de la red para acceder a la información. Las aplicaciones de tal servicio son inagotables, cualquier escenario de provisión de información es un ambiente ideal para apoyar la entrega en el modelo de WS.

Además de brindar información al cliente, un WS puede con la misma facilidad actuar como un repositorio de información. Esta capacidad permite que muchas aplicaciones de diversas plataformas compartan y manipulen la misma información. Servicios como agenda y almacenamiento de archivos son buenos ejemplos donde los WS pueden aportar valor. Estos servicios permitirían a las personas acceso a su información independientemente de su ubicación o plataforma utilizada.

Las características mencionadas abren muchas posibilidades para aplicaciones y WS intermediarios. Por ejemplo, si las compañías de transporte dispusieran información sobre los horarios de sus colectivos, trenes y vuelos utilizando WS, una aplicación o WS intermediario podría utilizar dicha información para planificar la ruta óptima entre dos lugares.

Otro ámbito excelente para la aplicación del modelo de WS es para integrar sistemas anteriores dentro de modernas soluciones IT. La utilización de WS para construir una capa de abstracción entre los clientes y los sistemas anteriores conlleva numerosos beneficios. Las nuevas plataformas del cliente obtienen acceso a los sistemas anteriores y el WS puede coordinar las actividades a través de múltiples sistemas a medida que procesa los requerimientos del cliente.

Ventajas de los Web Services

Como se desprende de los ejemplos anteriores, el modelo de WS provee interesantes posibilidades. Sin embargo, estas capacidades pueden ser realizadas usando otros modelos aplicativos. Las verdaderas ventajas de los WS no reside tanto en lo que hacen sino en cómo lo logran.

El principal beneficio es la integración. El costo de proyectos en los que se trata de integrar aplicaciones, sistemas y tecnología diversas es muy alto. Los WS ofrecen un estándar ampliamente consensuado que representa la herramienta de integración perfecta, logrando interoperabilidad real así como bajando ostensiblemente los costos.

• Basados en estándares
• Tecnología no propietaria
• Simplicidad
• Independencia de lenguaje y plataforma.
• Abstracción funcional
• Herramientas de búsqueda
• Tiempo de desarrollo reducido

Escenarios no recomendados para aplicar Web Services

El modelo de WS es una herramienta que provee un mecanismo para entregar funcionalidad a los usuarios. Los WS no son la respuesta indicada en todas las situaciones. Estas son situaciones en las cuales los WS pueden resultar inapropiados:

• Sistemas Cerrados: En ocasiones el ámbito del problema es tal que el cliente al que apuntamos está unívocamente definido. La solución puede ser diseñada para un grupo de personas o puede ser aplicable solo a usuarios de cierta plataforma. En estas situaciones, los beneficios de los WS pueden no ser necesarios.
• Performance Crítica: Los WS proveen flexibilidad al costo de la performance. Los documentos XML pueden ser lentos de crear y procesar. En sistemas donde la performance es un factor crítico de éxito debería evaluarse si el costo extra de la utilización de WS es realmente útil.
• Confiabilidad: Para proveer el soporte mas amplio posible, los WS se apoyan en los protocolos e infraestructura de Internet. Si la solución a desarrollar brindará servicios críticos a los usuarios, debería considerarse la confiabilidad general de Internet y la de los proveedores externos de WS.
• Limitaciones Técnicas: Los WS no se desempeñan tan bien como otras tecnologías en áreas como el soporte transaccional y la seguridad. Si estos son factores críticos debería considerarse la posibilidad de aplicar otra solución.

III. SAP y el soporte de Web Services

SAP brinda la posibilidad de extender las soluciones empresariales por medio de web services JAVA o ABAP. En caso de implementar procesos que involucran diversos socios comerciales y sistemas heterogéneos puede ser beneficioso optar por desarrollos en JAVA. En cambio, para soluciones centradas en la selección de información, podemos considerar el entorno nativo.

El marco de desarrollo consiste de:

• Entorno de desarrollo de la personalidad ABAP
• Entorno de desarrollo de la personalidad J2EE
• Herramientas que soportan registración UDDI
• Entorno de ejecución distribuido SOAP (ABAP / J2EE)

Copyright Teknoda S.A.

SAP Netweaver (Enterprise) Portal: Preguntas y Respuestas”

Desde la versión SAP Netweaver 2004s, liberada en Junio del corriente año, el nuevo nombre para SAP Enterprise Portal es SAP Netweaver Portal y será mencionado de esta forma en el presente tip.

Web Services en el entorno ABAP: un caso práctico Paso a Paso

Web Services: El Contexto

Los escenarios de negocio cada vez más competitivos y complejos, han gestado la demanda de funcionalidad cada vez más elaborada, y una oferta de soluciones cada vez más especializada, alimentada por el suceso de las aplicaciones tipo ERP. Sin embargo, la realidad muestra que no es posible implementar toda esta funcionalidad utilizando una única tecnología. Una infraestructura moderna de software debería permitir integrar funciones desarrolladas interna o externamente, por múltiples proveedores y plataformas en un único proceso completo y efectivo.

Hasta hoy, la integración de software se apoyaba principalmente en la definición manual de interfaces, formato de mensajes, y la concordancia explícita entre los “socios” de negocio involucrados. Este enfoque, además de laborioso, genera enormes trabas en la flexibilidad de las interfaces obtenidas y su capacidad de adaptarse a los cambios.

Seguir leyendo este artículo >>

Creación de variables en tiempo de ejecución

Conozca cómo crear variables en tiempo de ejecución en programas ABAP

A diferencia de las variables declaradas en tiempo de desarrollo, la generación dinámica de variables se realiza cuando el programa se encuentra en tiempo de ejecución. Esto es útil cuando no se conoce el tipo de dato que se requiere para dicha variable hasta el momento de necesitarla.

La creación de variables en tiempo de ejecución consta principalmente de tres partes: la primera es la creación de la “variable anónima” utilizando tipos de referencia; la segunda es la asociación de la “variable anónima” con el tipo de dato que se requiere y la tercera es la lectura y escritura en dicha variable.

En el presente tip definimos el procedimiento para crear esas variables y su manejo posterior.

I. Creación de la “variable anónima”

Dicha variable se declara de la misma forma como se declararía un objeto, pero con la diferencia que se le asocia un tipo de dato estándar genérico (DATA). A menos que se le indique un valor inicial, estará vacía.

Ejemplo:

DATA: v_data_ref TYPE REF TO data.

II. Creación del tipo de dato de la “variable anónima”

Mediante la sentencia CREATE DATA se declara el tipo de dato en la sesión interna del programa. El adicional TYPE soporta la referencia de utilización del nombre de una variable.

a) Definición de un tipo de dato ABAP

Los tipos de datos posibles a declarar dinámicamente son:

Para los tipos de datos C, N, P y X se puede definir la longitud mediante el adicional LENGTH. Si no se define, se tomará el valor inicial por defecto. Para todos los demás tipos de datos no se puede utilizar este adicional.

Para el tipo de dato P, se pueden definir los decimales mediante el adicional DECIMALS. Si no se define, se tomará el valor inicial por defecto. Para todos los demás tipos de datos no se puede utilizar este adicional.

Ejemplo:

b) Definición de un tipo de datos existente en el diccionario o en el reporte

Se pueden crear tipos de elementos del diccionario o de tipos declarados en el programa.

Ejemplo:

c) Definición de una tabla interna.

Los adicionales tienen el mismo significado y utilización como si se declarara la tabla con la sentencia DATA. La única diferencia es que se podría utilizar el adicional TYPE REF TO para crearla con referencia a otra “variable anónima”.

Ejemplo:

III. Acceso de lectura y escritura.

Para poder realizar los accesos a la variable de forma transparente es necesario asignar el contenido de la variable de referencia a un FIELD-SYMBOL.

Ejemplo:

IV. Para tener en cuenta

• Excepciones en la generación de DATA OBJECT.: La clase encargada de tratar las excepciones al momento de asociar la “variable anónima” con un tipo de datos es: CX_SY_CREATE_DATA_ERROR.
• La variable anónima puede ser reutilizada para instanciar distintos tipos de datos en la misma sesión de un programa.

  ---

Copyright Teknoda S.A.

FICHA TECNICA: Notas técnicas – Tips de SAP Netweaver ABAP ”Creación de variables en tiempo de ejecución”

Tema: Programación ABAP., Descripción: El objetivo de este tip es describir cuándo y cómo se generan las variables dinámicamente en tiempo de ejecución, a diferencia de las que se crean en tiempo de desarrollo.

Técnicas para Importar y Exportar Layouts en un ALV (SAP List Viewer)

Conozca técnicas de importación y exportación de Layouts definidos en un ALV en ABAP, hacia otros mandantes SAP

Qué es ALV?

ALV básicamente es una herramienta de reporting que ofrece ABAP para desplegar datos en forma de grilla, es decir, una técnica para emitir listados, cuyo objetivo es estandarizar el uso de listas en SAP R/3. Desde la versión de SAP R/3 4.6C el nuevo nombre para el ABAP List Viewer (ALV) es SAP List Viewer .

Dentro de esta técnica de reporting, existe una funcionalidad especial relacionada con la utilización de Layouts., que hasta la version 4.6B eran llamados “display variants” (“variantes de visualización”).

Leer más...

Nueva técnica en ABAP para el manejo de archivos en el Presentation Server

En programas ABAP conozca la nueva manera en programas ABAP de subir y/o bajar archivos desde/hacia la PC (Presentation Server) a partir de la versión 4.7.

Frecuentemente es necesario importar/exportar información desde/hacia un archivo localizado en una PC (Presentation Server). Este proceso se realizaba hasta ahora utilizando los módulos de función ‘UPLOAD’ , ‘WS_UPLOAD’, ‘DOWNLOAD’ y ‘WS_DOWNLOAD’. 

La diferencia fundamental entre las funciones ‘UPLOAD’ y ‘DOWNLOAD’ y entre las funciones ‘WS_UPLOAD’ y ‘WS_DOWNLOAD’ radica en la posibilidad de mostrar un POP_UP para colocar la ruta donde se desea subir/bajar el archivo. El resto de las funcionalidades de los FM son similares, por lo tanto primero explicaremos cómo subir o bajar un archivo a SAP sin utilizar las funciones obsoletas, y luego agregaremos la funcionalidad para poder especificar la ruta.

Cómo bajar  información desde SAP a un archivo de texto (Download)

En el primer ejemplo, se realizará el download de los datos de una tabla a un archivo en la PC local utilizando el método ‘GUI_DOWNLOAD’ de la clase ‘CL_GUI_FRONTEND_SERVICES’.

Para lograr el “Download” se deberán seguir los siguientes pasos:

1.       Declaración de tipos y variables:

2.     Carga de los datos a transferir en la tabla.

3.   Invocación al  método GUI_DOWNLOAD de la clase CL_GUI_FRONTEND_SERVICES.

El método GUI_DOWNLOAD es el que reemplaza a las funciones ‘WS_DOWNLOAD’ y ‘DOWNLOAD’.

Una vez ejecutado este método, se habrá grabado el archivo en la ruta especificada en el parámetro c_path.

Cómo subir información desde un archivo de texto a SAP (Upload)

Para subir información desde un archivo de texto del Presentation Server (la PC), se realiza un procedimiento muy similar al explicado anteriormente para  “bajar” (download)  información desde SAP.

Para efectuar el upload se debe utilizar el método GUI_UPLOAD de la clase CL_GUI_FRONTEND_SERVICES. El método GUI_UPLOAD es el que reemplaza a las funciones ‘WS_UPLOAD y ‘UPLOAD’.  .

El Paso 3. del procedimiento anterior (es decir, específicamente la invocación al método), se aplica de manera similar tanto para  realizar el upload como el download, sólo que con el método correspondiente en cada caso.

Cómo buscar archivos en el Presentation Server (PC)

El método  GUI_DOWNLOAD explicado anteriormente en el punto II. , no permite al usuario ingresar la ruta del archivo. Por esta razón en los siguientes pasos se detallará cómo implementar esta funcionalidad sin utilizar las funciones obsoletas.

1.       Declaración de la pantalla de selección.

PARAMETERS: p_file TYPE file_name.

2.   Evento ON VALUE-REQUEST sobre el parameter en el que se especifica la ruta del archivo que se desea abrir.

Para tener en cuenta …

Es recomendable familiarizarse con la clase CL_GUI_FRONTEND_SERVICES,  que puede accederse desde la Transacción SE24 (Class Builder)., para  conocer todas las funcionalidades que brinda esta clase (métodos, atributos, etc.), y de esta manera poder hacer un mejor uso de la misma.

Copyright Teknoda S.A.

FICHA TECNICA: Notas técnicas – Tips de SAP Netweaver ABAP ”Nueva técnica en ABAP para el manejo de archivos en el Presentation Server”

Tema: Programación ABAP Descripción: Conozca la nueva manera de subir y/o bajar archivos desde/hacia la PC (Presentation Server) a partir de la versión 4.7. del ERP