Document de release de la version I2.01

   Ce document présente les évolutions survenues sur l'application Cegid XRP Ultimate Fondations en I2.01.

      Afficher / Masquer le détail                                                   Format PDF

   Aucune modification de paramétrage n'est nécessaire pour que le fonctionnement soit comme avant le passage de la release.

   Pour des questions de sécurité et suite à une modification de la politique de rafraîchissement des onglets par les navigateurs, la déconnexion pour inactivité est passée à 30 minutes.

   Le fichier "endpoints.lst", situé à côté du fichier properties de configuration, permet de donner une "white list / black list" des endpoints autorisés ou interdits.

   Cela peut être utile par exemple sur les instances de WebServices utilisées pour la mobilité en ne laissant "passer" que les services strictement nécessaires. Chaque ligne du fichier représente un endpoint autorisé. Il est possible d'utiliser le caractère "joker" "*".

   Règles de syntaxe :
- Un endpoint par ligne ;
- Commencer la ligne par # pour commenter ;
- Commencer la ligne par ! pour exclure un endpoint (black list).

   La black list est prioritaire sur la white list. De ce fait, si un endpoint se trouve dans les deux parties, il sera bloqué.
Si le fichier n'est pas présent, tous les endpoints sont autorisés.

   Exemple de contenu
#endpoints autorisés
/mobile/purchasing/*
/finance/vouchers
/security/*
#endpoints interdits
!/expense/*
!/security/authenticationForm

   A noter que selon le principe des priorités, un accès au service /security/authenticationForm sera bloqué, bien que /security/* soit autorisé. De plus, le service /rest/api/misc/libsVersion sera quoi qu'il arrive insensible à cette configuration. Ce dernier ne retourne aucune donnée sensible, n'accède pas à la base, etc.
Cela permet d'avoir systématiquement un endpoint disponible pour tester à minima la bonne installation des services.

   Cette fonctionnalité est ici pour assurer un premier niveau de filtre, elle ne prétend pas remplacer des contrôles firewall/WAF, etc.

   Sur les services d'authentification, si le paramètre "with_sso" est ajouté à l'URL d'appel (et que le SSO est applicable), alors l'authentification pourra se faire en SSO.

   Authentification : headers

   Il est possible de s'authentifier en fournissant un header, en appelant le service authenticationWithHeaders :

   - Header "Authorization" : l'authentification se fera selon les principes "Basic", à savoir un header Authorization: Basic xxxxxx avec xxxxxx = login + ":" +   password, le tout encodé en B64
- Header "x-xrpu-apikey" : là aussi utilisation d'une authentification "Basic" (donc préfixer la valeur passée par "Basic"), mais le mot de passe à utiliser est une apikey

   Ici, on invoque le service d'authentification, qui retournera de façon standard un accessToken, utilisable par la suite pour l'appel de tous les services utiles.

   Une autre possibilité est d'appeler les services utiles sans passer par une phase d'authentification. Dans ce cas, il faudra impérativement fournir soit :
- Un header "autorisation", en mode basic, avec login + : + apikey (encodé en B64). Il n'est pas possible de passer un mot de passe utilisateur dans ce cas précis (trop de risque à faire transiter le mot de passe systématiquement)
- Un header x-xrpu-apikey, contenant login + : + apikey (encodé en B64).

   Important : Ces modes de fonctionnement sont à utiliser avec beaucoup de retenue, car ils exposent à des risques de sécurité (les informations d'authentification étant passées lors de chaque appel) et à des baisses de performances. En effet, la totalité des contrôles (contrôle user/mdp mais aussi contrôles des droits et sécurité Fondations, etc.) sont réalisés lors de chaque appel.

   Là encore, il faut bien évidement réaliser ces appels en https, l'apiKey étant une donnée sensible.

   Ce type d'appel peut donc être utilisé de façon occasionnelle, lors d'invocations ponctuelles, mais en aucun cas dans un contexte d'appels automatisées et massifs.

   Traces et logs

   Listener sur le fichier de configuration de Log4J. Il est possible de modifier le fichier log4j.properties sans avoir besoin de redémarrer pour que les modifications soient prises en compte. Un système qui écoute les changements toutes les minutes est mis en place. Le fichier log4j.properties doit se trouver au même niveau que les autres fichiers properties.

   Autre point :   si le répertoire de logs (/logs pour statistiques d'utilisation) n'existe pas, le créer.

   A présent le traitement permet de créer un fichier ZIP regroupant tous les documents (PDF ou non) présents dans la GED.

   Cette soumission est appelée directement en synchronisation avec ouverture automatique du fichier résultat à partir des transactions suivantes :
   - Consultation des documents (CTDOC) ;
   - Impression de documents attachés Finances (CIDAF) ;
   - Impression de documents attachés Achats (CIDAA) ;
   - Impression de documents attachés des ventes (CIDAV).

ECGED - Récupération des documents issus de la GED (Transaction GTECGED)

   Automatique.

   Prise en compte d'une liste d'établissements à traiter.

   Permet de spécifier une liste d'établissements (GTLEN) à traiter.
Si elle est renseignée, seuls les établissements présents dans la liste et situés entre les bornes de la fourchette d'établissements seront traités.

TTAU - Génération des accès par utilisateur (Transaction GTTAU)

   Automatique.

   Prise en compte d'une liste d'établissements à traiter.

   Permet de spécifier une liste d'établissements (GTLEN) à traiter.
Si elle est renseignée, seuls les établissements présents dans la liste et situés entre les bornes de la fourchette d'établissements seront traités.

ETAU - Simulation de la génér. des accès par utilisateur (Transaction GTETAU)

   Automatique.

   Prise en compte d'une liste d'établissements à traiter.

   Permet de spécifier une liste d'établissements (GTLEN) à traiter.
Si elle est renseignée, seuls les établissements présents dans la liste et situés entre les bornes de la fourchette d'établissements seront traités.

LTAU - Liste des accès existants par utilisateur (Transaction GTLTAU)

   Automatique.

   Ajout de deux formes sélections :
   - CSUSIB : Sélection des utilisateurs / profils bénéficiaires ;
   - CSUSID : Sélection des utilisateurs et profils délégants.

   Ces deux formes sélections mettent à disposition les zones des utilisateurs individuels et des profils fonctionnels, sous forme de fourchettes, afin de permettre des extractions sur ces zones.
   - CSUSIB : Sélection des utilisateurs / profils bénéficiaires permet de filtrer les bénéficiaires de GDLU ;
   - CSUSID : Sélection des utilisateurs et profils délégants permet de filtrer les bénéficiaires de GDLU.

GDLU - Délégations entre utilisateurs (Transaction GTIDLU)

   Automatique.

   Possibilité d'utiliser le paramétrage des messages électroniques disponible dans GKTUMELT.

   Ce paramétrage vient soit en complément du paramétrage existant dans GTPST comme MAIL_TO, MAIL_CC, MAIL_CCI, soit en remplacement de celui-ci MAIL_FROM, MAIL_MSG.

GTPST - Paramètres de synchronisation pour un traitement (Transaction GTIPST)

   Cette fonctionnalité nécessite la présence des licences Planification (QPN) et Workflow Information Manager (WIM).

   Prise en compte du PGP (Pretty Good Privacy) dans le système de signature et de cryptage.

   Il est désormais possible de signer et de chiffrer des documents avec le protocole PGP. Celui-ci prend en compte différents algorithmes tels que "BLOWFISH", "CAST5", "IDEA", "SAFER", "TRIPLE_DES".

GTPSC - Profils de signature et de cryptage (Transaction GTIPSC)

   Automatique.

   Une propriété (dans le fichier de config coté serveur Web) "rest.gedConfigType" permet de préciser quelle configuration sera prise dans GTDTY. Celle de la ligne RIA ou celle de la ligne technologique HTML5. Par défaut, c'est la configuration RIA (afin de rester sur la configuration historique si aucun changement lors de la migration) qui sera utilisée. Sinon, il faut positionner la valeur "HTML5".

   Evolutions sur les tokens

   Sur les authentifications en mode cookie, le refreshToken n'est plus renvoyé

   Selon la propriété qualiac.security.renewrefreshtoken (si true), alors un nouveau refreshToken sera renvoyé lors de chaque demande de renouvellement d'accessToken. L'ancien refreshToken sera supprimé et rendu inutilisable.

   En mode cookie, la durée de vie de l'accessToken est elle aussi prise dans la globale WIMS_MAXAGE

   Les programmes conçus avec le concepteur RIA du module XLinks continuent à fonctionner. Néanmoins, toute modification ou correction des programmes devra être réalisée par l'intermédiaire de la version HTML du concepteur. Pour cela, il faudra prévoir une migration des anciens programmes, afin qu'ils soient compatibles avec le nouveau concepteur.

TXLINK - Page d'accès à XLinks (Transaction GTTQETL)

   Il faudra prévoir la migration des anciens programmes.

   Jusqu'ici, la liste détaillée des composants du flux d'une interface ainsi que les propriétés de ces derniers étaient présents à côté du diagramme de flux ; il en résultait une certaine lourdeur d'affichage. Pour améliorer la lisibilité de ces éléments, trois onglets séparés ont vu le jour : un premier affichant le diagramme de flux, un deuxième affichant le détail des composants de flux, un troisième permettant d'accéder aux directives.

   Pour faciliter la navigation, le double-clic sur un jeu de données comme sur un lien débranche sur ses propriétés dans l'onglet des composants.

TXLINK - Page d'accès à XLinks (Transaction GTTQETL)

   Automatique.