SAP Build

Vamos a entrar en la harina de SAP Build, hemos ido preparando el terreno con los artículos Low-Code / No-Code y SAP BTP – Business Technology Platform (el que no los haya leído es una buena base para esto que vamos a contar). Ahora toca entrar en la suite de Low-Code/No-Code y RPA de SAP, SAP Build.

De cara a entender bien este artículo os recomiendo la realización de los cursos (gratuitos):

Como comenté en el artículo de Low-Code / No-Code, SAP compró la empresa AppGyver para potenciar la parte de Low-Code y automatización, de ahí SAP creó SAP Build Apps. Además está cimentado sobre SAP BTP como framework de trabajo. Pero SAP Build no es sólo eso, tiene tres áreas fundamentales, cada una especializada en un propósito:

SAP Build Apps

Inicialmente llamado AppGyver, con SAP Build Apps podemos realizar, arrastrando cajitas, aplicaciones web o de movilidad sin necesidad de tirar ningún código. Un ejemplo sacado de la cuenta oficial de SAP:

¿Podrías ir más rápido por favor?

A ver, va a toda máquina y nos perdemos un poco, pero el concepto es que, sin necesidad de desarrollar código es capaz de hacer una aplicación. Contamos con un área de trabajo con zonas bien diferenciadas:

No voy a explicarlo todo, que para eso está el curso que es ameno y fácil. Pero básicamente tenemos:

Canvas: El lienzo propiamente dicho, donde se van a poner los componentes visuales.
Listado de componentes: Donde poder usar botones, campos de texto, labels, checkbox, imágenes, etc. Sólo con arrastrar y soltar en tu lienzo ya lo tienes.
Propiedades: Para cambiar las propiedades de los componentes. Nombre, texto, etc…
Logic Pane: Muy importante. Abajo a la derecha hay un enlace «Add logic to…» para darle lógica a los botones, campos, etc. Solo tenemos que seleccionarlo y darle la lógica que queramos.
Data: Arriba tenemos otro botón importante, este para especificar una BBDD o bien una definir la llamada a un servicio REST.
Launch: Para probar nuestra App.

Ejemplo de una App creada por mi en Sap Build que genera un prompt para GPT, lo lanza contra la API y muestra el resultado (ya lo explicaré)

El resultado es una app móvil o web de este tipo:

Y con resultado de GPT

En otro artículo desgranaré cómo he creado esta aplicación en el SAP Build de pruebas que proporciona SAP.

SAP Build Process Automation

La aplicación SAP Build Process Automation combina gestión de Workflows y RPA (Robotic Process Automation) con herramientas visuales para hacer procesos sin necesidad de programar. Se apoya en la Inteligencia Artificial para adaptarse y saber leer el contenido de facturas, pedidos u otros documentos.

Con SAP Build Process Automation se puede hacer:

Crear Workflows con el inicio en un formulario o en el escaneo de un documento. Dichos workflows pueden contener formularios de aprobación, ramas condicionales, automatizaciones (RPA), iniciar otros workflows o usar contenido preconfigurado (como las librerías de Python)
Crear robots (RPA) para la realización de tareas repetitivas o tediosas, como extraer datos de documentos para pasarlos a nuestro sistema, o enviar emails automáticos. Todo esto pudiendo apoyarse en la Inteligencia Artificial para reconocer datos de las facturas y documentos. Se pueden crear robots como «cajas negras» de funcionalidad para ser llamadas en otros procesos como si fuesen una API (librerías).
Usar las automatizaciones ya preconfiguradas en la herramienta en nuestras propias automatizaciones.
SAP Build Process Automation contiene un Dashboard para monitorizar todos los workflows y automatizaciones.

Para ver ejemplos podemos pasarnos por el canal de youtube SAP Build Process Automation donde podemos ver videos demostrativos tan interesantes como este, que toma un documento y saca los datos de factura y comienza un proceso de aprobación.

A esto se le puede añadir Inteligencia Artificial para que, en vez de tener que tener una plantilla de campos, sepa identificarlos «viendo» el documento.

SAP Build Work Zone

Y por último, pero para nada menos importante. Tenemos el SAP Build Work Zone que es una plataforma donde los usuarios y administradores pueden crearse sus propios sitios web usando múltiples herramientas y tomando información tanto de aplicaciones SAP como externas.

Es complicado de entender y el papel lo soporta todo. Pero imaginaos que tenemos una herramienta donde poder crearnos nuestros sitios web con el resumen de todo lo que necesitamos en nuestro día a día, tanto interno de SAP como externo. Una especie de Cuadro de mando. Además de esto los administradores también pueden crear espacios de trabajo colaborativos, con foros, feeds, base de datos de conocimiento, etc… Y más aún, puedes compartir tus sitios creados o entrar en sitios creados por tus compañeros o los administradores.

¡¡Vaya!! ¿Dónde puedo comprar esto?

Todo esto, por supuesto, con tecnología Low-Code/No-Code. Usando el ratón y arrastrando y soltando. ¿Te lo crees? Pues yo a medias… 😅 Una cosa es poder crear páginas con datos y otra es ver cómo conectar las fuentes de datos a esos datos.

Versiones de SAP Build Work Zone

Hay dos versiones disponibles en el mercado las cuales no tienen nada que ver entre sí (cosas de SAP).

Standard Edition: Realmente es el antiguo Launchpad Service. SAP lo renonombró supongo que por temas de marketing, pero no tiene nada que ver con SAP Work Zone Advanced. Se trata de un servicio a activar en SAP BTP para ser usado y es tecnología SAPUI5.
Advanced Edition: Es el Work Zone que se presenta en los videos, imágenes y presentaciones. No tenemos acceso a probarlo porque lo que te deja SAP es probarlo en un sistema Trial de BTP y eso solo te permite activar el servicio de SAP Build Work Zone Standard Edition. Podeis ver más información al respecto en el Help de SAP. Si veo que hay interés quizás haga una entrada sobre esta parte que es la más «oscura» del ecosistema SAP Build.

Builders Beyond Code

El pasado 5 de Septiembre de 2023 hubo un evento en vivo en LinkedIn de SAP sobre SAP Build donde se habla de SAP Build y se muestran ejemplos y funcionalidades,.

En este evento se muestran ejemplos de todas las herramientas de la suite SAP Build. En concreto es muy interesante la parte en la cual Daniel Wroblewski muestra la funcionalidad en vivo (a partir del minuto 43). Donde muestra funcionalidades tan interesantes como:

SAP Build Apps (minuto 1:03): Crea una aplicación en 5 minutos que se conecta con un S/4 y muestra una lista de BPs.
SAP Build Process Automation (minuto 1:08): Cada vez que alguien cree un BPs de tipo individual en el sistema S/4 que se quiera relacionar con otro BP de tipo organización se lanzará un workflow de aprobación para que alguien apruebe esa creación. Pero en este caso no explica cómo ha hecho el RPA, simplemente muestra el resultado. Mal por Daniel.
SAP Build Process Automation (minuto 1:13): Usa la web www.rpachallence.com para demostrar que con RPA se pueden tomar datos de un excel, pasar cada campo a un campo del formulario y darle al botón.
SAP Build Process Automation (minuto 1:15): Copia un Proyecto del Store de SAP Build que envía mails vía outlook. Vamos que descubre el fuego. Realiza el envío de email vía un formulario externo, pero no le funciona (cosas del directo). El objetivo de esta demo era demostrar que, partiendo de un documento, word, pdf o excel de un evento con participantes, usando RPA puedes automatizar el envío emails de certificados de participación a todos los participantes.

No realiza ninguna demo de SAP Build Work Zone. 😥, supongo que por el mismo motivo por el cual no tenemos acceso a un SAP Build Work Zone de Trial. El resto de la charla es una ronda de preguntas acerca de procesos de negocio.

Mi Opinión

Creo que esto es otra tendencia a nivel de software empresarial. Las empresas de software tienen claro que democratizar el desarrollo les hace imprescindibles y se «controla» el desarrollo a medida sin control. Además es algo que se vende muy bien a los CIOs y CEOs de las empresas.

No obstante, creo que le queda mucho a todo esto para que sea una realidad palpable. La gente, con suerte, sabe pedir sus requerimientos a nivel tecnológico, como para saber implementarlos. El negocio va a seguir necesitando, y mucho, a consultores que traduzcan entre lenguajes. Y al final da igual que el consultor tenga que desarrollar 10.000 líneas de código en 3 meses, que tenga que hacer una app Low-Code/No-Code en 3 meses.

Estado de CRM en SAP – 2023

Nota: Nueva entrada de este Estado de CRM en SAP para el 2025 publicada.

Estado de CRM en SAP – 2025

Bueno, vamos a tomar el toro por los cuernos y e intentar armar el puzzle que tenemos acerca de la gestión de clientes (CRM, CX, o como lo quieras llamar) dentro del ecosistema SAP.

Y hay varias formas de abordar este trabajo, primero viéndolo desde donde venimos a donde vamos. Venimos de SAP CRM 7 On Premise, una solución que abarca las áreas Sales, Service, Marketing y Contact Center. Y vamos hacia el SAP CX (Customer Experience) varias soluciones, cada una con un paquete de funcionalidades, más especializadas en lo que saben hacer, pero independientes en su gran mayoría.

Pero, esto del SAP CX ¿Qué es? Pues muchas cosas, y esta es el segundo punto de vista, desgranar qué opciones tenemos. Aquí veremos términos como C/4HANA, S/4HANA for customer management, Hybris, Callidus, Emarsys, etc.

S/4HANA for Customer Management

Empiezo por aquí porque es la continuación natural al SAP CRM OnPremise de toda la vida (pero descafeinado). En S/4HANA se toma el concepto de Business Partner de SAP CRM OnPremise para clientes y proveedores, lo cual es un cambio importante para los consultores de ECC. Además se mantienen parte de las funcionalidades. Podemos verlo en el documento SAP S/4HANA for Customer Management – Feature Scope Description. En resumen tenemos la siguiente funcionalidad:

Faltan cosas importantes, como por ejemplo Marketing. No tenía sentido mantener Marketing en este sistema teniendo otros sistemas especializados en marketing como Emarsys, Marketing Cloud…

SAP C/4HANA

C/4HANA nació como el nombre comercial a un conjunto, mas o menos heterogéneo, de soluciones. Podemos ver su descripción en el blog de SAP What is SAP C/4HANA and why should you care? C/4HANA es la unión de varias herramientas, algunas compradas por SAP:

Hybris, como empresa de eCommerce, también fue comprado por SAP. Pero en esa marca comercial ha aglutinado también en la parte de C4C (Sales Cloud y Service Cloud).

SAP Customer Data Cloud: SAP renombró la herramienta Gigya como SAP CDC. Se trata de un gestor integral de identidades, autorizaciones, accesos y consentimientos para clientes, ofreciendo control y cumplimiento en la era de la privacidad de datos.
SAP Marketing Cloud: Basado en lo que era Hybris Marketing Cloud ha evolucionado para ofrecer capacidades avanzadas de marketing. La incorporación de Emarsys ha potenciado aún más Marketing Cloud, agregando funcionalidades de marketing automatizado y análisis de datos para una segmentación y personalización más eficaz.
SAP Sales Cloud: Sales Cloud, antes conocido como SAP C4C, es una herramienta de preventa y venta que facilita la gestión de leads, oportunidades y relaciones con clientes. La incorporación de CallidusCloud ha agregado funcionalidades como gestión de incentivos y automatización de la fuerza de ventas, enriqueciendo aún más la oferta de Sales Cloud.
SAP Service Cloud: Service Cloud, parte del original SAP C4C, se enfoca en la postventa, ofreciendo soporte y servicios al cliente a través de múltiples canales y plataformas..
SAP Commerce Cloud: Originalmente parte de Hybris, una empresa especializada en eCommerce, SAP Commerce Cloud es una herramienta omnicanal que ofrece una experiencia de compra unificada en múltiples plataformas y dispositivos.

Bueno el resumen del estado del CRM en SAP es muy escueto, cada apartado es, en sí mismo, un mundo. Además SAP está moviendo las fichas necesarias para dotar a la parte de CX de inteligencia artificial y procesos avanzados, como el SAP CDP Customer Data Platform. Pero si hay que desgranar, ya desgranaremos más adelante.

OData y SAP Gateway

Como el objetivo de este Blog es aprender y aportar conocimiento para que el que quiera aprenda, voy a explicar conceptos que, pareciendo básicos, puede ayudar a la gente a entender el ecosistema y las funcionalidades.

Serie de Artículos sobre OData

Este artículo pertenece a una serie de artículos que se van complementando poco a poco como itinerario de conocimiento:

OData y SAP Gateway (Este artículo)
OData y SAP Gateway – II – Publicar un servicio OData en SAP
OData y SAP Gateway – III – Recuperar Subentidades
OData y SAP Gateway – IV – Opciones sobre Entidades y Campos
OData y SAP Gateway – V – Documentar y Probar con OpenAPI

¿Qué es OData?

OData (Open Data Protocol) es una especificación abierta que define un conjunto de mejores prácticas para la construcción y el consumo de APIs RESTful. Fundamentado en protocolos web estándar HTTP, ATOM y JSON, permite a los desarrolladores exponer y consumir datos a través de servicios web de una manera simple y estándar.

Pero ¿Cuándo y por Quién?

Un poco de historia nos lleva de vuelta al año 2007, cuando Microsoft lideró el desarrollo de OData como parte de su iniciativa de plataforma de datos ADO.NET. En 2012, la Organización para el Avance de Estándares de Información Estructurada (OASIS) tomó el control de la norma, y desde entonces, su adopción y desarrollo han sido constantes.

Funcionalidad

Su capacidad para tratar los datos como recursos RESTful le otorga un papel vital en la construcción de aplicaciones modernas que necesitan interactuar con bases de datos, no solo para la simple lectura y escritura de datos, sino también para operaciones más complejas. OData soporta operaciones CRUD (Crear, Leer, Actualizar, Eliminar), así como consultas más complejas a través de sus capacidades de filtrado, ordenamiento, agrupación y paginación.

OData Entidad y Relaciones

Una entidad en OData es una unidad de datos que representa un objeto del mundo real. Cada entidad tiene un conjunto de propiedades y se identifica de forma única mediante una clave. Pudiendo hacer acciones sobre ella (CRUD). Por ejemplo la entidad Pedido Ventas, Producto, Interlocutor Comercial, etc.

Las entidades a menudo tienen relaciones entre ellas. Por ejemplo en la entidad Pedido de Ventas podemos tener relacionadas las entidades Cliente, Datos Organizativos, Notas, Anexos, etc. De esa forma podemos consultar la entidad padre y además las relaciones que se requieran.

OData ventajas sobre el REST puro

En OData tenemos las siguientes Ventajas:

Exploración de Datos: Las relaciones entre entidades en OData permiten a los clientes explorar el gráfico de datos de una manera estructurada y coherente.
Consultas Complejas: Con OData, puedes hacer consultas más complejas que abarcan múltiples entidades y sus relaciones, todo en una única petición.
Metadatos: OData proporciona un documento de metadatos que describe todas las entidades, propiedades y relaciones.
Estándar y Consistencia: Al tener un modelo de datos claramente definido con entidades y relaciones, OData ofrece una forma estándar de interactuar con el API, lo cual simplifica el desarrollo y el mantenimiento.
Optimización del Tráfico: Al poder seleccionar sólo las entidades y relaciones específicas que necesitas, se reduce la cantidad de datos transferidos sobre la red.

En una API REST puro, cada recurso (que es similar a una entidad) se accede mediante su propia URL. No hay una forma estándar de describir las propiedades o las relaciones del recurso, lo que puede llevar a una mayor complejidad para entender la estructura y la funcionalidad del API. En REST puro, las relaciones entre recursos a menudo se manejan mediante URL o IDs incrustados en las respuestas, sin una forma estándar de describir o navegar estas relaciones. Esto puede complicar las operaciones como filtrado, ordenación o selección de campos para datos relacionados

Ejemplo de uso de OData

Para poder probar OData podemos usar la guía oficial de OData en su web, usando Postman en el apartado Getting Started – Learning OData on Postman.

Ejemplo de ejecución en postman del proyecto de OData https://www.postman.com/collections/bf7d9130241aaa7160d8

OData en SAP – SAP Gateway

Ahora bien, ¿Cómo se enmarca OData en el ecosistema SAP? Aquí es donde entra en juego SAP Gateway.

SAP Gateway es un componente clave que facilita el camino para conectar dispositivos, entornos y plataformas no-SAP a sistemas SAP, de una forma segura y escalable. SAP Gateway aprovecha OData para exponer los datos y las funcionalidades de los sistemas SAP a aplicaciones basadas en web, móviles y otras plataformas.

Comparativa entre comunicaciones directas o por medio de SAP Gateway y OData

La integración de OData en SAP Gateway permite la creación de interfaces de usuario y la fácil exposición de la funcionalidad de los sistemas SAP. Esto ha allanado el camino para un desarrollo más rápido y eficiente de aplicaciones modernas que consumen datos y funcionalidades de SAP.

Funcionalidades y limitaciones de SAP Gateway

Las funcionalidades que le dan poder a SAP Gateway son:

Exposición de servicios OData: Gateway puede exponer datos y funcionalidades de SAP como servicios OData, permitiendo el desarrollo de aplicaciones web y móviles.
Seguridad y Autorización: Proporciona control granular sobre qué datos y funciones están disponibles para qué usuarios a través de la gestión de roles y autorizaciones de SAP.
Soporte para múltiples formatos de datos: Puede proporcionar datos en formatos JSON y XML, que son comúnmente utilizados en aplicaciones web y móviles.

Desde la introducción de SAPUI5 y Fiori, el papel de OData en el ecosistema SAP ha ganado aún más importancia. SAPUI5 y Fiori se basan en servicios OData para recuperar datos y funcionalidades de los sistemas SAP.

A pesar de sus muchas ventajas, SAP Gateway tiene algunas limitaciones. Por ejemplo, puede no ser la mejor opción para escenarios que requieran transacciones de alta velocidad o una gran cantidad de datos en tiempo real. Además, el rendimiento puede verse afectado si se manejan grandes volúmenes de datos a través de servicios OData.

Transacciones para el uso de SAP Gateway

Existen varias transacciones que son esenciales al trabajar con SAP Gateway. Algunas de las más importantes incluyen:

SEGW: SAP Gateway Service Builder, utilizado para desarrollar, probar y activar los servicios oData.
/IWFND/MAINT_SERVICE: Para activar y mantener los servicios.
/IWFND/ERROR_LOG: Para revisar los registros de error de Gateway.
/IWFND/APPS_LOG: Herramienta de rastreo para solucionar errores de aplicaciones en SAP Gateway.
/IWBEP/REG_MODEL: Para registrar los modelos de datos.
/IWBEP/TRACES: Permite la activación de trazas para servicios oData.
/IWFND/CACHE_CLEANUP: Útil para limpiar el caché de metadatos.
/IWBEP/CACHE_CLEANUP: Limpia el caché del modelo de datos.
SM59: Utilizada para configurar conexiones RFC.
SICF: Para configurar y activar los servicios HTTP necesarios para la comunicación oData.

Estas transacciones son cruciales para trabajar con SAP Gateway, desde el desarrollo y mantenimiento de servicios hasta la depuración y el manejo de errores. Utilizarlas eficientemente permitirá una mejor implementación y gestión de servicios oData en el entorno SAP.

Algunos trucos que debes conocer:

Utiliza la herramienta Gateway Client: La transacción /IWFND/GW_CLIENT te permite probar tus servicios directamente en el sistema SAP, lo cual es muy útil durante el desarrollo y la depuración.
Depuración de servicios OData: Puedes depurar los servicios OData en Gateway utilizando la transacción /IWBEP/DEBUG_GW_SERVICE, lo cual es muy útil para solucionar problemas y optimizar tus servicios.
F12 en el Navegador: Cuando estás en Fiori, por ejemplo, es muy útil abrir la consola de desarrollo de Chrome, Firefox, etc. Para saber las llamadas hacia el backend (Gateway) que realiza Fiori. Esto te da una idea del servicio llamado, la request lanzada y la respuesta recibida.

Y podría profundizar más en el uso y manejo de SAP Gateway pero como punto de partida y explicación del OData es más que suficiente. Espero que sea de ayuda, en caso de necesitar más información no dudéis en dejar comentarios en este artículo.

Si te interesa, suscríbete al blog por email

SAP S/4 HANA ¿Qué es un Business Partner?

Una de las cosas que sorprenden a los consultores de SAP ECC cuando pasan a S/4 HANA es que ya no existen deudores ni acreedores, ahora todo son Business Partner.

Si vemos la nota 2265093 – S4TWL – Enfoque de interlocutor comercial o vemos el documento Simplification List for SAP S/4HANA 2022 en su apartado 3.19 S4TWL – Business Partner Approach dice:

In SAP S/4HANA, Business Partner is the leading object and single entry point to maintain Business Partner, Customer and Supplier (formerly known as Vendor) master
data. This is to ensure ease of maintenance of the above master data and to achieve
harmonization between them. Compared to classical ERP transactions, maintenance of
Customer and Supplier master data via Business Partner has multiple advantages. Some of them are as follows:

Business Partner allows maintenance of multiple addresses with
corresponding address usages.

In classical transactions, one customer can only be associated to one account
group. But in Business Partner, multiple roles can be associated to the same
Business Partner.

Maximal data sharing and reuse of data which lead to an easier data consolidation.

General Data available for all different Business Partner roles, specific data is
stored for each role.

Maintenance of multiple relationships to the same Business Partner.

Maintenance of Time Dependency at different sub-entities roles, address,
relationship, bank data etc.

Simplification List for SAP S/4HANA 2022

Y no solo eso, sino que también comenta las transacciones clásicas de ECC que desaparecen o quedan obsoletas en S/4Hana:

Así que sí el shock de un consultor de ECC clásico es tremendo, ¿Dónde esta mi XD01, XK01, VD01? Todas estas transacciones serán redirigidas directamente a la transacción BP.

Consultor Senior ECC viendo como desaparecen los deudores y acreedores

Pero, Keep calm and relaxing cup of café con leche para todos, por favor. Desde la parte SAP CRM, que es mi especialidad, llevamos años (¿siempre?) usando los Business Partners (Interlocutores comerciales) como objeto de negocio sobre el que pivotan los documentos y procesos de negocio.

¿Qué es un Business Partner?

Pues voy a poner una definición formal, de la cual estoy 100% de acuerdo, y además una explicación que yo le daría a un compañero que necesita adquirir el concepto.

Un business partner (Interlocutor Comercial) es una persona, organización, grupo de personas u organizaciones con los que una empresa tiene un interés comercial. Cualquier transacción de negocio no se puede realizar con alguien que no esté definido como un business partner. Por lo tanto, los business partners son los partes interesadas que influyen en el desarrollo de una empresa. Los Business Partners pueden ser de diferentes tipos, como persona, organización, grupo, etc., y pueden desempeñar diferentes roles, como cliente, proveedor, contacto, etc.
Definición más o menos oficial

Pero ahora voy yo a contarte lo que llevo años usando. Un Business Partner es todo interlocutor, ya sea Persona, Empresa o Grupo, que se use en cualquier proceso comercial de preventas, ventas, postventa y, (a partir de ahora), de compras.

Estos Business Partner tienen varios atributos que los modelan y los definen, algunos atributos son obligatorios e iniciales, debes decidirlos al crear el BP (ojo a las siglas que es lo que se usa), otros pueden ser añadidos posteriormente. Algunos son únicos, otros múltiples. Vamos a desgranarlos:

Tipo de BP: Como se ha comentado en ambas definiciones se trata de definir si el BP es Persona, Organización o Grupo. Se trata de un atributo inicial, obligatorio y único. Un BP debe crearse bajo un tipo y solo uno, y este no puede ser cambiado. Por ejemplo,
- Empleado: si queremos crear un empleado, será un BP de tipo Persona.
- Cliente Persona: Si tenemos un cliente que es persona, lo crearemos como Persona.
- Cliente Empresa: Si tenemos un cliente empresa, lo crearemos como Empresa.
- Persona de Contacto: Claramente tendrá que ser Persona.
- Proveedor: Normalmente serán empresas, lo crearemos como Empresa.
Rol de BP: Aquí es donde viene la magia y la potencia de los BPs. Se pueden establecer roles a los BPs para indicar cómo actúan dentro de nuestra relación con ellos. Con esto y con las relaciones entre BPs, podemos hacer un mapa de donde está ese BP, con qué otros BPs se relaciona y de qué forma. Un BP puede tener varios roles simultáneamente, los roles pueden ser dependientes del tiempo (tener fechas de validez), y sobre ellos se pueden establecer autorizaciones. (Tal grupo de usuarios solo puede ver los «Clientes Mayoristas» por ejemplo).
Relaciones entre BPs: Más o menos explicado en el punto anterior. Se pueden establecer relaciones (con dependencia temporal o no) entre dos BPs. El objetivo de estas relaciones es múltiple:
- Tener un mapa de donde está ese BP tanto dentro de su organización como dentro de la nuestra. Con esto se pueden responder preguntas como «¿Quienes son sus superiores en su organización?», «¿Quien es su empleado responsable en la nuestra?», «¿Quien es su persona de contacto o de quien es persona de contacto?», etc.
- Establecer autorizaciones de visibilidad en nuestro sistema. Por ejemplo, un empleado solo podrá ver los BPs de los que es él o su unidad organizativa responsable.
- Determinación automática de BPs en documentos. Si creamos un documento, por ejemplo en ventas, con un cliente, podemos arrastrar de forma automática al documento su persona de contacto, empleado responsable, pagador, etc…
Posibilidad de que un BP tenga varias direcciones en su maestro. Cada una de ellas con atributos como, el tipo o uso de dirección, fechas de validez, notas de la dirección.
Hay más atributos, pero mayormente usados para procesos de preventa o marketing, como son el Ciclo de Vida del cliente, Atributos de Marketing, Gestión de duplicados y Data Cleansing, etc. Pero para hacerse una idea general sirve lo anterior.

Puedes profundizar un poco en la help de SAP «SAP S/4HANA for Customer Management->Master Data->Business Partners«.

Sí, has visto bien, pone 2002, este concepto es más viejo que el fuego

Hay más información que desgranar al respecto de los Business Partner en S/4HANA pero, por ahora, sirva este artículo de introducción y definición de lo que es un BP en S/4HANA.

SAP BTP – Business Technology Platform

En un proceso de autoaprendizaje que estoy realizando, en el marco del estudio para la certificación de SAP Build Platform realicé el curso «Discovering SAP Business Technology Platform«.

Mira lo que me han dado hoy con el periódico

Donde te da una introducción de las características y posibilidades de SAP BTP.

BTP ya lo conocía anteriormente al ser el framework donde se configura la posibilidad de tener aplicaciones Fiori, la integration suite de CPI y la gestión de usuarios y roles. Pero el curso me ha parecido muy interesante y enriquecedor, además de que es ameno.

¿Qué es SAP BTP – Business Technology Platform?

SAP BTP es una plataforma integrada y basada en la nube que combina servicios de desarrollo de aplicaciones, automatización de procesos, Integración, Gestión de datos y analíticas e Inteligencia Artificial en un solo lugar.

Esto significa que BTP es el Framework de desarrollo de soluciones en la nube donde aglutinar ciertas configuraciones o autorizaciones para todas esas soluciones.

¿Cómo se organiza SAP BTP?

Pues tenemos varios nodos jerárquicos:

Global Account: Es la cuenta relevante al contrato que el cliente hace con SAP para otorgarle los servicios de SAP BTP.
Subaccounts: Las Subcuentas te permiten estructurar una Cuenta Global de acuerdo a los requisitos de tu organización y proyecto en términos de miembros, autorizaciones y derechos. Una Cuenta Global puede contener una o más Subcuentas en las que despliegas aplicaciones, utilizas servicios y gestionas tus suscripciones.
Directory: Los Directorios te permiten organizar y gestionar tus Subcuentas de acuerdo a tus necesidades técnicas y de negocio. Un Directorio puede contener Directorios y Subcuentas para crear una jerarquía. El uso de Directorios para agrupar otros Directorios y Subcuentas es opcional, aún puedes crear Subcuentas directamente bajo tu Cuenta Global.
Entitlements: Un Entitlement es tu derecho a aprovisionar y consumir un recurso. En otras palabras, los Entitlements son los planes de servicio a los que tienes derecho a usar.

¿Qué ofrece SAP BTP?

Todos estos servicios:

Este esquema de memoria, caerá en el examen

Resumen

Por resumir mucho, mucho, de lo que tenga que ver con Cloud en SAP va a pasar por BTP casi con seguridad. Y lo interesante es que es muy útil para organizar tecnológicamente la empresa a nivel de aplicaciones, permisos y autorizaciones.

SAP BTP Neo vs SAP BTP Cloud Foundry

En el momento en el que estamos cabe diferenciar dos versiones muy distintas de SAP BTP.

Por un lado está la versión Neo que es un BTP alojado en los servidores de SAP, con software propietario y en estado de ser discontinuada.

Por otro lado está la versión Cloud Foundry que es un BTP bajo los estándares Open Source de Cloud Foundry, que puede ser alojado en cualquier Hyperscaler (cómo AWS, Microsoft Azure, Google Cloud Platform o Alibaba Cloud) y se enmarca dentro de un estándar Open Source mucho más versátil, flexible y escalable.

No sé porqué ponen primero Cloud Foundry, cuando el orden es inverso, pero así está

Es posible que todavía veáis muchas implementaciones de SAP BTP Neo, que poco a poco irán migrando a Cloud Foundry (cosa que no es directa). Con la versión Cloud Foundry se permite, como podéis ver, tener aplicaciones en lenguajes tan interesantes como Python, Go, Ruby y usarlas para nuestros desarrollos.

Madre mía ¡Qué imagen! Esto, según SAP, esto hace de todo.

Quiero probar SAP BTP

Para probar SAP BTP podemos pedir un entorno Trial en Try and buy SAP Business Technology Platform dándole al apartado:

Aquí tendremos que registrarnos y tendremos acceso a un sistema SAP BTP durante 90 días. Podemos logarnos con nuestro usuario SAP Universal ID.

Después de un tiempo tendremos nuestro BTP de pruebas configurado

Mensaje que nos informa que el sistema tendrá 90 días de validez

En el apartado de servicios podemos ver los servicios BTP que se pueden activar

En este caso he buscado SAP Build Apps y con darle a Create se activará el servicio en BTP

SAP BTP Tutoriales

Si vemos en el Trial tenemos a nuestra disposición una serie de tutoriales para demostrar las diversas funcionalidades que tiene SAP BTP.

Donde tenemos tutoriales tan interesantes como:

Use Machine Learning to Process Business Documents
SAP BTP ABAP Environment: Create and Expose a CDS-Based Data Model
Build an SAP Fiori App that Consumes Data from an On-Premise System
Build an iOS and MacOS App with One Code Line Using SAP BTP SDK for iOS
Build an SAP Fiori App Using the ABAP RESTful Application Programming Model [RAP100]
Build Your First Chatbot with SAP Conversational AI
Get Started with SAP BTP SDK for Android

Como hemos visto SAP BTP, si bien se pueden desarrollar directamente aplicaciones en él y puede tener su propia base de datos, su uso principal es como Framework de despliegue y desarrollo de aplicaciones (servicios). Creo que este camino es el correcto, por un lado hacer una plataforma open source donde se pueda desarrollar e implementar diversas soluciones de diversas tecnologías. Y por otro que SAP deje «jugar» con sus aplicaciones con versiones Trial y tutoriales y cursos gratuitos.