Architecture OnPremise et préconisations

Architecture générale

Open

Architecture 3 tiers

• La présentation avec le client - Xwpf ou Web

• Le code applicatif « métier » - xRtDiva

• L'accès aux données - XLAN/ODBC ou xRtDiva/ADO.NET

Open

Imbrication des composants

• Le serveur de données contient l'ensemble des composants nécessaires à l'exploitation de l'ERP :

  • Le serveur de données contient le serveur d'application

  • Le serveur d'application contient le client

Exemples d'architectures

Rôles des composants

Principaux services :

• DhsXlanServer :

  • Gère les licences, les réservations et l'accès aux fichiers (y compris certains accès SQL)

  • DhsTelnet

    • Permet l'interface entre des programmes Diva et des clients Telnet (Terminal code-barres)

  • DhsSearchServer

    • Assure l'indexation du contenu, à partir de la base de données SQL et des fichiers joints dans une base de données spécifique

• DhsServices

  • Permet le lancement de programmes Diva en tâche de fond (scrutateurs, BPM)

  • DhsTerminalServer

    • Gère les connexions pour le mode de transport Client 'Socket IP'

• DhsDivaAgent

• Exécution du Runtime Diva (XrtDiva.exe)

Principaux processus :

• Xwpf.exe

  • En charge de la présentation. Un processus Xwpf.exe est associé à chaque tâche utilisateur

  • xRtDiva.exe

    • Processus chargé d'exécuter les applications Diva (Diva est le langage de programmation)

Fichiers joints

On parle de “fichiers joints” dans l’ERP pour tous les fichiers attachés en pièces jointes a une entité stockée dans l’ERP, et ce pour de multiples usages.

Par exemple des pièces jointes sur un article ou un client (descriptif, photos) ou par exemple sur une pièce commerciale (devis joint à une commande) ou par exemple sur un calcul (trace de calcul). Ces fichiers peuvent être de toute extension possible et supportée par windows.

Tous ces fichiers joints sont stockés physiquement sur un serveur windows, dans une racine partagée puis une organisation de répertoires/dossiers dépendantes du paramétrage des fichiers joints dans l’ERP. Plus d’informations sur l’utilisation dans l’ERP par exemple ici Chemins, notes et fichiers joints
Au final, selon le paramétrage ERP, une arborescence de répertoires/dossiers personnalisable et dynamique (par exemple par nom du client) est créée.

• Tous les utilisateurs windows identifiés doivent avoir accès aux répertoires/dossiers des fichiers joints

• L’utilisateur du service DhsService doit également avoir accès aux répertoires/dossiers des fichiers joints

• L’utilisateur de service DhsXLan ne doit pas nécessairement avoir un accès explicite si les chemins exploités dans l’ERP sont des chemins UNC

• Il est possible de modifier les permissions windows accordées à ces répertoires/dossiers, en attribuant des droits différents par répertoire en utilisant par exemple des groupes de sécurité contenant les utilisateurs concernés. Permet par exemple de rendre confidentiel des fichiers sensibles
  
  

Flux et protocoles d'échange

Exemples de déploiements

• Configuration Standalone

  • Regroupement des services sur un même serveur

  • Cas d'usage :

    • Poste de démonstration

    • Installation avec un faible nombre d'utilisateurs (< 15)

• Configuration intermédiaire

  • Regroupement des services 'backend' sur un même serveur à l'exception de l'instance de base de données

  • Exploitation de serveurs dédiés pour les rôles suivants :

    • Infinity App (avec répartition de charge, tolérance de panne et accès à l'ERP depuis le réseau Internet)

  • Infinity DhsServices (exécution des programmes liés aux services Diva)

  • Cas d'usage :

    • Installation de moyenne à grande envergure. Le nombre d'utilisateurs dépend

principalement du nombre de serveurs 'App' et de leur dimensionnement.

• Isolation des traitements en tâche de fond sur un serveur dédié (scrutateurs, BPM)

• Accès des utilisateurs à l'ERP depuis le réseau Internet et/ou le réseau local

• Configuration avancée

  • Dissociation des composants sur différents serveurs

  • Exploitation de serveurs dédiés pour les différents composants Divalto:

    • Infinity DhsXlanServer

    • Infinity DhsSearchServer

    • Infinity DhsServices

    • Infinity WebServices

    • Infinity App Servers

    • Infinity DhsTelnet

• Cas d'usage :

  • Installation de grande envergure qui exploite de nombreux services Divalto. Dans ce contexte, le nombre d'utilisateurs dépend principalement du nombre de serveurs 'App' et de leur dimensionnement.

  • Isolation des traitements en tâche de fond sur un serveur dédié (scrutateurs, BPM)

  • Isolation des traitements liés aux services web (WebService Diva / API RecordSQL)

  • Isolation du mécanisme d'indexation PowerSearch

  • Isolation des accès DhsTelnet (terminaux code-barres)

  • Accès des utilisateurs à l'ERP depuis le réseau Internet et/ou le réseau local

• Les composants Divalto peuvent être isolés sur des serveurs dédiés à chaque type d'environnement (production – hors production)

Préconisations techniques serveur

• Les préconisations techniques en matière d'allocation de ressources sur les différents serveurs doivent être adaptées en fonction du contexte réel d'utilisation

  • DhsXlanServer

    • 4 vCPU – 8-12GB RAM

    • Quantité de mémoire variable selon nombre d'utilisateurs, nombre d'environnements actifs

    • Un volume de stockage dédié à l'ERP est recommandé en plus du volume dédié à l'OS

    • Si ce serveur contient également les fichiers joints, un volume supplémentaire est recommandé

  • DhsSearchServer

    • 2-4 vCPU – 4-8GB RAM

    • Variable selon le nombre de service, la fréquence des indexations et la quantité de données

    • Un volume de stockage dédié aux bases de données Search est recommandé en complément du volume lié à l'OS

  • SQL Server :

-4-8vCPU – 16-128GB RAM

• Selon usage (nombre de transactions, nombre et taille des bases de données

• Un volume de stockage supplémentaire est recommandé pour : SQLData, SQLTempDB, SQLLog (Taille de cluster : 64k)

• Le volume en charge de la base de données temporaire (TempDB) doit disposer d'un maximum d'IOPS

• Ces volumes doivent disposer d'un cache en écriture

• AppServer (Interface Web, Transport 'Socket IP' ou 'Service Web')

  • 4 vCPU – 8-16GB RAM

  • Un serveur par tranche de 70 utilisateurs environ

  • Scalabilité horizontale recommandée pour améliorer la montée en charge et accueillir davantage d'utilisateurs

  • Il faut compter 200MB par utilisateur en moyenne (dépend du nombre de tâche simultanée par utilisateur)

  • 200 MB x 70 utilisateurs = 14GB (Réserver au moins 2GB pour l'OS, IIS, ..)

• DhsTelnet

  • 2 vCPU – 4-8GB RAM

  • Une seule tâche par terminal avec une faible empreinte mémoire

  • Dépend du nombre d'utilisateurs connectés mais configuration de base suffisante dans la plupart des cas

• WebServices (SOAP/API REST)

  • 2-4 vCPU – 4-12GB RAM

  • Selon usage (fréquence d'appel) et type de service web

  • Scalabilité horizontale possible pour améliorer la montée en charge (et la tolérance de panne)

• DhsServices

  • 2-4 vCPU – 4-8GB RAM

  • Variable selon le nombre et le type d'activité des services Diva

Préconisations techniques client

Préconisations vis-à-vis du Client Divalto / Interface Web

• L'interface Web est compatible avec tout navigateur Web récent indépendamment de l'OS

• Configuration client léger recommandée : Windows 10 – 4 Core CPU – 8GB RAM – (300MB de stockage pour l'installation)

  • Cette configuration tient compte d'autres programmes exécutés en parallèle (Microsoft Office, ..)

  • La quantité de mémoire dépendra principalement du nombre de fenêtres ouvertes

• Indépendamment du protocole de transport client utilisé, il faut compter par poste client 25KB/s en réception (Serveur vers client) et 15 KB/s en émission (Client vers serveur)

  • Ceci ne tient pas compte des transferts de fichiers ou des flux d'impressions ponctuels

Protocoles d'échange

• Transport « Local » ou « Xlan » :

  • Permet à différents serveurs de dialoguer avec le service DhsXlanServer

    • Serveurs d'applications (xRtDiva.exe)

    • Serveurs WebServices (xRtDiva.exe)

    • […]

  • Nécessite une installation complète (Runtime Divalto) pour être utilisé

  • Nécessite un réseau fiable à faible latence donc inadapté pour des postes utilisateurs

  • Peut être exploité sur des serveurs de type 'Remote Desktop Host Session'

Transport Local

• Plusieurs services DhsXlanServer peuvent être exploités sur une même installation selon le type de déploiement. Il gère en effet :

  • Les réservations (entités, ..)

  • La gestion des fichiers, y compris certains accès à la base de données SQL

  • Les licences

• Le service DhsXlanServer écoute par défaut sur le port 1235 (Protocole TCP)

  • Possibilité de changer ce numéro de port en modifiant un paramètre de la base de registre globale au serveur (HKLM) à l'aide de l'utilitaire « xDivaltoMajIni.exe »

    • Chapitre « System »

    • Clé : « NumeroService »

Ce service est automatiquement déclaré et démarré lors de l'installation d'un Runtime Divalto

Protocoles d'échange

Transport « Socket IP »

• Exploité pour les échanges entre Divalto Client (Xwpf.exe) et les serveurs d'applications

• Nécessite Divalto Client ou un Runtime complet pour être utilisé

• Doit être exploité sur un réseau local fiable à faible latence (< 30ms)

• Ne nécessite aucun composant supplémentaire sur les serveurs d'applications

Transport 'Socket IP'

Le service 'DhsTerminalServer' est exploité sur chaque serveur d'applications pour permettre l'accès en mode 'Socket IP' depuis Divalto Client (Xwpf.exe)

• Ce service fonctionne en lien avec un autre service (DhsDivaAgent) qui a la

charge d'exécuter les processus 'xRtDiva.exe' en lien avec chaque tâche Divalto.

• Les processus 'xRtDiva.exe' sont exécutés sur les serveurs d'applications en utilisant l'identité de l'utilisateur à l'aide d'un mécanisme d'impersonation. Ceci permet d'exploiter le contexte de sécurité lié à l'utilisateur. Ces processus gèrent l'exécution des programmes Diva ainsi que l'accès aux ressources (base de données, fichiers, ..)

Le service DhsTerminalServer écoute par défaut sur le port 1246 (Protocole TCP)

• Possibilité de changer ce numéro de port en modifiant un paramètre de la base

de registre globale au serveur à l'aide de l'utilitaire « xDivaltoMajIni.exe »

• Chapitre « ClientLeger »

• Clé : « port »

Ce service est automatiquement déclaré et démarré lors de l'installation d'un Runtime Divalto

Protocoles d'échange

• Transport « Service Web »

  • Encapsule les échanges entre Divalto Client et les serveurs d'applications dans des trames HTTP

  • Nécessite Divalto Client ou un Runtime pour être utilisé

  • Tolère des perturbations réseaux et une latence maximale recommandée de 70ms

  • Impose l'installation de Microsoft IIS sur les serveurs d'applications

  • Il est recommandé d'ajouter une sécurité sur la couche de transport avec SSL/TLS

Transport 'Service Web'

• En mode de transport 'Service Web', l'application 'Divalto Client' (Xwpf.exe) dialogue avec un serveur d'applications en utilisant le protocole SOAP au travers d'une application Web sur le composant Microsoft IIS

  • L'application Web fonctionne en lien avec le service 'DhsDivaAgent' qui a la

charge d'exécuter les processus 'xRtDiva.exe' en lien avec chaque tâche Divalto.

• Les processus 'xRtDiva.exe' sont exécutés sur les serveurs d'applications en utilisant l'identité de l'utilisateur à l'aide d'un mécanisme « d'impersonation ». Ceci permet d'exploiter le contexte de sécurité lié à l'utilisateur. Ces processus gèrent l'exécution des programmes Diva ainsi que l'accès aux ressources (base de données, fichiers, ..)

• Le port d'accès dépend de la configuration IIS (binding)

  • Si le service est exposé sur Internet, des considérations particulières concernant la sécurité sont à prendre en compte (Reverse proxy, SSL/TLS, ..)

• Le composant Microsoft IIS doit être installé et configuré

  • Un assistant d'installation Divalto vous permet d'effectuer ces opérations

Divalto Client (Xwpf.exe)
WebService / Socket IP / Local

Divalto Client (Xwpf.exe)
WebService / Socket IP / Local

Interface Web / HTML5

• Transport « Web / HTML5 »

  • Interface Web pour exploiter les serveurs d'applications

  • Accessible à partir d'un simple navigateur Web

  • Tolère des perturbations réseaux et une latence maximale recommandée de 70ms

  • Impose l'installation de Microsoft IIS sur les serveurs d'applications

  • Il est recommandé d'ajouter une sécurité sur la couche de transport avec SSL/TLS

• L'interface Web intègre les fonctions du composant Divalto Client (Xwpf.exe) afin de permettre l'usage de l'ERP en utilisant un navigateur.

  • L'application Web fonctionne en lien avec le service 'DhsDivaAgent' qui a la charge d'exécuter les processus 'xRtDiva.exe' en lien avec chaque tâche Divalto.

  • Les processus 'xRtDiva.exe' sont exécutés sur les serveurs d'applications en utilisant l'identité de l'utilisateur à l'aide d'un mécanisme d'impersonation. Ceci permet d'exploiter le contexte de sécurité lié à l'utilisateur. Ces processus gèrent l'exécution des programmes Diva ainsi que l'accès aux ressources (base de données, fichiers, ..)

• Le port d'accès dépend de la configuration IIS (binding)

  • Si le service est exposé sur Internet, des considérations particulières concernant la sécurité sont à prendre en compte (Reverse proxy, SSL/TLS,..)

• Le composant Microsoft IIS doit être installé et configuré

  • Un assistant d'installation Divalto vous permet d'effectuer ces opérations

Interface Web / HTML5

Interface Web / HTML5

Récapitulatif

Protocoles d'échange

• Communication « Divalto Search »

  • Echange de données entre le processus 'xRtDiva.exe' et le service 'Search'

  • A chaque processus de recherche client correspond un thread sur le serveur de recherche. Le serveur renvoie le résultat de la recherche vers le client.

Communication 'Divalto Search'

• Le service 'DhsSearchServer' est exploité pour réaliser l'indexation et traiter les demandes de recherche des utilisateurs

  • Il est possible d'installer plusieurs services DhsSearchServer sur le même serveur afin de traiter des données en provenance de différentes sources.

  • Par défaut, aucun service DhsSearchServer n'est installé.

• Le service DhsSearchServer exploite le port 1236 (Protocole TCP)

  • Vous avez la possibilité d'assigner un numéro de port différent au moment de l'installation du service.

  • Chaque service doit disposer de son propre port s'il s'exécute sur le même serveur afin d'éviter tout conflit.

Protocoles d'échange

• Accès à la base de données

  • Deux canaux d'accès complémentaires à la base de données SQL :

    • XrtDiva/ADO.NET (RecordSQL en accès direct au travers d'une connexion ADO.NET)

    • XLAN/ODBC (Fonctions Diva de gestion des fichiers au travers du service DhsXlanServer)

Accès base de données

• Le service DhsXlanServer accède à la base de données en utilisant une source de données ODBC

  • DhsXlanServer nécessite une source de données 64 bits

  • La source ODBC est uniquement nécessaire sur le serveur DhsXlanServer.

  • Cette source de données (DSN) est définie au niveau du fichier 'connexionODBC.cfg' ou en cas d'absence de ce fichier dans les fichiers séquentiels « FHSQL »

• Le processus XrtDiva.exe accède directement à la base de données en utilisant le protocole ADO.NET

  • La configuration s'effectue au niveau du fichier 'connexions.xml'

Tables (Serveurs / Chemins)

• Des tables sont présentes pour indiquer les éléments d'accès aux différentes ressources

• La liste des 'serveurs' doit être définie pour définir :

  • Les bases de données (Uniquement sur le serveur DhsXlanServer)

  • Les serveurs DhsXlanServer

  • Les services DhsSearchServer

• Si vous exploitez des chemins qui figurent en dehors du dossier d'installation par défaut, ils devront également être définis dans une table des chemins.

  • Cette table contient la correspondance entre un chemin Harmony et un chemin Windows.

Ces deux tables sont gérées par les fichiers 'divaltoserver.cfg' et 'divaltopath.cfg' (divalto\sys) ou le cas échéant, dans les fichiers séquentiels indexés « FCONFIG ».

Chemins Harmony

• Définition

  • C'est un raccourci vers un répertoire Windows

Exemples : /divaltoc:\divalto /divalto_erpd:\divalto_erp

• Si un nom de fichier commence par /, le premier élément du nom est un chemin Harmony.

Exemples :

/divalto/sys/xtools.dhop c:/divalto/sys/xtools.dhop /divalto_erp/env/ d:/divalto_erp/env

• Ces chemins permettent d'accéder aux fichiers, programmes, masques, qui sont situés sur le serveur

• Le chemin '/divalto' est automatiquement défini et exploite le répertoire d'installation

• Nom de fichier réseau

  • //serveur/chemin_sur_serveur/…/monfichier

  • Le second élément du nom est obligatoirement un nom de chemin Harmony défini sur le serveur

Fichiers d’implicites

Un fichier d'implicites contient une liste de chemins qui seront exploités dans l'ordre d'apparition dans le fichier afin d'atteindre des ressources (programmes, base de données, masque d'écran, sources, ..)

• Il est important de limiter le nombre de déclarations et de veiller à ne pas conserver de déclarations obsolètes au niveau de ces fichiers.

• Il est recommandé de créer un fichier d'implicites minimaliste pour les utilisateurs et un fichier

plus complet (avec les sources, .. ) pour les administrateurs et les développeurs.

• Un fichier d'implicites est associé à chaque utilisateur. Si le nom du fichier n'est pas précisé, c'est le fichier 'ImplicitesDefaut.txt' qui sera exploité.

• Pour chaque fichier d'implicites, un fichier du même nom avec l'extension XML est présent afin

de faire le lien avec la connexion SQL du fichier 'connexions.xml'

• Dans le cas contraire, c'est la connexion 'Default' qui sera prise en compte

• Les fichiers d'implicites sont centralisés sur le serveur DhsXlanServer.

Fichiers d’implicites

• Exemple de fichier d'implicites

Utilisateurs

• L'utilisateur est l'entité de connexion

• Le code utilisateur détermine le contexte d'utilisation (droits, fichier d'implicites, ..)

• Il est possible de gérer les utilisateurs directement dans Divalto Infinity de manière indépendante

• Une synchronisation des utilisateurs en provenance d'un annuaire LDAP est cependant préférable pour simplifier la gestion des comptes

• Les comptes des utilisateurs sont gérés à deux niveaux :

  • Dans Infinity

    • Les utilisateurs créés/supprimés dans l'ERP sont aussi créés/supprimés dans Harmony

  • Outils de gestion centralisée des utilisateurs

  • Gestion des utilisateurs par groupe pour l'affectation des droits

  • Dans Harmony

    • Les utilisateurs créés/supprimés dans Harmony ne le sont pas dans l'ERP

Des confidentialités permettent de restreindre l'accès des utilisateurs au sein de l'ERP

• R***, G***, T***… : doit administrateur de module (Règlement, Gestion commerciale, CRM, …)

• $$ : super administrateur

Synchronisation LDAP

La synchronisation LDAP permet de n'avoir à gérer les utilisateurs qu'au niveau de l'annuaire

• Les utilisateurs sont membres de groupes de sécurité dans l'annuaire. Ces groupes sont associés à des modèles d'utilisateurs dans l'ERP. La synchronisation va permettre d'appliquer les paramètres du modèle à chaque utilisateur concerné

  • Si un utilisateur est désactivé ou supprimé, le processus de synchronisation va désactiver le compte au niveau de l'ERP

  • Dans le cas d'un nouvel utilisateur, ce mécanisme simplifie la configuration du fait de l'utilisation de modèles

La synchronisation peut également s'appliquer aux comptes existants lorsqu'il s'agit de répercuter des modifications effectuées sur le modèle par exemple

Environnements

• Un environnement est un ensemble de ressources et de services. Chaque environnement est potentiellement indépendant avec une base de données dédiée, des programmes particuliers, des utilisateurs, …

• Plusieurs environnements peuvent cohabiter sur la même installation

• Les environnements sont principalement exploités pour isoler

des contextes d'utilisation différents : Production, recette, ..

• La version de l'ERP peut être différente entre les environnements

Les environnements sont constitués par différents paramètres puis exposés aux utilisateurs sous un nom explicite

• Serveur d'identification

• Serveur Search

• Chemin des traductions

• Chemin des aides en ligne

• […]

Les services sont en mesure d'exploiter les environnements de la même manière que les utilisateurs (Interface Web / Divalto Client)

• DhsTelnet

• DhsServices

• WebServices

• […]