Dossiers
Cette fonction permet de créer et de mettre à jour un dossier. Un dossier est un référentiel complet, identifié par un code, dans lequel on retrouve tous les paramètres et règles de gestion et toutes les données utilisées. Un dossier se caractérise par :
- un répertoire de base et un ensemble de sous-répertoires sur le serveur d'application. On y retrouve les objets SAFE X3 issus du paramétrage.
- un user oracle (ou un couple user, login avec SQL server) défini sur le serveur de données. Toutes les tables de la base y sont rattachées.
Création/duplication d'un dossier
La création d'un dossier est un préliminaire indispensable avant de pouvoir commencer à paramétrer et /ou à saisir des données. Cette opération est relativement longue. Autant il est courant de revalider un dossier en cours de paramétrage lorsque les paramètres de configuration sont affinés, autant on essaiera de créer directement avec les bons paramètres le ou les dossiers qui seront utilisés en exploitation. En effet, cette phase conditionnera le bon dimensionnement de départ la base et évitera le recours ultérieur aux outils d'exploitation de la base pour redimensionner. Par ailleurs, sur un dossier en exploitation, une revalidation peut être une opération relativement longue et nécessite que personne ne soit connecté sur le dossier traité.
On part toujours d'un dossier de référence pour pouvoir créer un dossier. L'intérêt d'utiliser un dossier de référence est de pouvoir partir d'un paramétrage de base. Le dossier superviseur, qui peut servir de dossier de référence, et qui contient l'ensemble des paramètres relatifs à la législation courante, est livré avec le progiciel, mais n'importe quel autre dossier peut servir de référence.
La création/duplication d’un dossier dépend des options choisies au niveau de votre licence.
Cliquer sur le bouton Créer permet d’hériter par défaut de toutes les options (modules, codes activité, langues, etc) paramétrées.
Seules les options acquises lors de l’achat de votre licence peuvent être sélectionnées. »
La fiche X3, disposant de toutes les options, ne peut donc être dupliquée.
Onglet Ecrans
Dans cet onglet, un seul tableau apparaît. Il contient des codes activités de deux types, relatifs :
- au dimensionnement des tableaux dans les écrans du progiciel (en effet, les écrans permettant de saisir des documents multi-lignes sont dimensionnés statiquement à l'entrée dans une fonction).
- au dimensionnement de certaines valeurs stockées de façon dénormalisée dans la base de données. Dans ce cas, le nombre de valeurs est en général faible (normalement inférieur à la centaine).
Une valeur positive doit donc être entrée en regard de ces codes activité.
Les codes activités du premier type ne servant qu'à définir une quantité de mémoire utilisée pour l'écran, leur modification n'implique que la revalidation des écrans et fenêtres concernées. Il convient tout de même de noter que le fait de sur-dimensionner largement certaines valeurs de ce tableau signifie que l'on devra disposer de davantage de mémoire allouée par poste. Si le dimensionnement mémoire n'est pas suffisant, l'erreur Plus de mémoire disponible est susceptible d'être affichée à l'écran lors de l'exploitation du progiciel, la fonction concernée étant alors arrêtée. Il est à noter que l'on sait définir des quotas de mémoire supplémentaires pour des profils menus donnés (si certaines fonctions particulièrement consommatrices sont réservées à certains utilisateurs seulement, cela peut être paramétré de la sorte).
En regard de chaque code activité du second type, on saisit une dimension qui va permettre à la fois de définir le nombre de valeurs saisissables dans les écrans associés, mais aussi la structure des tables correspondantes de la base de données. La modification de ces valeurs impliquera donc, lors de la revalidation du dossier, un changement de structure des tables concernées.
Une valeur maximum pour la base de données est affichée pour ce type de codes activité. Cette valeur ne peut pas être dépassée, car elle conduirait à une table dont le nombre de colonnes ou la taille d'une ligne dépasserait les valeurs admissibles.
Dans certains cas, une valeur minimale pour la base de données peut être affichée. Si la valeur saisie est inférieure à cette valeur, on pourra saisir moins d'occurrences dans les écrans que ce que pourrait stocker la base. Si la valeur saisie est supérieure, les deux dimensionnements seront identiques. La raison pour laquelle ce nombre minimal peut exister est lié au fait que des états Crystal Reports standard risqueraient de ne plus fonctionner si certains champs ne sont pas présents dans la base.
Les champs suivants sont présents dans cet onglet:
Tableau Dimensionnement tables
| Code (champ DIMCOD) |
|
Les éléments de dimensionnement sont utilisés dans le calcul des formules de dimensionnement pour estimer le nombre de lignes prévues dans chaque table et, partant de là, calculer la taille prévue des tables. |
| Intitulé (champ ZDIMCOD) |
| Module (champ MODULE5) |
|
Sélectionnez un module pour le paramétrage. Ce champ vous permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier. |
| Valeur (champ NBR) |
|
Ce nombre correspond à la valeur associé à l'élément de dimensionnement de la ligne. |
| Aide |
|
Permet d'accéder à l'aide définissant la finalité de la variable de dimensionnement, les valeurs qu'elle peut prendre, les fonctions impactées. |
Onglet Tables
Cet onglet permet de renseigner un certain nombre de valeurs qui permettent ensuite à un algorithme de dimensionnement de calculer :
-
pour chaque table de la base, une taille physique de stockage estimée. Cette taille physique est utilisée lors de la définition des caractéristiques de la table (taille prévue, gestion des extents sous oracle, par exemple).
-
par cumul, une taille globale de la base
Il est important de bien renseigner ces paramètres en tenant compte de l'historique désiré (si par exemple on a une base de 500.000 écritures par an, et si on désire garder 5 ans d'historique, il faudra renseigner avec 2.500.000 le paramètre VOUCHER correspondant). En effet, si ceci n'est pas fait correctement, on devra ultérieurement réorganiser la base et ses paramètres pour éviter la fragmentation des données et obtenir des temps de réponse optimaux.
Les champs suivants sont présents dans cet onglet:
Tableau Validation transactions
| Module (champ MODTR) |
|
Sélectionnez un module pour le paramétrage. Ce champ vous permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier. |
| O/N (champ TRVAL) |
|
Une réponse positive à la question entraîne la validation des transactions associées au module. |
Tableau Langues
| Langues (champ LAN) |
|
Tableau permettant de saisir les langues avec lesquelles on pourra se connecter au dossier. La validation du dossier entraîne notamment la génération des écrans de saisie dans les toutes ces langues: cette opération est très consommatrice de ressources système. |
| Réf. traduction (champ LANREF) |
|
Cette case à cocher ne peut être cochée que si les deux conditions suivantes sont réunies :
Elle permet de préciser que le dossier courant est le dossier de référence de traduction pour la langue en question, c'est-à-dire qu'il est le dossier porteur des traductions les plus à jour pour la langue concernée. Par défaut pour les langues livrées en standard, il s’agit bien sûr du dossier racine, ce qui explique que la case ne puisse pas être cochée dans un dossier normal; mais pour des langues « non standard » liberté est donnée à l'utilisateur de se définir un dossier référence de traduction. Un contrôle vérifie l’unicité du dossier référence de traduction pour une langue, si on désire en changer, il faut d’abord décocher le dossier préalablement positionné. Si pour une langue, il n’y a pas de dossier de référence de coché, est choisi dans l’ordre :
|
Tableau Législation
| Législation (champ LEGDOS) |
Tableau Copie de données
| Options de copie (champ LIBCOP) |
|
Chaque groupe correspond à un ensemble cohérent de tables du dossier de copie, tables dont le contenu peut être copié dans le dossier en cours de paramétrage lors de sa création. Par clic droit sur le champ, on peut avoir accès à la liste des tables dont le contenu va être copié si on répond Oui. |
| O/N (champ OPTINI) |
|
En fonction de la réponse, les données sont copiées ou pas depuis le dossier de copie. Cette copie ne se fait que lors de la création du dossier, ou en cas de création des tables suite à l'activation d'un nouveau module. |
Valeurs par défaut
| Langue par défaut (champ LANDEF) |
|
Permet de mettre à jour le paramètre LANGAGE (langue principale) du dossier. Ce paramètre permet de définir une langue de connexion quand elle n'est pas précisée comme par exemple pour les traitements batch. |
| Pays par défaut (champ CRYDEF) |
|
Permet de mettre à jour, lors de la création du dossier, le paramètre CRYDEF. Ce paramètre correspond au pays proposé par défaut en saisie des adresses. |
| Crible pour renommer (champ CHGCOD) |
|
Ce champ permet de donner un crible qui définit une liste de codes de recodification. Si ce crible est renseigné, à la fin de la création, les paramètres recopiés depuis le dossier de référence seront renommés conformément aux règles de renommage définis par les codes considérés (pris dans l'ordre). Ceci est particulièrement utile lorsqu'on souhaite par exemple créer un dossier mono-législation : certains codes de paramétrage, préfixés par un code législation, sont particulièrement lourds à utiliser dans ce cas, et la recodification peut simplifier l'utilisation des paramètres par la suite. |
Mise à jour
| Mise à jour écrans (champ CREMSK) |
|
Ces champs sont toujours cochés dans un environnement normal de livraison. Ils servent à l'éditeur, dans un contexte de développement, de revalider un dossier pour tests en évitant la génération du code correspondant aux options présentées (écrans, objets, fenêtres, consultations). |
| Fenêtres (champ CREWIN) |
| Mise à jour objets (champ CREOBJ) |
| Consultations (champ CRECNS) |
| Aide |
Onglet Initialiser
Dans cet onglet, vous définissez les valeurs par défaut utilisées lors de la création effective du dossier, ainsi que les paramètres influant sur la façon dont la revalidation d'un dossier va se faire :
- Les options de copie permettent de renseigner les données de certaines tables à partir du contenu des tables d'un autre dossier (le dossier de copie déclaré dans le premier onglet, le dossier de référence par défaut). Cette opération se fait lors de la création du dossier, ou lors d'une revalidation, si un ajout de modules active des tables qui n'étaient pas encore utilisées. Le crible de renommage permet de renommer les codes créés par ces options de recopie.
- Le tableau Validation des transactions permet d'éviter la revalidation de tous les écrans paramétrables à partir d'écrans de base (dans le menu paramétrage de chaque module) lors d'une revalidation de dossier. Cette revalidation pouvant être longue, et n'étant pas nécessaire si les écrans de base n'ont pas vu leur structure changer, elle peut être évitée en répondant Non à la question. Si on a répondu Non par erreur à cette question, ou si on a voulu volontairement rendre plus courte la durée de revalidation de dossier, on pourra toujours relancer cette validation séparément par la fonction dédiée.
- La série de cases à cocher Mise à jour permet d'éviter la régénération de code associée à la revalidation d'un certain nombre d'éléments du dictionnaire en revalidation de dossier. Là encore, il s'agit d'optimiser un temps de revalidation. Pour des raisons de sécurité, ces cases ne peuvent être décochées que dans un dossier de développement, et elles doivent l'être avec prudence. Cette phase peut également être refaite a posteriori par une fonction dédiée.
- Le tableau des langues permet de définir la liste des langues utilisables par des utilisateurs en connexion sur le dossier. Il est conseillé de ne choisir que celles qui sont réellement utiles, car cela ralentit la création du dossier (une partie des fichiers liés aux fenêtres est générée dans chaque langue retenue).
Les champs suivants sont présents dans cet onglet:
Tableau Validation transactions
| Module (champ MODTR) |
|
Sélectionnez un module pour le paramétrage. Ce champ vous permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier. |
| O/N (champ TRVAL) |
|
Une réponse positive à la question entraîne la validation des transactions associées au module. |
Tableau Langues
| Langues (champ LAN) |
|
Tableau permettant de saisir les langues avec lesquelles on pourra se connecter au dossier. La validation du dossier entraîne notamment la génération des écrans de saisie dans les toutes ces langues: cette opération est très consommatrice de ressources système. |
| Réf. traduction (champ LANREF) |
|
Cette case à cocher ne peut être cochée que si les deux conditions suivantes sont réunies :
Elle permet de préciser que le dossier courant est le dossier de référence de traduction pour la langue en question, c'est-à-dire qu'il est le dossier porteur des traductions les plus à jour pour la langue concernée. Par défaut pour les langues livrées en standard, il s’agit bien sûr du dossier racine, ce qui explique que la case ne puisse pas être cochée dans un dossier normal; mais pour des langues « non standard » liberté est donnée à l'utilisateur de se définir un dossier référence de traduction. Un contrôle vérifie l’unicité du dossier référence de traduction pour une langue, si on désire en changer, il faut d’abord décocher le dossier préalablement positionné. Si pour une langue, il n’y a pas de dossier de référence de coché, est choisi dans l’ordre :
|
Tableau Législation
| Législation (champ LEGDOS) |
Tableau Copie de données
| Options de copie (champ LIBCOP) |
|
Chaque groupe correspond à un ensemble cohérent de tables du dossier de copie, tables dont le contenu peut être copié dans le dossier en cours de paramétrage lors de sa création. Par clic droit sur le champ, on peut avoir accès à la liste des tables dont le contenu va être copié si on répond Oui. |
| O/N (champ OPTINI) |
|
En fonction de la réponse, les données sont copiées ou pas depuis le dossier de copie. Cette copie ne se fait que lors de la création du dossier, ou en cas de création des tables suite à l'activation d'un nouveau module. |
Valeurs par défaut
| Langue par défaut (champ LANDEF) |
|
Permet de mettre à jour le paramètre LANGAGE (langue principale) du dossier. Ce paramètre permet de définir une langue de connexion quand elle n'est pas précisée comme par exemple pour les traitements batch. |
| Pays par défaut (champ CRYDEF) |
|
Permet de mettre à jour, lors de la création du dossier, le paramètre CRYDEF. Ce paramètre correspond au pays proposé par défaut en saisie des adresses. |
| Crible pour renommer (champ CHGCOD) |
|
Ce champ permet de donner un crible qui définit une liste de codes de recodification. Si ce crible est renseigné, à la fin de la création, les paramètres recopiés depuis le dossier de référence seront renommés conformément aux règles de renommage définis par les codes considérés (pris dans l'ordre). Ceci est particulièrement utile lorsqu'on souhaite par exemple créer un dossier mono-législation : certains codes de paramétrage, préfixés par un code législation, sont particulièrement lourds à utiliser dans ce cas, et la recodification peut simplifier l'utilisation des paramètres par la suite. |
Mise à jour
| Mise à jour écrans (champ CREMSK) |
|
Ces champs sont toujours cochés dans un environnement normal de livraison. Ils servent à l'éditeur, dans un contexte de développement, de revalider un dossier pour tests en évitant la génération du code correspondant aux options présentées (écrans, objets, fenêtres, consultations). |
| Fenêtres (champ CREWIN) |
| Mise à jour objets (champ CREOBJ) |
| Consultations (champ CRECNS) |
| Aide |
Onglet Spécifiques
Dans cet onglet, on trouve un tableau définissant la valeur et les caractéristiques associées aux codes activité commençant par X, Y, ou Z, qui permettent de marquer les développements spécifiques.
Les champs suivants sont présents dans cet onglet:
Tableau
| Code (champ CODACT4) |
|
Définit les codes activités spécifiques (ie. commençant par X, Y, ou Z), qui peuvent être activés sur le dossier. |
| Intitulé (champ LIBACT4) |
|
Intitulé associé au code précédent |
| Module (champ MODULE4) |
|
Sélectionnez un module pour le paramétrage. Ce champ vous permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier. |
| Actif (champ FLACT4) |
|
Si ce champ vaut Oui, les champs marqués par le code activité dans le dictionnaire seront activés. |
| Dimension (champ DIME4) |
|
Cette dimension associée au code activité spécifique permet de dimensionner des tableaux et des champs multi-occurrences marqués par le code activité en question. |
| Vertical (champ COP) |
|
Cet indicateur doit être mis à Oui dans le cas où :
Si l'indicateur reste à Non, les spécifiques ne seront pas remis à jour en cas de revalidation s'ils existent déjà. Cet indicateur permet en fait de distinguer les développements verticaux qui sont susceptibles d'être installés chez un ensemble de dossiers et remis à jour par revalidation à 3 niveaux, et les développements faits dans le dossier de plus bas niveau (développements faits par le client par exemple). Pour plus d'informations, il est conseillé de consulter l'annexe technique correspondante. |
Onglet Divers
Cet onglet permet de définir des éléments de dimensionnement utiles à l'environnement d'exécution des processus serveurs associés à chacune des sessions du progiciel ouvertes. Les données saisies sont stockées dans un fichier de configuration nommé APL.ini, situé sur le serveur, dans le répertoire de base du dossier, une fois qu'il est créé. Ces paramètres ont une valeur minimale qui sera utilisée si les valeurs paramétrées dans cet écran ne sont pas suffisants.
Les champs suivants sont présents dans cet onglet:
Système
| Mémoire processus moteur (Mo) (champ MEM) |
|
Ce paramètre correspond à la taille mémoire utilisée pour les données locales lors de l'exécution du processus serveur. Par défaut, elle est proposée à 16 Mo, ce qui est une valeur raisonnable même si la valeur minimale possible est de 4 Mo. On peut être amené à l'augmenter en fonction du nombre de lignes maximum utilisées pour les grands tableaux en mémoire (commandes, factures, écritures...). Plus les valeurs données dans l'onglet Ecrans sont élevées, plus on peut être amené à augmenter la taille mémoire nécessaire. La variable système maxmem permet d'en connaître la valeur courante dans une session en exécution. |
| champ MEM1 |
| Mémoire processus base de données (Mo) (champ MSA) |
|
Cette zone permet de définir la taille mémoire allouée au processus accédant à la base de données (il se nomme sadora ou sadoss selon la base de données). La valeur par défaut est égale à 20 Mo, et n'a pas besoin d'être changée, sauf rares exceptions. La variable système sadmem permet d'en connaître la valeur courante dans une session en exécution. |
| champ MSA1 |
| Programmes (champ MPR) |
|
Ce paramètre permet de définir le nombre maximum de traitements ouverts simultanément dans une session du progiciel. La valeur par défaut est de 200, la valeur minimale étant de 100. Un nombre plus élevé améliorera les performances en limitant le rechargement de traitements. La variable système adxmpr permet d'en connaître la valeur courante dans une session en exécution. |
| champ MPR1 |
| Tables ouvertes (champ MTO) |
|
Ce paramètre permet de définir le nombre maximum de tables de la base simultanément en ligne dans une session du progiciel. La valeur par défaut est de 150, et elle est bien adaptée dans la plupart des cas. La variable système adxmto permet d'en connaître la valeur courante dans une session en exécution. |
| champ MTO1 |
| Fichiers séquentiels (champ MSO) |
|
Cette zone permet de définir le nombre maximum de fichiers séquentiels simultanément ouverts dans une session du progiciel (par les instructions Openi, Openo, Openio). La valeur par défaut est de 10, la valeur minimale étant de 10. Sauf cas très particulier lié à l'utilisation de ces instructions, cette valeur n'a pas de raison d'être modifiée. La variable système adxmso permet d'en connaître la valeur courante dans une session en exécution. |
| champ MSO1 |
| Mémoire classes (champ MST) |
| champ MST1 |
| Activation lien |
| Test lien |
Onglet Liens
Cet onglet définit les caractéristiques de connexion au dossier, et notamment les informations se trouvant dans la boîte de connexion du poste client, lorsqu'on établit une connexion au dossier. Le fait de les renseigner ici permet de mettre à jour un fichier de configuration situé sur le serveur, dans le répertoire de base du dossier superviseur, et nommé X3APPLI.ini. Ce fichier peut être téléchargé sur les postes clients à l'aide du bouton idoine, à partir de la boîte de définition des paramètres de connexion.
Cet onglet permet également de définir des liens du dossier vers des dossiers situés dans d'autres solutions (ie. un autre serveur, ou un autre service de connexion, ou les deux).
L'intérêt est de simplifier la mise en oeuvre de connexions entre progiciels en technologie SAFE X3 lorsqu'ils doivent partager ou mettre à jour des données communes. L'exemple classique de ce type de coopération est le cas d'un progiciel qui doit mettre à jour une comptabilité située dans un dossier distant.
De façon technique, un programme situé dans un dossier DOSSIER1 est susceptible d'ouvrir des tables dans un dossier distant nommé DOSSIER2 par l'intermédiaire d'une syntaxe de type :
File ="serveur:[email protected]"
Lorsque ceci arrive, un processus d'accès aux données est ouvert sur le serveur distant ( il s'appelle sadora ou sadoss selon la base de données concernée), et cherche à se connecter à la base de données avec un nom d'utilisateur par défaut (au sens base de données) égal au code DOSSIER1 du dossier d'où la requête est lancée.
S'il existe, pas de problèmes, mais il faut faire en sorte que les privilèges d'accès aux tables du dossier DOSSIER2 soient suffisantes.
Si un dossier de nom DOSSIER1 n'existe pas sur le serveur distant, aucun accès ne sera possible, sauf si on a défini, sur le serveur distant, un répertoire DOSSIER1 contenant un nombre minimum de fichiers stratégiques utilisés lors du démarrage d'un processus de ce type (les fichiers .users, .password, APL.ini, adxora).
Le fichier adxora stocke notamment, sous forme codée, le code user sous lequel le processus d'accès aux données se connectera, et le mot de passe correspondant.
C'est pourquoi on saisira dans cet onglet un tableau de liens avec les paramètres suffisants pour permettre la création des fichiers autorisant la connexion distante. Cette création n'aura pas lieu lors de la saisie de la ligne, mais elle sera déclenchée lorsqu'on aura activé le lien (fonction accessible via clic droit sur la ligne).
Il est à noter que les liens peuvent être caractérisés fonctionnellement : un Lien comptable, par exemple correspond à un lien permettant à un progiciel d'accéder à une comptabilité distante. Un seul lien caractérisé de chaque type est possible par dossier, et dans ce cas, il faudra préciser les caractéristiques complètes du dossier distant auquel on se connecte. L'intérêt de ces liens caractérisés est qu'ils sont gérés par les progiciels qui les supportent (une opération de comptabilisation dans un progiciel sans comptabilité recherchera explicitement un lien comptable pour savoir s'il doit accéder à une comptabilité distante).
Il existe également des liens de type Divers : il peut y en avoir plusieurs de ce type pour un dossier donné (sachant que le nombre total de liens tous types confondus est limité à 5). Ils sont supposés être gérés dans des traitements spécifiques. Un lien de ce type ne référence pas forcément un dossier particulier, mais il peut simplement correspondre à un environnement donné. Dans ce cas, les connexions auront lieu avec un code user base de données à préciser.
Lors de la saisie de lignes de liens, le traitement recherche quelle est la version du progiciel SAFE X3 installée dans l'environnement cible. Il détecte notamment la présence d'un fichier solution.xml, ce qui permet de déduire un certain nombre de valeurs par défaut lors de la saisie d'une ligne. En l'absence d'un tel fichier, le traitement suppose que le dossier distant est en version 13X.
Les champs suivants sont présents dans cet onglet:
Connexion
| Dossier (champ CDOSSIER) |
|
Ce champ, uniquement affiché, correspond au code du dossier sur lequel on travaille. |
| Serveur d'application (champ CSERVEUR) |
|
Correspond au nom ou à l'adresse réseau du serveur d'application, c'est-à-dire au serveur sur lequel est stocké le référentiel du dossier (notamment les répertoires des différents dossiers de la solution). |
| Port (champ CPORT) |
|
Définit le port TCP/IP sur lequel le service de connexion attend les demandes de connexion au dossier. |
| Chemin d'accès (champ CPATH) |
|
Uniquement affiché, ce champ correspond au répertoire racine du dossier tel qu'il est défini sur le serveur d'application. Il est défini en fonction du volume saisi dans le premier onglet de la fiche dossier. Lorsqu'on sera connecté sur le dossier lui-même, on retrouvera cette information par la calculatrice, en tapant la fonction suivante :
|
| Serveur de traitement (champ CSERVTRT) |
|
Correspond au nom ou à l'adresse réseau du serveur de traitement proposé par défaut (il peut y en avoir plusieurs, et par défaut ce peut être le serveur d'application). Un serveur de traitement est un serveur sur lequel est exécuté le code applicatif transmis par le serveur d'application. |
| Répertoire de publication (champ CPUB) |
|
Correspond au répertoire du serveur d'application à partir duquel les éléments XML définissant l'interface utilisateur sont créés. Ce champ n'est qu'affiché, sa valeur étant définie en fonction de l'installation. |
Tableau Droits d'accès au dossier
| Dossier de la solution (champ SOLDOS) |
| Autorisation accordée sur le dossier courant (champ SOLAUZ) |
Tableau Liens dossiers hors solution
| Type de lien (champ LTYPLIEN) |
|
Définit le type de lien :
|
| Lien actif (champ LLIENACT) |
|
Champ uniquement affiché qui indique si le lien est actif. Ce champ est stocké la table des dossiers, mais un contrôle d'existence du répertoire distant est fait sur les actifs lorsqu'on affiche l'onglet. |
| Machine (champ LMAC) |
|
Chemin réseau définissant le serveur distant sur lequel on doit se connecter. |
| Service (champ LSERV) |
|
Numéro de service distant sur lequel on se connecte. |
| Répertoire (champ LREP) |
|
Adresse disque d'installation de la solution distante. C'est à cet endroit que le répertoire permettant la connexion distante va être créé si un dossier de même code que le dossier courant n'existe pas. Cette adresse correspond au répertoire de base (volume 0 dans adxvolumes) sur le serveur d'application. |
| Type d'OS (champ LTYPOS) |
|
Définit le système d'exploitation du serveur vers lequel se fait le lien. |
| Dossier lié (champ LDOSTARG) |
|
Définit le dossier lié sur lequel on veut se connecter. Cette information est obligatoire lorsque le lien est caractérisé, mais ne l'est pas pour un lien divers. |
| Solution (champ LSOL) |
|
Ce champ, uniquement affiché, donne le nom de la solution (au sens SAFE X3 du terme), si celui-ci peut être trouvé dans le fichier de configuration xml (ie. si on se connecte vers un environnement de version supérieure ou égale à 140). |
| Type de base (champ LTYPDBA) |
|
Définit le type de base de données auquel on veut se connecter. |
| Nom de la base (champ LDBA) |
|
Correspond au nom de la base distante où on se connecte. Cette information est récupérée dans le fichier solutions.xml si le lien pointe vers un environnement de version supérieure ou égale à 140. |
| Source de données (champ LSRC) |
|
Ce champ, uniquement affiché, donne le nom de la source de données ODBC si celui-ci peut être trouvé dans le fichier de configuration xml (ie. si on se connecte vers un environnement de version supérieure ou égale à 140). |
| Utilisateur SGBD (champ LUSR) |
|
Définit le code utilisateur (au sens de la base de données) utilisé pour la connexion. |
| Mot de passe (champ LPWD1) |
|
Définit le mot de passe (au sens base de données) de l'utilisateur sous lequel on va se connecter à la base distante. |
| Utilisateur système (champ LUSRJAV) |
|
C'est user plateforme utilisé par le Bridge Java pour ouvrir une session distante. |
| Mot de passe (champ LPWDJAV) |
|
C'est mot de passe du user plateforme utilisé par le Bridge Java pour ouvrir une session distante. |
| Activation lien |
|
Déclenche la mise à jour du lien, c'est-à-dire la création du répertoire correspondant au code du dossier en cours de paramétrage sur le serveur distant, avec les fichiers de configuration nécessaires. Si le répertoire existe déjà, et correspond à un répertoire d'un "vrai" dossier distant (on vérifie si un sous-répertoire TRT s'y trouve), rien n'est modifié, pour éviter de perturber les connexions au dossier sur le serveur d'origine. Mais dans ce cas, il n'y a de toutes les façons rien à faire, puisque la connexion pourra se faire à distance (avec les privilèges de l'utilisateur BDD correspondant au code du dossier). |
| Test lien |
|
Permet, une fois que le lien a été activé, de vérifier qu'une connexion est possible (on cherche à ouvrir une des tables du superviseur).
|
| Désactivation lien |
|
Cette fonction désactive le lien, c'est-à-dire :
|
Etats
Par défaut, les états suivants sont associés à la fonction:
- Paramètres dossiers
- Mais ceci peut être modifié par paramétrage.
Boutons spécifiques
|
Validation |
Ce bouton lance la fonction de validation du dossier. On trouvera dans l'annexe technique dédiée le détail des opérations réalisées en validation de dossier. |
Barre de menus
|
Cette fonction est particulièrement utile lors du transfert d'un dossier complet d'un serveur vers un autre. Il est alors nécessaire d'une part de transférer l'arborescence de fichiers du dossier, d'autre part de transférer les données (ceci peut se faire avec des outils de la base de données ou par import/export de tables safe x3 si le dossier cible existe déjà). Mais il est aussi nécessaire de récupérer les informations de structure contenues dans la fiche Dossier (en effet, les informations de cette fiche sont stockées dans les tables ADOSPAR, ADOSDIM, ADOSACT, qui sont des tables du superviseur, rattachées au dossier superviseur, et donc non transférées automatiquement. L'option Importer permet précisément de créer une fiche Dossier correcte, en lisant un fichier de configuration appelé PARAM.ini, situé dans le répertoire de base du dossier transféré. Ce fichier PARAM.ini, créé lors de la création d'un dossier, est remis à jour à chaque revalidation. |
|
Cette fonction permet de visualiser le fichier de trace relatif à la dernière validation faite sur le dossier. Il est important de consulter cette trace lorsque la validation est terminée, afin de vérifier qu'il n'y a pas eu d'erreurs. Les erreurs sont signalées en rouge dans le fichier de trace. |
|
Cette fonction déclenche le calcul de taille compte tenu des paramètres de dimensionnement définis dans l'onglet correspondant. Lorsque la fonction a été exécutée, une fenêtre permet de faire apparaître dans un tableau, pour chaque table, le nombre de lignes calculés et la taille en Méga-octets nécessaires pour les données et pour les index. En bas de cette fenêtre, la taille cumulée pour les données et pour l'index est affichée, ainsi que la taille totale nécessaire. Cette taille peut être reportée (avec une majoration éventuelle pour garder une marge de manoeuvre) dans le premier onglet de la gestion de dossier. Le format de la base est bien entendu pris en compte pour déterminer la taille réelle en méga-octets proposée. L'algorithme est le suivant :
|
|
Cette fonction permet d'importer le fichier "BATCH.tmp" présent dans le répertoire de base du dossier GDOSX3. Cet import écrase les enregistrements présent dans le fichier. Pour les abonnements on ne recupère pas les paramètres et on désactive tous les abonnements durant l'import. En fin d'import le fichier "BATCH.tmp" est supprimé. Cette fonction est accessible que depuis le dossier racine GDOSX3. |
|
Cette fonction permet de créer un fichier de paramétrage pour le serveur BATCH afin de pouvoir les récupérer dans un autre dossier, une autre version. On exporte les éléments suivants :
Cette fonction crée un fichier nommé « BATCH.tmp » dans le répertoire de base du dossier GDOSX3. On récupère tous les enregistrements supérieurs à "X" aussi. Cette fonction est accessible que depuis le dossier racine GDOSX3. |
Messages d'erreur
Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie:
Volume inexistant
Le nom du volume (A par défaut) n'est pas connu.
Code déjà existant en ligne i
Dans le tableau des langues, on a saisi un code langue déjà référencé dans une ligne antérieure.
N utilisateurs sur ce dossiers
On cherche à lancer la revalidation d'un dossier, mais des utilisateurs sont encore connectés au dossier.
Messages d'erreur en validation de dossier
Lorsque la validation de dossier est lancée, un fichier trace est créé. Toute une série d'erreurs peuvent survenir. Elles se présentent sous la forme d'une ligne d'erreur (en rouge) dans la trace, suivie éventuellement d'informations complémentaires. Certaines erreurs sont génériques, mais la plupart sont liées à la phase complexe de revalidation des écrans. Les deux séries d'erreurs sont listées ci-après.
Attention:
La trace de validation de dossier est accessible par le bouton Trace à partir de la gestion de dossier. Si la validation d'un dossier est lancée par le serveur batch, la trace de la requête ne donnera que l'heure de lancement de la validation : il faudra passer par la gestion de dossier pour visualiser la trace détaillée de l'opération.
D'autres erreurs non répertoriées sont susceptibles de survenir, en particulier en changement de version. Ces erreurs seront définies dans les releases notes accompagnant les mises à jour de version.
Erreurs génériques
Dossier en cours d'utilisation
Dossier en cours de génération
N utilisateurs sur ce dossier
Ces erreurs peuvent arriver dans la phase préliminaire de verrouillage d'un dossier en cours de revalidation, lorsque le verrouillage n'est pas possible.
Erreur de lecture / Erreur d'écriture / Erreur d'effacement
Un problème de droit d'accès existe dans une table dont le nom est donné en suite de message. Cette erreur peut arriver dans n'importe laquelle de phases de génération (création des écrans, menus...) si un problème d'accès existe sur l'une des tables du dictionnaire correspondant.
Erreurs liées à la revalidation des écrans
Pas assez de place en largeur ( largeur nécessaire / Largeur maximale )
Pas assez de place en hauteur ( hauteur nécessaire / Hauteur maximale )
Lors de la validation d'un écran, il n'y a pas assez de place pour positionner tous les champs dans l'écran (ceci n'empêche pas la validation de l'écran, mais il faudra aller vérifier l'écran manuellement.
Type de données inexistant
Action inexistante
Objet inexistant
Table inexistante
Paramètre non renseigné
Ces erreurs non bloquantes peuvent survenir lors de la validation d'un écran : elle ne peuvent pas arriver sur des écrans saisis, mais pourraient arriver après transfert par copie inter-dossier d'éléments, suivi d'une revalidation de dossier : là aussi, il faudra aller vérifier l'écran manuellement.
Trop de lignes sur le bloc (max 30)
Trop de colonnes sur le bloc (max 15)
Trop de champs sur le bloc (max 150)
Trop de paramètres sur un champ (max 20)
Trop d'actions dans un écran (max 500)
Ces erreurs bloquantes peuvent survenir lors de la validation d'un écran : elle ne peuvent pas arriver sur des écrans saisis, mais pourraient arriver après transfert par copie inter-dossier d'éléments, suivi d'une revalidation de dossier : là aussi, il faudra aller vérifier l'écran manuellement.
Variable non définie sur le bloc i
La variable de bas de tableau d'un bloc n'a pas été correctement déclarée dans la structure d'un onglet
Annexe : informations techniques complémentaires
Définition des volumes
Les volumes permettent de définir des répertoires où sont installés les fichiers de l'installation du progiciel, et les fichiers concernant les dossiers créés (base de données exclue).
Ces répertoires sont définis dans un fichier de configuration nommé adxvolumes, installé dans le répertoire de base de l'installation du moteur (ce répertoire étant lui-même identifié par le volume 0 (zéro), qui est réservé à l'installation du run-time du moteur).
Le chemin de base d'un volume peut être retrouvé en utilisant la fonction suivante dans la calculatrice SAFE X3 :
filpath("!","","","","x")
où x est le code du volume (0, A,B,C...)
En renseignant le deuxième paramètre dela fonction filpath, on peut ainsi trouver le chemin exact d'accès au fichier adxvolumes lui-même :
filpath("!","adxvolumes","","","0")
Dans l'installation standard, le fichier adxvolumes contient au moins deux lignes (une des lignes pour le volume 0, l'autre pour le volume A, éventuellement d'autres pour les volumes B, C, D...) sous la forme suivante (ici sur un serveur NT, sur un serveur UNIX, on trouverait des chemins sous la forme /home/SAFEX3/runtime, par exemple) :
0 :D:\SAFEX3\Runtime
A :D\SAFEX3\Dossiers
B :E:\VolumeB
Il faut noter que l'intérêt d'utiliser d'autres volumes que les deux premiers offre relativement peu d'intérêt en soi en version 140, car les arborescences de dossier, si elles contiennent beaucoup de fichiers, prennent en général une place qui n'évolue pas beaucoup; une problématique d'optimisation d'entrées sortie par répartition sur différents disques n'est pas vraiment utile dans ce cas, les données étant stockées dans la base. Le seul cas où ceci peut être intéressant est celui où on stocke des fichiers textes et images dans le répertoire TXT, comme on le faisait en version 130 (en version 140, on a la possibilité, de loin préférable, de les stocker dans la base). Par ailleurs, lorsqu'on utilise l'interface Web, les fichiers XML générés et exploités par le serveur http sont toujours stockés dans un répertoire défini à partir du volume où le dossier superviseur est installé (c'est normalement A).
Modules utilisables pour la définition des dossiers
Les modules utilisables peuvent être définis en plusieurs types :
- Des modules fonctionnels décrits dans une documentation annexe.
- Des modules techniques (Superviseur, Tronc commun, Développement, Interne X3). Le module Interne X3 ne peut pas être activé (il est réservé aux équipes de développement SAFE X3). Il est conseillé d'activer le module Développement, même si aucun développement spécifique n'est prévu, afin d'avoir accès à certaines fonctions de maintenance directement depuis le dossier.
- Des modules supplémentaires (Module spé 1 à 4) ouverts à des développements partenaires.
Des contraintes d'interdépendance existent entre les modules. Ces contraintes sont directement testées dans la saisie des modules actifs, et documentées dans la documentation annexe. Pour les modules techniques, il est impératif que les modules Superviseur et Tronc commun soient égaux à Oui.
Tables mises en oeuvre
Reportez-vous à la documentation de Mise en oeuvre