Log des requêtes ORDA sur le serveur

Depuis sa sortie, la popularité d’ORDA ne cesse de croître et il est maintenant largement utilisé sur vos serveurs de production. Avec 4D v20, nous vous apportons 2 améliorations sur la façon dont les requêtes ORDA sont loggées côté serveur. La première est une amélioration du request log qui donnera désormais plus d’informations sur les requêtes ORDA. La seconde est l’ajout d’un log ORDA côté serveur similaire au log ORDA côté client. Permettez-moi de vous présenter ces nouvelles fonctionnalités.

La première amélioration concerne le request log. Le request log est extrêmement important si vous voulez optimiser votre serveur de production. Il vous donne des informations sur les requêtes reçues, le temps nécessaire pour les traiter et les données envoyées sur le réseau. Il est également important de considérer que l’activation des journaux a un impact sur les performances. Le request log est très optimisé et peut donc être utilisé en production sans trop affecter les performances du serveur.

Si vous activez le request log sur votre serveur, vous verrez que les requêtes ORDA sont enregistrées avec un identifiant de requête dans les 14000s (vous pouvez trouver les identifiants de requêtes ici). Vous avez également des informations sur la dataclasse ou l’attribut dans la colonne extra. Par exemple, cette ligne indique que l’attribut Employee.Bloby a été modifié (en gras l’identifiant de la requête et le contenu de la colonne supplémentaire) :


La deuxième amélioration est assez facile à utiliser. Vous pouvez activer les logs ORDA côté serveur en appelant la fonction startRequestLog sur le datastore. Par exemple :

ds.startRequestLog()

Si vous exécutez ce bout de code, toutes vos requêtes ORDA seront enregistrées dans le fichier ORDAlog.jsonl. Les logs ORDA côté serveur utilisent la syntaxe json lines, chaque ligne étant une description json de la requête envoyée. Voici un exemple d’une telle ligne :

{
    "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
}

Vous pouvez voir des informations sur l’utilisateur, la durée d’exécution de la requête et la réponse du serveur. Vous avez également le numéro de séquence qui est le même numéro que vous trouverez dans le request log, reliant les deux logs (si le request log n’est pas activé, le numéro de séquence est omis dans le log ORDA).

Le log ORDA côté serveur est très intéressant pour le débugging. Il vous donne des informations détaillées sur les requêtes que le serveur reçoit et sur ses réponses. Mais il prend beaucoup de ressources, à la fois en termes de CPU et d’espace disque, et vous devriez donc l’utiliser avec prudence sur votre serveur de production.

Ces deux logs peuvent également être activés à l’aide du fichier de configuration des logs ou directement à partir de l’onglet maintenance de la fenêtre d’administration de 4D Server.

blank
Le bouton Start Request et Debug Logs activera à la fois le request log et le log ORDA.

Nous espérons que ces deux fonctionnalités vous aideront à maintenir et à optimiser vos appels ORDA. Si vous avez des commentaires ou des questions, n’hésitez pas à les poser sur les forums 4D.

Nicolas Brachfogel
- Product Owner & Senior Developer - Nicolas Brachfogel a rejoint 4D en 2017 en tant que développeur senior (4D Server et networking) et en tant que Product Owner pour gérer la mise en production d'Apple Silicon. Il est chargé de rédiger les user stories et de les traduire en spécifications fonctionnelles, ainsi que de s'assurer que les implémentations des fonctionnalités répondent aux besoins des clients. Diplômé de l'Institut Supérieur d'Informatique Appliquée (INSIA), Nicolas a commencé sa carrière en tant que développeur de logiciels en 2001. Après plusieurs années de programmation en Java et C++, il s'est spécialisé dans le développement client-serveur pour des sociétés de jeux vidéo. En tant que développeur/architecte serveur, il a travaillé avec succès sur les architectures serveur de nombreux jeux (Dofus Arena, Drakerz, Trivial Pursuit Go !).