FAQs - Suporte técnico

Cross Segmentos - TOTVS Backoffice (Línea Protheus) MI - Configurador (SIGACFG) - Rest 2.0

time.png Tiempo aproximado de lectura: 00:05:00 min

Duda

Que es el Rest 2.0?

Ambiente
Cross Segmentos - TOTVS Backoffice (Línea Protheus) MI - Configurador (SIGACFG) - Rest 2.0 - A partir de la versión 12

Solución

Llamamos REST 2.0 al modelo que reemplazará a REST ADVPL y es mantenido por los equipos de Tecnología Framework , dependiendo solo de dónde ocurre la situación reportada, es decir, en qué capa ocurre.

Este modelo utiliza las capas:

  • Aceptar de binario
  • control tlppCore
  • Negocio híbrido:
    • API ADVPL con clases WSRESTFul, para mantener la compatibilidad.
    • API TLPP con anotaciones, para nuevas API modernas.

 

El detalle aquí es que, independientemente del tipo de API, los recursos del entorno precargados, la autenticación de Protheus y los modelos de licencia están disponibles.

El objetivo es obtener todos los beneficios del modelo más moderno, pero también mantener la mayor compatibilidad posible para no romper nada de lo que ya está construido. Sin embargo, algunos pequeños cambios de comportamiento son necesarios para no afectar el rendimiento o la facilidad de evolución de los recursos. Algunos cambios que se mapean:

  • 404 Página no encontrada en HTML en lugar de Json;
  • Las barras diagonales adicionales en la dirección de solicitud ya no se ignoran y provocan una devolución de estado 404;
  • La versión 2 de SSL (clave SSL2) está descontinuada.
  • Algunos encabezados informativos como FWRESTBUILD que ya no se envía.
  • El mecanismo que mantuvo la capa de aceptación en ejecución ya no se repite en un subproceso ADVPL. Ahora ejecuta cada ciclo de actualización del [ONSTART] del AppServer y finaliza la ejecución después de asegurarse de que el servicio de aceptación está respondiendo. Este cambio hace que se escriban mensajes adicionales en la consola, lo que indica que el trabajo se ejecutó con frecuencia de actualización. No está relacionado y no requiere ningún cambio de configuración en el archivo ini, simplemente sucedió debido al cambio de arquitectura que sufrió el modelo.
  • REST 2.0 ahora siempre devuelve el  encabezado  Content-Type con el valor de codificación utf-8. Si se recibe el encabezado  Aceptar en la solicitud al servidor REST 2.0  , con el contenido charset=cp1522, este será el retorno del tipo de contenido de la solicitud. Ejemplo:

 

 

Solicitud
Respuesta REST ADVPL
RestServer 2.0 respuesta
Codificación devuelta en respuesta (REST ADVPL y REST 2.0)
Aceptar: conjunto de caracteres = utf8 Tipo de contenido: juego de caracteres = utf8 Tipo de contenido: conjunto de caracteres = utf-8 La lib misma realiza la codificación a utf-8 
Aceptar: conjunto de caracteres = utf-8 Tipo de contenido: conjunto de caracteres = utf-8 Tipo de contenido: conjunto de caracteres = utf-8 La lib misma realiza la codificación a utf-8
Aceptar: conjunto de caracteres = cp1252 Tipo de contenido: juego de caracteres = cp1252 Tipo de contenido: juego de caracteres = cp1252 No se realiza la codificación (se usará el valor predeterminado del sistema)
Aceptar: conjunto de caracteres = cp1251 Tipo de contenido: juego de caracteres = cp1251 Tipo de contenido: juego de caracteres = cp1251 No se realiza la codificación (se usará el valor predeterminado del sistema)
Vacío Vacío Tipo de contenido: conjunto de caracteres = utf-8 La codificación no se realiza en la capa lib.
Aceptar: charset=CualquierOtroValor Tipo de contenido: charset=AnyOtherValue Tipo de contenido: conjunto de caracteres = utf-8 La codificación no se realiza en la capa lib.

 

 

Con el reemplazo de las capas de aceptación y control, ya era posible notar un rendimiento de respuesta de solicitud hasta 3 veces más rápido en comparación con el modelo ADVPL. Sin embargo, es importante recalcar que el tiempo de respuesta depende mucho del tipo de procesamiento que realiza cada API y que la ganancia automática de rendimiento se refiere únicamente al tiempo de preprocesamiento de la solicitud. Con la sustitución paulatina de las API's por las TLPP podremos tener las respuestas aún más performativas, dependiendo únicamente del buen uso del lenguaje y de la arquitectura adoptada en cada API.

¿Fue útil este artículo?
Usuarios a los que les pareció útil: 0 de 0

0 Comentarios

Inicie sesión para dejar un comentario.
X Fechar

Olá ,

Há pendência referente a um de seus produtos contratados para a empresa ().

Entre em contato com o Centro de Serviços TOTVS para tratativa.

Ligue! 4003-0015 opção 4 e 9 ou registre uma solicitação para CST – Cobrança – Verificação de pendências financeiras . clique aqui.

TOTVS

X Fechar

Olá ,

Seu contato não está cadastrado no Portal do Cliente como um perfil autorizado a solicitar consultoria telefônica.

Por gentileza, acione o administrador do Portal de sua empresa para: (1)configurar o seu acesso ou (2)buscar um perfil autorizado para registro desse atendimento.

Em caso de dúvidas sobre a identificação do contato administrador do Portal, ligue (11) 4003-0015, opção 7 e, em seguida, opção 4 para buscar o suporte com o time de Assessoria ao Portal do Cliente. . clique aqui.

TOTVS

X Fechar

Olá ,

Para o atendimento de "Consultoria Telefônica" você deverá estar de acordo com o Faturamento.

TOTVS

X Fechar

Olá,

Algo inesperado ocorreu, e o usuario nao foi reconhecido ou você nao se encontra logado

Por favor realize um novo login

Em caso de dúvidas, entre em contato com o administrador do Portal de Clientes de sua empresa para verificação do seu usuário, ou Centro de Serviços TOTVS.

Ligue! 4003-0015 opção 4 e 9 ou registre uma solicitação para CST – Cadastros . clique aqui.

TOTVS

Chat _

Rellene los campos siguientes para iniciar el chat:

Chat _