Quantcast
Channel: SAP Netweaver archivos - Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap...
Viewing all 72 articles
Browse latest View live

¿Qué son las BAdIs de SAP?

$
0
0

Las BAdIs (Business Add-Ins) son una herramienta de programación ABAP orientada a objetos que se utilizan en SAP para implementar validaciones y ampliaciones en el código standard de SAP en versiones a partir de la 4.6c.

A la pregunta “¿Qué son las BAdIs de SAP?“, diríamos que son la manera que da SAP de acomodar los requerimientos específicos de un cliente a sus transacciones estándar, que de no ser por las ampliaciones (las BAdIs son las más actuales, pero previamente se utilizaron las user exits y los field exits), habría que modificar el propio código de SAP. Esto último no es conveniente en prácticamente ningún caso, porque se pierde el soporte que SAP ofrece a sus productos.

Imaginemos, por ejemplo, que cada vez que damos de alta a un empleado por la transacción PA40 necesitamos guardar algunos de los datos del mismo en una tabla transparente ZEMPLE que hemos creado nosotros. Para casos como éste existen las ampliaciones, que, al fin y al cabo, no son más que fragmentos de código que SAP nos deja introducir dentro de su código estándar para realizar ciertas operaciones a medida; en este caso, introducir la información que se necesita en una tabla cuando se da de alta al empleado.

BAdIs y USER EXIT

Como hemos dicho previamente, las BAdIs no son la única forma de ampliación que tenemos en SAP, pero sí la más recomendable utilizar por varios motivos:

  • Las BAdIs son las nuevas ampliaciones de SAP, las que recomienda utilizar, y al estar basadas en la programación orientada a objetos dan más opciones que las user exits (o Customer Exits).
  • Las BAdIs se pueden implementar tantas veces como se quieran, mientras que las user exit son únicas, así, diferentes programadores pueden trabajar en diferentes proyectos e implementar la misma BAdI de una forma independiente.
  • Las BAdIs están basadas en una infraestructura multinivel (SAP, versión de país, socio, cliente, …) mientras que en las user exit solo tiene dos niveles (SAP, cliente). Gracias a esto podemos crear BAdIs a cualquier nivel de esa infraestructura.

Buscar la BAdI adecuada

Una de los mayores problemas al trabajar con Business Add-Ins, es saber cuál tenemos que utilizar en cada caso, y para ello proponemos a continuación dos técnicas distintas.

TRANSACCIÓN ST05 – Performance Analysis

Una de las más comunes es utilizar la transacción ST05 que nos permite crear trazas en tramos de ejecución. Utilizando esta transacción, y teniendo en cuenta que SAP siempre utiliza las vistas V_EXT_IMP y V_EXT_ACT cuando accede a las BAdIs, podremos saber cuáles se llaman en nuestro proceso. Los pasos a seguir son los siguientes:

  1. Accedemos a la transacción ST05
  2. Nos aseguramos de que la opción “Table Buffer Trace” (“Buffer Trace” dependiendo de la versión de Netweaver) está marcada y Activamos la traza
  3. Ejecutamos el proceso que queremos adaptar
  4. Desactivamos la traza y mostramos los resultados
  5. Filtramos los resultados para mostrar únicamente los relacionados con las vistas V_EXT_IMP y V_EXT_ACT

*Es importante que no ejecutemos ninguna otra transacción mientras la traza esté activa si queremos que los resultados sean más fáciles de analizar.

Si uno de los resultados empieza por “IF_EX_”, el nombre de la BAdI será lo que esté a continuación, ya que esta primera parte común hace referencia a la Interface.

Una vez hecho esto, tendremos un listado de BAdIs que pueden servirnos, aunque tendremos que analizarlas una a una para encontrar la adecuada. Para analizarlas, accederemos a la transacción SE18 – Definición de BAdIs que explicaremos a continuación.

Transacción SE18 – Definición de BAdIs

Otra opción es hacer uso de la ayuda de búsqueda de la propia transacción SE18. Para ello, basta con acceder a la transacción, abrir el matchcode y seleccionar la opción “Aplicaciones SAP” que nos mostrará un árbol donde podremos buscar la BAdI navegando por los componentes del sistema.

BAdI, transacción SE18, matchcode

Implementar una BAdI

El proceso de implementación de una BAdI tiene dos pasos. El primero es mirar la definición de la misma, para saber los métodos de los que disponemos y qué parámetros tiene cada uno de ellos.

Este paso lo haremos en la transacción SE18, donde, introduciendo el nombre de la BAdI, tendremos acceso a toda su información. Lo que nos interesa es la última pestaña, y más concretamente, la parte de “Interface”. Aquí veremos los métodos y podremos navegar por los diferentes objetos dentro del generador de clases (SE24).

Cuando ya tenemos clara la BAdI que queremos implementar, accedemos a la transacción SE19 para el siguiente paso: la implementación.

BAdI-Builder, transacción SE19

Como se puede ver en la imagen, tenemos dos partes bien diferenciadas. La parte de abajo será la primera que utilicemos, puesto que lo primero es crear la ampliación. Indicando la BAdI que queremos implementar se nos pedirán los nombres de la implementación y la clase a crear. Normalmente se suele añadir un prefijo (que empiece por Z) al nombre original, para que sea fácil relacionar la implementación con la propia definición.

Cuando todo se haya creado, ya podremos programar cada uno de los métodos que necesitamos para nuestro desarrollo. A partir de ahora, cada vez que queramos modificar la implementación, podremos volver a la pantalla inicial de la transacción SE19 y utilizar el bloque superior.

Para finalizar, es muy importante acordarse de activar la implementación para que se ejecute. No solo activar el objeto en SAP, como con todos los que creamos, sino marcar el check de “Implementación está activa” en la SE19 para que la tenga en cuenta en tiempo de ejecución.

Ahora que ya sabes qué son las BAdIs de SAP y cómo implementarlas, sólo tienes que aplicarlas en tus procesos.


Configuraciones dinámicas SAP PI

$
0
0

En este artículo veremos cómo usar configuración dinámicas SAP PI (Process Integration).

Adaptadores de conexiones SAP PI

Adaptadores de comunicación en SAP FI

Existen en este módulo de SAP diferentes tipos de adaptadores que permiten establecer todo tipo de comunicaciones: RFC, File, SOAP, HTTP, Mail, IDOC…

Cada uno de estos adaptadores en SAP PI ofrece diferentes parámetros para configurar correctamente dicha comunicación. Estos parámetros cambian en función de si el adaptador es de tipo Sender o de tipo Receiver.

La mayoría de estos parámetros son estáticos, esto es, hay que configurarlos desde el Integration Builder introduciendo valores en los campos correspondientes del adaptador. En la siguiente imagen vemos la configuración de un canal de comunicación con adaptador RFC Receiver con los siguientes parámetros estáticos:

  • Application Server
  • Logon User
  • Logon Password
  • Logon Language
  • Logon Client

Es solo un ejemplo, ya que de hecho, la mayoría de los adaptadores tienen este tipo de parámetros estáticos.

Dynamic Configuration SAP PI

Con las nuevas versiones de SAP Process Integration (SAP PI 7.31, SAP PO 7.40…), cada vez son más los adaptadores que permiten la configuración dinámica de adaptadores. Es decir, adaptadores cuyos parámetros pueden variar en función del mensaje que se vaya a transmitir durante la integración.

A esto se le conoce como Dynamic Configuration y se consigue utilizando un mapeo Java o una UDF (User Defined Function) en la parte de diseño de SAP PI, el Enterprise Service Builder.

Un caso muy claro de este tipo de configuraciones dinámicas, se da en los adaptadores de tipo File. Por ejemplo, un adaptador File Receiver que va a dejar un fichero .TXT cuyo nombre depende de la fecha y hora en el que se produzca el procesamiento.

Usar dynamic configuration

A continuación vamos a ver qué pasos hay que llevar a cabo para configurar dinámicamente este tipo de parámetros:

Activar y configurar los atributos de mensaje específicos del adaptador (variables)

Los adaptadores que permiten Dynamic Configuration disponen de una opción para activar este tipo de atributos. En función del adaptador aparecerán más o menos opciones. En función de estas opciones se debe hacer la correspondiente configuración.

SAP PI, Adaptador file

Crear una UDF o mapeo Java para establecer valor dinámico

En el Enterprise Service Builder, se debe un mapeo de mensaje con una UDF (o mapeo Java). Utilizando código JAVA podemos dar valor al atributo variable que corresponda. A continuación se muestra el código para establecer dinámicamente el nombre de un fichero:

Date fecha = new Date();
DateFormat dateFormat = new SimpleDateFormat("yyyyMMdd_000000000");
String nombreDinamico = " dateFormat.format(new Date()) +"_FACTURA.txt";
DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
DynamicConfigurationKey key = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/File","FileName");
conf.put(key, nombreDinamico);
 

Con estos dos pasos, conseguiremos que el nombre del fichero que genere el adaptador File Receiver sea dinámico en función de la fecha y hora actual.  Este es solo un ejemplo de esta interesante capacidad de SAP PI.

Fichero generado por el adaptador File receiver de SAP PI

Como habrás podido comprobar, las configuraciones dinámicas en SAP PI son muy sencillas y añaden funcionalidades muy interesantes a nuestras aplicaciones.

SAP Portal: Filtrando contenido por desktop

$
0
0

En el siguiente artículo veremos cómo filtrar el contenido de los usuarios de SAP Portal por desktop.

Este contenido se asigna a los diferentes usuarios usando roles de portal, es algo bastante intuitivo y eficiente a la hora de gestionar permisos y perfiles de usuario en SAP, esta técnica puede derivar en una situación algo incómoda.

Hay veces que un usuario con diferentes roles, al acceder al portal se encuentra con un montón de ítems de diferente naturaleza en su menú (Top Level Navigation) del portal de SAP.

Esos ítems se corresponderán con los Entry Points o puntos de acceso definidos en los diferentes roles de portal que tenga asignado.

Sin ir más lejos, esta situación puede darse cuando un usuario con permisos de administración (content_admin_role, user_admin_role, system_admin_role…) tiene también asignados roles de negocio.

SAP Portal

¿Cómo podemos solventar esta situación y permitir a un mismo usuario acceder al portal de SAP utilizando distintas perspectivas que le permitan ver en cada caso el grupo de ítems deseado?

El término clave para dar con la respuesta a la pregunta anterior es Filter ID, y es que SAP Portal nos permite filtrar el contenido por Desktop utilizando un identificador común entre diferentes Desktops y puntos de acceso, de manera que sólo serán mostrados los Entry Points cuyo ID de filtro coincida con el del propio Desktop.

Activación del filtrado por Desktop

Esta funcionalidad, ha de ser activada previamente desde el SAP Netweaver Administrator (nwa) de SAP Portal. Concretamente es necesario activar y configurar el siguiente módulo de portal:

Application Module com.sap.portal.navigation.helperservice
Module Component navigation_events_helper
Property FilterbyDesktopView

La propiedad anterior acepta 3 posibles valores:

  • 0 – Filtrado desactivado: Independientemente del Desktop se mostrarán todos los puntos de acceso habilitados en los roles que el usuario tenga asignados.
  • 1 – Filtrado activado: Cuando no existan coincidencias se mostrarán todos los puntos de acceso habilitados en los roles que el usuario tenga asignados.
  • 2 – Filtrado activado: Cuando no existan coincidencias se mostrarán todos los puntos de acceso que tengan un Filter ID.

SAP Portal, Filtrados

Por lo general, estableceremos el valor 1 para activar el filtrado de contenido por Desktop.

Para continuar la explicación, seguiremos con el ejemplo de un usuario de portal SAP con roles de administración y con roles de negocio.

ID de filtro en los Desktops

Para que este usuario pueda acceder de manera diferenciada a cada tipo de contenido crearemos dos Desktops diferentes:

  • Desktop A (Filter ID – Administration): Copia del Desktop AFP estándar de SAP donde visualizará el contenido relacionado con administración de contenido, usuarios y sistemas del portal.
  • Desktop B (Filter ID – fiori): Copia del Desktop FLP estándar de SAP donde visualizará un Fiori Launchpad con los distintos iviews de negocio.

ID de filtro en Desktop A

SAP Portal, Desktop A

ID de filtro en Desktop B

SAP Portal, Desktop B

Para poder acceder a cada uno de los Desktop se crearán los correspondientes alias y reglas.

ID de filtro en los Entry Points

Una vez definidos los IDs de filtro en cada Desktop asignaremos contenido a cada uno estableciendo el correspondiente Filter ID a los Entry Points de los distintos roles.

El contenido de administración será mostrado en el Desktop A, por tanto, los Entry Points que queramos visualizar deberán llevar ID de filtro “Administration”.

SAP Portal, Desktop A asignado

En cambio, el contenido de negocio que queramos mostrar en el Desktop B, deberá llevar el ID de filtro “fiori”.

SAP Portal, Desktop B asignado

Con estos 3 pasos, este usuario del que hemos ido hablando a lo largo del artículo podrá acceder de manera diferenciada, por un lado, al Desktop A para realizar tareas de administración del portal de SAP:

SAP Portal, Administración

Y cuando, en cambio, quiera acceder al contenido negocio, accederá al Desktop B en el que sólo verá el contenido buscado.

SAP Portal, Negocio

Launchpad Designer: La trastienda de SAP Fiori

$
0
0

Hace tiempo hablamos de SAP Fiori Launchpad el punto de acceso central a las aplicaciones SAP Fiori, que permite a los diferentes usuarios disponer de las aplicaciones que le corresponden por su rol organizadas en catálogos y grupos.

Esta vez vamos a ir a la trastienda de SAP Fiori y vamos a ver cómo publicar aplicaciones en SAP Fiori Launchpad, desde el Launchpad Designer.

Launchpad Designer es la herramienta que utilizan los administradores SAP Fiori para configurar qué es lo que se va a ver en SAP Fiori Launchpad.

En artículos anteriores ya comentamos los 4 conceptos más importantes en lo relativo al Launchpad Designer. A continuación, vamos a profundizar en cada uno de ellos:

Catálogo SAP Fiori

Los catálogos SAP Fiori permiten organizar las aplicaciones Fiori en roles. Dentro de cada catálogo, se incluirán las aplicaciones SAP Fiori disponibles para un determinado Rol ABAP. La asignación de los catálogos a estos roles, se realizará como en otros casos desde la transacción PFCG.

Los catálogos SAP Fiori, así mismo, es donde se configuran las aplicaciones Fiori mediante la creación de Target Mappings y Tiles, traducidos como mosaicos y asignaciones de destino.

Catálogo de SAP Fiori

Grupos SAP Fiori

Desde el Launchpad Designer también es posible crear grupos SAP Fiori. Los grupos, presentan otra forma de organizar los tiles o aplicaciones Fiori, que dota al usuario de la capacidad de personalizar su SAP Fiori Launchpad.

Los grupos permiten agrupar aplicaciones procedentes de diferentes catálogos.

Target Mapping

Es la referencia a la aplicación que va a ser accedida desde SAP Fiori Launchpad. Pueden ser de diferentes tipos según el tipo de aplicación que se quiera enlazar:

  • Aplicaciones Fiori SAPUI5
  • Aplicaciones Fiori configuradas en la LPD_CUST
  • Transacciones
  • URL
  • Web Dynpros

Obviamente según el tipo de aplicación, los parámetros a configurar serán diferentes.

Por ejemplo, para una aplicación Fiori de tipo UI5 deberemos determinar la URL en la que se puede encontrar dentro del árbol de SAP y el ID del componente asociado a esa aplicación.

Aplicación Fiori SAPUI5

No obstante, sea cual sea el tipo de aplicación, siempre se debe determinar el objeto semántico y la acción asociado a esa aplicación.

Estos términos definen la forma de navegar a esas aplicaciones desde SAP Fiori Launchpad.

SAP Fiori Launchpad

Tiles

Con la creación del Target Mapping, no es suficiente para que la aplicación esté disponible en el catálogo en cuestión. Es necesario configurar un tile o mosaico que realmente se visualizará en SAP Fiori Launchpad.

Es importante que este tile tenga el mismo objeto semántico que el Target Mapping para que se consiga realizar la navegación de manera correcta.

En los mosaicos además, se configuran elementos visuales como el icono, título y subtítulo.

Configuración SAP Fiori Launchpad

SAP icon

Configurados estos elementos ya podríamos visualizar la aplicación en cuestión en el SAP Fiori Launchpad.

Launchpad Designer

Con este repaso de los 4 términos más importantes de Launchpad Designer contamos con las herramientas más importantes para empezar a sacar rendimiento a nuestro SAP Fiori.

El SII con SAP: opciones técnicas diferentes para la nueva gestión del IVA

$
0
0

En este artículo queremos explicaros las diferentes opciones que tenemos para implementar en SAP el nuevo SII de la AEAT para la nueva gestión del IVA y otros documentos.

El SII (Suministro Información Inmediato) es un nuevo requerimiento legal puesto en marcha en primer lugar por la Agencia Tributaria Española el 1 de julio de 2017 y que también entrará en vigor en las Haciendas Forales de Álava, Bizkaia, Gipuzkoa y Navarra el 1 de enero de 2018. Básicamente consiste en que las empresas que cumplan determinadas condiciones deben informar periódicamente y de manera automática sobre el IVA de sus facturas, tanto emitidas como recibidas (además de otros tipos de documentos como bienes de inversión, operaciones intracomunitarias, etc.).

AEAT - SII

Este envío automático es posible gracias a los servicios web SOAP publicados por la AEAT y puestos a disposición de las distintas empresas para enviar los diferentes tipos de información de facturación. Estos servicios web describen una serie de estructuras XML que permiten hacer el envío de los distintos documentos.

  • Facturas emitidas
  • Facturas recibidas
  • Operaciones intracomunitarias
  • Bienes de inversión
  • Cobros
  • Pagos
  • Otras operaciones intracomunitarias

Estas estructuras también van a ser utilizadas por las haciendas forales a partir del 1 de enero de 2018.

Para implementar este nuevo requerimiento del SII, SAP ha propuesto dos soluciones basadas en el eDocument Framework, una funcionalidad adaptada a esta cuestión, que también se usa para otras soluciones como la factura electrónica en diferentes países.

  • Full Solution: Solución completa que además del eDocument Framework utiliza el add-on AIF para la generación de los XML a enviar a los servicios web y el componente HCI (HANA Cloud Integration) para efectuar la comunicación vía protocolo SOAP con los servicios web.
  • Basic Solution: Solución básica que cubre únicamente el eDocument Framework. La generación de los XML y la solución técnica para establecer la comunicación con los servicios web SOAP para enviar estos XML no está contemplada.

Por tanto, en lo que a SAP FI y la relación de los documentos financieros corresponde, la solución es clara: eDocument Framework. Pero, en lo que a la solución técnica para enviar la información requeridas por el SII de manera telemática se refiere, ¿qué opciones tenemos? ¿Cuál es la más adecuada?

La clave de este tema es SOAP (Simple Object Access Protocol) que es la naturaleza de los servicios web del SII. Por tanto, las distintas opciones técnicas disponibles en SAP sobrevuelan este concepto y por tanto están basadas en cualquier caso en la capacidad de crear clientes SOAP con los que consumir estos servicios.

Opciones para implementar SII en SAP

  • Clases proxy ABAP: Desde la plataforma ABAP Netweaver es posible crear un cliente SOAP mediante la creación de clases proxy basadas en las estructuras XML definidas para los citados servicios web. Mediante programación y configuración de puertos lógicos, es posible efectuar esta comunicación desde el propio SAP ERP.
  • SAP PI (SAP Process Integration): Organizaciones con necesidades de integración entre diferentes sistemas pueden disponer de este software de integración de SAP, capaz de establecer interfaces entre sistemas de naturaleza tecnológica muy diferente. Este es un caso ideal para implementar a través de SAP PI creando una interfaz síncrona entre SAP ERP y la plataforma SII, reduciendo la necesidad de programación, disponiendo de esta comunicación aislada en un sistema dedicado y con grandes posibilidades de monitorización, seguridad y reprocesamiento de mensajes.
  • HCI (HANA Cloud Integration): Al igual que SAP PI, HCI es una solución de SAP para llevar a cabo integraciones entre sistemas, con la principal diferencia de que es una solución Cloud basada en suscripción. De hecho, esta es la opción que SAP ha elegido para su Full Solution.

Todas estas soluciones deben contar también con las tareas necesarias para configurar los certificados SSL correspondientes al cliente (sociedades para las que se está implementando el SII) y al servidor (endpoint en el que se encuentran los servicios web de las haciendas).

¿Cuál es la mejor opción? Depende de cada caso. No obstante, con este resumen de las opciones técnicas que existen para implementar el SII desde SAP pretendemos ayudar a la hora de decidir cómo llevar a cabo esta implementación.

Esperamos haberos aclarado las diferentes opciones técnicas para integrar el SII y la nueva gestión del IVA con SAP. Recordad que podemos ayudaros con esta implementación y con el mantenimiento de SAP desde Oreka IT. Contactad con nosotros sin compromiso.

Consumir servicios SOAP desde SAP

$
0
0

En ocasiones vamos a necesitar conectar aplicaciones externas con nuestro SAP a través de webservices. En este artículo veremos cómo consumir un WebService SOAP desde SAP.

Para empezar debemos tener en cuenta que, al ser un servicio web, necesitaremos una dirección desde la que obtendremos el WSDL, que es el fichero en el que encontraremos la estructura que deberá tendrá nuestro WebService (WS), en este caso utilizaremos el siguiente:

http://www.webservicex.net/length.asmx?WSDL

Tras conseguir nuestro link al WS y comprobar que el funcionamiento es correcto, y que al entrar a él descarga un fichero WSDL tendremos que realizar los siguientes pasos:

  • Crear un Service-Consumer (SC) (Cliente Proxy).
  • Crear el Logical Port.
  • Crear programa ABAP para consumir Web Service.

 

Crear Service-Consumer (Cliente proxy)

A continuación crearemos el Service Consumer, que usaremos para consumir nuestro servicio SOAP desde SAP.

Para empezar crearemos un paquete desde SE80 (ZARTICULO en este caso) en el que guardaremos nuestro SC.

Crear cliente proxy - Conectar SAP mediante webservices SOAP

Una vez creado el paquete, para crear nuestro Service Consumer tendremos que realizar la siguiente acción:

Click derecho sobre el paquete -> Crear à Enterprise Service.

Nos saldrá a continuación la siguiente ventana, en la que deberemos elegir SC.

Creación de Service Consumer - SAP SOAP

Una vez realizado esto, continuaremos, y nos dará a elegir entre 3 opciones:

  • Backend
  • Enterprise Service Respository
  • External WSDL/Schema

Elegiremos External WSDL/Schema, debido a que nuestro WSDL será importado.

Pasando a la siguiente pantalla, tendremos la opción de elegir de qué manera queremos importar nuestro WSDL. En este caso podemos hacerlo mediante dos métodos:

  • descargar el fichero desde la URL que he dejado anteriormente, y seleccionar la opción de Local File
  • o introducir directamente la URL mediante la opción HTTP Destination.

En este caso utilizaremos la primera opción, aunque ambas son válidas.

Importar WSDL a SAP (SOAP)

Tras realizar esto tendremos que seleccionar el tipo de puerto que queremos usar. Como en este artículo estamos aprendiendo a consumir un servicio SOAP, elegiremos la opción lengthUnitSoap, y continuaremos con el proceso, para llegar al último paso.

Tendremos que elegir el paquete al que va a pertenecer el servicio, la orden en la que lo crearemos, y un prefijo, el cual servirá para que al crear la clase, se cree con ese prefijo. En este caso utilizaremos el prefijo ZART.

Consumir servicios SOAP desde SAP

Por último, y para terminar con nuestro Service-Consumer, clicaremos en Concluir.

Nos aparecerá en la pantalla nuestro Service Consumer, desde la cual podremos editar el nombre por ejemplo, y como podemos comprobar se habrá creado con el prefijo anteriormente elegido. Guardamos y nuestro SC estará terminado.

 

Crear Logical Port (LP)

El Logical Port (LP) nos permitirá llamar al servicio externo. Para crearlo tenemos dos opciones:

  • Desde la propia pantalla anteriormente nombrada. Tras activar nuestro SC, nos aparecerá una nueva opción en el menú, Start SOA Manager.

Llamar a servicio externo desde SAP con Logical Port (LP)

  • La otra opción sería abrirlo desde la TX SOAMANAGER.

Tendremos que seguir los siguientes pasos para la creación de nuestro Logical Port (LP):

Create -> Create WSDL Based Configuration.

Nos pedirá un nombre para el LP. En este caso usaremos ZART_LP y checkearemos la opción de Logical Port is Default (esta opción dejará este puerto por defecto, y a la hora de ejecutar ejecutará el mismo).

En la siguiente pantalla, dependiendo de cómo hayamos creado anteriormente nuestro Service Consumer (desde fichero o mediante HTTP) elegiremos una u otra. En este caso Via File y seleccionaremos el WSDL anteriormente descargado.

Continuaremos hasta que nos salga la pantalla “Transport Binding”. En esta pantalla podremos cambiar distintas cosas, aunque en este caso tal y como viene estará bien configurado y por lo tanto no tenemos que cambiar nada, clicaremos en Finish, y nuestro LP estará creado.

 

Crear programa ABAP

Por último y no menos importante crearemos un programa en la SE80 en el que introduciremos el siguiente código (depende del programa el código será distinto):

REPORT ZART_CONSUMER.
 DATA: lv_conv TYPE REF TO zartco_length_unit_SOAP, "Clase proxy (Service Consumer)
 lv_out  TYPE ZARTCHANGE_LENGTH_UNIT_SOAP_OU,       "Método de salida
 lv_in   TYPE ZARTCHANGE_LENGTH_UNIT_SOAP_IN,       "Método de entrada
 int     TYPE i.
 PARAMETERS: p_valor TYPE i.
 TRY.
 CREATE OBJECT lv_conv
 EXPORTING
 logical_port_name = 'ZART_LP'.                     "Nombre de nuestro Logical Port
 CATCH cx_ai_system_fault .
 ENDTRY.
 lv_in-from_length_unit  = 'Meters'.
 lv_in-to_length_unit    = 'Centimeters'.
 lv_in-length_value      = p_valor.
 CALL METHOD lv_conv->change_length_unit             
 EXPORTING
 input  = lv_in
 IMPORTING
 output = lv_out.
 int = lv_out-change_length_unit_result.
 WRITE: int.

Lo único que nos queda es ejecutar nuestro programa, y verificar que la conexión y el resultado es correcto.

Así es como se conectan servicios externos con SAP mediante webservices SOAP en diferentes contextos.

En Oreka IT somos especialistas en SAP. Seguro que podemos ayudarte con tu proyecto. ¡Contáctanos!

Transformaciones de XML complejos a ABAP

$
0
0

Los ficheros realizados con lenguaje XML son muy comunes a la hora de intercambiar información entre diferentes sistemas. Es un lenguaje estándar fácil de entender, pero dependiendo de la complejidad del fichero la transformación puede volverse complicada. En este artículo explicaremos cómo transformar la información de un XML de varios niveles a ABAP para poder tratar esos datos.

Para poder explicar el funcionamiento de la transformación utilizaremos un ejemplo. El fichero XML utilizado en el artículo tiene el siguiente formato:

<DatosReceptoresEf4ktur>
    <DatosReceptor>
        <RazonSocial></RazonSocial>
        <Direccion></Direccion>
        <CodigoPostal></CodigoPostal>
        <Poblacion></Poblacion>
        <Provincia></Provincia>
        <Correo></Correo>
        <ContactoAdicional></ContactoAdicional>
        <CorreoEnvio></CorreoEnvio>
        <DescripcionDepartamento></DescripcionDepartamento>
        <Departamento></Departamento>
        <CIF></CIF>
        <DatosContratante>
            <CentroAdministrativo>
                <CentreCode></CentreCode>
                <CentreDescription></CentreDescription>
                <RoleTypeCode></RoleTypeCode>
                <CodigoEntidadRelacionada></CodigoEntidadRelacionada>
                <Name></Name>
                <FirstSurname></FirstSurname>
                <SecondSurname></SecondSurname>
<Address></Address>
                <PostCode></PostCode>
                <Town></Town>
                <Province></Province>
                <Pais></Pais>
                <ElectronicMail></ElectronicMail>
                <Telephone></Telephone>
            </CentroAdministrativo>
        </DatosContratante>
    </DatosReceptor>
</DatosReceptoresEf4ktur>

 

En el fichero habrá varios datos de receptores, y dentro de los datos contratantes podrá haber varios centros administrativos. También puede darse el caso de que un receptor no tenga ningún centro administrativo. Para poder importar los datos lo dividiremos en dos partes:

  • la creación de objetos del diccionario ABAP
  • la creación de la transformación

 

Creación de los objetos del diccionario ABAP

Nuestro objetivo en la SE11 es crear un tipo de tabla que tenga una estructura la cual pueda contener todos los campos que tiene el XML.

Actualizar tipo de tablas para transformaciones XML complejos a ABAP

SAP: estructura XML a ABAP

Si nos fijamos en la imagen el último campo de la estructura es otro tipo de tabla. Este tipo de tabla tendrá que tener una estructura para poder guardar todo lo que hay dentro de las etiquetas “DatosContratante”, es decir, todos los centros administrativos.

SAP: estructura XML a ABAPSAP: estructura XML a ABAP

También, habría que crear, los dominios y elementos de datos necesarios para cada campo, en caso de no poder reutilizar otros ya creados.

Creación de la transformación

Una vez creados todos los objetos necesarios para albergar los datos del XML tendremos que realizar la transformación. Las transformaciones se crean en la transacción STRANS. Al darle al botón crear nos pedirá una descripción y la clase de transformación. La clase que elegiremos será “Transformación Simple”.

SAP: Transformación simple XML

Para crear la lógica de la transformación utilizaremos el modo gráfico pinchando en la varita redondeada en la imagen.

SAP - lógica de transformación simple - XML

Por defecto, nos aparece el elemento “ROOT” que borraremos (click derecho -> delete) para meter la estructura creada por nosotros en la SE11 (click derecho -> Insert new root).

Estructura - root - SAP - XML

De esta manera, se cargará la estructura y podremos arrastrarla a la otra columna para que nos cree la transformación para la plantilla que hemos cargado.

Cargar estructura creada - transformación XML

Prácticamente ya tenemos creada nuestra transformación. Sólo nos falta cambiar algunos elementos para finalizar.

Lo primero será ponerles el mismo nombre a las etiquetas que en el XML. Por ejemplo en el caso de “DatosReceptor” que la etiqueta sale con el nombre “Z……”.

También, el caso de “CorreoEnvio”, que en nuestra transformación la etiqueta tiene el nombre SENTMAIL porque es nombre del campo en la estructura creada en la SE11. Si nos fijamos en el código, veremos que dentro de cada etiqueta tenemos asignado el campo en el que se guardará ese valor.

Otro aspecto a tener en cuenta es que las etiquetas son “case sensitive”, así que hay que escribirlos exactamente igual al XML, controlando que coincidan las mayúsculas/minúsculas.

Antes de los cambios:

<?sap.transform simple?>
<tt:transform xmlns:tt="http://www.sap.com/transformation-templates" xmlns:ddic="http://www.sap.com/abapxml/types/dictionary" xmlns:def="http://www.sap.com/abapxml/types/defined">
  <tt:root name="DATOSRECEPTORESEF4KTUR" type="ddic:ZXMLRECEPTOR_TT"/>
  <tt:template>
    <DATOSRECEPTORESEF4KTUR>
      <tt:loop ref=".DATOSRECEPTORESEF4KTUR">
        <ZXMLRECEPTOR_ST>
          <DESCRIPTION tt:value-ref="DESCRIPTION"/>
<ADDRESS tt:value-ref="ADDRESS"/>
          <POSTCODE tt:value-ref="POSTCODE"/>
          <TOWN tt:value-ref="TOWN"/>
          <PROVINCE tt:value-ref="PROVINCE"/>
          <MAIL tt:value-ref="MAIL"/>
          <MAIL2 tt:value-ref="MAIL2"/>
          <SENTMAIL tt:value-ref="SENTMAIL"/>
          <DEPARTMENTDESCRI tt:value-ref="DEPARTMENTDESCRI"/>
          <DEPARTMENT tt:value-ref="DEPARTMENT"/>
          <CIF tt:value-ref="CIF"/>
          <DATOSCONTRATANTE>
            <tt:loop ref="DATOSCONTRATANTE">
              <ZCENTROADMIN_ST>
                <CENTRECODE tt:value-ref="CENTRECODE"/>
                <DESCRIPTION tt:value-ref="DESCRIPTION"/>
                <ROLETYPE tt:value-ref="ROLETYPE"/>
                <RELATEDENTITY tt:value-ref="RELATEDENTITY"/>
                <NAME tt:value-ref="NAME"/>
                <FIRSTSURNAME tt:value-ref="FIRSTSURNAME"/>
                <SECONDSURNAME tt:value-ref="SECONDSURNAME"/>
<ADDRESS tt:value-ref="ADDRESS"/>
                <POSTCODE tt:value-ref="POSTCODE"/>
                <TOWN tt:value-ref="TOWN"/>
                <PROVINCE tt:value-ref="PROVINCE"/>
                <COUNTRY tt:value-ref="COUNTRY"/>
                <MAIL tt:value-ref="MAIL"/>
                <PHONE tt:value-ref="PHONE"/>
              </ZCENTROADMIN_ST>
            </tt:loop>
          </DATOSCONTRATANTE>
        </ZXMLRECEPTOR_ST>
      </tt:loop>
    </DATOSRECEPTORESEF4KTUR>
  </tt:template>

 

Por último, como hemos dicho al principio del artículo, puede que algún receptor no tenga centros administrativos. Por lo tanto, no tendrá la estructura a partir de “DatosContratante”. Para que durante la deserialización de la transformación no nos salte el error de que no encuentra esas etiquetas deberemos añadir la siguiente etiqueta al código de la transformación: <tt:d-cond>. Después de los cambios de nombre anteriores y la condición:

 <?sap.transform simple?> <tt:transform xmlns:tt="http://www.sap.com/transformation-templates" xmlns:ddic="http://www.sap.com/abapxml/types/dictionary" xmlns:def="http://www.sap.com/abapxml/types/defined"> <tt:root name="DATOSRECEPTORESEF4KTUR" type="ddic:ZXMLRECEPTOR_TT"/> <tt:template> <DATOSRECEPTORESEF4KTUR> <tt:loop ref=".DATOSRECEPTORESEF4KTUR"> <DatosReceptor> <RazonSocial tt:value-ref="DESCRIPTION"/> <Direccion tt:value-ref="ADDRESS"/> <CodigoPostal tt:value-ref="POSTCODE"/> <Poblacion tt:value-ref="TOWN"/> <Provincia tt:value-ref="PROVINCE"/> <Correo tt:value-ref="MAIL"/> <ContactoAdicional tt:value-ref="MAIL2"/> <CorreoEnvio tt:value-ref="SENTMAIL"/> <DescripcionDepartamento tt:value-ref="DEPARTMENTDESCRI"/> <Departamento tt:value-ref="DEPARTMENT"/> <CIF tt:value-ref="CIF"/> <tt:d-cond> <DATOSCONTRATANTE> <tt:loop ref="DATOSCONTRATANTE"> <CentroAdministrativo> <CentreCode tt:value-ref="CENTRECODE"/> <CentreDescription tt:value-ref="DESCRIPTION"/> <RoleTypeCode tt:value-ref="ROLETYPE"/> <CodigoEntidadRelacionada tt:value-ref="RELATEDENTITY"/> <Name tt:value-ref="NAME"/> <FirstSurname tt:value-ref="FIRSTSURNAME"/> <SecondSurname tt:value-ref="SECONDSURNAME"/> <Address tt:value-ref="ADDRESS"/> <PostCode tt:value-ref="POSTCODE"/> <Town tt:value-ref="TOWN"/> <Province tt:value-ref="PROVINCE"/> <Pais tt:value-ref="COUNTRY"/> <ElectronicMail tt:value-ref="MAIL"/> <Telephone tt:value-ref="PHONE"/> </CentroAdministrativo> </tt:loop> </DATOSCONTRATANTE> </tt:d-cond> </DatosReceptor> </tt:loop> </DATOSRECEPTORESEF4KTUR> </tt:template> 

 

De esta manera, si lo que hay dentro de las etiquetas <tt:d-cond> no existe, la transformación lo obviará. No nos saltará ningún error y seguirá con el siguiente receptor. La transformación estaría finalizada, y tan sólo faltaría activarla para poder usarla.

Con lo explicado anteriormente ya tendríamos hecha la transformación del XML para poder pasar la información a ABAP. La forma de poder utilizarla en un report es mediante la sentencia CALL TRANSFORMATION.

 

SAP HANA: Conceptos clave sobre SAP S/4HANA

$
0
0

En Febrero de este 2015, SAP lanzó la nueva versión de su suite de aplicativos de gestión de negocio, construida sobre SAP HANA y con toda la capacidad que ésta ofrece. SAP S/4HANA es la mayor innovación de SAP desde SAP R/3

SAP HANA: La nueva revolución de SAP

¿Qué es SAP S/4HANA?

SAP S/4HANA es una suite de aplicativos informáticos de gestión integral de negocio de última generación. Se trata de un nuevo producto desarrollado sobre SAP HANA, la plataforma de procesamiento in-memory más avanzada a día de hoy y que se aprovecha de las últimas innovaciones de SAP para optimizar la experiencia de usuario con SAP Fiori.

SAP S/4HANA ofrece una gran simplificación en cuanto a gestión de procesos (modelo de datos, experiencia de usuario nuevo, toma de decisiones, modelos y procesos de negocio) y en cuanto a alineamiento con las últimas innovaciones tecnológicas (Internet of Things, Big Data, Business Networks, Movilidad).

En definitiva, SAP S/4HANA ha sido concebido como la herramienta de gestión idónea para impulsar la economía digital y el modelo de Industria 4.0.

¿De dónde viene el nombre de SAP S/4HANA?

SAP S/4HANA es la abreviatura para SAP Business Suite 4 HANA. Incorpora una cantidad masiva de innovaciones y desde el punto de vista tecnológico supone un salto incluso mayor que el de la transición de SAP R/2 a SAP R/3.

¿Qué opciones de implantación están disponibles?

Los partners de SAP ofrecen modelos de implantación on-premise (en las propias instalaciones del cliente), en la nube y modelos híbridos. Todos estos modelos de implantación están disponibles en el mercado.

¿Cuáles son las ventajas de migrar a SAP S/4HANA para un cliente de SAP?

La visión y estrategia de SAP es ayudar a sus clientes a impulsar la economía digital. Para realizar su visión, SAP está redefiniendo cómo el software de empresa crea valor.

SAP S/4HANA está diseñado para añadir valor en todas las líneas de industria y de negocio gracias a la sofisticación última: la simplicidad.

Desde una perspectiva de valor de negocio, esto significa que SAP S/4HANA crea oportunidades únicas para reinventar el modelo de negocio y organizativo de sus clientes y acompañar en la creación de nuevos modelos de gestión y de beneficio. Por un lado, las empresas ahora se pueden conectar fácilmente a personas, dispositivos y redes de negocio para ofrecer valor a sus clientes por cualquier canal – se trata de sacar partido a los conceptos Internet of Things y Big Data. Por otro lado, las empresas pueden simplificar sus procesos, gestionarlos en tiempos real y cambiarlos según vean necesario para maximizar su eficiencia – aquí el batch processing ya no es necesario.

Por último, los usuarios de negocio pueden consultar los datos que quieran, de la forma y con el nivel de detalle que quieran, en cualquier sitio, a cualquier hora, y en tiempo real: Se pueden controlar todos los aspectos de planificación, ejecución, predicción y simulación.

Desde una perspectiva de valor de sistemas de información, esto significa que SAP S/4HANA crea oportunidades para simplificar infraestructura y reducir el Coste Total de Propiedad (CTO) con SAP HANA. Primero, las empresas pueden concentrar todas sus fuentes de datos en un mismo sistema de gestión que centralice todas las operaciones de la empresa (ERP, CRM, SRM, SCM, PLM), lo cual además de reducir tiempos, permite ahorrar en hardware.

Además, tenemos la posibilidad de crear experiencias de usuarios basadas en roles concretos, lo cual incrementa la productividad a la vez que permite reducir costes de formación. Finalmente, se ofrece a la empresa el modo de implementación que mejor le encaje: cloud, servidores en las propias instalaciones, y modelo híbrido.

Conceptos clave sobre SAP S/4 HANA

  • Menor infraestructura de almacenamiento de datos y en el data footprint (rastros de datos dejados por el usuario)
  • Mayor integración entre procesos
  • Analíticas y reportes más rápidos
  • Simplificación en la gestión de procesos
  • Implementación simultánea de ERP, CRM, SRM, PLM
  • Convivencia de datos actuales (25%) y datos históricos (75%)
  • Capacidad de carga de datos ilimitada
  • Realización sencilla de predicciones, modelos y simulaciones
  • SAP HANA en tenencia múltiple: misma infraestructura que sirve a varias aplicaciones que a su vez pueden servir a varios clientes, organizaciones, etc.
  • Todo tipo de datos: social, textos, numéricos, geográfico, procesamiento, etc
  • Integración con cualquier dispositivo de movilidad
  • Modelo de implementación a la carta

Estas son en resumen las claves sobre la SAP S/4HANA, la suite de negocios más innovadora del grupo SAP.


¿Qué es SAP Netweaver Gateway?

$
0
0

En el artículo “¿Qué es SAPUI5?” comenzábamos a conocer la tecnología SAPUI5,  por la que en los últimos años SAP ha apostado para el diseño de interfaces SAP.

Tras conocer sus librerías, su potencial para diseñar interfaces responsive e incluso empezar a generar código, en este artículo os presento un nuevo componente de SAP que proveerá a nuestras aplicaciones de lo más importante para que estas sean útiles: los datos. Este componente es SAP Netweaver Gateway.

¿Qué es SAP Netweaver Gateway?

Gran parte de los productos que engloba SAP Netweaver ayudan a integrar y aumentar el alcance de los distintos aplicativos de SAP. En este caso, SAP Netweaver Gateway facilita el desarrollo de aplicaciones de negocio SAP tanto en beneficio de los usuarios finales, como de los desarrolladores.

Con SAP Netweaver Gateway se rompen las barreras de la tecnología, haciendo posible explotar los datos SAP desde aplicaciones desarrolladas  en cualquier lenguaje de programación, sin que saber ABAP, sea necesario. La clave de todo esto son los servicios oData.

¿Qué es oData?

oData es un protocolo basado en el paradigma de desarrollo REST.

Este paradigma entre otros aspectos tiene en cuenta 5 comandos ante los que el servidor debe responder: GET, POST, PUT, DELETE y PATCH. Estos comandos se corresponden con las operaciones Create, Retrieve, Update y Delete de las interfaces CRUD.

Los servicios oData soportan este tipo de operaciones, aunque no es obligatorio que implementen todas.

En SAP Netweaver Gateway es posible crear este tipo de servicios oData que permitan crear, leer, actualizar o borrar datos procedentes de por ejemplo un SAP ERP desde una aplicación  desarrollada por ejemplo con HTML5 y Javascript.

Los servicio oData se basan en XML aunque también es posible desplegarlos utilizando JSON. La elección de un formato u otro dependerá del desarrollador y/o de la tecnología a usar para consumir servicios oData.

Servicios oData en SAP Netweaver Gateway

SAP Netweaver Service Builder

Desde la transacción SEGW del SAP Netweaver Gateway se pueden crear servicios oData de manera manual creando las entidades deseadas e implementando las operaciones requeridas o a partir de estructuras ya definidas como por ejemplo:

  • Estructuras de diccionario ABAP
  • Remote Function Call (RFCs)
  • BAPIs del Bussiness Object Repository (BOR)

SAP Netweaver Service Builder

 SAP Netweaver Gateway Client

Esta herramienta del SAP Gateway permite testear los servicios oData creados desde la transacción anterior.

  • Ver la descripción del servicio: operaciones, entidades, tipos de datos…

SAP Netweaver Gateway Client

  • Probar las diferentes operaciones para las entidades disponibles en cada servicio:

SAP Netweaver Gateway, operaciones  disponibles en cada servicio

 

SAP Netweaver Gateway, operaciones  disponibles

 

  • Utilizar todas las opciones de filtrado, selección, formato etc. ofrecidas por el protocolo oData.

SAP Netweaver Gateway, opciones de filtrado

Consumir servicios desde SAPUI5

Siendo ambos productos (tanto SAPUI5 como SAP Netweaver Gateway) productos de SAP, es lógico que al desarrollar un framework de desarrollo como SAPUI5, se haya tenido en cuenta este potencial de publicar servicios oData en el Gateway.

No en vano, SAPUI5 pone a disposición del desarrollador clases y funciones para el consumo de servicios oData, tanto para crear, leer, actualizar y borrar datos SAP a través de lo que se conocen como modelos oData en SAPUI5.

SAP Netweaver Gateway,servicios oData

Está claro que este artículo no es más que un resumen de qué es SAP Netweaver Gateway, qué son los servicios oData y qué potencial nos pueden ofrecer a la hora de desarrollar nuestras apps SAPUI5, pero desde luego debe quedar muy claro que debemos tener muy en cuenta SAP Netweaver Gateway si queremos apostar por la movilidad en los productos SAP de nuestra empresa.

¿Qué son las BAdIs de SAP?

$
0
0

Las BAdIs (Business Add-Ins) son una herramienta de programación ABAP orientada a objetos que se utilizan en SAP para implementar validaciones y ampliaciones en el código standard de SAP en versiones a partir de la 4.6c.

A la pregunta “¿Qué son las BAdIs de SAP?“, diríamos que son la manera que da SAP de acomodar los requerimientos específicos de un cliente a sus transacciones estándar, que de no ser por las ampliaciones (las BAdIs son las más actuales, pero previamente se utilizaron las user exits y los field exits), habría que modificar el propio código de SAP. Esto último no es conveniente en prácticamente ningún caso, porque se pierde el soporte que SAP ofrece a sus productos.

Imaginemos, por ejemplo, que cada vez que damos de alta a un empleado por la transacción PA40 necesitamos guardar algunos de los datos del mismo en una tabla transparente ZEMPLE que hemos creado nosotros. Para casos como éste existen las ampliaciones, que, al fin y al cabo, no son más que fragmentos de código que SAP nos deja introducir dentro de su código estándar para realizar ciertas operaciones a medida; en este caso, introducir la información que se necesita en una tabla cuando se da de alta al empleado.

BAdIs y USER EXIT

Como hemos dicho previamente, las BAdIs no son la única forma de ampliación que tenemos en SAP, pero sí la más recomendable utilizar por varios motivos:

  • Las BAdIs son las nuevas ampliaciones de SAP, las que recomienda utilizar, y al estar basadas en la programación orientada a objetos dan más opciones que las user exits (o Customer Exits).
  • Las BAdIs se pueden implementar tantas veces como se quieran, mientras que las user exit son únicas, así, diferentes programadores pueden trabajar en diferentes proyectos e implementar la misma BAdI de una forma independiente.
  • Las BAdIs están basadas en una infraestructura multinivel (SAP, versión de país, socio, cliente, …) mientras que en las user exit solo tiene dos niveles (SAP, cliente). Gracias a esto podemos crear BAdIs a cualquier nivel de esa infraestructura.

Buscar la BAdI adecuada

Una de los mayores problemas al trabajar con Business Add-Ins, es saber cuál tenemos que utilizar en cada caso, y para ello proponemos a continuación dos técnicas distintas.

TRANSACCIÓN ST05 – Performance Analysis

Una de las más comunes es utilizar la transacción ST05 que nos permite crear trazas en tramos de ejecución. Utilizando esta transacción, y teniendo en cuenta que SAP siempre utiliza las vistas V_EXT_IMP y V_EXT_ACT cuando accede a las BAdIs, podremos saber cuáles se llaman en nuestro proceso. Los pasos a seguir son los siguientes:

  1. Accedemos a la transacción ST05
  2. Nos aseguramos de que la opción “Table Buffer Trace” (“Buffer Trace” dependiendo de la versión de Netweaver) está marcada y Activamos la traza
  3. Ejecutamos el proceso que queremos adaptar
  4. Desactivamos la traza y mostramos los resultados
  5. Filtramos los resultados para mostrar únicamente los relacionados con las vistas V_EXT_IMP y V_EXT_ACT

*Es importante que no ejecutemos ninguna otra transacción mientras la traza esté activa si queremos que los resultados sean más fáciles de analizar.

Si uno de los resultados empieza por “IF_EX_”, el nombre de la BAdI será lo que esté a continuación, ya que esta primera parte común hace referencia a la Interface.

Una vez hecho esto, tendremos un listado de BAdIs que pueden servirnos, aunque tendremos que analizarlas una a una para encontrar la adecuada. Para analizarlas, accederemos a la transacción SE18 – Definición de BAdIs que explicaremos a continuación.

Transacción SE18 – Definición de BAdIs

Otra opción es hacer uso de la ayuda de búsqueda de la propia transacción SE18. Para ello, basta con acceder a la transacción, abrir el matchcode y seleccionar la opción “Aplicaciones SAP” que nos mostrará un árbol donde podremos buscar la BAdI navegando por los componentes del sistema.

BAdI, transacción SE18, matchcode

Implementar una BAdI

El proceso de implementación de una BAdI tiene dos pasos. El primero es mirar la definición de la misma, para saber los métodos de los que disponemos y qué parámetros tiene cada uno de ellos.

Este paso lo haremos en la transacción SE18, donde, introduciendo el nombre de la BAdI, tendremos acceso a toda su información. Lo que nos interesa es la última pestaña, y más concretamente, la parte de “Interface”. Aquí veremos los métodos y podremos navegar por los diferentes objetos dentro del generador de clases (SE24).

Cuando ya tenemos clara la BAdI que queremos implementar, accedemos a la transacción SE19 para el siguiente paso: la implementación.

BAdI-Builder, transacción SE19

Como se puede ver en la imagen, tenemos dos partes bien diferenciadas. La parte de abajo será la primera que utilicemos, puesto que lo primero es crear la ampliación. Indicando la BAdI que queremos implementar se nos pedirán los nombres de la implementación y la clase a crear. Normalmente se suele añadir un prefijo (que empiece por Z) al nombre original, para que sea fácil relacionar la implementación con la propia definición.

Cuando todo se haya creado, ya podremos programar cada uno de los métodos que necesitamos para nuestro desarrollo. A partir de ahora, cada vez que queramos modificar la implementación, podremos volver a la pantalla inicial de la transacción SE19 y utilizar el bloque superior.

Para finalizar, es muy importante acordarse de activar la implementación para que se ejecute. No solo activar el objeto en SAP, como con todos los que creamos, sino marcar el check de “Implementación está activa” en la SE19 para que la tenga en cuenta en tiempo de ejecución.

Ahora que ya sabes qué son las BAdIs de SAP y cómo implementarlas, sólo tienes que aplicarlas en tus procesos.

Configuraciones dinámicas SAP PI

$
0
0

En este artículo veremos cómo usar configuración dinámicas SAP PI (Process Integration).

Adaptadores de conexiones SAP PI

Adaptadores de comunicación en SAP FI

Existen en este módulo de SAP diferentes tipos de adaptadores que permiten establecer todo tipo de comunicaciones: RFC, File, SOAP, HTTP, Mail, IDOC…

Cada uno de estos adaptadores en SAP PI ofrece diferentes parámetros para configurar correctamente dicha comunicación. Estos parámetros cambian en función de si el adaptador es de tipo Sender o de tipo Receiver.

La mayoría de estos parámetros son estáticos, esto es, hay que configurarlos desde el Integration Builder introduciendo valores en los campos correspondientes del adaptador. En la siguiente imagen vemos la configuración de un canal de comunicación con adaptador RFC Receiver con los siguientes parámetros estáticos:

  • Application Server
  • Logon User
  • Logon Password
  • Logon Language
  • Logon Client

Es solo un ejemplo, ya que de hecho, la mayoría de los adaptadores tienen este tipo de parámetros estáticos.

Dynamic Configuration SAP PI

Con las nuevas versiones de SAP Process Integration (SAP PI 7.31, SAP PO 7.40…), cada vez son más los adaptadores que permiten la configuración dinámica de adaptadores. Es decir, adaptadores cuyos parámetros pueden variar en función del mensaje que se vaya a transmitir durante la integración.

A esto se le conoce como Dynamic Configuration y se consigue utilizando un mapeo Java o una UDF (User Defined Function) en la parte de diseño de SAP PI, el Enterprise Service Builder.

Un caso muy claro de este tipo de configuraciones dinámicas, se da en los adaptadores de tipo File. Por ejemplo, un adaptador File Receiver que va a dejar un fichero .TXT cuyo nombre depende de la fecha y hora en el que se produzca el procesamiento.

Usar dynamic configuration

A continuación vamos a ver qué pasos hay que llevar a cabo para configurar dinámicamente este tipo de parámetros:

Activar y configurar los atributos de mensaje específicos del adaptador (variables)

Los adaptadores que permiten Dynamic Configuration disponen de una opción para activar este tipo de atributos. En función del adaptador aparecerán más o menos opciones. En función de estas opciones se debe hacer la correspondiente configuración.

SAP PI, Adaptador file

Crear una UDF o mapeo Java para establecer valor dinámico

En el Enterprise Service Builder, se debe un mapeo de mensaje con una UDF (o mapeo Java). Utilizando código JAVA podemos dar valor al atributo variable que corresponda. A continuación se muestra el código para establecer dinámicamente el nombre de un fichero:

Date fecha = new Date();

DateFormat dateFormat = new SimpleDateFormat("yyyyMMdd_000000000");

String nombreDinamico = " dateFormat.format(new Date()) +"_FACTURA.txt";

DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);

DynamicConfigurationKey key = DynamicConfigurationKey.create("https://sap.com/xi/XI/System/File","FileName");

conf.put(key, nombreDinamico);

 

Con estos dos pasos, conseguiremos que el nombre del fichero que genere el adaptador File Receiver sea dinámico en función de la fecha y hora actual.  Este es solo un ejemplo de esta interesante capacidad de SAP PI.

Fichero generado por el adaptador File receiver de SAP PI

Como habrás podido comprobar, las configuraciones dinámicas en SAP PI son muy sencillas y añaden funcionalidades muy interesantes a nuestras aplicaciones.

SAP Portal: Filtrando contenido por desktop

$
0
0

En el siguiente artículo veremos cómo filtrar el contenido de los usuarios de SAP Portal por desktop.

Este contenido se asigna a los diferentes usuarios usando roles de portal, es algo bastante intuitivo y eficiente a la hora de gestionar permisos y perfiles de usuario en SAP, esta técnica puede derivar en una situación algo incómoda.

Hay veces que un usuario con diferentes roles, al acceder al portal se encuentra con un montón de ítems de diferente naturaleza en su menú (Top Level Navigation) del portal de SAP.

Esos ítems se corresponderán con los Entry Points o puntos de acceso definidos en los diferentes roles de portal que tenga asignado.

Sin ir más lejos, esta situación puede darse cuando un usuario con permisos de administración (content_admin_role, user_admin_role, system_admin_role…) tiene también asignados roles de negocio.

SAP Portal

¿Cómo podemos solventar esta situación y permitir a un mismo usuario acceder al portal de SAP utilizando distintas perspectivas que le permitan ver en cada caso el grupo de ítems deseado?

El término clave para dar con la respuesta a la pregunta anterior es Filter ID, y es que SAP Portal nos permite filtrar el contenido por Desktop utilizando un identificador común entre diferentes Desktops y puntos de acceso, de manera que sólo serán mostrados los Entry Points cuyo ID de filtro coincida con el del propio Desktop.

Activación del filtrado por Desktop

Esta funcionalidad, ha de ser activada previamente desde el SAP Netweaver Administrator (nwa) de SAP Portal. Concretamente es necesario activar y configurar el siguiente módulo de portal:

Application Module com.sap.portal.navigation.helperservice
Module Component navigation_events_helper
Property FilterbyDesktopView

La propiedad anterior acepta 3 posibles valores:

  • 0 – Filtrado desactivado: Independientemente del Desktop se mostrarán todos los puntos de acceso habilitados en los roles que el usuario tenga asignados.
  • 1 – Filtrado activado: Cuando no existan coincidencias se mostrarán todos los puntos de acceso habilitados en los roles que el usuario tenga asignados.
  • 2 – Filtrado activado: Cuando no existan coincidencias se mostrarán todos los puntos de acceso que tengan un Filter ID.

SAP Portal, Filtrados

Por lo general, estableceremos el valor 1 para activar el filtrado de contenido por Desktop.

Para continuar la explicación, seguiremos con el ejemplo de un usuario de portal SAP con roles de administración y con roles de negocio.

ID de filtro en los Desktops

Para que este usuario pueda acceder de manera diferenciada a cada tipo de contenido crearemos dos Desktops diferentes:

  • Desktop A (Filter ID – Administration): Copia del Desktop AFP estándar de SAP donde visualizará el contenido relacionado con administración de contenido, usuarios y sistemas del portal.
  • Desktop B (Filter ID – fiori): Copia del Desktop FLP estándar de SAP donde visualizará un Fiori Launchpad con los distintos iviews de negocio.

ID de filtro en Desktop A

SAP Portal, Desktop A

ID de filtro en Desktop B

SAP Portal, Desktop B

Para poder acceder a cada uno de los Desktop se crearán los correspondientes alias y reglas.

ID de filtro en los Entry Points

Una vez definidos los IDs de filtro en cada Desktop asignaremos contenido a cada uno estableciendo el correspondiente Filter ID a los Entry Points de los distintos roles.

El contenido de administración será mostrado en el Desktop A, por tanto, los Entry Points que queramos visualizar deberán llevar ID de filtro “Administration”.

SAP Portal, Desktop A asignado

En cambio, el contenido de negocio que queramos mostrar en el Desktop B, deberá llevar el ID de filtro “fiori”.

SAP Portal, Desktop B asignado

Con estos 3 pasos, este usuario del que hemos ido hablando a lo largo del artículo podrá acceder de manera diferenciada, por un lado, al Desktop A para realizar tareas de administración del portal de SAP:

SAP Portal, Administración

Y cuando, en cambio, quiera acceder al contenido negocio, accederá al Desktop B en el que sólo verá el contenido buscado.

SAP Portal, Negocio

Launchpad Designer: La trastienda de SAP Fiori

$
0
0

Hace tiempo hablamos de SAP Fiori Launchpad el punto de acceso central a las aplicaciones SAP Fiori, que permite a los diferentes usuarios disponer de las aplicaciones que le corresponden por su rol organizadas en catálogos y grupos.

Esta vez vamos a ir a la trastienda de SAP Fiori y vamos a ver cómo publicar aplicaciones en SAP Fiori Launchpad, desde el Launchpad Designer.

Launchpad Designer es la herramienta que utilizan los administradores SAP Fiori para configurar qué es lo que se va a ver en SAP Fiori Launchpad.

En artículos anteriores ya comentamos los 4 conceptos más importantes en lo relativo al Launchpad Designer. A continuación, vamos a profundizar en cada uno de ellos:

Catálogo SAP Fiori

Los catálogos SAP Fiori permiten organizar las aplicaciones Fiori en roles. Dentro de cada catálogo, se incluirán las aplicaciones SAP Fiori disponibles para un determinado Rol ABAP. La asignación de los catálogos a estos roles, se realizará como en otros casos desde la transacción PFCG.

Los catálogos SAP Fiori, así mismo, es donde se configuran las aplicaciones Fiori mediante la creación de Target Mappings y Tiles, traducidos como mosaicos y asignaciones de destino.

Catálogo de SAP Fiori

Grupos SAP Fiori

Desde el Launchpad Designer también es posible crear grupos SAP Fiori. Los grupos, presentan otra forma de organizar los tiles o aplicaciones Fiori, que dota al usuario de la capacidad de personalizar su SAP Fiori Launchpad.

Los grupos permiten agrupar aplicaciones procedentes de diferentes catálogos.

Target Mapping

Es la referencia a la aplicación que va a ser accedida desde SAP Fiori Launchpad. Pueden ser de diferentes tipos según el tipo de aplicación que se quiera enlazar:

  • Aplicaciones Fiori SAPUI5
  • Aplicaciones Fiori configuradas en la LPD_CUST
  • Transacciones
  • URL
  • Web Dynpros

Obviamente según el tipo de aplicación, los parámetros a configurar serán diferentes.

Por ejemplo, para una aplicación Fiori de tipo UI5 deberemos determinar la URL en la que se puede encontrar dentro del árbol de SAP y el ID del componente asociado a esa aplicación.

Aplicación Fiori SAPUI5

No obstante, sea cual sea el tipo de aplicación, siempre se debe determinar el objeto semántico y la acción asociado a esa aplicación.

Estos términos definen la forma de navegar a esas aplicaciones desde SAP Fiori Launchpad.

SAP Fiori Launchpad

Tiles

Con la creación del Target Mapping, no es suficiente para que la aplicación esté disponible en el catálogo en cuestión. Es necesario configurar un tile o mosaico que realmente se visualizará en SAP Fiori Launchpad.

Es importante que este tile tenga el mismo objeto semántico que el Target Mapping para que se consiga realizar la navegación de manera correcta.

En los mosaicos además, se configuran elementos visuales como el icono, título y subtítulo.

Configuración SAP Fiori Launchpad

SAP icon

Configurados estos elementos ya podríamos visualizar la aplicación en cuestión en el SAP Fiori Launchpad.

Launchpad Designer

Con este repaso de los 4 términos más importantes de Launchpad Designer contamos con las herramientas más importantes para empezar a sacar rendimiento a nuestro SAP Fiori.

El SII con SAP: opciones técnicas diferentes para la nueva gestión del IVA

$
0
0

En este artículo queremos explicaros las diferentes opciones que tenemos para implementar en SAP el nuevo SII de la AEAT para la nueva gestión del IVA y otros documentos.

El SII (Suministro Información Inmediato) es un nuevo requerimiento legal puesto en marcha en primer lugar por la Agencia Tributaria Española el 1 de julio de 2017 y que también entrará en vigor en las Haciendas Forales de Álava, Bizkaia, Gipuzkoa y Navarra el 1 de enero de 2018. Básicamente consiste en que las empresas que cumplan determinadas condiciones deben informar periódicamente y de manera automática sobre el IVA de sus facturas, tanto emitidas como recibidas (además de otros tipos de documentos como bienes de inversión, operaciones intracomunitarias, etc.).

AEAT - SII

Este envío automático es posible gracias a los servicios web SOAP publicados por la AEAT y puestos a disposición de las distintas empresas para enviar los diferentes tipos de información de facturación. Estos servicios web describen una serie de estructuras XML que permiten hacer el envío de los distintos documentos.

  • Facturas emitidas
  • Facturas recibidas
  • Operaciones intracomunitarias
  • Bienes de inversión
  • Cobros
  • Pagos
  • Otras operaciones intracomunitarias

Estas estructuras también van a ser utilizadas por las haciendas forales a partir del 1 de enero de 2018.

Para implementar este nuevo requerimiento del SII, SAP ha propuesto dos soluciones basadas en el eDocument Framework, una funcionalidad adaptada a esta cuestión, que también se usa para otras soluciones como la factura electrónica en diferentes países.

  • Full Solution: Solución completa que además del eDocument Framework utiliza el add-on AIF para la generación de los XML a enviar a los servicios web y el componente HCI (HANA Cloud Integration) para efectuar la comunicación vía protocolo SOAP con los servicios web.
  • Basic Solution: Solución básica que cubre únicamente el eDocument Framework. La generación de los XML y la solución técnica para establecer la comunicación con los servicios web SOAP para enviar estos XML no está contemplada.

Por tanto, en lo que a SAP FI y la relación de los documentos financieros corresponde, la solución es clara: eDocument Framework. Pero, en lo que a la solución técnica para enviar la información requeridas por el SII de manera telemática se refiere, ¿qué opciones tenemos? ¿Cuál es la más adecuada?

La clave de este tema es SOAP (Simple Object Access Protocol) que es la naturaleza de los servicios web del SII. Por tanto, las distintas opciones técnicas disponibles en SAP sobrevuelan este concepto y por tanto están basadas en cualquier caso en la capacidad de crear clientes SOAP con los que consumir estos servicios.

Opciones para implementar SII en SAP

  • Clases proxy ABAP: Desde la plataforma ABAP Netweaver es posible crear un cliente SOAP mediante la creación de clases proxy basadas en las estructuras XML definidas para los citados servicios web. Mediante programación y configuración de puertos lógicos, es posible efectuar esta comunicación desde el propio SAP ERP.
  • SAP PI (SAP Process Integration): Organizaciones con necesidades de integración entre diferentes sistemas pueden disponer de este software de integración de SAP, capaz de establecer interfaces entre sistemas de naturaleza tecnológica muy diferente. Este es un caso ideal para implementar a través de SAP PI creando una interfaz síncrona entre SAP ERP y la plataforma SII, reduciendo la necesidad de programación, disponiendo de esta comunicación aislada en un sistema dedicado y con grandes posibilidades de monitorización, seguridad y reprocesamiento de mensajes.
  • HCI (HANA Cloud Integration): Al igual que SAP PI, HCI es una solución de SAP para llevar a cabo integraciones entre sistemas, con la principal diferencia de que es una solución Cloud basada en suscripción. De hecho, esta es la opción que SAP ha elegido para su Full Solution.

Todas estas soluciones deben contar también con las tareas necesarias para configurar los certificados SSL correspondientes al cliente (sociedades para las que se está implementando el SII) y al servidor (endpoint en el que se encuentran los servicios web de las haciendas).

¿Cuál es la mejor opción? Depende de cada caso. No obstante, con este resumen de las opciones técnicas que existen para implementar el SII desde SAP pretendemos ayudar a la hora de decidir cómo llevar a cabo esta implementación.

Esperamos haberos aclarado las diferentes opciones técnicas para integrar el SII y la nueva gestión del IVA con SAP. Recordad que podemos ayudaros con esta implementación y con el mantenimiento de SAP desde Oreka IT. Contactad con nosotros sin compromiso.

Consumir servicios SOAP desde SAP

$
0
0

En ocasiones vamos a necesitar conectar aplicaciones externas con nuestro SAP a través de webservices. En este artículo veremos cómo consumir un WebService SOAP desde SAP.

Para empezar debemos tener en cuenta que, al ser un servicio web, necesitaremos una dirección desde la que obtendremos el WSDL, que es el fichero en el que encontraremos la estructura que deberá tendrá nuestro WebService (WS), en este caso utilizaremos el siguiente:

https://www.webservicex.net/length.asmx?WSDL 


09/04/2018 – Actualización: parece que se que todos los servicios web SOAP de prueba que había publicados en webservicex.net han sido retirados de la web. Añadimos este link a otro WSDL diferente para que pueda probarse el consumo de WS desde SAP. 


Tras conseguir nuestro link al WS y comprobar que el funcionamiento es correcto, y que al entrar a él descarga un fichero WSDL tendremos que realizar los siguientes pasos:

  • Crear un Service-Consumer (SC) (Cliente Proxy).
  • Crear el Logical Port.
  • Crear programa ABAP para consumir Web Service.

 

Crear Service-Consumer (Cliente proxy)

A continuación crearemos el Service Consumer, que usaremos para consumir nuestro servicio SOAP desde SAP.

Para empezar crearemos un paquete desde SE80 (ZARTICULO en este caso) en el que guardaremos nuestro SC.

Crear cliente proxy - Conectar SAP mediante webservices SOAP

Una vez creado el paquete, para crear nuestro Service Consumer tendremos que realizar la siguiente acción:

Click derecho sobre el paquete -> Crear à Enterprise Service.

Nos saldrá a continuación la siguiente ventana, en la que deberemos elegir SC.

Creación de Service Consumer - SAP SOAP

Una vez realizado esto, continuaremos, y nos dará a elegir entre 3 opciones:

  • Backend
  • Enterprise Service Respository
  • External WSDL/Schema

Elegiremos External WSDL/Schema, debido a que nuestro WSDL será importado.

Pasando a la siguiente pantalla, tendremos la opción de elegir de qué manera queremos importar nuestro WSDL. En este caso podemos hacerlo mediante dos métodos:

  • descargar el fichero desde la URL que he dejado anteriormente, y seleccionar la opción de Local File
  • o introducir directamente la URL mediante la opción HTTP Destination.

En este caso utilizaremos la primera opción, aunque ambas son válidas.

Importar WSDL a SAP (SOAP)

Tras realizar esto tendremos que seleccionar el tipo de puerto que queremos usar. Como en este artículo estamos aprendiendo a consumir un servicio SOAP, elegiremos la opción lengthUnitSoap, y continuaremos con el proceso, para llegar al último paso.

Tendremos que elegir el paquete al que va a pertenecer el servicio, la orden en la que lo crearemos, y un prefijo, el cual servirá para que al crear la clase, se cree con ese prefijo. En este caso utilizaremos el prefijo ZART.

Consumir servicios SOAP desde SAP

Por último, y para terminar con nuestro Service-Consumer, clicaremos en Concluir.

Nos aparecerá en la pantalla nuestro Service Consumer, desde la cual podremos editar el nombre por ejemplo, y como podemos comprobar se habrá creado con el prefijo anteriormente elegido. Guardamos y nuestro SC estará terminado.

 

Crear Logical Port (LP)

El Logical Port (LP) nos permitirá llamar al servicio externo. Para crearlo tenemos dos opciones:

  • Desde la propia pantalla anteriormente nombrada. Tras activar nuestro SC, nos aparecerá una nueva opción en el menú, Start SOA Manager.

Llamar a servicio externo desde SAP con Logical Port (LP)

  • La otra opción sería abrirlo desde la TX SOAMANAGER.

Tendremos que seguir los siguientes pasos para la creación de nuestro Logical Port (LP):

Create -> Create WSDL Based Configuration.

Nos pedirá un nombre para el LP. En este caso usaremos ZART_LP y checkearemos la opción de Logical Port is Default (esta opción dejará este puerto por defecto, y a la hora de ejecutar ejecutará el mismo).

En la siguiente pantalla, dependiendo de cómo hayamos creado anteriormente nuestro Service Consumer (desde fichero o mediante HTTP) elegiremos una u otra. En este caso Via File y seleccionaremos el WSDL anteriormente descargado.

Continuaremos hasta que nos salga la pantalla “Transport Binding”. En esta pantalla podremos cambiar distintas cosas, aunque en este caso tal y como viene estará bien configurado y por lo tanto no tenemos que cambiar nada, clicaremos en Finish, y nuestro LP estará creado.

 

Crear programa ABAP

Por último y no menos importante crearemos un programa en la SE80 en el que introduciremos el siguiente código (depende del programa el código será distinto):

REPORT ZART_CONSUMER.
 
 DATA: lv_conv TYPE REF TO zartco_length_unit_SOAP, "Clase proxy (Service Consumer)
 lv_out  TYPE ZARTCHANGE_LENGTH_UNIT_SOAP_OU,       "Método de salida
 lv_in   TYPE ZARTCHANGE_LENGTH_UNIT_SOAP_IN,       "Método de entrada
 int     TYPE i.
 
 
 PARAMETERS: p_valor TYPE i.
 
 TRY.
 CREATE OBJECT lv_conv
 EXPORTING
 logical_port_name = 'ZART_LP'.                     "Nombre de nuestro Logical Port
 CATCH cx_ai_system_fault .
 ENDTRY.
 
 lv_in-from_length_unit  = 'Meters'.
 lv_in-to_length_unit    = 'Centimeters'.
 lv_in-length_value      = p_valor.
 
 CALL METHOD lv_conv->change_length_unit             
 EXPORTING
 input  = lv_in
 IMPORTING
 output = lv_out.
 
 int = lv_out-change_length_unit_result.
 
 WRITE: int.

Lo único que nos queda es ejecutar nuestro programa, y verificar que la conexión y el resultado es correcto.

Así es como se conectan servicios externos con SAP mediante webservices SOAP en diferentes contextos.

En Oreka IT somos especialistas en SAP. Seguro que podemos ayudarte con tu proyecto. ¡Contáctanos!


Transformaciones de XML complejos a ABAP

$
0
0

Los ficheros realizados con lenguaje XML son muy comunes a la hora de intercambiar información entre diferentes sistemas. Es un lenguaje estándar fácil de entender, pero dependiendo de la complejidad del fichero la transformación puede volverse complicada. En este artículo explicaremos cómo transformar la información de un XML de varios niveles a ABAP para poder tratar esos datos.

Para poder explicar el funcionamiento de la transformación utilizaremos un ejemplo. El fichero XML utilizado en el artículo tiene el siguiente formato:

[php]
<DatosReceptoresEf4ktur>
<DatosReceptor>
<RazonSocial></RazonSocial>
<Direccion></Direccion>
<CodigoPostal></CodigoPostal>
<Poblacion></Poblacion>
<Provincia></Provincia>
<Correo></Correo>
<ContactoAdicional></ContactoAdicional>
<CorreoEnvio></CorreoEnvio>
<DescripcionDepartamento></DescripcionDepartamento>
<Departamento></Departamento>
<CIF></CIF>
<DatosContratante>
<CentroAdministrativo>
<CentreCode></CentreCode>
<CentreDescription></CentreDescription>
<RoleTypeCode></RoleTypeCode>
<CodigoEntidadRelacionada></CodigoEntidadRelacionada>
<Name></Name>
<FirstSurname></FirstSurname>
<SecondSurname></SecondSurname>

<Address></Address>

<PostCode></PostCode>
<Town></Town>
<Province></Province>
<Pais></Pais>
<ElectronicMail></ElectronicMail>
<Telephone></Telephone>
</CentroAdministrativo>
</DatosContratante>
</DatosReceptor>
</DatosReceptoresEf4ktur>
[/php]

 

En el fichero habrá varios datos de receptores, y dentro de los datos contratantes podrá haber varios centros administrativos. También puede darse el caso de que un receptor no tenga ningún centro administrativo. Para poder importar los datos lo dividiremos en dos partes:

  • la creación de objetos del diccionario ABAP
  • la creación de la transformación

 

Creación de los objetos del diccionario ABAP

Nuestro objetivo en la SE11 es crear un tipo de tabla que tenga una estructura la cual pueda contener todos los campos que tiene el XML.

Actualizar tipo de tablas para transformaciones XML complejos a ABAP

SAP: estructura XML a ABAP

Si nos fijamos en la imagen el último campo de la estructura es otro tipo de tabla. Este tipo de tabla tendrá que tener una estructura para poder guardar todo lo que hay dentro de las etiquetas “DatosContratante”, es decir, todos los centros administrativos.

SAP: estructura XML a ABAPSAP: estructura XML a ABAP

También, habría que crear, los dominios y elementos de datos necesarios para cada campo, en caso de no poder reutilizar otros ya creados.

Creación de la transformación

Una vez creados todos los objetos necesarios para albergar los datos del XML tendremos que realizar la transformación. Las transformaciones se crean en la transacción STRANS. Al darle al botón crear nos pedirá una descripción y la clase de transformación. La clase que elegiremos será “Transformación Simple”.

SAP: Transformación simple XML

Para crear la lógica de la transformación utilizaremos el modo gráfico pinchando en la varita redondeada en la imagen.

SAP - lógica de transformación simple - XML

Por defecto, nos aparece el elemento “ROOT” que borraremos (click derecho -> delete) para meter la estructura creada por nosotros en la SE11 (click derecho -> Insert new root).

Estructura - root - SAP - XML

De esta manera, se cargará la estructura y podremos arrastrarla a la otra columna para que nos cree la transformación para la plantilla que hemos cargado.

Cargar estructura creada - transformación XML

Prácticamente ya tenemos creada nuestra transformación. Sólo nos falta cambiar algunos elementos para finalizar.

Lo primero será ponerles el mismo nombre a las etiquetas que en el XML. Por ejemplo en el caso de “DatosReceptor” que la etiqueta sale con el nombre “Z……”.

También, el caso de “CorreoEnvio”, que en nuestra transformación la etiqueta tiene el nombre SENTMAIL porque es nombre del campo en la estructura creada en la SE11. Si nos fijamos en el código, veremos que dentro de cada etiqueta tenemos asignado el campo en el que se guardará ese valor.

Otro aspecto a tener en cuenta es que las etiquetas son “case sensitive”, así que hay que escribirlos exactamente igual al XML, controlando que coincidan las mayúsculas/minúsculas.

Antes de los cambios:

[php]
<?sap.transform simple?>
<tt:transform xmlns:tt="https://www.sap.com/transformation-templates" xmlns:ddic="https://www.sap.com/abapxml/types/dictionary" xmlns:def="https://www.sap.com/abapxml/types/defined">
<tt:root name="DATOSRECEPTORESEF4KTUR" type="ddic:ZXMLRECEPTOR_TT"/>
<tt:template>
<DATOSRECEPTORESEF4KTUR>
<tt:loop ref=".DATOSRECEPTORESEF4KTUR">
<ZXMLRECEPTOR_ST>
<DESCRIPTION tt:value-ref="DESCRIPTION"/>

<ADDRESS tt:value-ref="ADDRESS"/>
<POSTCODE tt:value-ref="POSTCODE"/>
<TOWN tt:value-ref="TOWN"/>
<PROVINCE tt:value-ref="PROVINCE"/>
<MAIL tt:value-ref="MAIL"/>
<MAIL2 tt:value-ref="MAIL2"/>
<SENTMAIL tt:value-ref="SENTMAIL"/>
<DEPARTMENTDESCRI tt:value-ref="DEPARTMENTDESCRI"/>
<DEPARTMENT tt:value-ref="DEPARTMENT"/>
<CIF tt:value-ref="CIF"/>
<DATOSCONTRATANTE>
<tt:loop ref="DATOSCONTRATANTE">
<ZCENTROADMIN_ST>
<CENTRECODE tt:value-ref="CENTRECODE"/>
<DESCRIPTION tt:value-ref="DESCRIPTION"/>
<ROLETYPE tt:value-ref="ROLETYPE"/>
<RELATEDENTITY tt:value-ref="RELATEDENTITY"/>
<NAME tt:value-ref="NAME"/>
<FIRSTSURNAME tt:value-ref="FIRSTSURNAME"/>
<SECONDSURNAME tt:value-ref="SECONDSURNAME"/>

<ADDRESS tt:value-ref="ADDRESS"/>
<POSTCODE tt:value-ref="POSTCODE"/>
<TOWN tt:value-ref="TOWN"/>
<PROVINCE tt:value-ref="PROVINCE"/>
<COUNTRY tt:value-ref="COUNTRY"/>
<MAIL tt:value-ref="MAIL"/>
<PHONE tt:value-ref="PHONE"/>
</ZCENTROADMIN_ST>
</tt:loop>
</DATOSCONTRATANTE>
</ZXMLRECEPTOR_ST>
</tt:loop>
</DATOSRECEPTORESEF4KTUR>
</tt:template>
[/php]

 

Por último, como hemos dicho al principio del artículo, puede que algún receptor no tenga centros administrativos. Por lo tanto, no tendrá la estructura a partir de “DatosContratante”. Para que durante la deserialización de la transformación no nos salte el error de que no encuentra esas etiquetas deberemos añadir la siguiente etiqueta al código de la transformación: <tt:d-cond>. Después de los cambios de nombre anteriores y la condición:

[php] <?sap.transform simple?> <tt:transform xmlns:tt="https://www.sap.com/transformation-templates" xmlns:ddic="https://www.sap.com/abapxml/types/dictionary" xmlns:def="https://www.sap.com/abapxml/types/defined"> <tt:root name="DATOSRECEPTORESEF4KTUR" type="ddic:ZXMLRECEPTOR_TT"/> <tt:template> <DATOSRECEPTORESEF4KTUR> <tt:loop ref=".DATOSRECEPTORESEF4KTUR"> <DatosReceptor> <RazonSocial tt:value-ref="DESCRIPTION"/> <Direccion tt:value-ref="ADDRESS"/> <CodigoPostal tt:value-ref="POSTCODE"/> <Poblacion tt:value-ref="TOWN"/> <Provincia tt:value-ref="PROVINCE"/> <Correo tt:value-ref="MAIL"/> <ContactoAdicional tt:value-ref="MAIL2"/> <CorreoEnvio tt:value-ref="SENTMAIL"/> <DescripcionDepartamento tt:value-ref="DEPARTMENTDESCRI"/> <Departamento tt:value-ref="DEPARTMENT"/> <CIF tt:value-ref="CIF"/> <tt:d-cond> <DATOSCONTRATANTE> <tt:loop ref="DATOSCONTRATANTE"> <CentroAdministrativo> <CentreCode tt:value-ref="CENTRECODE"/> <CentreDescription tt:value-ref="DESCRIPTION"/> <RoleTypeCode tt:value-ref="ROLETYPE"/> <CodigoEntidadRelacionada tt:value-ref="RELATEDENTITY"/> <Name tt:value-ref="NAME"/> <FirstSurname tt:value-ref="FIRSTSURNAME"/> <SecondSurname tt:value-ref="SECONDSURNAME"/> <Address tt:value-ref="ADDRESS"/> <PostCode tt:value-ref="POSTCODE"/> <Town tt:value-ref="TOWN"/> <Province tt:value-ref="PROVINCE"/> <Pais tt:value-ref="COUNTRY"/> <ElectronicMail tt:value-ref="MAIL"/> <Telephone tt:value-ref="PHONE"/> </CentroAdministrativo> </tt:loop> </DATOSCONTRATANTE> </tt:d-cond> </DatosReceptor> </tt:loop> </DATOSRECEPTORESEF4KTUR> </tt:template> [/php]

 

De esta manera, si lo que hay dentro de las etiquetas <tt:d-cond> no existe, la transformación lo obviará. No nos saltará ningún error y seguirá con el siguiente receptor. La transformación estaría finalizada, y tan sólo faltaría activarla para poder usarla.

Con lo explicado anteriormente ya tendríamos hecha la transformación del XML para poder pasar la información a ABAP. La forma de poder utilizarla en un report es mediante la sentencia CALL TRANSFORMATION.

 

Configuración de transportes en SAP PO

$
0
0

Uno de los puntos clave en un proyecto de integración a través de SAP PO es el transporte de las interfaces entre diferentes entornos, en especial, cuando la infraestructura de sistemas en la que se esté montando no cuente con CTS+ (Change and Transport System) para llevar a cabo los trasportes.

En este artículo vamos a explicar cómo relacionar Business Systems en SAP PO para que, al efectuar el transporte, se haga correctamente la traducción de los objetos relacionados con esos Business Systems en cada entorno. Esto es un problema común en cualquier infraestructura de integración SAP PO tenga o no sistema de transporte automático.

La herramienta básica para esto es el SLD (System Landscape Directory).

Configuracion de trasnportes SAP PO - System Landscape

Esta herramienta está accesible desde la página principal de SAP PO:

http(s)://dominio:puerto/dir/start/index.jsp

Algunas de las tareas principales de esta herramienta son:

  • Configurar los sistemas técnicos (Technical Systems) conectados a SAP PO a través del Data Supplier.
  • Crear sistemas de negocio (Business Systems) asociados a estos sistemas técnicos y relacionados concretamente con un mandante de estos sistemas (en el caso de sistemas ABAP)
  • Crear productos y Software Components y asignar estos a los sistemas de negocio en los que vayan a ser utilizados.
  • Clasificar los sistemas como sistemas de aplicación o sistemas de integración.

Sistema con rol de Integration Server

Configuracion de transportes SAP PO - Integration server

Sistema con rol de Application Server

Configuracion de transportes de SAP PO - Application system

Además de esto, de cara a establecer las relaciones de transporte es necesario realizar lo siguiente:

Configuración de transportes SAP PO - Business System Group

  1. Agrupar los sistemas en función de su sistema de integración correspondiente.
  2. Establecer las relaciones de transporte entre los sistemas de negocio.

Configuración de transportes SAP PO

Esta configuración de transportes SAP PO, debe existir en todos los entornos para los que se vaya a realizar el transporte, desde desarrollo pasando por integración y producción. De esta manera, todos los objetos que referencien a los sistemas de negocio al transportar objetos del Integration Directory, serán traducidos correctamente y el transporte será satisfactorio.

Siguiendo estos pasos, el momento de pasar a producción las interfaces de SAP PO será mucho más sencillo y seguro.

 

SCP Portal, la evolución de SAP Enterprise Portal

$
0
0

Ya lo íbamos sospechando, pero tras el SAP Teched Barcelona 2018 no cabe duda sobre la fuerte apuesta de SAP por la tecnología cloud y el futuro inminente de las arquitecturas híbridas. Dentro de este escenario, podemos cuestionarnos bastantes cosas, una de ellas es, ¿cuál es el futuro de SAP Enterprise Portal?

Lo cierto es que según parece, SAP no tiene ninguna intención de dar continuidad a este producto y está centrando todos sus esfuerzos en su equivalente en la nube: SAP Cloud Platform Portal. De hecho, 2020 es la fecha fin para los SAP Enterprise Portal en versiones de SAP Netweaver 730 y 740, y 2024 para SAP Enterprise Portal 750.

De hecho, a diferencia de en otros productos de la plataforma Netweaver para los que sí va a haber alguna novedad a corto plazo, para el portal no se prevé ninguna y como comentaba, la recomendación es ir pensando en migrar a SAP Cloud Platform Portal.

¿Por qué SAP Cloud Platform Portal?

Al igual que hasta ahora SAP Enterprise Portal, SAP Cloud Platform Portal se presenta como el punto de acceso central para todo tipo de contenidos SAP y no SAP procedente de distintos sistemas: aplicaciones Fiori, SAP GUI para HTML, aplicaciones ABAP Web Dynpro, informes BEx, Lumira, etc.

De hecho, SAP Cloud Platform Portal se presenta como Content Consumer y ofrece además componentes estándar para publicar contenido de Content Providers como Success Factors, Concur, Ariba, y por supuesto el SAP Fiori Content que es el contenido Fiori para el portal en la nube que es posible instalar a partir de una determinada versión del backend tanto on premise como on cloud.

SCP Portal - Landscape overview in details

La configuración del contenido es más simple que en el caso de las iviews para las que cada vez hay que rellenar más y más propiedades.

Por supuesto es posible configurar Single Sign On (SSO) para no tener que autenticar al usuario más que una vez para todos los sistemas.

Uno de los puntos débiles de SAP Enterprise Portal era su muy limitada capacidad de diseño. Primero acostumbrados a layouts basados en masthead + top level navigation y luego ya algo más modernizado con el Portal Fiori Launchpad.

Con SAP Cloud Platform Portal es posible crear 3 tipos de layouts:

  • Fiori Launchpad: Layout basado en tiles equivalente al SAP Fiori Launchpad ABAP.
  • Freestyle: Layout totalmente personalizable para crear portales corporativos, usando widgets, miniaplicaciones, etc. Da mayor libertad a los diseñadores y sin ninguna duda se pueden conseguir resultados mucho más personalizados y corporativos.

SCP Portal - tipos de layout 1

  • Híbrido (Fiori Launchpad embebido en un portal freestyle)

Dentro del layout freestyle se proponen algunas plantillas de las que es posible partir para crear ciertos tipos de portal: portal de administradores, portal para proveedores, portal para ventas, incluso SAP trabaja en el EmployeeWorkplace totalmente integrado con SuccessFactors que permitirá configurar de una manera sencilla un portal del empleado. Es lo que podríamos considerar la evolución directa del Employee Self Service.

SCP Portal - Portal empleado

Por supuesto, SAP Cloud Platform Portal está basado en roles, sin embargo, su creación y configuración se aproxima más al concepto de roles ABAP, catálogos y grupos Fiori que ya conocemos, que a los roles de portal del SAP Enterprise Portal actual.

De cara a plantear una migración de un portal (EP) a la nube, debemos tener en cuenta los siguientes aspectos.

  • Las iviews de tipo Web Dynpro Java NO están soportadas en SAP Cloud Platform Portal, sin embargo, es posible utilizar SAP Enterprise Portal 750 como Content Provider de este tipo de contenidos mientras se migran a otra tecnología.
  • El KM (Knowledge Management) puede sustituirse con la solución en la nube SAP Document Center. Es posible usar la herramienta Egnyte Connect para migrar el contenido de un repositorio a otro.
  • Si se utiliza la UWL (Universal Work List) en EP, las tareas pasan a gestionarse desde la aplicación estándar Fiori My Inbox.
  • Para versiones SAP Netweaver 7.30 en adelante, hay una herramienta de migración de SAP Enterprise Portal.

Como comentaba al principio, SAP apuesta fuerte por las soluciones cloud, pero el camino es largo. Por esto, SAP Cloud Platform Portal puede ser un buen punto de partida para dar ese salto a la nube y aprovechar la potencia que ofrece como punto de acceso central tanto a nuestros sistemas de negocio on-premise (SAP ECC, S4HANA, SAP BW…) como a nuevas soluciones en la nube (SuccessFactors, Ariba…) que vayamos incorporando a la infraestructura de nuestros sistemas.

Esperamos que te haya resultado interesante este artículo. Si tienes cualquier consulta, puedes dejarnos un comentario o con nuestro equipo especializado de consultores.

La entrada SCP Portal, la evolución de SAP Enterprise Portal se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Diez razones para migrar a SAP PO

$
0
0

En el anterior artículo hablábamos de SAP Process Orchestration (PO) y sus características básicas. Aquí hablaremos de las ventajas de una migración a SAP PO.

SAP PO es un paquete de instalación completo que incluye un ESB, un motor de reglas de negocio y un motor de procesos de negocio en una única solución integrada de software basada en una pila única Java.

Incluye SAP PI y SAP Composition Environment (CE) y, por lo tanto, encapsula el conjunto de funciones de ambos. Con SAP PO las organizaciones pueden comunicarse fácilmente a través de diferentes sistemas (internos y externos) mediante un set de estándares y protocolos de integración completo y bien establecido.Diez razones para migrar a SAP PO (2)

Además, SAP PO incluye todas las herramientas de desarrollo y administración de BPM y BRM para ayudar a las organizaciones a diseñar, modelar, ejecutar, monitorizar, gestionar y analizar procesos y reglas de negocio usando una única plataforma. Esta consolidación trae consigo una mejora del rendimiento y un aumento de la eficiencia a la vez que reduce el coste total de propiedad (TCO) de manera significativa.

Es importante destacar que, al ser SAP PO una instalación basada únicamente en Java, todas las funcionalidades ABAP han desaparecido y han sido sustituidas por alternativas equivalentes en Java.

Diez razones para migrar a SAP PO (1)

Razones para la migración a SAP PO:

  1. Se simplifica el escenario IT al estar basado en una única pila Java. Se evita el inconveniente de necesitar una arquitectura que soporte dos servidores diferentes, ya que la comunicación Java-ABAP tiene impacto negativo sobre el rendimiento y la sostenibilidad.
  2. La migración a una arquitectura Java aumenta el rendimiento a todos los niveles.
  3. Con PO tenemos acceso a BPM, que facilita la integración y los flujos de trabajo, automatizando donde sea posible y solicitando intervención del usuario en los pasos que necesitan aprobación o datos adicionales.
  4. Reglas de negocio nativas que permiten flexibilizar los procesos por parte de los usuarios de negocio con SAP BRM.
  5. Mejora de la experiencia de usuario – Gracias a la integración de Fiori, se pueden crear para PO interfaces de usuario en HTML5 para ser visualizadas desde ordenadores, tabletas o teléfonos.
  6. Proporciona todas las herramientas necesarias, lo que permite desarrollar soluciones completas con mayor facilidad y eficacia.
  7. Facilidad de configuración y monitorización. Al tener todas las herramientas en la misma plataforma solo hay que preocuparse de mantener y configurar un único servidor de aplicaciones.
  8. Java Gateway permite fácil integración con servicios de SAP Fiori.
  9. Preparado para la nube. Los iFlows usados en el sistema de PO utilizan artefactos compatibles con HANA Cloud Integration, lo que permite la reutilización del trabajo realizado para la definición de interfaces y mapeos.
  10. Preparado para HANA. SAP PO permite ejecutar el middleware directamente en HANA, proporcionando información en tiempo real del sistema y permitiendo la participación en los procesos y eventos de la integración.

Por último, recordemos que SAP PI 7.4 es la última versión de PI con doble pila y que el soporte para la misma termina en 2020. Al menos hasta 2022, la versión 7.5 soportará las pilas separadas, pero es importante dejar de usar ABAP en las nuevas integraciones de sistemas PI para ir adelantándose al proceso de la migración.

Esperamos que este artículo te haya sido de interés. Puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro departamento de desarrollo e integración.

Departamento de Desarrollo & Integración

La entrada Diez razones para migrar a SAP PO se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

SAP Screen Personas

$
0
0

En este artículo vamos a hablar sobre otra de las novedades de SAP dentro de la estrategia SAP Fiori UX: SAP Screen Personas. SAP Screen Personas es una herramienta de IU que nos permite mejorar la productividad de los usuarios mediante la personalización y simplificación de las pantallas, sin necesidad de modificar el funcionamiento back-end.

Gracias a esa personalización, podremos diseñar pantallas dirigidas a cubrir las necesidades de un usuario o grupo de usuarios, evitando grandes costes de programación y reduciendo tiempos de desarrollo.

Además, con SAP Screen Personas podremos adaptar las pantallas de una forma sencilla a dispositivos móviles, sin necesidad de crear aplicaciones IU5 desde cero.

SAP Screen Personas se fundamenta en estas tres herramientas para mejorar la productividad:

  • Editor de pantallas, con él podremos ocultar campos que los usuarios no utilicen, combinar la información dividida en diferentes pestañas en una única vista. Realizar cambios en las pantallas para hacerlas más atractivas para el usuario.
  • Mediante los scripts, podremos automatizar las tareas que los usuarios realicen repetidamente.
  • Los temas, nos permiten cambiar la apariencia de todas las pantallas al mismo tiempo, dándoles un estilo coherente entre ellas.

Los beneficios que SAP Screen Personas puede tener sobre una empresa son los siguientes:

  • Los procesos de negocio se simplifican al condesar la información de estos en pantallas más simples.
  • La toma de decisiones se acelera al facilitar la introducción de los datos en los sistemas permitiendo tener la información en tiempo real más rápidamente.

Próximamente, tendréis disponible un videotutorial explicando cómo crear una variante para personalizar vuestras pantallas.

Esperamos que este artículo te haya servido de ayuda. Recuerda que puedes dejarnos tus dudas en comentarios o ponerte en contacto con nuestro departamento de UX/I.

Área UX/I

 

La entrada SAP Screen Personas se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Viewing all 72 articles
Browse latest View live