Registro de peticiones ORDA en el servidor

Desde su lanzamiento, la popularidad de ORDA no ha dejado de crecer y ahora es ampliamente utilizado en sus servidores de producción. Con 4D v20, le ofrecemos 2 mejoras en la forma en que las peticiones ORDA se registran en el servidor. La primera es una mejora del registro de peticiones que ahora dará más información sobre las llamadas ORDA. La segunda es la adición de un registro ORDA del lado del servidor similar al registro ORDA del lado del cliente. Permítanme presentarles estas nuevas funcionalidades.

La primera mejora concierne al registro de peticiones. El registro de peticiones es extremadamente importante si quiere optimizar su servidor de producción. Le da información sobre las peticiones recibidas, el tiempo que ha llevado gestionarlas y los datos enviados a la red. También es importante tener en cuenta que la activación de los registros tiene un impacto en el rendimiento. El registro de peticiones está muy optimizado y como tal puede ser utilizado en producción sin impactar demasiado en el rendimiento del servidor.

Si activa el registro de peticiones en su servidor, verá que las peticiones ORDA se registran con un id de petición en los 14000s (puede encontrar los ids de peticiones aquí). También tiene información sobre el dataclass o atributo en la columna extra. Por ejemplo, esta línea indica que el atributo Employee.Bloby ha sido modificado (en negrita el id de la petición y el contenido de la columna extra):


La segunda mejora es bastante fácil de usar. Puede activar los registros ORDA del lado del servidor llamando a la función startRequestLog en el almacén de datos. Por ejemplo:

ds.startRequestLog()

Si ejecuta este fragmento de código, todas sus peticiones ORDA serán registradas dentro del archivo ORDAlog.jsonl. Los registros ORDA del lado del servidor utilizan la sintaxis json lines, con cada línea siendo una descripción json de la petición enviada. Aquí hay un ejemplo de esa línea:

{
    "url" : "rest/Company[4]",
    "systemUserName" : "nbrachfogel",
    "userName" : "Designer",
    "machineName" : "OPT9010-1168",
    "taskID" : 5,
    "taskName" : "P_1",
    "startTime" : "2023-05-22T14:29:00.289",
    "response" : {
        "status" : 200,
        "body" : {
            "__entityModel" : "Company",
            "__DATACLASS" : "Entreprise",
            "__KEY" : "4",
            "__TIMESTAMP" : "2023-03-30T14:16:47.337Z",
            "__STAMP" : 1,
            "ID" : 4,
            "Name" : "Compagnie 31740",
            "Turnover" : 32205,
            "MyEmployees" : {
                "__deferred" : {
                    "uri" : "/rest/Company[4]/MyEmployees?$expand=MyEmployees"
                }
            }
        }
    },
    "sequenceNumber" : 60,
    "duration" : 282
}

Puede ver información sobre el usuario, el tiempo que ha tardado en ejecutarse la petición y la respuesta del servidor. También tiene el número de secuencia que es el mismo número que encontrará en el registro de peticiones, enlazando ambos registros (si el registro de peticiones no está activado, el número de secuencia se omite en el registro ORDA).

El registro ORDA del lado del servidor es muy interesante para la resolución de problemas. Le da información detallada sobre las peticiones que recibe el servidor y sus respuestas. Pero consume muchos recursos, tanto de CPU como de espacio en disco, por lo que debería usarlo con precaución en su servidor de producción.

Estos 2 logs también pueden ser activados con el archivo de configuración de logs o directamente desde la pestaña de mantenimiento de la ventana de administración de 4D Server.

blank
El botón Start Request and Debug Logs activará tanto el registro de peticiones como el registro de ORDA.

Esperamos que estas 2 funcionalidades le ayuden a solucionar problemas y optimizar sus llamadas ORDA. Si tiene comentarios o preguntas, no dude en llevarlas a los foros 4D.

Nicolas Brachfogel
• Propietario de producto y Desarrollador Senior - Nicolas Brachfogel se unió a 4D en 2017 como Senior Developer (4D Server y networking). Como Product Owner para gestionar el lanzamiento de Apple Silicon, está a cargo de escribir historias de usuario y traducirlas en especificaciones funcionales, así como asegurarse de que las implementaciones de las funcionalidades satisfagan las necesidades del cliente. Diplomado por el Instituto Superior de Informática Aplicada (INSIA), Nicolas comenzó su carrera como desarrollador de software en 2001. Tras varios años codificando en Java y C++, pasó a especializarse en el desarrollo cliente-servidor para empresas de videojuegos. Como desarrollador/arquitecto de servidores, trabajó con éxito en las arquitecturas de servidores de muchos juegos (Dofus Arena, Drakerz, Trivial Pursuit Go!).