Aunque el modelo de interfaz de usuario establecido por Douglas Engelbart, presentado en el anterior artículo sobre la historia de la interfaz hombre máquina, ha sido un rotundo éxito, como respaldan sus más de 50 años de trayectoria, no es ni mucho menos el último paso en lo que se refiere a formas de interacción hombre-máquina.

En este artículo sobre la evolución Interfaz de Usuario, nos vamos a centrar en el modelo que más repercusión mediática está teniendo, aunque ni mucho menos es el único. Nos referimos al Natural User Interface (NUI).

Natural User Interface se podría definir como un conjunto de métodos y mecanismos para que la conexión entre el humano y la máquina se produzca de la forma más intuitiva posible. Se podría decir que es una respuesta al modelo anterior, en el que el usuario tenía que hacer un esfuerzo en cuanto a ergonomía y fisionomía se refiere para comunicarse con la máquina. Lo que propone Natural User Interface es eliminar en la medida de lo posible el “hardware intermediario”, esto es el ratón y el teclado, y aprovecharse de los comportamientos naturales del ser humano para mediar con la máquina. Los comportamientos que se podrían asociar a NUI incluirían:

• Movimientos y gestos naturales
• Lenguaje verbal y no verbal
• Gestos faciales
• Trayectoria del ojo humano

Además, Natural User Interface incluye otros comportamientos humanos no tan visibles, como pueden ser los aspectos relacionados con la neuroergonomía. Estos contemplan cambios inconscientes o no voluntarios en el estado del cuerpo (sueño, temperatura, respiración, dilatación de la púpila, tasa cardiaca).
A día de hoy, el ejemplo más popular en cuanto a desarrollo embrionario de NUIs se refiere posiblemente sea el dispositivo Kinect desarrollado por Microsoft para la Xbox 360. La idea es eliminar el controlador clásico de videojuegos y usar los gestos espaciales del jugador como input. A continuación, un vídeo de demostración sobre las capacidades de este no-controlador:

Pinche aquí para ver el vídeo

Está claro que todavía queda mucho camino que recorrer para llegar al nivel de las NUIs de ciencia-ficción que se muestran en películas como Minority Report o Iron Man, pero pensamos que vamos por el buen camino. Otra cosa, es el uso que decidamos darle…

Esta es por el momento la tendencia de que sigue la evolución Interfaz de Usuario.

En un artículo anterior describimos el elemento UI Date Navigator. Este elemento ha sido modificado para la versión 7.4 de SAP NetWeaver, por lo tanto ciertas partes del artículo mencionado han quedado obsoletas para las nuevas versiones. A continuación se describen las modificaciones para poder seguir utilizando este elemento UI Date Navigator.

Las propiedades y eventos del propio elemento no han cambiado como tal. Sin embargo, lo que si se ha modificado ha sido el subelemento DateNavigatorMarking, que se encargaba de dar color a los días del calendario. Como antes, se debe añadir un subelemento de este tipo y también se define un nodo (de cardinalidad 0..n ó 1..n), pero en este caso se ha modificado el atributo Category por el atributo DaySemantics.

Si recordamos, el atributo antiguo debía tener un binding con el tipo WDY_MD_DATE_MARKING_CATEGORY, que permitía dar cuatro tipos de colores al calendario. La nueva propiedad, que se debe ligar al tipo WDUI_TABLE_CELL_DESIGN, permite utilizar cualquier color definido en el estándar de Web Dynpro for Abap. Además, se ha añadido la propiedad tooltip, con la que se puede dar una explicación a cada día del calendario, que se mostrará al pasar el cursor por el día correspondiente.

A parte de esta modificación en el DateNavigatorMarking, se ha eliminado la posibilidad de adjuntar una leyenda al calendario del tipo DateNavigatorLegend. Si se quiere añadir una leyenda al calendario, habrá que hacerlo con el elemento general para las leyendas, que es el Legend.

A este elemento se le pueden añadir dos tipos de subelementos. El primero es el Legend_Item, que sirve para poner una línea en la leyenda, explicando un color o un símbolo. Las propiedades que se le puede dar a este elemento son:

• ImageSource: para indicar un icono o imagen a explicar.
• Semantics: para indicar un color a explicar.
• Striped: para indicar si el color es a rayas o no.
• Text: para escribir el texto de la explicación.
• Tooltip: por si se requiere una mayor explicación, que aparezca en un cuadro al poner el cursor por encima de la línea.

Con este elemento podemos poner a mano uno a uno las líneas de la leyenda. El segundo elemento que admite es el Multiple_Legend_Item, que permite con un solo elemento meter varias líneas a la leyenda. Para ello se debe crear un nodo de contexto (cardinalidad 0..n ó 1..n), con los atributos que se quieran rellenar de los mencionados en la lista anterior. Después, si el contexto se rellena con varias líneas, estas serán las que aparezcan en la leyenda. Una vez creada la leyenda, en la propiedad LegendID del calendario habrá que indicarle el ID de la leyenda recién creada.

Con estos cambios se puede seguir usando este elemento UI Date Navigator para Web Dynpro for Abap , con la mejora de que ahora se permiten muchos más colores en los días a resaltar.

En oreka IT queremos informáticos o ingenieros titulados buscando su primer empleo y que puedan sorprendernos. Necesitamos gente con mucho talento y que dominen inglés y euskera. ¿Das el perfil?

Ofrecemos formación gratuita en programación SAP Abap (Curso de 350 horas, de Abril a Junio en Vitoria-Gasteiz). Incorporación a plantilla y desarrollo profesional en el mundo de la consultoría SAP.

Bere lehenengo enplegua bilatzen ari diren eta gu harritzeko kapaz diren, tituludun informatiko edo ingeniariak nahi ditugu. Talentu askoko, eta ingelesa eta euskara menperatzen duen jendea behar dugu. Profila daukazu?

Gure Eskaintza

SAP Abap programazioan dohaineko heziketa (350 orduko kurtsoa, Vitoria- Gasteizen, apiriletik ekainera). Lan- taldera sartzea eta SAP aholkularitzan garapen profesionala.

Uno de los aspectos clave a la hora de desarrollar aplicaciones SAPUI5 es la necesidad de acceder a los diferentes elementos de la aplicación desde cualquier punto de la aplicación.

En artículos anteriores ya hablábamos del patrón Modelo-Vista-Controlador usado en SAPUI5 y vimos los ficheros de los que constan las aplicaciones SAPUI5 que se corresponden con cada uno de los componentes en los que se basa este patrón.

Es por tanto, sencillo darse cuenta de que en cualquier momento puede ser necesario por ejemplo, obtener desde un controlador el valor de un control representado en una determinada vista (por ejemplo el nombre de usuario) o acceder a un determinado modelo para utilizar sus datos desde una vista para, por ejemplo rellenar un combobox. ¿Cómo conseguimos conseguir esta información en las aplicaciones  SAPUI5?

La respuesta a esta pregunta es: mediante las funciones de acceso al core.

Diferenciamos entre las siguientes tres funciones:

sap.ui.getCore()

Devuelve una instancia de la propia aplicación o core. En el core se puede guardar información global, almacenar modelos entre otras cosas. A nivel de aplicación sap.ui.getCore() es la más potente e interesante a la hora de desarrollar una aplicación SAPUI5.

A partir de esta instancia obtenida se puede acceder a otros objetos de la aplicación utilizando sap.ui.getCore().byId(“ID”), para como hemos dicho antes como ejemplo, obtener el nombre usuario introducido en un campo de un formulario. A continuación se muestra un ejemplo:

Vista: Definimos en la vista un campo de tipo Input para introducir el nombre con ID “miNombre” y un botón que cuando es pulsado ejecuta la función “onPress” definida en su controlador.

createContent : function(oController) {
return new sap.m.Page({
title: "Title",
content: [
new sap.m.Input("miNombre",{
type: sap.m.Input.Text
}),
new sap.m.Button("miBoton", {
text: "Pulsame",
type: sap.m.ButtonType.Accept,
press: oController.onPress})
] });
}

Controlador: Define la función “onPress” mostrando una alerta que informa sobre quién ha pulsado el botón en función del nombre de usuario introducido en el campo.

onPress:function(){
var miNombre = sap.ui.getCore().byId("miNombre");
alert("Boton pulsado por " + miNombre.getValue() + "!!");
}

jQuery.sap.domById()

Esta función devuelve elementos del DOM de Javascript. Funciona igual que la función document.getElementById(“ID”). Se puede utilizar para manipular el DOM o para asignar eventos.

Controlador: Obtiene la referencia del campo de texto con ID “miNombre” y le asigna funcionalidad al evento “onmouseover”.

onPress:function(){
var miNombreDOM = jQuery.sap.domById("miNombre");
miNombreDOM.setAttribute('onmouseover','alert("hover")');
}

jQuery.sap.byId()

Devuelve un objeto jQuery correspondiente a elementos del DOM de Javascript. Funciona igual que los selectores jQuery(“#ID”) o $(“#ID”). Es muy útil para llevar a cabo efectos visuales colores, efectos, tamaños de letras etc…

Controlador: Modifica el color del elemento cuyo ID sea miNombre y sus hijos.

onPress:function(){
jQuery.sap.byId("miNombre *").css("color","red");
}

Con estas tres funciones de acceso al core ya podemos acceder a los diferentes elementos de nuestra aplicación SAPUI5.

¿Qué es programar bien? Antes de responder a esta pregunta, tal vez debiéramos definir qué es para nosotros “programar bien”, porque seguro que cada uno tenemos una idea diferente sobre este concepto.

Para algunos un programa bien hecho es cualquiera que haga lo que tiene que hacer, para otros es el que menos tiempo tarde en hacerlo, o el que menos recursos necesite…

Parece claro que no hay una única respuesta a esta pregunta, así que vamos a aclarar a que nos referimos con “programar bien” aquí. Todos los factores mencionados son, por supuesto, muy importantes y a tener en cuenta, pero hay otro que muchas veces se nos olvida, y es de lo que vamos a hablar en este artículo, de cómo hacer que nuestros programas sean legibles por todos, ya que, estos consejos nos pueden ahorrar mucho tiempo y esfuerzo en el día a día.

Un programa bien hecho tiene que ser fácil de entender, tiene que poder seguirse de un vistazo, sin necesidad de invertir mucho tiempo en ello.

Buenas prácticas en programación: Utilizar nombres claros

Todos hemos visto programas en los que los nombres de las variables, los métodos o las funciones no tienen ninguna relación aparente con su funcionalidad. Y, aunque es cierto que resulta más cómodo llamar a una variable nm o tl, lo más probable es que nadie (incluidos nosotros mismos pasado un tiempo) entienda a que hacen referencia. Pero, si utilizamos numero_de_mes o tipo_de_libro, todos sabremos de lo que estamos hablando. En el siguiente ejemplo se pueden ver claramente las ventajas de utilizar nombres claros.

FORM calc_d.
IF nm = '02' AND tl = 'PO'.
pd = 25.
ENDIF.
IF nm = '06' AND tl = 'CF'.
pd = 15.
ENDIF.
IF nm = '09' AND tl = 'LE'.
pd = 20.
ENDIF.
ENDFORM.

Con este código no sabemos lo que estamos haciendo, ni la subrutina ni las variables tienen nombres que aclaren su funcionalidad. El siguiente, en cambio, empieza a aclararnos qué hace la subrutina y que valores guardan nuestras variables.

FORM calcular_descuento.
IF numero_de_mes = '02' AND tipo_de_libro = 'PO'.
porcentaje_de_descuento = 25.
ENDIF.
IF numero_de_mes = '06' AND tipo_de_libro = 'CF'.
porcentaje_de_descuento = 15.
ENDIF.
IF numero_de_mes = '09' AND tipo_de_libro = 'LE'.
porcentaje_de_descuento = 20.
ENDIF.
ENDFORM.

Aprender a programar bien: Evitar el uso de literales

Una vez que hemos conseguido que las variables tengan nombres que podamos entender, otra clave a tener en cuenta es la utilización de literales. En el ejemplo anterior utilizábamos ‘06’ y ‘CF’ directamente en el código, y, sí, el número de mes se puede intuir por el contexto (06 – Junio), pero, ¿qué significa CF? Justo son estas dudas las que queremos evitar, y, para ello, una manera de programar bien es la utilización de constantes. Nos llevará más tiempo de primeras, pero hará que nuestro código sea más entendible y más fácilmente modificable.

A continuación hemos sustituido los literales del ejemplo anterior por constantes más claras y explicativas.

CONSTANTS: febrero    TYPE string VALUE '02',
junio      TYPE string VALUE '06',
septiembre TYPE string VALUE '09'.
CONSTANTS: policiaco       TYPE string VALUE 'PO',
ciencia_ficcion TYPE string VALUE 'CF',
libro_escolar   TYPE string VALUE 'LE'.
FORM calcular_descuento.
IF numero_de_mes = febrero AND tipo_de_libro = policiaco.
porcentaje_de_descuento = 25.
ENDIF.
IF numero_de_mes = junio AND tipo_de_libro = ciencia_ficcion.
porcentaje_de_descuento = 15.
ENDIF.
IF numero_de_mes = septiembre AND tipo_de_libro = libro_escolar.
porcentaje_de_descuento = 20.
ENDIF.
ENDFORM.

Aquí sí que se aprecia claramente lo que nuestro código hace, de un vistazo, y sin tener que intuir nada. Esta es la diferencia de seguir buenas prácticas a la hora de programar, o no.

Antes de seguir para un momento y vuelve a mirar el código del que partíamos, con dos cambios sencillos hemos conseguido que un código ininteligible sea muy sencillo de seguir.

Cómo programar bien: Organizar el código

Otro de los hábitos más comunes entre muchos programadores es escribir todo el código seguido, sin separarlo u organizarlo de ninguna manera. Y esto también complica mucho su lectura, porque no sabremos qué se está haciendo en cada sitio, ni sabremos a donde ir cuando tengamos que hacer alguna modificación.

En ABAP tenemos varias herramientas para evitar esto: funciones, subrutinas, métodos, clases… La cuestión es utilizarlas para que nuestro código quede bien estructurado y su compresión sea más fácil.

Un buen ejemplo de esto lo podemos encontrar en la serie de artículos sobre Procesamiento de XML en ABAP, en el que se declaran tres subrutinas con objetivos muy claros y que organizan tanto de forma visual como lógica, todo nuestro código. Así, en vez de tener una llamada a una función seguida de un LOOP y un INSERT, todo del tirón, tenemos tres procesos bien definidos (Leer el XML, Transformar el XML y Guardar los datos).

Consejos para programar bien: Conclusión

Aunque a priori nos cueste más trabajo, siguiendo algunas pautas sencillas y cambiando un poco nuestros hábitos, podemos hacer que nuestro código sea mucho más entendible y utilizable por todos. Así, además de alegrarle el día al que tenga que leer nuestros programas podremos decir que sí, que  sabemos programar bien.

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

¿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.

En ocasiones, desde el punto de vista de un responsable, es interesante conocer qué opina el resto de empleados acerca de un tema en concreto. Una forma de llevarlo a cabo es preparar una encuesta de satisfacción personalizada.

Con la herramienta SAP SURVEY, SAP nos brinda la posibilidad de conocer las opiniones de nuestros empleados, con la posibilidad de personalizar y enviar por email cuestionarios a los usuarios y, posteriormente, visualizar las respuestas que han rellenado.

Transacción SAP SURVEY.

Su gran particularidad es que está integrado en el propio sistema, por lo que, entre sus múltiples posibilidades, se pueden enviar los resultados a BW y evaluarlos mediante sus propios métodos. A su vez, gracias al uso de una Biblioteca o Librería de aplicación, podemos personalizar aún más la encuesta de satisfacción personalizada, permitiéndonos, por ejemplo, alterar preguntas según qué usuario sea el receptor de la encuesta, validar campos, etc.

Survey Cockpit

Al entrar en esta transacción podemos crear o seleccionar una encuesta existente y así accederemos a la “Survey Cockpit“, que se definiría como la pantalla principal de control desde la que se gestiona todo lo referente a las encuestas.

En esta pantalla, a la izquierda, tendremos definidos los destinatarios o grupos de ellos, que van a ser objetivo de esta encuesta de satisfacción personalizada y, a la derecha, una previsualización del cuestionario a enviar, o, si ya ha sido respondido, podremos ver qué contestaciones han dado. También podemos ver el estado en el que se encuentra la encuesta (enviada, respondida, etc). Si el usuario receptor existe en nuestro entorno de SAP, no es necesario rellenar ni sus datos ni su e-mail, ya que automáticamente los busca en el sistema una vez introducido su uname.

Para comenzar una encuesta primero hay que formular la serie de preguntas que nos interesa que sean respondidas. Se crea mediante el botón “Nuevo” y puede tener distintos formatos: desde cuadros de texto en los que el usuario ha de escribir la respuesta, a múltiples opciones de las que se ha de seleccionar una o varias (checkbox, radiobuttons, etc).

Envío del cuestionario

Una vez se ha seleccionado la encuesta y el grupo destinatario que va a ser objetivo de esta, al pulsar “Enviar cuestionario”  da comienzo y se envía mediante un email a los integrantes del grupo destino. Cuando el receptor está de acuerdo con las respuestas introducidas, con pulsar el botón “Enviar cuestionario”  se enviará de vuelta y ya estará listo para ser analizado por su responsable mediante la Survey Cockpit.

Gracias a su facilidad de uso, la transacción SAP SURVEY es una intuitiva herramienta para tener control sobre las opiniones que tienen los usuarios acerca de un tema determinado. Además, debido a su gran profundidad, la encuesta de satisfacción personalizada puede ir desde la simpleza más absoluta hasta la complejidad que se desee.

Si en artículos anteriores, parametrización de viajes parte 1 y parametrización de viajes parte 2, aprendíamos a parametrizar los datos de un viaje en SAP HCM, En este artículo se explicará cómo visualizar los datos del clúster TE de viajes.

Para ello accederemos a la transacción PRTE (programa: RPCLSTTE)

Como vemos, podemos filtrar por diferentes criterios; así como por número de personal, número de la hoja de gastos, fechas del viaje…

Una vez seleccionado los criterios necesarios para la ejecución y ejecutemos el programa obtendremos un listado de los viajes resultantes y todas sus versiones:

En este caso en las columnas “P.VS” y “H.VS” vemos que todos los valores son 99; eso indica que la hoja de gastos no ha tenido modificaciones después de haberse transferido a nómina o FI. En el caso en el que una hoja de gastos se haya transferido y posteriormente se haya modificado, se creará automáticamente una nueva versión, para que SAP pueda calcular las diferencias entre ambas versiones.

Tablas del cluster TE de viajes

Si seleccionamos una de las líneas y hacemos doble clic o pinchamos sobre  obtendremos las diferentes tablas que conforman el clúster de viajes. A continuación se hace un resúmen de las tablas más importantes:

• PTRV_HEAD: En esta tabla tendremos los datos relacionados a la cabecera del viaje, así como la variante de reglamentación del viaje, el tipo de esquema seleccionado…
• PTRV_PERIO: En esta tabla tendremos los datos relacionados al periodo en el que se ha liquidado el viaje, área de nómina correspondiente al empleado…
• BELEG: En esta tabla veremos una entrada por cada clase de gasto introducida en la hoja de gastos. Por cada una de ellas veremos los datos de importe, fecha, tipo de cambio…
• TEXT: En esta tabla encontraremos los comentarios introducidos a nivel de hoja de gastos
• KMVER: Aquí veremos los datos relacionados al kilometraje
• AEND: En esta tabla veremos todos los estados por los que ha ido pasando esta hoja de gastos
• STATU: En esta tabla veremos el estado actual de la hoja de gastos
• KONTI: Esta tabla contendrá las órdenes de imputación que el empleado haya introducido en la hoja de gastos. Mediante otra serie de tablas de costes podremos ver exactamente la imputación si es a nivel de hoja, de clase de gasto o de kilometraje. En el caso en el que esta tabla esté vacía significará que se contabilizará contra las órdenes del infotipo 0027 subtipo 02.
• ROT: Una vez liquidada la hoja de gastos se rellena esta tabla, haciendo la conversión entre clase de gasto / CC-nómina. Estos datos serán los que posteriormente se transfieran a nómina o FI.

Como vemos, es sencillo visualizar los datos del cluster de viajes, ya que una vez que accedemos a la transacción PRTE, basta con seleccionar los criterios de búsqueda que más se ajusten a nuestras necesidades. Estos datos pueden ser muy útiles en el módulo SAP HCM.

En Web Dynpro for Abap (WD4A), a la hora de definir el contexto de una aplicación Web Dynpro tenemos que tener en cuenta cómo queremos definir los diferentes nodos para poder mostrar y recoger información del usuario. Por esto es muy importante definir correctamente las propiedades de los nodos del contexto. A continuación se explican las diferentes propiedades que podemos modificar.

Interface Node

En el artículo reutilización de componentes comentamos la posibilidad de reutilizar los componentes que creamos, y que los nodos pueden ser parte de la interfaz del componente reutilizado. Al marcar esta propiedad hacemos que este nodo sea visible para un componente que reutilice este contexto.

Input Element

En WD4A, esta propiedad es utilizada en la reutilización. Si la propiedad Input Element también está seleccionada, el nodo debe estar también mapeado al nodo definido en el Component Controller padre. Esto sirve para poder modificar el contexto en el componente padre.

Dictionary Structure

A un nodo se le puede relacionar con una estructura o tabla definida en el Diccionario de Datos. De este modo, los atributos de este nodo tendrán las mismas propiedades que en el diccionario. El problema de asignar esta propiedad, es que a este nodo únicamente se podrán meter atributos de esta estructura.

Cardinality

En tiempo de ejecución, las estructuras se rellenan con valores, y cada atributo puede tener varios valores (tablas). Para especificar cuántos valores puede contener un nodo, se usa la propiedad cardinality:

• .1: Cero o un elemento permitidos (estructura).
• .n: Cero o más elementos permitidos (tabla).
• .1: Exactamente un elemento permitido (estructura).
• .n: Uno o más elementos permitidos (tabla).

Por lo tanto, un nodo que tenga de cardinalidad máxima 1, es como una estructura ABAP, y un nodo que tenga n, será como una tabla interna.

Selection

Esta propiedad indica el número de elementos de la colección que pueden ser seleccionados. Habrá que tener en cuenta la propiedad anterior para definir esta, ya que no se podrá decir que se puedan seleccionar n elemento en una estructura.

Lead Selection

Un elemento de una colección de un nodo (tabla) puede ser seleccionado por un valor basado en índices. Exactamente un elemento de la colección del nodo puede ser marcado como Lead Selection. El Lead Selection del contexto de un nodo apunta bien a un solo elemento del nodo, ó, si no hay elemento seleccionado, tiene el valor de la constante: IF_WD_CONTEXT_NODE=>NO_SELECTION.

El valor del Lead Selection puede ser automáticamente inicializado con la propiedad Initialize Lead Selection.

Si el Lead Selection tiene valor:

• Se pueden utilizar métodos especiales para acceder al Lead del nodo en el código del controlador.
• Elementos del interfaz de usuario pueden ser asignados a los atributos de este elemento.

Singleton

En un contexto como el de la imagen en el que existe un nodo FLIGHTS con cardinalidad 0..n que contiene otro nodo BOOKINGS, con cardinalidad 0..n, la propiedad Singleton afecta de manera crítica a la relación entre el nodo FLIGHTS y el nodo BOOKINGS.

Si el nodo BOOKINGS tiene la propiedad Singleton con valor ‘false’, por cada elemento en la colección del nodo padre, existirá una instancia del nodo hijo BOOKINGS.

En cambio si el nodo BOOKINGS tiene la propiedad Singleton marcada, no importará cuantos elementos estén presentes en el nodo padre, siempre existirá una sola instancia del nodo hijo BOOKINGS, por lo que la colección BOOKINGS será Singleton en tiempo de ejecución.

Ventajas de nodos Singleton:

• Acceso a datos ‘Lazy’. Los datos son creados cuando son realmente necesitados. Esto significa que si los datos no se requieren, el nodo hijo permanece sin procesar. También implica que colecciones dependientes no son creadas automáticamente para todos los elementos del nodo padre. La creación de la colección de nodo dependiente es retardada hasta el punto que el elemento relacionado de la colección padre obtiene el Lead Selection.
• Menor consumo de datos.

Inconvenientes de nodos Singleton:

• Mayor número de accesos a base de datos. Por lo que se puede ralentizar la ejecución de la aplicación.

Este es un pequeño resumen de la propiedades de los nodos del contexto más importantes, de Web Dynpro For Abap.

Vamos a realizar una explicación de cómo SAP gestiona los materiales y pedidos de consigna en SAP MM, es decir, del proceso que sigue la consignación en compras.

En la gestión de stocks en consignación, el proveedor suministra materiales y los almacena en sus dependencias. El proveedor queda como el propietario legal del material hasta que se tomen los materiales del almacén de artículos en consignación.

Es en este momento que el proveedor solicita el pago. El vencimiento de la factura se produce en períodos de tiempo prefijados. Además, puede acordar con el proveedor que asumirá personalmente la propiedad del material restante en consignación tras un determinado período de tiempo.

Registro de materiales

Una de los primeros requisitos dentro de los datos maestros será tener bien definido el dato del material que se quiera tener en consigna (MM01 – Crear maestro materiales), material en consignación.

En este punto dentro de la pestaña “Planificación de necesidades 2″ deberemos alimentar el campo clase de aprovisionamiento especial con 10 (Consignación).

Este tipo de aprovisionamiento especial de consignación conlleva que automáticamente la posición del pedido de compras que se haga en el futuro; esté marcada como posición de pedido de consigna (C).

Registro info

Otro de los datos maestros que debemos informar es la creación de un registro info de tipo consignación con el proveedor.

Se creará un registro info (ME11 – Crear Registro info) de tipo subcontratación.

Y ahí se añadirán los datos correspondientes al acuerdo entre la empresa y el proveedor de consignación.

Pedido de consigna

Llega el momento del aprovisionamiento del material y nos debemos crear el pedido de compras (ME21N – Crear pedido de compras).

En el caso de haber informado correctamente los datos maestros (Registro de material y registro info); al crear el pedido contra el material subcontratado, el pedido avisará para marcar como consigna (Tipo de posición – C)

Ya tenemos la base para comenzar con el aprovisionamiento de material y seguir con la consignación en compras. En el siguiente artículo, aprenderemos a realizar la entrada de mercancía asignándosela al pedido de consigna y liquidar así la consignación en compras.

En el artículo anterior, aprendimos a crear un pedido de consignación en SAP MM, partiendo de la creación de registo de materiales y registro info.

En este nuevo artículo, seguiremos con la gestión de consignación en compras, aprendiendo a controlar la mercancía mediante el pedido de consigna creado, ya que, una vez que el pedido llega al proveedor y éste envía la mercancía, se realiza la entrega entrante contra el pedido de consigna.

Entrada de mercancías

Se realiza la entrada de mercancías del material en consigna. Esto se puede realizar desde la transacción MIGO (Registrar movimientos de material) o desde la transacción VL31n (Crear entrega entrante) y de esta manera registramos la entrada de mercancías del pedido con nuestro material en consigna.

Debido a que en nuestro caso tenemos parametrizado que en el pedido nos exige realizar una entrega entrante en el control de confirmación de la entrega,

Vamos a utilizar la transacción Vl31n – Entrega entrante.

Una vez realizada la entrega del material de forma correcta y en las cantidades que le hayamos indicado; contabilizaremos en el sistema la entrada del stock.

Esta entrada nos determinará el siguiente movimiento:

• Se contabiliza la EM, creando un movimiento 101-K entrada mercancía consigna. (MB03 – visualizar documento material)

• Este movimiento de material no genera ningún documento financiero en las cuentas de existencias; ya que a efectos prácticos sigue perteneciendo al proveedor.
• Al consultar los listados de stock del material, esta mercancía aparece asignada al proveedor. (Listad de stocks – MMBE)

Nos muestra seleccionando el registro, el número de proveedor de dicho material.

Traspaso de stock a propio

Al realizar el paso de stock del material al stock propio mediante un traspaso se realiza el movimiento 411 – K (traspaso consigna a propio).

Este documento material sí generará los documentos contables de existencias correspondientes.

Una vez hecho nuestro el stock de consigna mediante el movimiento 411 – K, el stock quedará actualizado. Descontará de la consigna del proveedor la cantidad traspasada y lo dejará en el almacén escogido.

Liquidación de la consignación

Registros de condición de mensaje – MRM1:

Es necesario que estén parametrizados los registros de condición KONS (Consignación) para los proveedores de consigna y de esta manera poder informarles del consumo del material en depósito. Esta información puede ser vía mail, fax o mensaje EDI.

Una vez ya tengamos el registro de condición creado; se realiza la liquidación del consumo del material traspasado al stock propio – Liquidación de consignación MRKO. (Es el equivalente a la MIRO.)

En esta transacción es tanto de consulta (Visualizar):

Como para la liquidación (Liquidar):

Automáticamente se genera un documento financiero visible desde la transacción FBL1N (listado de proveedores). Este documento se compensará con la salida de pagos al proveedor.

Una vez realizado todo este proceso, ya habrá finalizado la consignación en compras.

En el artículo anterior sobre los nodos de contexto de WD4A, comentábamos las propiedades del contexto, pero no mencionamos nada de la función supply. Este artículo explicamos que es y para que se puede utilizar.

La función Supply es un mecanismo para repoblar nodos hijos. Una función Supply puede ser asignada a cada nodo del contexto de un controlador. Esta función se llama automáticamente cuando se intenta leer los datos de un nodo de contexto inválido.

Esta invalidez ocurre cuando:

• Una colección de un nodo es inicial. Todavía no se han cargado datos en el nodo.
• La colección del nodo es invalidada por código (método invalidate).
• El Lead Selection en la colección del nodo padre cambia. Esto solo ocurre para nodos hijos con la propiedad singleton marcada.

Para introducir una función de este tipo, le indicamos el nombre que le queramos dar en la opción Supply Function del nodo. Después, por forward navigation (doble clic sobre el nombre de la función), se crea un método en el controlador en que nos encontremos, donde se crea el código para introducir los datos en el contexto automáticamente. En esta función únicamente se debe crear la lectura de datos de base de datos.

El método creado en el controlador tendrá dos parámetros import. Un elemento de contexto, que corresponde al elemento padre del nodo, y un nodo de contexto, que es el propio nodo.

También en este método aparece una serie de código abap comentado. Este código nos ayuda a rellenar el nodo con los datos que queramos. Por lo tanto lo más fácil será descomentar las líneas de código que aparecen. Para explicarlo mejor utilizaremos el siguiente contexto de ejemplo, donde existe un nodo hijo con las reservas de un vuelo.

Primero aparecen unas líneas de código por si queremos coger los elementos del padre. Por ejemplo, para coger el id de Vuelo y la conexión para saber las reservas:

*  if necessary, get static attributes of parent element
DATA ls_parent_attributes TYPE wd_this->element_vuelos.
parent_element->get_static_attributes(
IMPORTING
static_attributes = ls_parent_attributes ).

Luego se accede a la base de datos o lo que se requiera para cargar el nodo, en el ejemplo, recogemos todas las reservas del vuelo:

* data declaration
DATA lt_sbook TYPE wd_this->elements_sbook.
DATA ls_sbook LIKE LINE OF lt_sbook.
* @TODO compute values
* e.g. call a data providing FuBa
SELECT * INTO CORRESPONDING FIELDS OF TABLE lt_sbook FROM sbook
WHERE carrid = ls_parent_attributes-carrid
AND connid = ls_parent_attributes-connid
AND fldate = ls_parent_attributes-fldate.

Y por último cargamos el nodo con los datos recogidos.

* bind all the elements
node->bind_table(
new_items            =  lt_sbook
set_initial_elements = abap_true ).

Así, en nuestra aplicación WD4A, mediante la función supply nos podremos asegurar de que siempre que se intente accede a la información del nodo, este tenga los datos correspondientes y así evitemos errores en tiempo de ejecución.

En este artículo se explicará cómo cargar y ver los datos del clúster de movimientos de tarjeta de crédito para el módulo de SAP HCM.

SAP dispone de un programa estándar que genera ficheros con movimientos de tarjetas de crédito para un empleado específico: RPRCCC_CREATE_TESTFILE

Para generar el fichero en SAP HCM, el empleado debe tener correctamente informados los infotipos 0002, 0008 y en el 0105 el subtipo 0011 con el nº de la tarjeta.

En esta pantalla tendremos que rellenar:

• Compañía de la tarjeta de crédito: VI, MC…
• Nº ejecución: es un ID para cada fichero ejecutado (solo se puede cargar un fichero por cada ID)
• ID empresa: es un ID identificado de la compañía
• Ruta donde se generará el fichero
• Número de personal del empleado al que se le van a cargar movimientos de tarjeta de crédito

Para cargar los movimientos de tarjeta de crédito en SAP, utilizaremos la transacción estándar PRCC:

En esta pantalla tendremos que indicar:

• ID empresa (mismo dato que hemos introducido en el paso anterior)
• Test/Real: Si queremos simular o cargar realmente los movimientos en SAP HCM
• Ruta donde tenemos el fichero a cargar

Una vez ejecutado el programa nos aparecerá una pantalla con los movimientos erróneos, y si damos para atrás nos aparecerán los movimientos correctamente cargados.

Una vez que hemos cargado datos en SAP HCM, podemos ver los movimientos cargados correctamente mediante la transacción PRCCD:

En este pantallazo podemos ver un movimiento cargado en SAP, pero que aún no se ha asignado a ninguna hoja de gastos:  ; y otro movimiento que ya se ha asignado a una hoja de gastos: 

Por otra parte, los movimientos de tarjeta de crédito que no han podido cargarse correctamente en SAP, se pueden visualizar a través de la transacción PRCCE:

Mediante esta transacción podremos arreglar los datos del movimiento que no se ha podido cargar; como por ejemplo si el número de tarjeta venía incorrecto, si el empleado no tenía cargada la tarjeta en el infotipo 0105 subtipo 0011… Una vez modificados los datos incorrectos podemos grabar las modificaciones, y mediante el programa RPRCCC_CREATE_CORRECTION_FILE podremos generar otro fichero para poder cargarlo en SAP.

Siguiendo esta breve explicación, podrás cargar y ver los movimientos de tarjeta de crédito de tus empleados, en SAP HCM.

SAP HANA vs SAP BW: Desde la aparición de SAP HANA se viene produciendo un encendido debate respecto a su aplicación y sobre si es el sucesor natural de SAP BW, tal vez por la confusión que este término genera.  Frecuentemente las discusiones se mueven alrededor de estas preguntas:

1. Tengo SAP ECC y BW, ¿debería valorar SAP HANA?
2. Tengo SAP ECC y estoy valorando montar BW, ¿Hago bien o debería apostar por SAP HANA?
3. Tengo SAP ECC y me han recomendado diseñar un data warehouse (repositorio de información) desde cero, ¿Es esto correcto o debería aprovecharme de SAP HANA?

El mejor punto de partida para empezar a despejar dudas es recordar las definiciones de SAP Business Warehouse vs SAP HANA.

SAP Business Warehouse

SAP Business Warehouse es el nombre de la solución para Inteligencia de Negocio, análisis, informes y repositorio de datos de SAP AG, el fabricante alemán de sistemas de gestión. A día de hoy, después de la compra de BusinessObjects por SAP AG, SAP BW se refiere a la parte de Data Warehouse Area and Accelator (Almacenamiento y procesado rápido de datos). Sobre todo, es usado por compañías que soportan su gestión en SAP ERP y sus soluciones satélite (SCM, CRM, BPC, etc). SAP BW consta de varios componentes, entre los que destacan:

• Herramienta ETL (Extración, Transformación y Carga) para mover y cargar datos.
• Repositorio de Datos (Data Warehouse).
• Componente de reporting para explotación de datos del repositorio.
• Herramienta de planificación y análisis para simular operaciones como cálculos de presupuestos y sacar tendencias.

Por tanto, si tuviéramos que seleccionar un término para definir la esencia de SAP BW diríamos que es un sistema.

SAP HANA

En relación a SAP HANA es una plataforma in-memory para el procesado de grandes volúmenes de datos en tiempo real. El motor de cálculo in-memory permite a HANA procesar datos directamente en la memoria RAM, con lo cual se ahorra los tiempos de lectura y escritura de datos de un disco físico. SAP HANA  es capaz de usar 3 tipos de replicación de datos, en función del origen de los mismos: basado en log, basado en ETL y basado en un desencadenantes (trigger-based).

Por tanto, SAP HANA es en esencia una Base de Datos; eso sí, con importantes particularidades. SAP HANA es un tipo especial de base de datos in-memory que permite un gran rendimiento cuando es usado para soportar sistemas como BW. Llegados a este punto, podemos empezar a responder a las preguntas de arriba: HANA no va a reemplazar a BW, por el contrario, SAP HANA permite que BW sea más eficiente en sus labores de procesado.

En este sentido, la regla general sería usar SAP HANA como Base de Datos para soportar otras aplicaciones. En relación a BW, la estrategia más adecuada sería usar SAP HANA  como plataforma de BBDD y de soporte a la ejecución de los procesos de SAP BW. Para terminar de bordar el asunto, la mejor apuesta sería valorar BusinessObjects como capa de presentación de BW, mejorando el aspecto y la facilidad de interacción con los reportes y cuadros de mando generados.

En el siguiente artículo daremos más detalles sobre SAP HANA vs SAP BW y cubriremos los escenarios que corresponden a las preguntas anteriores.

Referencia/s: Vijay Vijayasankar, Strategy & Business Analytics, IBM

En este artículo vamos a responder a las preguntas planteadas en la primera parte, SAP HANA vs SAP BW: ¿Qué elegir?  e intentaremos dar consejos sobre buenas prácticas en posibles proyectos de implementación.

Dicho esto, pasemos a cubrir los escenarios que corresponden a las preguntas planteadas.

Tengo SAP HANA y SAP BW, ¿Debería valorar SAP HANA?

En el artículo anterior, SAP HANA vs SAP BW (primera parte), mencionábamos que la velocidad de procesado sin HANA es un hándicap para BW. Este el primer motivo por el que una empresa que tenga un volumen de datos considerable debería valorar SAP HANA. Con SAP HANA tenemos la posibilidad de reducir considerablemente los tiempos de carga de datos, ETL y reporting.

Otro aspecto, tal vez incluso más importante que el anterior, es la simplificación. BW tiene una serie de capas que fueron construidas para mejorar el rendimiento. Estas capas ya no serían necesarias si implementamos SAP HANA como Base de Datos para BW. Adelgazar BW hace que construir nueva funcionalidad y gestionar el entorno productivo del mismo sean más eficientes. Por tanto, la tendencia es mover la funcionalidad de BW que estaba construida sobre ABAP a HANA para que tanto la arquitectura como el trabajo de procesado sean más ágiles.

Por tanto, creemos que las empresas que tengan un volumen de datos importante deberían valorar HANA. La migración a SAP HANA es un proceso relativamente sencillo; de hecho SAP tiene un manual de buenas prácticas como guía a los partners implementadores que llevan a cabo este tipo de proyectos.

Tengo SAP ECC y estoy valorando montar BW, ¿Cuál es la mejor estrategia y que papel desempeñaría SAP HANA?

Depende de varios factores relativos a la gestión de datos, volumen y estructura de los mismos y estrategia de analíticos de una empresa en concreto.

Implementar SAP BW es muy recomendable para empresas que tengan SAP ECC muy desarrollado y que estén buscando un repositorio de información para consolidar y depurar datos corporativos en una misma fuente.

Un caso todavía más claro que el anterior sería si la fuente de datos de la empresa es el transaccional de SAP ECC. Aquí la integración con SAP BW en cuanto a carga de datos y ETL sería prácticamente lineal.

Respecto al papel de SAP HANA, el factor determinante de cara a valorarlo sería el volumen de datos de la empresa. Si este es considerable, podríamos valorar SAP BW sobre HANA, o incluso si la empresa en cuestión tiene un volumen de datos descomunal, no sería mala estrategia valorar correr tanto los aplicativos de gestión SAP (ERP, CRM, SCM, BPC, etc) como los analíticos y data warehouse (BW, BI) sobre HANA.

Tengo SAP ECC y me han recomendado diseñar un data warehouse (repositorio de información) desde cero, ¿Qué debería hacer?

SAP ha pasado los últimos 15 años construyendo y mejorando el mapeado de datos de su suite de aplicativos para BW. Pretender abarcar el mismo grado de funcionalidad y mejoras desde cero sería como pretender reinventar la rueda, no tiene sentido y supondría una inversión enorme.

Dicho de otra manera más clara, los diseños son baratos, las implementaciones no. 

Referencia/s:

• Vijay Vijayasankar, Strategy & Business Analytics, IBM
• Steve Lucas, President, SAP Solution Platform

Al igual que comentamos en el artículo Web Dynpro Abap Layout: Modificaciones dinámicas,   en WD4A, existen las modificaciones dinámicas del contexto y por tanto, puede modificar cualquier elemento UI mediante código, lo mismo ocurre con el contexto de un controlador. A continuación se describe como poder tratar el contexto en tiempo de ejecución.

Es preferible crear todo el contenido del contexto posible en tiempo de diseño, sin embargo, pueden darse situaciones en las que se deba modificar en tiempo de ejecución:

• Si la estructura de los datos no es conocida en tiempo de diseño.
• Si el comportamiento de la pantalla va ser genérica.
• Si los componentes de utilización tiene que ser desarrollados, de una manera genérica.

En WD4A, la definición de cada nodo se guarda en sus metadatos, y para acceder a ellos deberemos instanciar un objeto con referencia al tipo if_wd_context_node_info. En esta interfaz están definidos los métodos para poder crear, modificar o eliminar cualquier elemento del contexto, ya sean nodos o atributos.

Para empezar a modificar los elementos existentes o crear uno nuevo, lo primero es recoger los metadatos del nodo raíz. Este nodo, llamado “CONTEXT” existe en todos los contextos de todos los controladores y se recoge de la siguiente manera.

DATA: lr_root_info TYPE REF TO if_wd_context_node_info.
lr_root_info = wd_context->get_node_info( ).

Una vez que se tiene la referencia a los metadatos, se pueden usar diferentes métodos para ir creando nodos o atributos de contexto. Para crear un nodo se utiliza el método add_new_child_node, con dos diferentes opciones para crearlo:

Crear un nodo sin estructura definida

Crear un nodo vacío, al que luego habrá que ir añadiendo los atributos que se deseen, como por ejemplo:

DATA lr_node_info TYPE REF TO if_wd_context_node_info.
*se crea un nodo vacío, sin atributos
CALL METHOD lr_root_info->add_new_child_node
EXPORTING
name                         = 'NODO_PRUEBA'
is_multiple                  = abap_false
is_mandatory                 = abap_true
is_mandatory_selection       = abap_false
is_multiple_selection        = abap_false
is_singleton                 = abap_true
is_initialize_lead_selection = abap_true
RECEIVING
child_node_info              = lr_node_info.

Con esta llamada se crearía un nuevo nodo con el nombre “NODO_PRUEBA” colgando del nodo raíz. Este nodo sería un nodo de cardinalidad 1…1, de selección 0…1, con las propiedades Lead Selection y Singleton seleccionadas.

Una vez creado el nodo, deberemos ir añadiendo los atributos que se requieran. Esto lo haremos con el método add_attribute. Primero definimos las propiedades del atributo en una estructura del tipo wdr_context_attribute_info, y luego lo añadimos al nodo. Por ejemplo añadimos un atributo de nombre “ATRIBUTO_PRUEBA”, de tipo “STRING” y sin ayuda de búsqueda:

DATA: ls_attribute TYPE wdr_context_attribute_info.
*Se define un atributo
ls_attribute-name   = 'ATRIBUTO_PRUEBA'.
ls_attribute-type_name    = 'STRING'.
ls_attribute-value_help_mode  = '0'.
CALL METHOD lr_flights_info->add_attribute
EXPORTING
attribute_info = ls_attribute.

Esta acción se debe repetir por cada atributo que se necesite.

Crear nodo con estructura definida

Una manera más rápida y sencilla de crear atributos es definiendo el nodo con una estructura ya existente en el diccionario. Con esta opción todos los atributos del nodo se crearán automáticamente con el tipo que tengan definidos en la estructura del diccionario. Esto se realiza utilizando también el método add_ner_child_node, pero pasando como parámetro la estructura.

DATA:  lr_root_info TYPE REF TO if_wd_context_node_info,
lr_flights_info TYPE REF TO if_wd_context_node_info.
*cogemos los metadatos del nodo raíz del contexto
lr_root_info = wd_context->get_node_info( ).
*creamos un nuevo nodo con una estructura ya definida en el diccionario de datos
CALL METHOD lr_root_info->add_new_child_node
EXPORTING
name                         = 'VUELOS'
static_element_type          = 'SFLIGHT'
is_multiple                  = abap_true
is_mandatory                 = abap_true
is_mandatory_selection       = abap_false
is_multiple_selection        = abap_true
is_initialize_lead_selection = abap_true
RECEIVING
child_node_info = lr_flights_info.

Al ejecutarse el método superior, se crearía en el contexto un nodo “VUELOS” del tipo de la tabla de diccionario “SFLIGHT”, con cardinalidad 1…n, selección 0…n y con el Lead Selection seleccionado por defecto.

Así es como se gestionan las modificaciones dinámicas de contexto en WD4A.

“SAP Anywhere”, la nueva apuesta de SAP AG para el sector PYME, ha comenzado su andadura en el mercado Chino, fruto de la colaboración del gigante de software europeo y China Telecom, ésta última para soportar el servicio en nube.

SAP para pymes

SAP AG, la compañía de software más importante de Europa, se ha aliado con China Telecom para ofrecen una solución en nube para micropymes cuyo negocio esté enfocado en e-Commerce. A principios de Octubre de este año, las 2 corporaciones presentaron en Beijing el nuevo producto, que se prevé llegue a los mercados norteamericano y europeo durante el primer semestre de 2016. Se ha elegido China para realizar las primeras implementaciones de SAP Anywhere por tener el mayor volumen de negocios basados en e-Commerce.

SAP AG espera que los primeros casos de éxito de SAP Anywhere en empresas chinas hagan de tractor para generar interés en el mercado de los negocios de e-Commerce occidentales. Rodolpho Cardenuto, director de operaciones de SAP AG, se manifestaba en estos términos:

“SAP Anywhere permitirá que las pequeñas empresas le saquen partido a la revolución digital y será el software que acompañe el crecimiento de sus negocios gracias a la posibilidad de que sus clientes puedan comprar sus productos en cualquier momento, desde cualquier lugar”.

Por tanto, quedan claros cuáles van a ser los ejes de SAP Anywhere: Cloud, e-Commerce, pequeño negocio, ubicuidad, software como servicio (SaaS).  En relación a los puntos de Cloud y SaaS, recordemos que son las principales líneas de crecimiento de SAP a día de hoy junto con los licenciamientos de SAP Business One.

Ayuda para pequeños negocios con SAP Anywhere

Funcionalidad de SAP Anywhere

Respecto a la funcionalidad estándar de la solución, SAP Anywhere permitirá gestionar procesos de ventas y compras, marketing, pedidos e-Commerce, inventario, soporte post-venta y, por supuesto, integración total para operaciones desde dispositivos móviles. Además, estará la posibilidad de que tantos los clientes como los proveedores puedan acceder a áreas compartidas de inventario y logística en tiempo real, con la ayuda de un software unificado para gestión de órdenes. Por último, SAP Anywhere contará con un sistema de información para realizar analíticos, consultar reportes y llevar a cabo simulaciones en tiempo real.

Comercialización

Respecto a la estrategia de comercialización de esta nueva solución, SAP quiere contar con su red de partners de Business One para ofrecer el nuevo producto entre su base instalada. La idea es que las empresas que gestionan sus procesos de back-office con Business One puedan reforzar su infraestructura de gestión IT con las funcionalidades front-office de SAP Anywhere. En este sentido, Navigator Business Solutions, partner gold de Business One en Salt Lake City, ya ha firmado un acuerdo para ser partner piloto de esta solución y empezar a comercializarla entre su cartera.

Para finalizar con esta pequeña presentación de SAP Anywhere, aquí tenéis un vídeo muy interesante sobre este nuevo desarrollo.

Pinche aquí para ver el vídeo

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 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…

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

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

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.

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.

En el siguiente artículo vamos a hablar de los atributos que existen en todos los controladores de las aplicaciones Web Dynpro for Abap, para que sirven y cómo crear nuestros propios atributos.

Cualquier controlador de web dynpro (que es realmente un objeto abap) tiene una pestaña de atributos. Existen una serie de atributos que vienen definidos por defecto y también es posible crear otros a necesidad del programador. Sigue leyendo para aprender cómo hacerlo.

Atributos predefinidos

Existen una serie de atributos predefinidos en todos los controladores, que no pueden ser modificados ya que se crean cuando se crea el controlador correspondiente. Estos hacen referencia a los diferentes objetos que se utilizan en el controlador:

WD_THIS

Este atributo es la instancia propia del controlador en el que se está programando. Como en cualquier programación orientada a objetos, es la instancia para poder utilizar todos los métodos y atributos privados de la clase. Así que siempre que desde nuestra aplicación WD4A se quiera llamar a un método de la clase, o utilizar otro atributo definido por el usuario, es necesario utilizar esta instancia.

*llamamos a un método del controlador
wd_this-><nombre_metodo>().
*o usamos un atributo
wd_this-><nombre_atributo> = 'ejemplo'.

El tipo de este atributo dependerá del controlador en el que estemos. Si estamos en el controlador del componente, hará referencia a la interfaz del mismo (IF_COMPONENTCONTROLLER), pero si estamos en una vista, hará referencia a la interfaz de esa vista (IF_NOMBRE_VISTA).

WD_CONTEXT

Todo controlador de Web Dynpro for Abap tiene un contexto con el que poder hacer bindings a los objetos UI para interactuar con el usuario. Como este contexto también es un objeto ABAP, es posible instanciarlo. Para ello en todos los controladores por defecto se crea este atributo, con el que podremos acceder a los diferentes nodos y atributos del contexto. Para ello, este atributo se instancia mediante la interfaz IF_WD_CONTEXT_NODE.

WD_COMP_CONTROLLER

Este atributo aparece en todos los controladores excepto en el controlador del componente, ya que es la referencia a este controlador. El controlador del componente es visible por el resto de controladores, y con este atributo es como se accede a sus atributos o métodos públicos. De esta manera, un método definido en el controlador del componente puede ser usado en varios controladores.

DATA lo_componentcontroller TYPE REF TO ig_componentcontroller.
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller-><nombre_metodo>().

*o también usando el atributo
wd_comp_controller-><nombre_metodo>().

WD_ASSIST

Como vimos en el artículo: WD4A: Clase de asistencia, cuando se utiliza una clase de asistencia en un componente, en todos sus controladores se crea automáticamente este atributo. Este atributo es la instancia de dicha clase, para que nos permita acceder a sus métodos y atributos de manera sencilla.

Atributos definidos por el programador

Como en cualquier clase que estamos definiendo, en cualquier controlador podremos crear nuestros propios atributos. Para ello, en la pestaña atributos podemos definir tantos atributos como queramos. Lo único a tener en cuenta es que si queremos un atributo que sea referencia a algún objeto, hay que marcar el check box RefTo. Si creamos uno de este tipo, después por programa habrá que instanciar dicho objeto, lo cual es conveniente hacerlo en el método Hook WDINIT, ya que es el constructor del controlador.

Si creamos atributos en el controlador del componente, aparecerá un checkbox más, Public. Esto sirve para hacer el atributo público y así poder usarlo en el resto de controladores.

Esta es toda la información necesaria para que puedas manejar los atributos del controlador de tu aplicación Web Dynpro for Abap.