ir a la publicación Luis Angel Pére... · 18 abr, 2023 Buenas Yone. Sospecho que quizás el problema pueda estar en la definición del objeto GetCursosAdmitidosResponse, según su definición tiene una propiedad cursos: Property cursos As list Of EsquemasDatos.miFormacion.CursoAdmitido; Pero lo que enviais para hacer el mapeo de json al objeto comienza así: [ { "codigo": "5128", "descripcion": "LAS ENFERMERAS FRENTE A LOS PROBLEMAS DE SALUD MENTAL", "programa": "Probabilidad de contagio ante un accidente hemático.", "admitido": 1, "desdefecha": "26/10/2022", "hastafecha": "26/10/2029", "cursohorario": [ { "aula": "AULA 1", Cuando debiera ser: "cursos": [ { "codigo": "5128", "descripcion": "LAS ENFERMERAS FRENTE A LOS PROBLEMAS DE SALUD MENTAL", "programa": "Probabilidad de contagio ante un accidente hemático.", "admitido": 1, "desdefecha": "26/10/2022", "hastafecha": "26/10/2029", "cursohorario": [ { "aula": "AULA 1", Yo probaría modificando el JSON que estáis enviado para ver si es ese el problema.
ir a la publicación Luis Angel Pére... · 18 abr, 2023 Buenas Yone. Al ser tu collection una propiedad de otro elemento podrías usar el método Serialize para obtener el %String, luego sólo tendrías que añadir los corchetes al inicio y al final. Puedes ver la documentación al respecto en la siguiente URL: https://docs.intersystems.com/iris20201/csp/documatic/%25CSP.Documatic.c...
ir a la publicación Luis Angel Pére... · 18 abr, 2023 Buenos días Yone, por definición los campos de la cabecera de un mensaje HTTP son case-insensitive por lo que a ESB llegan ya en minúsculas. Puedes echar un ojo a esta URL donde se explica: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
ir a la publicación Luis Angel Pére... · 9 feb, 2023 ¡Buenas Jaime! Puedes configurar tu aplicación web desde la edición de las aplicaciones web para que funcione con autorización por password. (System > Security Management > Web Applications) A continuación deberás acceder a la pestaña de Application roles y asignar los roles que consideres necesarios para el usuario que se ha logueado con éxito en la aplicación. Esto le asignará dichos roles únicamente en el contexto de la invocación del servicio web, es decir, fuera de ese acceso el usuario seguirá con sus roles habituales. Con esta configuración el último paso será enviar el usuario y la contraseña en la cabecera de tu invocación REST como un tipo de autentificación Basic (o bien pasar por URL los parámetros ?CacheUserName=username&CachePassword=password), en ambos casos sería recomendable que la invocación se haga usando https para evitar exponer el usuario y la contraseña abiertamente.De esta forma tendrás una validación de los datos del usuario y la asignación de los roles necesarios dentro del contexto de la invocación del servicio web.
ir a la publicación Luis Angel Pére... · 12 dic, 2022 Buenos días Yone, ¿has probado con el siguiente comando? set token = %request.GetCgiEnv("HTTP_AUTHORIZATION")) Aquí tienes una pregunta de la comunidad similar a la tuya que quizás te resulte interesante: https://community.intersystems.com/post/get-request-header-rest-api
ir a la publicación Luis Angel Pére... · 10 oct, 2022 Buenas de nuevo Marta. El problema radica en que el ORL^O34 no es propiamente un mensaje de ACK, los cuales sólo informan de la recepción (acknowledgement) de un mensaje. Por lo tanto el business service, al tener configurado el Modo ACK a Application y recibir un mensaje ORL^O34, remitirá siempre un ACK tras dicha recepción. El parámetro "Omitir ACK entrante" sólo funciona para ignorar todos los mensajes ACK^XXX que reciba el business service. Si queréis que no se envíe ningún ACK de respuesta ante la recepción del ORL^O34 podríais crear un business service específico para recibir esos mensajes y configurar el Modo de ACK tal que así:
ir a la publicación Luis Angel Pére... · 3 oct, 2022 ¡Hola Marta! ¿Has echado un ojo al parámetro Ignore inbound ack del business service? https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...