El título de este artículo sólo lo entenderán los Boomers y los Milenials como yo. Mazinger Z eran unos dibujos animados japoneses sobre un niño y un súper robot acojonante que luchaba con otros robots acojonantes u otros bichejos. Tampoco lo recuerdo mucho.
El tema del que vamos a hablar no son los dibujos, no os preocupéis, pero el nombre me venía perfecto para lo que quería explicar.
El caso es que SAP es una herramienta estándar, de caja, instalar, configurar y listo. Esa es su ventaja competitiva, y eso es por lo que los clientes pagan las licencias tan baratas que cobra SAP. Eso es lo que le ha traído aquí a estar donde está, y lo que ha hecho que sus competidores vayan saliendo con sus soluciones «Out of the box» al igual que SAP (Salesforce, Oracle, Microsoft, etc).
Out of the box
Pero en ocasiones, como los niños o los gatos.
A ciertos clientes y consultores lo que les gusta es jugar con la caja y no con el contenido.
Entienden que lo divertido es lo que ponga en la caja del software pero los procesos estándar, aplicaciones, integraciones no se adecúan a ellos.
Es aquí donde nace SAP Mazinger Z, poco a poco empresas, consultores y desarrolladores van construyendo una especie de sistema paralelo al sistema estándar.
Ampliaciones en SAP
Pero ¿por qué he traído el nombre de Mazinger Z? Porque en SAP, las ampliaciones de cliente se realizan, normalmente, con el prefijo Z. Hay locos que usan ‘Y’, pero esa gente quiere ver el mundo arder.
Yo entrando en un proyecto donde las ampliaciones comienzan por Y
Y claro, ceñirse al estándar es, en ocasiones, más difícil que hacerte un Mazinger Z monstruoso.
El primer nivel que debe controlar esto es el propio cliente, que es el dueño del negocio y es el que compra el producto (SAP) y debe ser consecuente con esa decisión.
Nadie compra un Ferrari para llevar una caravana
El segundo nivel es la consultoría. Como consultores tenemos la obligación de conocer la herramienta y saber adaptar el negocio del cliente manteniendo, en la medida de lo posible, el estándar. Ofrecerle al cliente las mejores prácticas tecnológicas de un software usado por miles de empresas. En definitiva, ser un buen consultor.
Y es que, en ocasiones, los sistemas se modifican tanto o se crean tantos procesos no estándar y tan complejos (y mal codificados/documentados) que el cliente y la consultora se hace presa del desarrollo realizado. En ocasiones me he encontrado con semidioses intocables, creadores del averno codificado, que están ahí porque son los padres de la fiera y los únicos que saben domarla. Se han convertido en los dueños del Mazinger Z.
Upgrades y actualizaciones estándar
Porque claro, cuando se compra una herramienta como SAP se paga una licencia anual que, entre otras cosas, te asegura el soporte y mantenimiento de la herramienta estándar, corrigiendo errores vía Support Packages o Notas. Además puedes querer o necesitar un upgrade a una nueva versión superior.
Cada vez que SAP lanza una actualización, los desarrollos Z pueden generar incompatibilidades que requieren tiempo y recursos adicionales para ser resueltos, afectando la agilidad del negocio.
Futuro y tendencia
Con el avance de las plataformas Low-code y No-code, el futuro del desarrollo en sistemas ERP podría orientarse hacia configuraciones cada vez más sofisticadas sin necesidad de recurrir a desarrollos complejos, facilitando el mantenimiento y las actualizaciones. Ejemplos de esto en SAP seria, SAP Build, SAP Build Code, Github Copilot, Microsoft Power Platform, etc.
El desarrollo dentro de suites como SAP es, sin duda, necesario, pero, como consultores, tenemos que conocer la herramienta y sus posibilidades, saber si de una manera u otra los requerimientos del negocio pueden ser satisfechos configurando la herramienta y, finalmente, si es necesario un desarrollo, acotar bien el alcance del mismo.
En un mundo donde la tecnología evoluciona rápidamente, saber cuándo y cómo construir tu propio ‘Mazinger Z’ dentro de SAP puede ser la diferencia entre un sistema que empodera a tu negocio y uno que lo atrapa en su propia complejidad.
Vamos a hablar de una de las metodologías de gestión de proyectos y desarrollo de software que más se ha estado usando y de la que vamos a analizar y definir para tener una idea global de sus características, ventajas e inconvenientes. Hablaremos de las metodologías Agile (a·jile).
Agile es un conjunto de metodologías de gestión de proyectos y desarrollo de software que se centra en la entrega incremental, la colaboración entre equipos multifuncionales y la adaptación constante al cambio. Surgió en 2001 con la publicación del Manifiesto Ágil, creado por un grupo de 17 desarrolladores de software que buscaban una alternativa más eficiente y flexible a las metodologías tradicionales como Waterfall. Desde entonces, Agile ha ganado popularidad no solo en el desarrollo de software, sino también en diversas industrias que valoran la capacidad de respuesta rápida y la mejora continua.
Se nota que priorizan que funcione la web a que sea bonita…
Individuos e interacciones sobre procesos y herramientas
Priorizar la comunicación y colaboración efectiva entre los miembros del equipo por encima de seguir procesos rígidos y usar herramientas específicas. Con esto se facilita la adaptabilidad, aumenta la motivación del equipo y fomenta la innovación. En ocasiones damos más valor al uso de herramientas y estándares para organizar el equipo y el trabajo, esto hace que perdamos mucho tiempo de valor y genere desmotivación y hartazgo.
Software funcionando sobre documentación extensiva
Este valor prioriza la entrega de software funcional que cumpla con los requisitos del cliente sobre la creación de documentación extensa. Si bien la documentación es necesaria, en Agile se considera más importante que el software funcione correctamente y aporte valor al usuario final. La documentación debe ser suficiente para apoyar el desarrollo y el mantenimiento, pero no debe convertirse en un fin en sí misma.
Colaboración con el cliente sobre negociación de contratos
En lugar de centrarse en la negociación de contratos detallados, Agile promueve la colaboración continua con el cliente. Esto significa que los clientes están involucrados activamente en el proceso de desarrollo, proporcionando feedback constante y participando en la toma de decisiones. La colaboración permite al equipo ajustarse mejor a las necesidades del cliente y responder rápidamente a los cambios.
Respuesta ante el cambio sobre seguir un plan
Este valor destaca la importancia de ser flexible y adaptarse a los cambios en lugar de seguir estrictamente un plan predeterminado. En un entorno ágil, se espera que los requisitos evolucionen y cambien a lo largo del proyecto. Los equipos ágiles están preparados para ajustar sus planes y procesos para acomodar estos cambios y maximizar el valor entregado.
Principios de Agile
Además, establece 12 principios que guían las prácticas Agile:
Satisfacer al cliente mediante entregas tempranas y continuas de software valioso.
Aceptar cambios en los requisitos, incluso en etapas avanzadas del desarrollo.
Entregar software funcional con frecuencia, desde un par de semanas hasta un par de meses.
Colaboración diaria entre desarrolladores y el negocio.
Construir proyectos alrededor de individuos motivados, y proporcionarles el entorno y el soporte que necesitan.
El método más eficiente y efectivo de transmitir información es la conversación cara a cara.
El software funcional es la medida principal del progreso.
Los procesos ágiles promueven el desarrollo sostenible.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo y ajusta su comportamiento en consecuencia.
Metodologías Agile Populares
SCRUM
Scrum es una metodología ágil que se centra en entregas incrementales de productos a través de iteraciones cortas llamadas sprints. Los elementos clave de Scrum incluyen:
Roles en Scrum
Scrum Master
Facilita el proceso Scrum, asegura que todos comprendan y sigan los principios de Scrum, elimina impedimentos y ayuda a mejorar la productividad del equipo. Organiza eventos Scrum, optimiza la gestión del backlog y colabora estrechamente con el Product Owner.
Product Owner
Representa los intereses del cliente o negocio, define y prioriza los requisitos del producto. Gestiona el Product Backlog, documenta y prioriza las necesidades y responde a las preguntas del equipo de desarrollo.
Equipo de Desarrollo
Entrega incrementos de producto potencialmente utilizables al final de cada Sprint. Equipos autoorganizados y multifuncionales, responsables de sus éxitos y fracasos.
Eventos en Scrum
Sprint
Periodo de tiempo fijo (un mes o menos) en el que se crea un incremento de valor. El propósito es mantener al equipo enfocado y permitir ajustes basados en la retroalimentación.
Sprint Planning
Evento que define lo que se puede entregar en el Sprint y cómo se logrará. Seleccionar y planificar el trabajo del Product Backlog para el Sprint actual.
Daily Scrum
Reunión diaria de 15 minutos para inspeccionar el progreso hacia el objetivo del Sprint y ajustar el plan de trabajo. El objetivo es mejorar la comunicación, identificar impedimentos y tomar decisiones rápidas.
Sprint Review
Revisión del trabajo completado durante el Sprint con los stakeholders. El objetivo es inspeccionar el resultado del Sprint y adaptar el Product Backlog basado en la retroalimentación.
Sprint Retrospective
Evento final del Sprint para reflexionar sobre el proceso y planificar mejoras para mejorar la calidad y efectividad del equipo mediante la identificación de áreas de mejora
Herramientas de Scrum
Product Backlog
Lista ordenada de todo lo necesario para el producto. Ha de ser la única fuente de requisitos para el equipo de Scrum.
Sprint Backlog
Conjunto de Product Backlog items seleccionados para el Sprint, junto con un plan para entregar el incremento. Guiará el trabajo del equipo de desarrollo durante el Sprint.
Increment
Suma de todos los Product Backlog items completados durante un Sprint y los incrementos de todos los Sprints anteriores. Provee un incremento de producto utilizable y que cumpla con la definición de «Done».
KANBAN
Kanban es una metodología de gestión ágil que ayuda a los equipos a visualizar su trabajo, maximizar la eficiencia y mejorar continuamente. Originada en el sistema de producción de Toyota en los años 1940, Kanban se ha adaptado para el desarrollo de software y otros entornos de trabajo que requieren gestión de flujos de trabajo y optimización de procesos.
Ahí pone: «Tonto el que lo lea»
Principios de Kanban
Comienza con lo que haces ahora: Kanban no requiere cambios radicales iniciales. En lugar de eso, comienza con los procesos actuales y se mejora de manera incremental.
Busca el cambio evolutivo e incremental: Implementa cambios pequeños y manejables para evitar la resistencia al cambio y minimizar riesgos.
Respeta los procesos, roles y responsabilidades actuales: La metodología Kanban se integra con los procesos existentes y los mejora sin causar grandes disrupciones.
Fomenta el liderazgo a todos los niveles: Todos los miembros del equipo, desde los directivos hasta los empleados, son responsables de contribuir a la mejora continua.
Prácticas de Kanban
Visualiza el flujo de trabajo
Utiliza tableros Kanban para representar visualmente las etapas del trabajo, como «Por hacer», «En progreso» y «Hecho». Esto ayuda a todos a ver el estado del trabajo en tiempo real. Yo, personalmente, uso mucho la herramienta Trello para coordinar el trabajo del equipo y controlar el estado de los requerimientos del proyecto.
Limita el trabajo en progreso (WIP)
Establece límites en la cantidad de trabajo que se puede realizar simultáneamente en cada etapa del flujo de trabajo para evitar sobrecargas y mejorar el enfoque.
Gestiona el flujo
Supervisa y mide el flujo de trabajo para identificar cuellos de botella y asegurarte de que el trabajo se complete de manera fluida y predecible.
Hacer explícitas las políticas
Define y comunica claramente las reglas y políticas de trabajo, como criterios para mover tareas entre columnas, límites de WIP y procedimientos de revisión.
Implementa bucles de retroalimentación
Establece reuniones regulares para revisar el progreso, discutir problemas y planificar mejoras. Esto puede incluir reuniones diarias, revisiones de flujo y retrospectives.
Utiliza datos y retroalimentación para realizar cambios experimentales y medir su impacto, permitiendo ajustes y mejoras continuas
Beneficios de Kanban
Mejora la comunicación: Los tableros Kanban proporcionan una visión clara del estado del trabajo, mejorando la transparencia y la comunicación entre los miembros del equipo.
Priorización efectiva: Ayuda a los equipos a enfocarse en tareas que realmente importan y a priorizar eficientemente.
Visibilidad y transparencia: Hace visibles los cuellos de botella y otros impedimentos en el proceso de trabajo.
Asignación eficiente de recursos: Permite una visualización clara de la carga de trabajo de cada miembro del equipo, optimizando la distribución de tareas.
Mejora continua: La naturaleza iterativa de Kanban facilita la identificación y eliminación de obstáculos a lo largo del proceso, promoviendo la mejora continua
Extreme Programming (XP)
Extreme Programming (XP) es una metodología ágil de desarrollo de software que se enfoca en mejorar la calidad del software y la capacidad de respuesta a los cambios en los requisitos del cliente. Fue creada por Kent Beck a finales de la década de 1990 y se caracteriza por una serie de prácticas que se combinan para mejorar la productividad y la calidad del producto final.
Me da que a esto no nos referimos
Principios Básicos de XP
Como podemos ver en la web oficial de Extreme Programming, los principios/valores de XP son:
Pero ¿Qué significan todos estos principios del XP? Pues el objetivo es mejorar la calidad del software y la eficiencia del equipo de desarrollo pero teniendo en cuenta la colaboración, la simplicidad en el diseño, la adaptación rápida a los cambios, y la creación de un ambiente de trabajo respetuoso y sostenible. Es decir crear un entorno donde los equipos de desarrollo puedan producir software de alta calidad de manera rápida y efectiva, respondiendo ágilmente a las necesidades cambiantes del cliente. No está nada mal todo esto
Prácticas de XP
Ahora bien, ¿Cómo se pone en práctica estos conceptos teóricos? Todos sabemos que el papel lo soporta todo y que de buenas intenciones está empedrado el infierno. Vamos a ver las prácticas de Extreme Programming:
Desarrollo Iterativo: El software se desarrolla en iteraciones cortas, típicamente de una a tres semanas. Entronca con los Sprints de Scrum.
Planificación iterativa: El cliente y el equipo de desarrollo colaboran para planificar qué funcionalidades se desarrollarán en cada iteración.
Pruebas Unitarias: Los desarrolladores escriben pruebas automáticas para cada pequeña pieza de funcionalidad antes de escribir el código correspondiente.
Refactorización: Mejorar el diseño del código existente sin cambiar su funcionalidad externa.
Programación de pares: Dos desarrolladores trabajan juntos en una misma computadora, alternando roles de escritura y revisión de código.
Propiedad Colectiva del Código: Cualquier miembro del equipo puede modificar cualquier parte del código en cualquier momento.
Integración Continua: El código se integra y se prueba frecuentemente, al menos una vez al día.
Metáfora del Sistema: Utilizar una metáfora simple y común para guiar el diseño y el desarrollo. Es como usar una comparación fácil de entender para que todos estén alineados sobre cómo debería funcionar el software, facilitando la comunicación y la colaboración.
Diseño Simple: Se mantiene el diseño tan simple como sea posible. Aqui viene el principio KISS (Keep It Simple, Stupid!)
Semana Laboral Sostenible: Se evita el exceso de trabajo y se mantiene un ritmo sostenible.
Cliente disponible: El cliente debe estar disponible para responder preguntas y proporcionar retroalimentación continua.
Estándares de Codificación: Se acuerdan y siguen estándares comunes de codificación.
Conclusión
Cada una de las metodologías (Scrum, Kanban, XP) dan para un artículo, varios o incluso cursos al respecto. Yo no soy un experto, solo lo conozco y uso un poco de cada cosa según me convenga. Espero, al menos, que sirva de introducción a las metodologías Agile.
Hoy vamos a hablar de un tema que me afecta directamente pero que, creo, tengo controlado. ¿Verborrea? ¿Meter la pata? No, eso no lo tengo controlado. Vamos a hablar de ser perfeccionista.
Cuando termines de cortar este lado del césped ya te ha crecido el otro
La Psicología del Perfeccionismo
Psicológicamente, el perfeccionismo surge de un deseo profundo de evitar el fracaso y la crítica. En muchos casos, tiene raíces en la inseguridad y el miedo, dos factores que también alimentan problemas como el Síndrome del Impostor. Este último se manifiesta cuando crees que no eres lo suficientemente competente para la labor asignada, a pesar de tener pruebas objetivas de lo contrario.
El perfeccionismo, aunque en algunas situaciones puede ser una fuerza motivadora, se vuelve problemático cuando llega a niveles obsesivos. Esto puede traducirse en estrés, ansiedad y una continua sensación de insuficiencia. Paradójicamente, en la búsqueda de la perfección, se terminan sacrificando tanto la salud mental como la calidad de vida, dañando la autoestima y las relaciones interpersonales en el proceso.
Lo perfecto es enemigo de lo bueno
Y es que no se es mejor por hacer las cosas de forma perfecta, eso es un ideal inalcanzable. Al querer hacer algo perfecto, no consigues terminarlo nunca o el resultado va a ser peor de si hubieses sabido parar cuando ya era bueno.
La búsqueda constante de mejoras lleva a un ciclo en el que nunca se está satisfecho, lo que puede paralizar la toma de decisiones y la innovación, especialmente en industrias como la tecnología y el desarrollo de software.
Au revoir que dijo Voltaire
El objetivo no es buscar la perfección, sino encontrar un equilibrio entre calidad y esfuerzo. En el mundo de la consultoría TI y SAP, donde los proyectos tienen plazos ajustados y la presión por entregar resultados es constante, es esencial aprender a identificar cuándo algo es «suficientemente bueno«.
El ratio calidad-esfuerzo «perfecto» es el que no intenta llegar a la «perfección»
Parálisis por Análisis
El ser perfeccionista no solo trata de aquello que haces, también trata de lo que planeas hacer. Querer tomar el análisis perfecto como punto de partida para la selección, desarrollo o implementación de una solución tecnológica puede hacer que nunca consigas siquiera iniciar dicha iniciativa.
¿Cuántas iniciativas personales he iniciado y terminado en el análisis? Gastando una cantidad de tiempo energía enormes, y que al final no lo ejecuté porque cuando quise hacerlo ya se me pasó el interés o voló el momento oportuno.
Lo mismo he visto en clientes, que nunca evolucionan por querer hacer el salto tecnológico con todo perfectamente atado y cinco paracaídas. Por suerte, los jefes de tecnología de muchos de los clientes son conscientes de esto, han sido consultores y saben que hay que saltar al vacío y presionarse todos a salir a producción, aunque haya temas pendientes.
Procrastinación: El gemelo malvado del perfeccionismo
Otro aspecto importante a considerar es cómo el perfeccionismo y la procrastinación suelen ir de la mano. Cuando intentamos alcanzar un estándar inalcanzable, es común retrasar el inicio de tareas importantes, precisamente por el miedo a no cumplir con esas expectativas. El perfeccionista puede postergar decisiones o acciones con la esperanza de que, con más tiempo, logrará acercarse a ese ideal. Sin embargo, esta dilación puede llevar a una sobrecarga de trabajo en el último minuto, comprometiendo la calidad final y aumentando los niveles de estrés.
Delegar o no delegar, esa es la cuestión
El perfeccionismo no solo afecta cómo abordas tus propias tareas, sino también cómo gestionas las tareas de los demás. Si eres un líder de equipo o un consultor, es posible que te cueste delegar, pensando que «nadie más puede hacer el trabajo tan bien como tú». Este comportamiento, lejos de ser eficiente, puede llevar a un agotamiento personal y a una falta de confianza dentro del equipo. Aprender a confiar en las capacidades de otros y aceptar que el trabajo de un compañero puede ser «suficientemente bueno» es clave para romper con la trampa del perfeccionismo.
Impacto en la Innovación: El dilema de la Beta perpetua
En el mundo del desarrollo de software, el perfeccionismo puede frenar la innovación, especialmente en proyectos ágiles que requieren iteraciones rápidas. Hay equipos que nunca lanzan una versión porque siempre hay «algo más que mejorar». Este fenómeno, conocido como «beta perpetua», puede estancar proyectos y evitar que una solución llegue al mercado en el tiempo necesario. A veces, es más importante lanzar y aprender de los errores, que esperar a tener un producto impecable desde el inicio.
Aprendiendo a soltar: El arte de «dejarlo ir»
Una de las habilidades más valiosas en la vida profesional y personal es aprender a soltar. El perfeccionismo puede hacer que te aferres a detalles insignificantes, perdiendo de vista el panorama general. Adoptar la mentalidad de «mejor hecho que perfecto» no significa conformarse con la mediocridad, sino entender que cada proyecto o tarea tiene un punto de rendimiento decreciente, donde el esfuerzo adicional no se traduce en mejoras significativas. Soltar es un acto de confianza en uno mismo y en los demás.
En Conclusión
El perfeccionismo puede ser tanto un impulso hacia la excelencia como una trampa paralizante. Es mejor hacer cosas imperfectas que no hacer nada por intentar llegar a un estándar inalcanzable. Lo esencial es aprender a identificar cuándo algo es «suficientemente bueno» y entender que, en muchos casos, lo perfecto es enemigo de lo bueno. La clave está en avanzar, incluso si no todas las piezas están perfectamente alineadas, porque en el camino se aprende y se mejora.
Podría continuar con este artículo ahondando en estrategias para manejar ese estado, pero bah,o voy a dejar aquí, que ya se entiende lo que quería expresar.
Espera, creo que este artículo todavía se puede mejorar más. ¡Pongamos más gifs animados!
¡No! Tampoco lo van a leer tantos y en algún momento tienes que cerrarlo. Total, te va a salir mal porque en realidad eres un impostor que vas de listo.
Para ello lo primero es diferenciar las dos roles que puede actuar nuestro sistema en base a una comunicación vía servicio web.
Publicador: se trata del sistema que publica el servicio web y que espera ser llamado.
Consumidor: se trata del sistema que consume un servicio web existente de otro sistema.
Y esto es importante porque en base a esto lo que tenemos que hacer en el sistema difiere.
Serie de Artículos sobre servicios SOAP en SAP
Este artículo pertenece a una serie de artículos sobre la gestión de servicios SOAP en SAP:
Servicios Web SOAP en SAP – Publicar un servicio SOAP (Este artículo)
Publicar un Servicio Web SOAP
Publicar un servicio Web SOAP supone la creación de una puerta de entrada para que un sistema externo nos llame y nosotros realicemos la acción para la que esté hecho el servicio Web. Esta acción puede ser la consulta o búsqueda de datos en base a una entrada o bien la creación o modificación de registros o la ejecución de una acción en nuestro sistema. Sea cual sea la opción el proceso es similar. Veámoslo.
Para publicar un servicio web SOAP lo primero que tendremos que hacer es un módulo de función que tenga la lógica que queramos implementar, con los parámetros de entrada/salida que queramos publicar para la ejecución de la lógica implementada.
En este ejemplo vamos a crear nuestro módulo de funciones de recuperación de datos del BP en base al modelo de datos que hemos visto anteriormente, lo llamaremos ZCRM_GET_BP_DATA. Y tendrá la siguiente estructura
Parámetros de Entrada
Parámetros de salida
En este caso contendrá la estructura de datos generales que tenga los datos de la BUT000 y las tablas de funciones, direcciones, relaciones e identificadores. Es importante destacar que, para que este módulo de función pueda ser usado como base para un servicio SOAP es necesario que sea de acceso remoto, por lo que todos los parámetros deben ser de Traspaso de Valores.
Módulo de función de acceso remoto
Importante es que ese MF esté marcado como de acceso remoto (RFC).
Lógica del Servicio Web
La lógica a aplicar, en este caso de consulta de bps, será algo sencillo. Recuperamos los datos de las tablas BUT000, BUT100, ADRC, BUT050 y BUT0IE.
Y, al ejecutar el Módulo de Función, vemos su resultado.
En este ejemplo hemos implementado una consulta de datos pero podemos hacer lo que queramos, al final es un Módulo de Función y puede hacerse creaciones, Borrados, actualizaciones o, como en este caso, consultas.
Wizard de creación del servicio
Una vez tengamos el Módulo de Función de acceso remoto tendremos que ir a la SE80 o bien pulsar el botón para acceder al repositorio.
Una vez en el repositorio buscamos nuestro MF en la lista y haciendo click derecho del ratón encima del Módulo de Función y accederemos a la opción «Crear->Enterprise Services» .
Y comienza el Wizard de creación del servicio SOAP. Lo primero en ponerle un nombre y descripción.
El siguiente paso es seleccionar el módulo de función, pero como hemos comenzado este wizard desde un Módulo de Función esto nos vendrá dado.
El siguiente paso es definir el perfil de seguridad del servicio. Esto nos permitirá, más adelante, en la SOAMANGER configurar unas opciones u otras de seguridad. Yo siempre elijo la LOW, que obliga al llamante a indicar usuario y password pero sin necesidad de hacer la comunicación con certificados entre máquinas. Para eso suele estar la gente de sistemas y seguridad que determinan los sistemas que pueden entrar.
Por último tenemos que seleccionar el paquete y la orden de transporte. En este ejemplo lo he puesto como objeto local porque es una prueba.
Al finalizar el Wizard nos aparecerá la definición del servicio.
Donde además veremos la estructura y tipo de datos de Entrada/Salida del servicio (que son los del módulo de función).
Tenemos que guardar y activar este servicio creado y con esto hemos terminado la primera parte, pero todavía no es accesible este servicio desde fuera, porque nos falta crear en Endpoint o puerto lógico de acceso.
SOAMANAGER
Ya tenemos el Servicio a nivel técnico creado, pero tenemos que publicarlo. Para publicarlo y crear el Endpoint con sus opciones tenemos la herramienta SOAMANAGER en SAP. Para acceder a la SOAMANAGER, la forma más sencilla es introducir la transacción SOAMANAGER en el SAP GUI.
Una vez aquí veremos muchas opciones. Para poder publicar un servicio SOAP tendremos que ir a la opción «Web Service Configuration» y ahí nos saldrá un buscador de servicios tanto de Publicador como de Consumidor.
En esta aplicación podemos buscar servicios publicados (Service Definition) o Servicios a consumir (Consumer Proxy). En este caso buscamos nuestro servicio creado en la SE80 usando el Object Type «Service Definition».
Pulsamos en nuestro servicio creado en la SE80 para acceder a su configuración,.
Cuando accedemos a él veremos que no tiene ningún Service/Binding creado, esto es la creación de Endpoints o puestas de entrada al servicio. Como no tenemos ninguna pulsamos al botón Create Service.
Y empezará un nuevo Wizard. En la primera pantalla le datos un nombre al Servicio a publicar (habitalmente le pongo el mismo que el nombre del servicio creado en la SE80), una descripción y un nombre al Binding o puerto lógico para construir el Endpoint.
En el siguiente paso, nos aparecerán las opciones dependiendo lo que hayamos configurado en el wizard de creación del servicio de la SE80. En mi caso tengo la opción de seleccionar que es necesario usuario y contraseña para poder acceder. Si vuestro departamento de sistemas o de seguridad os pide algo más sería en la creación del servicio y aquí donde hay que afinar.
Los siguientes pasos no hay que hacer nada. Finalizamos el wizard.
Una vez publicado el Servicio y creado el Endpoint tendremos disponible el WSDL para mandárselo al consumidor del servicio web que corresponda. Como vimos en la entrada:
El fichero WSDL (Web Services Description Language) es un fichero para describir la estructura y el uso de un servicio web SOAP. Este fichero puede estar disponible vía URL o como fichero plano. Pero siempre es mucho más recomendable que sea vía URL porque puede tener dependencias con otros ficheros XSD (XML Schema Definition). Para acceder a la URL del WSDL del endpoint recién creado de nuestro servicio pulsamos en este icono.
Y veremos en la parte inferior, en el campo WSDL URL for Binding la URL para acceder al WSDL. Nota: Si hemos puesto que necesitamos Usuario y Contraseña para que alguien consuma el servicio también lo necesitará para consultar el WSDL.,
Si copiamos la URL y la abrimos en un navegador veremos un archivo XML de esta forma.
La importancia del WSLD
El archivo WSDL es fundamental para el correcto uso de un web service SOAP, sea cual sea la tecnología. Define las operaciones disponibles, los tipos de datos de entrada y salida, y el protocolo de comunicación. Esto permite que cualquier sistema que consuma el servicio entienda cómo interactuar con él.
El WSDL contiene:
Tipos de datos: Estructuras que se envían y reciben, así como los tipos de datos y longitudes. Esto es de suma importancia porque SAP es muy estricto en esto (y otros sistemas se ve que no) y si recibe algo que no se acoge a la definición da error en la entrada.
Mensajes: Solicitudes y respuestas entre el cliente y el servicio.
Operaciones: Acciones que el servicio web puede ejecutar.
Bindings: Protocolo de comunicación y formato de los mensajes (SOAP/HTTP).
Puertos/Servicios: La URL para acceder al servicio y sus modos de seguridad.
Al compartir el WSDL, se facilita la integración y se garantiza que diferentes sistemas puedan comunicarse correctamente con el servicio, independientemente de su plataforma o lenguaje de desarrollo.
Conclusión y Siguientes Pasos
En una entrada posterior vamos a ver cómo manejar el WSDL para poder hacer pruebas sobre servicios web publicados por nosotros en SAP o consumidos de otros sistemas externos. Con lo que continuaremos esta entrada sobre la publicación de servicio SOAP en SAP añadiendo la gestión de errores y logs, las formas de probar los servicios, etc.
Además otro de los apartados importantes será Cómo consumir un servicio web SOAP de un sistema externo en SAP. A
Al igual que hicimos en diciembre de 2023 en la entrada «Hablemos de esto«, donde desgranamos el estado del Blog, su pasado y el enfoque futuro, ahora toca, justo 1 año después, hacer balance de este año y mirar adelante.
ATENCIÓN: Este artículo no tiene nada de humor, ni de SAP, ni de consultoría, ni de Inteligencia Artificial. Ni pierdas tiempo en leerlo a no ser que quieras conocer el Blog un poco más por dentro.
Año 2024
Bueno, el 2024 ha sido un año bastante intenso. Desde el anterior «Hablemos de esto» he publicado en el blog 43 artículos, 50.000 palabras, lo cual ni me lo creo yo. Luego desgranaré un poco todo este contenido poniendo números y categorías.
Es decir, si el año 2024 tuvo 52 semanas casi publiqué una entrada por semana, con los parones de verano y navidad. Y con las palabras que pone en el resumen ya puedo tachar eso de «escribir un libro».
Mi situación personal/profesional
A nivel personal/profesional he tenido un viaje algo movido. Empecé el año siendo empleado por cuenta ajena en Deloitte, lo cual expliqué en la entrada:
Pasé por un bache importante a nivel personal y profesional. Lo cual me hizo volver a ordenar mis prioridades, mis objetivos y mi estado en ese momento. A mitad de año volví a ser lo que siempre había sido, volví al mundo Freelance de la mano de Avvale y volví a un cliente conocido. Lo puedes ver en la entrada:
A pesar de todo esto, he mantenido el objetivo de hacer crecer el blog, que solo es mantenido por mi mismo, y generar algo de impacto en internet con él (eso ya es más difícil). Creo que es para estar orgulloso poder decir que he estado un año entero publicando un artículo, más o menos, cada semana, dándome igual el número de visitantes e intentando aprender y dar a conocer aquello que me interesa. Además de esto estoy inmerso en proyectos profesionales muy interesantes y que me motivan. Y en proyectos personales para mejorar día a día.
Números del Blog
Vamos a la chicha, al éxito medible, pero cuidado, que como vimos en el artículo…
…el éxito no es solamente aquello que se puede medir. Además de estos números me llevo sobre todo el aprendizaje. Además me sirve para darme a conocer y generar mi imagen profesional de internet como vimos en el artículo:
Ahora veamos la estadística de visitantes y visitas.
Visitas (verde claro) y Visitantes únicos (verde oscuro)
Bueno, queda claro el salto cuantitativo (y cualitativo) que ha dado el blog en este año. Realmente el salto de calidad fue desde Junio de 2023, que retomé esto de escribir en el blog, pero las visitas orgánicas (las de los buscadores) van creciendo con el tiempo, si vemos los mismos datos por mes, vemos que la subida de visitas y visitantes va sucediendo, más o menos, desde septiembre del 2023.
Visitas (Azul) y Visitantes únicos (rojo)
Artículos más visitados
Pues si miramos las estadísticas esta bastante claro cuales son los artículos más visitados.
Además tiene mucho que ver con el posicionamiento en buscadores y del interés de la comunidad de esta tecnología. El artículo en cuestión es el siguiente:
Y al ver que este artículo donde se explica como se gestiona OData en SAP vía el SAP Gateway comencé la serie de artículos sobre OData.
Además de esto se nota también una preocupación sobre uno de los aspectos que modifican más nuestras certezas de SAP ECC al pasar a S4, los Business Partner.
Lo que está claro es que la mayor parte de las visitas las recibo desde buscadores en temas concretos de SAP. ¿Por qué? Porque de psicología del trabajo, de metodologías de gestión de proyecto, etc. está Internet lleno y, obviamente, mi aportación no es importante.
¿Por qué escribes de otros temas?
Pues porque me gusta escribir, porque me gusta aprender, porque hay algunos de los artículos que me permiten ser más libre y más literario y me gusta enlazar conceptos que en mi mente están enlazados, como por ejemplo la piscología del trabajo y los mitos de la mitología griega.
Como he comentado anteriormente, muchas de las visitas que recibe el blog se debe a visitas desde buscadores. Esto significa visitas orgánicas, visitas que se realizan por la relevancia del contenido publicado en los buscadores (mayoritariamente Google). Cabe destacar que el blog está alojado en WordPress.com y yo no realizo ningún tipo de estrategia SEO para optimizar la presencia en buscadores, más que nada porque son de pago y no quiero gastarme un euro en esto. El posicionamiento, por tanto, es debido a:
Contenido de calidad: El contenido es interesante (algunos) y atractivo para los usuarios de los buscadores.
Periodicidad y Constancia de las publicaciones: A Google no le gusta nada los sitios que no avanzan, le gusta los creadores de contenido, que sigas creando, publicando, que estés activo.
Etiquetas, Categorías, Encabezados, Textos de Imágenes, Lista de conceptos: Seguro que en este punto podría mejorar, pero si se lo pones fácil a los robots de los buscadores, teniéndolo todo bien organizado, te lo agradecen.
Una vez dicho esto podemos ver como algunas palabras clave o búsquedas de Google devuelven el blog como uno de los primeros resultados (por lo menos en España y descontando enlaces patrocinados):
El simple hecho de estar en primera página va a atraer a muchas visitas. Y el trabajo ya está hecho y habrá muchas visitas orgánicas que vayan entrando solo por aparecer y aportar contenido de cierta calidad.
¿Desde donde me leen?
Pues en este 2024 sigue siendo principalmente desde España.
Y desde qué plataformas, pues principalmente desde motores de búsqueda (Google, etc.)
Organización del Blog
Como vimos en el «Hablemos de esto» de 2023, había abierto el blog a otros temas más allá de SAP. Este año ha sido el de aterrizar los grandes bloques del blog e ir generando contenido en base a esos temas, que son los temas de mi interés. Son los siguientes
Y las categorías han venido solas, al abrir el blog a cualquier aspecto relacionado con mi profesión, cualquier tema que me interesase ha sido objetivo de estudio y explicación.
Además de estas categorías, en el blog he iniciado distintas series de artículos relacionados.
OData y SAP Gateway
Blockchain
Errores en SAP
Calidad del código ABAP
Mi objetivo con el Blog
Bueno, mis objetivos sigue siendo el mismo. Por orden de importancia serían:
Aprender: Este es el principal objetivo del Blog. Siempre que he dado un curso, he hecho un manual, he explicado algo a alguien, siempre, he aprendido algo. En el blog, en muchas ocasiones, cojo temas que me interesan pero de los cuales me falta conocimiento. Investigando, analizando, probando, organizando la información y escribiéndola me el conocimiento. Sobre los temas que ya sé, profundizo y, al tener que explicarlos resuelvo dudas o descubro algo que no usaba o conocía.
Perfil profesional: No cabe duda que el blog es un gran escaparate, que te proporciona un aura de experto por el simple hecho de escribir, ya ves tú. Pero yo siempre me he cuidado de aquello que puedan encontrar de mí en Internet, que sea bueno. Si a esto le sumas que aprendo por el camino…
Me gusta escribir: Me gusta leer y me gusta escribir. En mi situación personal actual, con niños y trabajo, mis hobbies están físicamente reducidos al tener que estar de vigilante de las fieras en casa. Pero el móvil lo tengo en la mano, y puedo escribir. Podría estar jugando a juntar caramelitos, pero escribir también me divierte.
Siguientes pasos
Bueno, he llegado a tener más de 20 artículos escritos pendientes de publicarse y es verdad que este Noviembre-Diciembre he estado más «despistado» en la escritura. Sigo teniendo muchas ideas y muchos retos por delante. Mi vida a nivel personal es complicada y no me deja mucho tiempo, además estoy en un proceso personal de mejora continua (leer, hacer ejercicio, otros proyectos profesionales, etc) y tengo que encajar todo en el tiempo que tengo.
para acceder al repositorio.
Jorge Ocampos 