Mises à jour majeures

Ci-dessous sont décrites les actions importantes à effectuer pour le passage d’une version majeure de SAINet à une autre. Pour chaque point mentionné, il est indiqué quelles actions doivent être entreprises selon le type d’installation.

0. Stopper les différents containers (docker-compose down), puis effectuer une sauvegarde de la base de données.
1. Mettre à jour le container MariaDB vers la version 10.11.
2. Redémarrer le container (docker-compose up -d sainet_db) et appliquer le script de migration des données à l’intérieur du container:

docker ps
docker exec -ti <container_id> /bin/bash
mariadb-upgrade --user=root --password=<pwd>

3. Mettre à jour le container de SAINet vers la version saierp/sainet:4.11.
4. Si utilisées, renommer les variables d’environnement relatives à MariaDB (voir les paramètres ci-dessous).
5. Mettre à jour les versions des autres services si nécessaire (traefik, redis, …).
6. Relancer les containers (docker-compose up -d).

0. Stopper les services SAINet et MariaDB, puis effecuter une sauvegarde de la base de données.
1. Mettre à jour MariaDB vers la version 10.11.
2. Redémarrer le service MariaDB et appliquer le script de migration: mariadb-upgrade --user=root --password=<pwd>.
3. Mettre à jour le JDK vers la version 21.
4. Si utilisées, renommer les variables d’environnement relatives à MariaDB (voir les paramètres ci-dessous).
5. Télécharger la version 4.11 désirée et remplacer le fichier sainet.jar existant.
6. Appliquer la mise à jour manuellement: java -Djdk.jar.maxSignatureFileSize=32000000 -jar sainet.jar --runtime <runtime> --update.
7. Démarrer le service SAINet.

Les variables d’environnement ont été renommées:

Dans le cas où le fichier server.properties est utilisé, la propriété database.type doit être modifiée de mysql à mariadb et les propriétés suivantes modifiées:

Le système n’effectue plus de sauvegarde automatique lors des mises à jour de SAINet.

Cela n’a aucune influence sur les sauvegardes automatiques quotidiennes qui sont généralement effectuées par un autre système (soit au niveau de la machine virtuelle, soit par un script externe).

Pour les installations Docker du portail, mettre à jour le tag vers la version 4.11.

Il est possible de saisir des clés de répartition comptables pour la saisie des factures fournisseurs. Ces clés peuvent être enregistrées dans le FOU07, puis être sélectionnées dans les adresses de paiement en FOU02 (elles seront ainsi utilisées automatiquement) et également au niveu du FOU30.

Cette nouvelle fonctionnalité n’implique pas d’adaptation majeure dans le processus de saisie des factures fournisseur.

Plusieurs modifications ont été introduites dans le dossier de l’employé (SAL04) et la saisie des assurances (SAL05) afin de répondre à la certification Swissdec 5. D’autres modifications seront également amenées dans les versions suivantes au fur et à mesure de l’avancement des travaux. Celles-ci sont indiquées dans le guide de migration Swissdec 5 dans l’aide en ligne.

Ces changements n’impliquent pas d’adaptation majeure dans le processus de saisie des données salariales.

Une incohérence de fond provoquait une erreur d’affichage dans l’ordre des pages, typiquement lorsque des pages devant être ordrées chronologiquement n’étaient pas saisies dans l’ordre croissant des dates. Désormais, l’ordre des pages multiples affichées dans les vues de dossier (par exemple SALV4) est cohérent avec l’affichage présenté dans la tâche de saisie correspondante (SAL04).

Toutefois, cette modification peut provoquer des différences dans certaines listes UNI94 qui utilisent le formatteur legacy (avec des <array>). Les formatteurs BlueIron ne sont pas affectés par ce changement.

Il est possible de revenir à l’ancien comportement en utilisant la valeur by_occurrence dans la propriété dossier.views.page_sort en SYS22.

Le moteur de salaire SAL24 utilise le mode strict lorsqu’une tabelle IJM/LAAC est recherchée en UNI85. Ainsi, si une tabelle n’est pas trouvée, une erreur sera mentionnée alors qu’auparavant toute la ligne était à zéro, sans soumis. Plus d’informations ici.

Il est possible de revenir à l’ancien comportement en changeant la variable sal24.legacy_table_lookup_strict en SYS22.

Ces changements sont principalement techniques et ne devraient pas impacter les fonctionnalités de l’application.

La mise à jour sur les dernières versions de Hibernate impliquent que certaines requêtes EJBQL sont plus strictes et que désormais certaines constructions peuvent être rejetées.

• Les comparaisons avec NULL doivent systématiquement se faire avec <field> IS NULL/<field> IS NOT NULL. Les prédicats <field> = NULL/<field> != NULL ne sont plus valides. Cela ne provoque pas d’erreur, mais les résultats peuvent être différents et certains enregistrements qui étaient renvoyés auparavant ne le seront plus.
• Les types des paramètres doivent correspondre au type de l’entité. Ainsi, il n’est plus possible d’effectuer le prédicat <dateField> = ?1 et de passer une chaîne de caratère pour le paramètre ?1.

Cela nécessite une vérification dans les macros UNI93 (notamment pour le DEB22).

Dès la version 23.1.0 de GraalJS, certaines variables entrent en conflit avec les variables injectées par SAINet. Par conséquent, celles-ci ont du être renommées.

La nouvelle version de Apache HttpComponents implique quelques changements de fond dans le traitement des requêtes HTTP/HTTPS. Cela ne devrait pas avoir de conséquence particulière, mais les accès aux services externes (Mises à jour automatiques, Exchange, OBP, MediData, ISM, …) doivent être testés afin de valider leur fonctionnement suite à la mise à jour.

Le format d’échange n’était pas tout à fait identique entre le serveur et le client riche, notamment sur les données relatives aux dossiers. Le serveur utilisait le nom complet (par exemple ADRDOSDOSSIER.ID_PK) tandis que le client utilisait le nom raccourci (ADRDOS.ID_PK). Tout a été aligné afin que seul le nom raccourci soit utilsé partout.

Ce changement peut notamment affecter les templates en UNI94 et la gestion des référents ou les filtres spéciaux gérés par le code métier. De manière générale, tout devrait fonctionner de manière identique sans modification spéciale. Il n’est pas exclus que pour certains templates UNI94 il faille également passer à la syntaxe raccourcie.

• Le support de la base de données Oracle a été supprimé.
• Le support du serveur applicatif JBoss a été supprimé.

docker ps
docker exec -ti <container_id> /bin/bash
mariadb-upgrade --user=root --password=<pwd>

var a = new BigDecimal(100);
var b = new BigDecimal(a); //erreur

var a = new BigDecimal(100);
var b = a.divide(BigDecimal.ZERO, MathContext.DECIMAL64); //pas d'erreur

if(divisor.compareTo(BigDecimal.ZERO) != 0) {
  var b = value.divide(a, MathContext.DECIMAL64);
}

var a = 5;
var b = new BigDecimal(10);
var c = a + b; //15

var a = 5;
var b = new BigDecimal(10);
var c = a + b.intValue(); //15

var a = new BigDecimal(5);
var b = new BigDecimal(10);
var c = a.add(b); //new BigDecmial(15)

var a = new BigDecimal("123.456");
var b = a.setScale(2, BigDecimal.HALF_DOWN); //BigDecimal.HALF_DOWN n'existe pas

var x = myString.isEmpty(); //erreur 'isEmpty' is not defined
var y = "a".compareTo("c"); //erreur 'compareTo' is not defined, utiliser la méthode localeCompare