Dossiers

• Dossier (champ DOSSIER)

Le nom du dossier peut prendre 10 caractères alphanumérique maximum. La première lettre doit être alphanumérique.

• Nom (champ NOMDOS)

Saisissez la description de la fiche concernée.

Cet intitulé long est utilisé en titre dans les écrans et les états.

• Type de base (champ TYPDBA)

Définit la base utilisée pour créer le dossier. Cette base peut être SQL SERVER ou ORACLE. En fonction de la licence qui est utilisée, ce choix sera possible ou imposé.

• Volume (champ VOLUME)

Ce numéro de volume "SAFE X3" correspond au répertoire à partir duquel les fichiers physiques (hors base de données) décrivant les objets du dossiers sont implantés sur le serveur de traitement. Les volumes SAFE X3 sont définis dans le fichier "adxvolumes" sous le répertoire d'installation (contenu dans la variable d'environnement ADXDIR). Le volume par défaut est A, mais d'autres peuvent avoir été définis lors de l'installation du progiciel.

Il est possible de sélectionner le volume par la touche .

Cf. l'annexe technique sur les volumes en fin de la documentation de la gestion de dossier.

• Groupe fichier (champ GRPFIL)

Cette question posée dans le cas d'une base SQL server permet de définir si on crée ou pas des fichiers séparés pour stocker les index et les données (pour des bases conséquentes, c'est en général le cas).

• Taille données (champ SIZDAT)

Ces valeurs permettent de dimensionner les fichiers données et index de la base. La taille est exprimée en Méga-octets.

Ces valeurs n'ont d'intérêt que pour la création d'un dossier, et elles seront mises en général saisies en fin de définition des paramètres du dossier, juste avant la création effective d'un dossier. En effet, pour disposer d'une valeur estimative correcte, il importe d'avoir au préalable dimensionné les tables de la base par le biais de valeurs de dimensionnement (onglet Tables), et d'avoir défini plus précisément la structure des tables de la base par le biais de codes activité (onglets Options, Ecrans, Spécifiques).

• Taille index (champ SIZIDX)

• Format (champ CODDBA)

Définit le jeu de caractères utilisé pour stocker les champs caractères dans la base de données. Celui-ci peut prendre les valeurs ASCIIou UNICODE.

• Le format ASCII correspond à la gestion des langues européennes : chaque caractère est stocké sur un octet, les caractères accentués étant stockés sur des valeurs supérieures à 128.

• Le format UNICODE n'est utile que lorsqu'on veut gérer des langues dont le jeu de caractères nécessite plus de 256 combinaisons. C'est le cas du chinois, par exemple.
  Le client SAFE X3 est nativement UNICODE, il sait par conséquent gérer les textes de ce type. Il a le choix, au niveau de la base de données, d'utiliser l'un des deux formats : UCS2 ou UTF8.
  
  Le format UCS2 est un format d'origine Microsoft(TM), dans lequel tout caractère est stocké sur deux octets ; les caractères ASCII usuels ont le même code (mais l'un des deux octets sur lequel ils sont codés est nul). C'est le seul format de type UNICODE supporté par SQL server. Oracle admet pour sa part d'autres formats, et en particulier le format UTF8 qui est le plus fréquent. C'est un format dans lequel les caractères sont stockés sur un nombre variable d'octets (de 1 à 5 selon les cas, les caractères ASCII standard sont stockés sur un octet, les caractères accentués en utilisent deux ; au-delà, on retrouve les langues asiatiques). Il est à noter qu'Oracle supporte d'autres normes de codage (UCS3, UCS4, UTF16...) et que ces normes pourraient être utilisées (à condition de créer manuellement la base de données).

De façon interne et indépendante du format de la base (pour ses variables temporaires), le moteur SAFE X3 utilise le format UTF8 (les sources des traitements sont codés en UTF8), et le client Windows la norme UCS2.

• Dossier de référence (champ DOSREF)

Le dossier de "référence" doit être un dossier existant, dont les données du dictionnaire seront utilisés lors de l'initialisation du dossier. Un lien de filiation demeure entre un dossier et le dossier de référence. Ainsi, par défaut, si une ressource (traitement, table, état) n'est pas trouvée dans le dossier courant, elle est recherchée dans le dossier de référence, par un mécanisme d'héritage.

Cette valeur est reprise par défaut dans le dossier de copie, dossier à partir duquel, lors de la création du dossier, on peut également recopier certaines données (paramètres, plan comptable...) ainsi qu'indiqué dans l'onglet Init.

• Dossier de copie (champ DOSCOP)

Le dossier de copie, qui doit avoir été créé au préalable, est le dossier à partir duquel les données définies par l'onglet Init vont être copiées. Ce dossier peut être le dossier de référence, mais également un autre dossier de structure identique (par exemple, un dossier de paramétrage sur lequel les paramétrages ont été affinés lors de la phase d'analyse, sur lequel certaines données ont pu être introduites ou reprises par import). Il est important que la structure du dossier de copie soit équivalente (même si aucun contrôle ne peut être fait, des erreurs pourraient se produire lors de la copie si ce n'est pas le cas).

• Dossier historisé (champ DOSHIS)

Ce dossier ne peut pas être saisi directement en gestion de dossier. Il est renseigné lorsqu'un dossier d'historisation est créé après la création du dossier d'exploitation, par la fonction correspondante.

Le dossier d'historisation permet de stocker des données considérées comme non évolutives, que l'on souhaite pouvoir consulter à part.

• Date de début (champ STRDAT)

Cette date permet de définir la date de premier exercice d'un dossier nouvellement créé.

Cette date est fondamentale, car elle ne pourra plus être changée après coup. Elle correspond à la date de début du premier exercice à partir duquel on gère des données de l'entreprise avec le progiciel. Attention, il est souvent intéressant (pour des raisons de reprises d'à-nouveaux) de partir de l'exercice précédent celui où l'exploitation commence réellement.

Par défaut, les valeur des deux paramètres superviseur STRDAT et ENDDAT, qui définissent la période de connexion possible, seront définis par :

• STRDAT = Date saisie
• ENDDAT = max(STRDAT+ 12 mois, Date du jour)

Ces paramètres, modifiables par la suite, sont utilisés à la connexion dans le dossier. Il est contrôlé que la date saisie est comprise dans la fourchette de dates définie par ces 2 paramètres.

• Devise dossier (champ RPTCUR)

Permet de mettre à jour le paramètre SYSCUR du dossier. Ce paramètre ne peut plus être modifié par la gestion des dossiers après la génération du dossier.

• Dossier test (champ TSTFLG)

L'indicateur Dossier test signifie que ce dossier a vocation à recevoir une copie des traitements standard présents dans un patch, si celui est installé sur le dossier. Si cet indicateur n'est pas positionné, les traitements de patch ne sont intégrés qu'au niveau du dossier superviseur. Le fait d'avoir ce flag positionné permet de réaliser des tests d'intégration de patches sur un dossier. Une fois que les patches en question ont été définitivement intégrés dans l'environnement, il est conseillé de « faire le ménage » en supprimant les traitements installés précédemment (sinon, une prochaine installation de patches ou de version ne serait pas prise en compte sur ces traitements, ce qui risque de faire apparaître des dysfonctionnements). Un dossier en exploitation réelle ne doit pas avoir cet indicateur positionné.

• Dossier spécifique (champ SPEFLG)

Cette case à cocher signifie que les traitements spécifiques présents dans un patch seront installés sur le dossier même s'ils n'existaient pas auparavant. Les traitements spécifiques sont identifiés par leur nom : ils commencent soit par X, Y, ou Z, soit par SPE, soit ils commencent par CNS et se terminent par SPE. Si cet indicateur n'est pas positionné, seuls les traitements spécifiques précédemment existants sont remplacés dans le dossier par une nouvelle version présente dans un patch.

• Intitulé (champ LIBMOD)

• Actif (champ MODULE)

Ce tableau contient les modules retenus pour le dossier à générer. Seules les fonctions et les tables associées à des modules activés seront utilisables dans le dossier une fois qu'il aura été créé.

Il est recommandé de ne prendre que les modules réellement utiles. En effet, ceci permet de ne créer que les tables et objets réellement utilisés et diminue donc le temps de création et la place prise. Il sera toujours possible d'ajouter des modules après coup. La liste des modules et les contraintes éventuelles sont données en annexe en fin de la documentation décrivant la gestion de dossier.

• Taille images (champ BLBLNG)

Ce champ détermine la taille maximale prise par défaut dans les champs blob (binary large objects) stockés dans la base. Ces champs correspondent notamment aux images stockées dans la base de données.

Ce champ est défini comme une puissance de 2 : 1 équivaut à 2 Ko, 2 à 4 Ko, 3 à 8 Ko et ainsi de suite (la valeur correspondante est affichée, elle peut aller jusqu'à 20, qui correspond à 1 Go).

Il est à noter que chaque champ de type blob peut être dimensionné de façon différente dans la base (si le type de données porte la longueur de façon explicite, cette longueur par défaut n'est pas utilisée).

• champ BLBTXT

• Taille textes (champ CLBLNG)

Ce champ détermine la taille maximale prise par défaut dans les champs clob (character large objects) stockés dans la base. Ces champs correspondent notamment aux textes stockées dans la base de données.

Ce champ est défini comme une puissance de 2 : 1 équivaut à 2 Ko, 2 à 4 Ko, 3 à 8 Ko et ainsi de suite (la valeur correspondante est affichée, elle peut aller jusqu'à 20, qui correspond à 1 Go).

Il est à noter que chaque champ de type clob peut être dimensionné de façon différente dans la base (si le type de données porte la longueur de façon explicite, cette longueur par défaut n'est pas utilisée).

• champ CLBTXT

• Code (champ CODACT1)

Un code activité permet :

• de rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle.
• de signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z.
• de dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau.

Ainsi, si le code activité est non actif, l'élément marqué ne sera pas utilisable, et le code associé (s'il y en a) ne sera pas généré ni activable.

• Intitulé (champ LIBACT1)

Intitulé associé au code précédent.

• Module (champ MODULE1)

Module d'appartenance auquel le code activité est rattaché. Si le module n'était pas actif, le code activité n'apparaîtrait pas dans ce tableau.

• Actif (champ FLACT1)

Pour le développement, ce champ positionné à Oui active les tables, les écrans, ou les champs dans les tables et les écrans qui dépendent du code activité. Inversement, si ce champ est à Non, les écrans et les tables, ou les champs qui en dépendent ne sont pas accessibles et n'apparaissent pas.

Attention, en exploitation, pour tout changement de positionnement de code activité, il est nécessaire de :

• faire la modification du code activité, dans la fiche dossier, à partir du dossier mère
• puis de déclencher une validation du dossier fille.

• Code (champ CODACT2)

Un code activité permet :

• de rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle.
• de signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z.
• de dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau.

Ainsi, si le code activité est non actif, l'élément marqué ne sera pas utilisable, et le code associé (s'il y en a) ne sera pas généré ni activable.

• Intitulé (champ LIBACT2)

Intitulé associé au code précédent.

• Module (champ MODULE2)

Module d'appartenance auquel le code activité est rattaché. Si le module n'était pas actif, le code activité n'apparaîtrait pas dans ce tableau.

• Actif (champ FLACT2)

Pour le développement, ce champ positionné à Oui active les tables, les écrans, ou les champs dans les tables et les écrans qui dépendent du code activité. Inversement, si ce champ est à Non, les écrans et les tables, ou les champs qui en dépendent ne sont pas accessibles et n'apparaissent pas.

Attention, en exploitation, pour tout changement de positionnement de code activité, il est nécessaire de :

• faire la modification du code activité, dans la fiche dossier, à partir du dossier mère
• puis de déclencher une validation du dossier fille.

• Code (champ CODACT3)

Un code activité permet :

• de rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle.
• de signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z.
• de dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau.

Ainsi, si le code activité est non actif, l'élément marqué ne sera pas utilisable, et le code associé (s'il y en a) ne sera pas généré ni activable.

• Intitulé (champ LIBACT3)

Intitulé associé au code précédent.

• Module (champ MODULE3)

Module d'appartenance auquel le code activité est rattaché. Si le module n'était pas actif, le code activité n'apparaîtrait pas dans ce tableau.

• Dim écran (champ DIME3)

Définit le nombre d'occurrences utilisées dans les écrans, et également dans les tables concernées, sachant que pour une table, un nombre minimum (et un nombre maximum) peuvent exister, ce qui conduira alors à utiliser, pour dimensionner les tables, la formule :

min(max(MINI,ECRAN),MAXI).

• Mini BDD (champ DIMIN3)

Définit le nombre minimum de colonnes stockées dans la base de données (indépendamment du nombre vus dans l'écran, qui peut être inférieur). Ceci permet d'éviter à des états standard de faire référence à des colonnes susceptibles de ne pas exister selon le paramétrage.

• Maxi BDD (champ DIMAX3)

Définit la dimension maximale possible compte tenu des structures des tables dans la base de données.

• 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)

Intitulé associé au code précédent.

• Module (champ MODULE5)

[object Object]

• Valeur (champ NBR)

Ce nombre correspond à la valeur associée à l'élément de dimensionnement de la ligne.

• Module (champ MODTR)

[object Object]

• O/N (champ TRVAL)

Une réponse positive à la question entraîne la validation des transactions associées au module.

• 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 :

• la langue est une langue non livrée en standard par l'éditeur
• cette langue n'est pas déjà cochée pour un autre dossier dans l'environnement courant (que l'on appelle également solution).

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 :

• le dossier racine (si la langue concernée y est définie)
• le premier dossier (dans l’ordre alphabétique) qui contient cette langue 

• Législation (champ LEGDOS)

• 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.

• 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 é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)

• Module (champ MODTR)

[object Object]

• O/N (champ TRVAL)

Une réponse positive à la question entraîne la validation des transactions associées au module.

• 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 :

• la langue est une langue non livrée en standard par l'éditeur
• cette langue n'est pas déjà cochée pour un autre dossier dans l'environnement courant (que l'on appelle également solution).

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 :

• le dossier racine (si la langue concernée y est définie)
• le premier dossier (dans l’ordre alphabétique) qui contient cette langue 

• Législation (champ LEGDOS)

• 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.

• 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 é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)

• 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)

[object Object]

• 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ù :

• on se trouve dans une architecture de dossier à 3 niveaux (dossier de référence, dossier de développement, dossier d'exploitation).
• les spécifiques qui en dépendent sont définis dans le niveau intermédiaire et doivent être automatiquement transférés dans le dossier de plus bas niveau en cas de revalidation ou de patch, y compris en cas de mise à jour.

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.

• 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 sadoraou sadossselon 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

• 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 :

filpath("","","")

• 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.

• Dossier de la solution (champ SOLDOS)

• Autorisation accordée sur le dossier courant (champ SOLAUZ)

• Type de lien (champ LTYPLIEN)

Définit le type de lien :

• soit il s'agit d'un lien Divers, qui doit être géré en spécifique dans les traitements.
• soit il s'agit d'un lien caractérisé (Vers Comptabilité, Vers immobilisations, Vers paie, Vers Logistique...). Ce type de lien est géré par le progiciel lorsqu'il a un sens. Un seul lien de chaque type peut exister pour un dossier donné.

• 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.