Discussion :

[ShaiLeTroll]

Bonjour,

Un sujet "Architecture N-Tiers avec Delphi 10.2 Tokyo" qui va m'occuper longtemps.
Possible que l'on passe en "10.3 Rio" si certains serveurs sont en Linux

Le Contexte

Notre ERP Maison développé depuis 1999 en Delphi (5 puis XE2) sera remplacé par un ERP du marché dit plus "standard" c'est à dire SAP S/4 qui ne fait pas grand chose donc faut lui adjoindre le WMS REFLEX, PIM & SIM ContentServe ... le tout lié par un EAI / ESB+ETL

Pas un seul partenaire n'ose assumer le rôle de notre outil d'étiquetage.
Juste 7-8 millions d'étiquette par an [chiffre de 2018] sur un peu moins de 10 sites mais ce qui fait peur c'est 3 fois plus dans cinq ans sur plus de 70 sites

Actuellement c'est petit programme Delphi XE2 utilisé en local(*) connecté en direct sur ORACLE avec plein de règle en dur
(* local ou via CITRIX qui lui nous gère très bien le montage d'imprimante même depuis la Chine ou l'Inde)

Tout ça c'est fini
Je dois mettre en place un Serveur d'Etiquetage utilisé via WebService (par REFLEX) via un Portail (FMX, CITRIX refonte en Web pour 2021) et le plus intéressant un Designer (FMX, CITRIX refonte en Web pour 2022) et avec aucune règle en dur (tout sera au maximum déporté dans l'EAI, j'espère éviter de scripter de trucs)

L'un des chemins possible c'est
Un utilisateur a son navigateur Internet (Poste Client) connecté sur Reflex WEB (server web A) invoque le WS d'étiquetage (serveur DataSnap 1) qui lui doit récupérer les formats (directement sur Oracle/MYSQL) et compléter les données via un WS de l'EAI (server Web B) qui lui même devra consulter SAP et sa base HANA (un serveur SAP 1) pour ensuite imprimer des milliers d'étiquette à l'heure en simultané sur plusieurs imprimantes (une par format de papier) du poste Client où était ouvert la page Web Reflex

On va éviter qu'un serveur connaissent les 50-70 imprimantes SATO du Parc qui montera bien à 500 dans quelques années, entre la France, l'Italie, l'Allemagne, la Chine, L'Inde et un tas d'autres pays à l'avenir
Car cela serait à notre équipe de gérer le recensement des imprimantes à travers le Monde

La Question
Ma question c'est quelle(s) Architecture(s) N-Tiers est la plus pertinente en avec Delphi 10.2 Tokyo ?


Dans une ancienne boite, je n'ai expérimenté que le DCOM qui a été remplacé par du DataSnap (jouant juste le rôle d'un Transport entre un objet COM lancé en local sur le client et lancé en local sur le serveur, c'est DS qui assure le transport en JSON et c'est réinjecté dans la couche COM) pour les applications c'était comme si rien ne s'était passé
A mon grand regret, je n'ai participé à ce développement, j'ai aidé sur des bricoles mais pas pu expérimenté tout ça !


Principalement, le système aura des petites requêtes très nombreuses.
Pour tout ce qui est exposé à un tiers, j'ai choisi REST qui semble bien intégré à DataSnap

Pour ceux qui pratique le N-Tiers et qui ont connu CORBA, DCOM, SOAP, DataSnap ...
Est-ce qu'il y a mieux qu'un WS REST pour ce qui est de la communication interne entre les clients et serveurs (non exposés aux tiers).
Le but étant d'avoir un temps de réponse le plus court possible évidemment et beaucoup d'asynchrone !

J'aimerais bien expérimenté autre chose comme la propriété RemoteServer du TClientDataSet (Est-ce encode d'actualité ou c'est out-of-date ?)
Surtout qu'à certaines étapes, cela sera plutôt du binaire qui sera envoyé comme la matrice d'un code barre (oui, une suite de 0 et 1 peut se convertir en Base64 et s'envoyer en texte mais si il y a plus original, je suis curieux)

Pour le moment, Je suis entrain de dépoussiérer un code maison pour gérer le Code128 ABC qui transforme la donnée en une matrice 0/1 représentant les barres, cela pourra ainsi être le même code qui calcul le code barre mais VCL.Canvas ou FMX.Canvas pour l'impression et l'autre pour l'aperçu

Après même opération mais pour un QRCode

Ensuite, j'attaque les différents mécanismes de connexion DB en N-Tiers de Delphi

[Paul TOTH]

héhé, je suis pas certain que tu auras beaucoup de réponse sur une question comme ça.

je réfléchie également à la mise en place d'un service REST.

je n'ai pas d'expérience en la matière et suis donc sans préjugé.

en faisant mes recherches je suis tombé sur un article qui comparent notamment DataSnap et mORMot, et la suite, mais il est à noter que c'est pour XE3. Plus récemment un autre test qui ne semble pas révolutionner les choses.

Après j'ai un défaut (qui a ses avantages) c'est que j'aime savoir ce qu'il se passe sous le capot et je fini souvent par réinventer la roue, ça me permet notamment (c'est un des avantages) de pouvoir faire du tout terrain car je sais exactement ce qu'il se passe et pourquoi ça fonctionne ou pas.

J'ai commencé à regarder comment fonctionnait mORMot, et j'ai vu des choses assez complexe en interne, ce qui est bien naturel puisqu'en surface c'est plutôt simple, et plus tu veux automatiser les choses, plus cela se complique en interne. J'ai un peu le même sentiment avec Indy, quand on regarde la structure interne, c'est relativement complexe, mais en fait un protocole de base comme HTTP peut devenir extrêmement complexe quand on veux supporter toutes les extensions.

Par contre, si je n'ai pas tout compris dans ton architecture (tu utilises trop de d'acronymes pour ma culture de self made man), mais il me semble comprend que le client final sera dans un navigateur, et c'est lui qui doit imprimer ? ou il se content de lancer les ordres d'impression, car c'est pas forcément simple la gestion des impressions depuis un navigateur.

[ShaiLeTroll]

héhé, je suis pas certain que tu auras beaucoup de réponse sur une question comme ça..

Je n'attends pas forcément une réponse ferme
Je suis ouvert à toutes méthodes de transfert de données que cela soit DataSnap à l'ancienne, du DataSnap moderne, même du Tethering ... tant que je découvre des choses nouvelles pour moi et qu'ensuite je peux les confronter pour en retenir une ou deux selon les circonstances et la pertinence face au besoin

je réfléchie également à la mise en place d'un service REST.

je n'ai pas d'expérience en la matière et suis donc sans préjugé...

Un peu comme toi, j'ai fait des clients mais pas encore de Serveur.

en faisant mes recherches je suis tombé sur un article qui comparent notamment DataSnap et mORMot, et la suite, mais il est à noter que c'est pour XE3. Plus récemment un autre test qui ne semble pas révolutionner les choses.

mORMot ... d'Arnaud Bouchez (à cause de son Avatar HAL, je me suis toujours demandé si ce n'était pas un grand membre du forum)
Ce qui est bon signe c'est que le Framework est encore mis à jour pour Delphi même Rio

Oui j'étais tombé dessus il y a des années de cela : Viabilité projet avec datasnap
Comme j'ai l'intention de diviser mon application en un tas de petite brique interchangeable pour justement différencier la partie transport, serialization et traitement cela ne me pose pas de problème de faire plusieurs serveurs différents et de retenir le meilleur

Je note TMS Sparkle et mORMot dans mon TODO comparatif

Après j'ai un défaut (qui a ses avantages) c'est que j'aime savoir ce qu'il se passe sous le capot et je fini souvent par réinventer la roue, ça me permet notamment (c'est un des avantages) de pouvoir faire du tout terrain car je sais exactement ce qu'il se passe et pourquoi ça fonctionne ou pas..

Ne me tente pas, j'en suis tout aussi capable, un piège que j'aimerais éviter quand mêmetout dépendra de ma concentration et si je ne suis pas pris sur d'autres projets (genre le changement de protocole d'un robot de tri qui me fera me balader en Floride)

J'ai commencé à regarder comment fonctionnait mORMot, et j'ai vu des choses assez complexe en interne, ce qui est bien naturel puisqu'en surface c'est plutôt simple, et plus tu veux automatiser les choses, plus cela se complique en interne. J'ai un peu le même sentiment avec Indy, quand on regarde la structure interne, c'est relativement complexe, mais en fait un protocole de base comme HTTP peut devenir extrêmement complexe quand on veux supporter toutes les extensions..

Oui alors que je vais totalement spécialiser mon programme, pour la partie "publique", je ne vais pas hésiter, je vais choisir un outil plutôt standard et\ou répandu comme mORMot ou un TidHTTPServer

Alors que la communication privée entre mes couches, là, cela sera à celui en lequel j'ai le plus confiance (genre mon propre protocole qui tourne avec des machines depuis Delphi 5 avec 1 000 000 requêtes en 8h d'activité, ce qui donne 3M/jours, je le testerais à fond pour voir si il supporte 2 fois plus sur 24h ce qui donnerait l'équivalent de DataSnap en terme de perf, et 20 fois plus c'est le niveau de mORMot)

A la lecture des chiffres,
la partie exposée sera très loin du stresstest, ce qu'ils ont testé soit 1 million requests en 20 minutes à 800r/s, c'est en gros un mois d'activité
la partie privée, le nombre de requête le volume de données est multiplié par 100, et même là, DataSnap doit pouvoir encore suivre la cadence.

Mais avant la performance, ce que je recherche c'est aussi la robustesse, je vais faire souffrir chacune des couches pour leur faire subir un Benchmark pendant plusieurs jours continus avec une cadence bien supérieure à la réalité,
En gros simuler une année en quelques jours.

Par contre, si je n'ai pas tout compris dans ton architecture (tu utilises trop de d'acronymes pour ma culture de self made man), mais il me semble comprend que le client final sera dans un navigateur, et c'est lui qui doit imprimer ? ou il se content de lancer les ordres d'impression, car c'est pas forcément simple la gestion des impressions depuis un navigateur.

Oui c'est les acronymes à la mode chez nous EAI, ETL, ESB

le client final sera dans un navigateur sur la version Web d'un système de gestion d'entrepôt du marché
Ils ont un système d'impression d'étiquette, ils vont gérés quelques format mais comme il supporte que le ZPL ce que ne fait pas 99% de nos imprimantes SATO, qu'ils ne peuvent pas assumer l'impression en dehors du site (chez les fournisseurs ou suite à une demande SAP), cela retombe sur nous.
Nous n'avons pas la main sur le logiciel version Web et c'est bien un ordre d'impression que l'utilisateur soumets à notre outil
Très différent du mode où l'on fourni un portail CITRIX justement en cas de SAP ou chez nos fournisseurs