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í:

¡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.

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.

¡Hola Albert! Te agradecería que, para beneficio de todos los usuarios de la comunidad de desarrolladores en español, planteases la pregunta traducida al español si es posible.

Con respecto a tu pregunta, prueba con la siguiente query:

SELECT 
a1.ID, AVG(a1.Price)
FROM Comp.AlbLin a1
WHERE a1."Date"in (SELECT TOP 3 a2."Date"FROM Comp.AlbLin a2 WHERE a1.ID = a2.ID ORDERBY a2."Date"DESC )
GROUPBY a1.ID orderby a1.ID asc

Entiendo que el campo AlbLin.ID no es único por lo que indicas, por lo que podemos utilizar como criterio la fecha del dato. Te explico un poco la query:

  1. Puedes ver como tenemos dentro del WHERE una subquery que nos extraerá las últimas 3 fechas para cada AlbLin.ID, serán las 3 últimas ya que hemos indicado TOP 3 de una query ordenada por fecha de forma descendiente, así que siempre serán las 3 últimas fechas.
  2. En la SELECT principal hemos sacado el AlbLin.ID que nos servirá como criterio agrupador y hemos usado la función agrupadora AVG para AlbLin.Price.
  3. En la instrucción GROUP BY hemos definido el campo agrupador AlbLin.ID y hemos añadido un ORDER BY, este último no es necesario.

Pues bien, la subquery nos devolverá las 3 últimas fechas que usaremos en la query principal para sólo utilizar aquellos registros relativos al AlbLin.ID que coincidan con esas fechas (la subquery usa dentro de su WHERE el identificador de la query principal).

Prueba la query y coméntanos el resultado.

Pues solo tienes que meter la condición de la subquery entre paréntesis y añadir un And con la condición de la fecha a modo de:

WHERE (date>X AND subquery top 2) OR (date <=X AND subquery top 3)

Buenas @Daniel Aguilar! Pues la principal ventaja de usar producciones es que puedes hacer un seguimiento de las peticiones que has recibido así como el ciclo de vida de esa petición dentro de tu sistema, desde la recepción, transformaciones en BP y almacenamientos u otras operaciones en el BO.

Una vez que esos mensajes se persisten puedes realizar búsquedas por la fuente del mensaje, fechas, cabeceras del mensaje, etc...y estos quedarán almacenados hasta que se programe una tarea de purgado. 

Buenas @Victor Quisbert 

HL7 es un estándar de intercambio de información clínica y por lo tanto cubre una gran variedad de tipo de datos. Cada mensaje corresponde a un tipo de evento (admisión hospitalaria, solicitudes de laboratorio...), en esta URL puedes comprobar todos los tipos de mensajes que existen:

https://hl7-definition.caristix.com/v2/HL7v2.5.1/Tables/0076

Cada mensaje se compone a su vez de una serie de segmentos que portan una determinada información, tales como los datos del paciente, información sobre ubicaciones hospitalarias, tipo de pruebas...puedes consultarlos en la siguiente URL:

https://hl7-definition.caristix.com/v2/HL7v2.5.1/Segments

Y en el caso de que eches de menos algún tipo de dato, siempre puedes crear tus propios segmentos y crear versiones derivadas del estándar.

Nada mejor que la Wikipedia para entender qué es HL7:

https://es.wikipedia.org/wiki/HL7

Veamos como fue la predicción de esta jornada:

¡Pues esta jornada ha sido un total fracaso! Sólo hemos tenido 4 aciertos, bueno, aún así no cejaremos en nuestro empeño de enriquecernos.