Metodologías Ágiles. SCRUM

Sabiendo que en este blog está dedicado al mundo SAP, siempre me gusta escribir sobre todo aquello que esté relacionado con cualquier tipo de tecnología. Si hablamos de desarrollo, igualmente, me gusta ir un poco mas allá y hablar por ejemplo de metodologías.


Cualquier persona que desarrolle software habrá oído hablar de diferente metodologías a la hora de trabajar. Hay diferentes y cuando afrontamos un nuevo proyecto debemos decidir cual de ellas es la que mejor se adapta a nuestras necesidades.
De entre muchas metodologías que podemos encontrar, desde hace tiempo, sigo con mucho interés todo lo que tenga que ver con metodologías ágiles.


Para que os hagáis una idea de que representa una metodología ágil, disponemos de un manifiesto donde se explican los 4 fundamentos principales. Según el manifiesto se valora:

• A los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Estos cuatro valores dieron lugar a los principios que fundamentan las metodologías agiles:

• Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
• Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
• Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
• La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
• El software que funciona es la principal medida del progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica enaltece la agilidad.
• La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
• En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

Dentro de las diferentes metodologías ágiles que podemos encontrar, la mas famosa es SCRUM. He encontrado un articulo buenísimo que explica de forma sencillísima que es SCRUM y en que consiste. La explicación es algún así como ¿Cómo puedo explicar a mi abuela que es SCRUM?.

Leerlo, es 100% recomendable. Si os interesa el tema seguiremos desarrollándolo.

SAP quiere multiplicar por 7 el crecimiento en Cloud de aquí a 2020

A través de AUSAPE he encontrado los siguientes datos sobre facturación de SAP. Son interesantes de cara a ver por donde está creciendo SAP y cuales serán las tendencias de cara a los próximos años. Os dejo el resumen de la noticia:

"Según los resultados preliminares del año 2004, SAP obtuvo unos ingresos unos ingresos totales (no IFRS) de 17.870 millones de euros, mientras que el beneficio operativo no IFRS se incrementó un 3 por ciento en moneda constante hasta los 5.630 millones de euros.

La mayoría de la facturación (no IFRS) procede del software y servicios relacionados, totalizando 14.870 millones de euros.

Hay varios aspectos que la multinacional resalta: ha experimentado un “crecimiento excepcionalmente fuerte” en la nube y también en SAP HANA. Sus ingresos no IRFS por suscripciones y soporte Cloud en todo el año aumentaron un 45 por ciento, al cambio actual y constante, hasta los 1.100 millones de euros. La compañía se ha establecido un objetivo de ingresos
por Suscripciones y Soporte Cloud entre los 7.500 y los 8.000 millones de euros y una facturación de entre 26.000 y 28.000 millones de euros para 2020. 

Por otro lado, SAP HANA sigue constituyendo un gran motor de crecimiento para SAP. Según informó, ya cuenta con más de 5.800 clientes en esta área y más de 1.850 de Suite on HANA."

EDI. Definición de puerta y sistemas lógicos

En este post vamos a seguir avanzando con EDI. Ya hemos visto anteriormente los que es un IDOC. Ahora vamos a continuar viendo como definir la puerta y los sistemas lógicos para poder trabajar con EDI desde SAP.

Los idocs pueden ser enviados y recibidos a través de diferentes medios. Con el objetivo de no acoplar la definición de las características del medio con la aplicación que lo está utilizando, el medio es accedido vía puertas. En otras palabras, una puerta es un nombre lógico para un dispositivo de entrada/salida. Los programas se comunican con una puerta a través de una interfaz estándar.

En vez de definir el medio de comunicación directamente en el Acuerdo de Interlocutor (Partner Profile), se asigna un número de puerta, y es esta puerta la que designa realmente al medio. Esto permite definir las características de las puertas individualmente y usar una puerta en múltiples Acuerdos de Interlocutores. Los cambios en una puerta se reflejarán automáticamente en todos los acuerdos que lo estén utilizando.

Al menos debe existir una puerta para cada sistema externo. Los tipos de puertas más comunes son los siguientes (desde la transacción WE21):

• Ficheros (File Interface). Permite intercambiar idocs a través de archivos del sistema operativo. El sistema que envía el idoc crea un archivo en el file system. Luego notifica al sistema receptor vía RFC sincrónico que el archivo ha sido transferido, que está localizado en un determinado directorio, y que tiene un determinado nombre. SAP recomienda no usar nombres de archivos estáticos, dado que el archivo es sobrescrito cada vez que el idoc se envía. Se recomienda usar el módulo de funciones EDI_PATH_CREATE_CLIENT_DOCNUM, el cual genera el nombre del archivo a partir del mandante y número de idoc.
  
• RFC Transaccional. Se usa para escenarios de distribución ALE. El nombre del puerto se puede definir a mano o dejar que SAP lo elija. Además del puerto, hay que definir el destino RFC.
  
• Archivo XML. Envía documentos en formato XML. Para utilizar este tipo de puerta, es necesario definir el nombre de la puerta, el formato del XML, y el nombre del archivo a generar. Al igual que con el tipo de puerto Fichero, se puede invocar a la función EDI_PATH_CREATE_CLIENT_DOCNUM para que genere los nombres del archivo en forma dinámica.
  
• XML-HTTP. En vez de definir el nombre del archivo XML, se especifica un destino RFC. 

Además de definir la puerta deberemos definir los sistemas lógicos utilizando la transacción BD54 y asignar estos sistemas lógicos al mandante que corresponda con la transacción SCC4.

Nuevos cursos gratruitos en OpenSap

A raiz del anuncio ofial de SAP S4 HANA ya tenemos disponible un curso gratuito para poder comenzar a formarnos en la nueva suite de SAP. El curso está disponible a traves de la página openSAP.

La inscripción es totalmente gratuita. Podeis acceder al curso a través del siguiente link.

Como crear plantillas de código ABAP utilizado frecuentemente

Es muy frustrante para un desarrollador escribir los mismos bloques de código una y otra vez. Para resolver este problema, el editor ABAP tiene una función de plantilla de código que te permite utilizar plantillas predefinidas o crear tus propias plantillas interactivas. También nos da la posibilidad de crear plantillas con porciones de código que ya tenemos escritas.

En este post vamos a ver cómo utilizar esta función para reducir la cantidad de tiempo que dedicamos a escribir bloques de código de uso frecuente.

Por defecto en el editor ABAP tenemos activada la característica de plantillas de código. Por ejemplo cuando utilizamos palabras clave como WHILE, LOOP, IF, etc. el editor nos marca con una flechita roja la palabra clave indicándonos que por defecto se dispone de una plantilla.

Cuando aparece este símbolo, podemos presionar la combinación de teclas Ctrl + Enter o TAB para que se nos inserte la plantilla de código. Por ejemplo si utilizamos la palabra clave CASE el resultado sería el siguiente:

Por ejemplo tenemos algunos comandos que nos habilitan plantillas para comentarios. Si escribimos *** o *-- el editor nos propondrá plantillas.

Podemos ver la lista de plantillas predefinidas si pulsamos sobre el botón "Opciones" que se encuentra en la esquina inferior derecha del editor ABAP.

Desde esta misma pantalla podemos crear y tratar nuestras propias plantillas predefinidas. Para ello tenemos las opciones disponibles de "Añadir", "Modificar" y "Borrar".

Otra interesante opción que nos da está funcionalidad es la de poder introducir tags o variables predefinidas que nos aportan algo de funcionalidad a nuestra plantilla.

Las opciones disponibles son:

• Date Time
• Clipboard
• Surrounded Text
• Document Name
• Interactive

Estas opciones nos permitirán insertar automáticamente Fecha/Hora o el nombre del progrma. Incluso podemos insertar variables en la plantilla. Cuando insertemos la plantilla en nuestro código el sistema muestra un popup para que marquemos el valor de dichas variables.

Un ejemplo de plantilla podría ser el siguiente:

"<Y0UR NAME %Date Time% >

“%Additional Info %

% Surrounded Text %

"</Y0UR NAME %Date Time%>

Sería interesante por ejemplo cuando hacemos un cambio en el código y lo queremos dejar marcado. Utilizaríamos la variable "Additional Info" para introducir la explicación del cambio.

Otra forma, también muy interesante, para crearnos plantillas es utilizar la funcionalidad de modelos que nos proporciona SAP. De por si esta funcionalidad nos permite insertar casi cualquier objeto que esté creado en el sistema (Módulos de funciones, métodos de clases, etc.). Pero además nos deja crear nuestros propias plantillas. Para crearnos una debemos seguir la siguiente ruta:

Le damos un nombre a nuestro patrón.

Se nos abrirá un editor donde podremos insertar el código que queramos. Lo insertamos y grabamos.

El último paso sería cargar en nuestro programa la plantilla creada a través de la funcionalidad de "Modelo".

Comparar dos Programas ABAP con el editor SplitScreen. SE39

En este post vamos a hablar de como comparar dos programas ABAP (Ya hemos tocado el tema anteriormente para ver como comparar dos programas en entornos diferentes. Dejo el link).
En este caso el tema cambia un poquito, pues lo que proponemos es tener en la misma pantalla dos editores cada uno con un programa cargado. Además pudiendo tener los programas en modo editable para poder irles modificando.
Por ejemplo, se me ocurre que estamos construyendo una nueva transacción y nos damos cuenta que en otro programa tenemos una porción de código que nos interesa. Podemos abrir ambos programas a la vez para tomar uno como referencia para el otro.

Para poder disponer de esta funcionalidad debemos utilizar la transacción SE39. La transacción nos da opción de comparar programas, módulos de funciones o clases.

Incluso podemos comparar  con programas en diferentes sistemas. Para utilizar esta funcionalidad debemos presionar en botón de la parte superior "Comparar diferentes sistemas".

Una vez hemos informado que programas vamos a comparar podemos simplemente visualizarlos o ejecutar la transacción en modo editable para tener la opción de modificarlos.

El resultado final es el que veis en la siguiente imagen:

IDOCs en SAP

En este post vamos a seguir hablando de un tema que introducimos hace algún tiempo, EDI. Y mas en concreto vamos a ver que es un IDOC.

Los idoc permiten intercambiar información entre distintos sistemas. Se puede ver como un archivo de texto plano, con registros. Un idoc es por ejemplo los datos de un cliente, o un pedido de venta.

Contiene una cabecera y posiciones, pero todos los datos pertenecen a la misma entidad. O sea, para transmitir datos de más de un cliente, haría falta más de un idoc.

Los idocs se crean y luego se envían. Este envío se realiza en un segundo paso; o sea que podría haber idocs que todavía no se hayan enviado.

Un idoc, como se mencionó más arriba, está formato por dos bloques:

• Un registro de control.
• Una tabla con los datos del idoc.

El registro de control contiene toda la información administrativa del idoc, como el origen y el destinatario, y qué tipo de idoc es. Sería algo así como el sobre que acompaña a cualquier carta. Este registro es muy importante ya que es necesario para saber, entre otras cosas, cuál será el destinatario del idoc. La tabla SAP donde se guardan es la EDIDC.

Los registros de datos se guardan en la tabla EDID4 en un campo de 1000 caracteres. Para saber interpretar esa cadena, el registro cuenta con un campo que informa cuál es la estructura con la que se deben interpretar los datos. El nombre de dicha estructura existe en SAP y se puede ver desde la transacción SE11.

Desde la transacción WE30 se puede ver el formato de los idocs. Por ejemplo, para el idoc ORDERS05, el formato es el siguiente:

Generalmente, varios registros de estado se adjuntan a un idoc. El sistema automáticamente asigna registros de estado durante todo el proceso, a medida que el idoc va alcanzando diversos puntos de control. 

Contienen información de estado, tal como código de estado, fecha y hora en que el punto de control es alcanzado. Estos registros de estado existen solamente en SAP y no son almacenados en el archivo de salida. La estructura de los registros de estado está definida por la estructura del DDIC EDI_DS40. La tabla es EDIDS.