Todo
Respuestas aceptadas
Luis Angel Pérez Ramos · jun 21, 2023 ir a la publicación

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. 

Luis Angel Pérez Ramos · mayo 9, 2023 ir a la publicación

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)

Luis Angel Pérez Ramos · mayo 7, 2023 ir a la publicación

¡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 ORDER BY a2."Date" DESC )
GROUP BY a1.ID order by 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.

Luis Angel Pérez Ramos · abr 18, 2023 ir a la publicación

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.

Luis Angel Pérez Ramos · feb 9, 2023 ir a la publicación

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

Luis Angel Pérez Ramos · oct 10, 2022 ir a la publicación

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