Blog

¿Cómo gestionar el flujo de desarrollo en SAP?

[fa icon="calendar"] 29/08/2016 por Equipo de Redacción Linke IT

Equipo de Redacción Linke IT

Como gestionar el flujo de desarrollo en SAP


Hoy trabajamos en lo relacionado a cómo gestionar el flujo de desarrollo en SAP, mediante el sistema NWDI (NetWeaver Development Infrastructure) que probablemente conozcáis. Veremos los aspectos generales y repasaremos los puntos clave en los que tenéis que depositar vuestro mayor nivel de atención si queréis obtener unos resultados a la altura de las circunstancias. 

Entendiendo la gestión del flujo de desarrollo

Lo primero que decimos es que nuestra prioridad se encuentra en garantizar el flujo adecuado en la coordinación del transporte que se lleva a cabo de los distintos componentes que hay en una aplicación híbrida. Tenemos que contar con la garantía de que el transporte se produce de una forma controlada a través del landscape y de que no se produce ningún tipo de interrupción.

Pueden formar parte varios lenguajes de programación con distintos procesos de desarrollo que derivan en esa aplicación híbrida que hemos mencionado, proporcionando comodidad y eficiencia a partes iguales para que podamos organizarnos dependiendo de cada caso. Por ejemplo, tendremos la oportunidad de establecer unas fases muy personalizadas y que así cada tipo de componente actúe en el momento en el que resulte más adecuado dentro de los procesos de transporte.

 

Paso a paso

1. Definimos el entorno de desarrollo

Para que todo marche como la seda tenemos que comenzar definiendo el entorno de desarrollo en el que vamos a trabajar. Esto es algo que debemos realizar teniendo en cuenta las particularidades y exigencias del lenguaje de programación que estemos utilizando en nuestro día a día. Si tomamos de referencia NetWeaver Developer Studio lo que haremos será definir el entorno al cargar un perfil de desarrollo que hayamos obtenido desde el repositorio que nos proporciona una amplia variedad de opciones.

 

2. Elegimos los componentes

Después será el momento de la elección de los componentes. Continuamos poniendo el ejemplo de NetWeaver Developer Studio al ser el tipo de sistema que hemos tenido la ocasión de probar más a fondo. En este caso los cambios que realicemos en los componentes que hemos elegido se irán llevando a cabo en una copia local de los archivos. Si vosotros habéis optado por ABAP Workbench como alternativa a nuestra elección, tendréis que saber que el movimiento será un poco diferente, puesto que lo que ocurrirá será que los componentes se duplicarán a través de una versión inactiva de los mismos con la que trabajaremos.

Es importante tener en cuenta que en este proceso del trabajo no tendremos de qué preocuparnos sobre los demás desarrolladores, puesto que ellos no tendrán control sobre lo que nosotros estamos haciendo. Mientras nosotros estamos trabajando con estas versiones editadas, ya sean con la versión local como con la edición inactiva, lo que pasará es que el sistema seguirá manteniendo las versiones activas tal y como eran originariamente. Cualquier desarrollador sabrá que esos archivos están en su sitio, de forma indiferente a los planes que nosotros tengamos para ellos, pero no tendrán la oportunidad de editarlos. De esta manera se evitan complicaciones que podrían producirse si dos desarrolladores distintos editan el mismo archivo al mismo tiempo.

Cómo no, hagamos lo que hagamos, antes de proceder a la activación de cualquier tipo de cambio habrá que realizar una comprobación previa. En el sistema de NetWeaver lo que haremos será un check sobre los cambios locales que hayamos llevado a cabo. De esta manera se comprobará la viabilidad del trabajo que hemos realizado y si existe margen para el error o si todo está perfecto. Si no hay sobresaltos y todo va bien, la activación se producirá sin que nos tengamos que preocupar absolutamente de nada.

Esta es una gran ventaja de este paso, dado que no se ralentiza el proceso y se garantiza un alto nivel de seguridad. No penséis tampoco que es mejor que con ABAP, puesto que lo que ocurre con la alternativa es que el check se realiza de manera simultánea a la activación, lo cual tampoco está mal, sobre todo si no solemos cometer errores.

 

3. Proceso de prueba

Por último damos salida al proceso de prueba para ver que las comunicaciones entre las dos piezas del sistema híbrido funcionan de manera adecuada. Y cuando todo está más que ajustado se lanzan para ser transportados y que encajen en sus posiciones, momento a partir del cual serán asimilados. De esta forma nos habremos asegurado de potenciar el flujo de desarrollo en los sistemas SAP con sencillez, que viene a ser una de las principales peticiones que se suelen recibir.

 

Si te ha interesado este post, quizás también pueda ser tu interés esta guía gratuita en PDF:

Guía: Todo lo que necesitas saber sobre SAP en AWS

Categorías: SAP