Introducción
Al desarrollar aplicaciones en la
Plataforma Tecnológica Empresarial de SAP
(BTP), a menudo llegas naturalmente al punto en el que deseas probar ciertas funciones a través de APIs. Estas pueden ser funciones en tu propia aplicación o servicios proporcionados por el
BTP
. Hasta este punto, principalmente he utilizado el cliente de API
Postman
, porque ofrece una gran cantidad de funciones y facilita mucho el desarrollo y la prueba. Por ejemplo,
Postman
hace que sea mucho más fácil para ti utilizar
OAuth 2.0
como un mecanismo de autorización al llamar a las APIs e incluso establece las líneas de encabezado HTTP correctas en tu solicitud. Por otro lado, podrías perder un poco la comprensión de lo que realmente sucede (a menos que revises la consola).
Recientemente, en mi rol como Consultor de Educación de SAP, estaba trabajando en un nuevo entrenamiento para
Gestión de Flujos de Trabajo de SAP
y como este es un producto en el
BTP
, la mayor parte del desarrollo ocurre en el
Estudio de Aplicaciones Empresariales de SAP
(SBAS). Dado que
SBAS
es un entorno de desarrollo en la nube, es muy conveniente de usar en entrenamientos porque los participantes no necesitan el software en sus máquinas locales. Además, ya no se requieren sesiones WTS molestas, simplemente trabajas en tu navegador. Este es el punto en el que me encontré con el problema de no querer usar
Postman
, al menos en estas configuraciones. Quiero poder demostrar solicitudes de API en un entorno de entrenamiento ligero, que sea fácil de replicar. Afortunadamente,
SBAS
tiene una extensión que está integrada por defecto, la extensión de
REST Client
. En esta publicación quiero describir algunas características básicas de la extensión de
REST Client
basada en una llamada de API de
Servicio de Flujos de Trabajo de SAP
que requiere autorización
OAuth 2.0
utilizando tanto el tipo de concesión de
Authorization Code
como el tipo de concesión de
Client Credentials
.
Para comprender y poner en marcha el flujo de
Authorization Code de OAuth 2.0
, este artículo de blog por
carlos.roggan
fue muy útil para mí.
Escenario
Nota:
El escenario que voy a mostrar puede sonar específico para
Gestión de Flujos de Trabajo de SAP
, pero todo en esta publicación es aplicable a cualquier escenario en el que desees probar la integración de API con otras aplicaciones y servicios de
BTP
.
El
Servicio de Flujos de Trabajo de SAP
ofrece una amplia variedad de puntos finales de API para gestionar flujos de trabajo y tareas. Al construir tus propios flujos de trabajo, es posible que desees iniciar instancias de los flujos de trabajo con fines de prueba. Por defecto, esto es posible a través de la aplicación Fiori
Gestionar Flujos de Trabajo
. Pero durante el desarrollo puede resultar inconveniente cambiar a una interfaz de usuario diferente y requerir muchos clics adicionales para iniciar un flujo de trabajo. Además, en un entorno productivo, los flujos de trabajo generalmente se activarán mediante otras aplicaciones como interfaces de inicio, que utilizan APIs en segundo plano. Por lo tanto, deseas usar APIs para pruebas para ser más flexible y estar lo más cerca posible del caso de uso final. Utiliza
SAP API Business Hub
para descubrir APIs de SAP y opciones de integración para tu escenario.
Dado que el
Servicio de Flujos de Trabajo de SAP
API requiere autorización
OAuth 2.0
, quiero mostrar cómo activar el punto final de la API para iniciar una nueva instancia de flujo de trabajo utilizando el flujo de
Client Credentials
y el flujo de
Authorization Code
. Estaré utilizando la extensión de
REST Client
en
SBAS
para ser independiente de la plataforma durante el desarrollo.
El punto final de la API del Servicio de Flujos de Trabajo que voy a activar, encontrado en SAP API Business Hub
Cliente REST de SAP Business Application Studio
Al escribir esta publicación en un contexto de SAP, me refiero a la extensión de
Cliente REST de SAP Business Application Studio
, aunque en realidad el
Cliente REST
es una extensión de
Microsoft Visual Studio Code
(