Avis importants avant la mise à jour

Mettre à jour .NET

WorkflowGen 9.1.0 requiert la version 4.8 de .NET; il est donc nécessaire d'installer cette version avant la mise à jour.

Usage des paramètres BACKURL_SUBMIT et BACKURL_CANCEL dans les URL WorkflowGen personnalisées

À partir de la version 7.15.5, les paramètres HTTP facultatifs BACKURL_SUBMIT et BACKURL_CANCEL utilisés dans les URL WorkflowGen personnalisées (par exemple, lors du lancement d'une nouvelle demande et du déclenchement de la première action sur un autre site Web) supportent UNIQUEMENT les URL absolues (commençant par http:// ou https://), les URL relatives (commençant par /) ou les URL définies dans le paramètre de configuration PortalRedirectAllowedHttpUrls (par exemple, value='blank.htm, myPage.htm').

Changement au cryptage des mots de passe

À partir de la version 7.15.0 de WorkflowGen, les mots de passe du compte de serveur SMTP et du compte de serveur entrant de l'approbation à distance ne sont plus chiffrés dans le fichier web.config.

Avant de mettre à jour un serveur WorkflowGen existant, vous devez réinitialiser manuellement les mots de passe en texte clair pour les paramètres ApplicationSmtpPassword et RemoteApprovalIncomingServerPassword dans le fichier web.config. Vous pouvez également utiliser le script PowerShell convert-web-config-pwd.ps1 fourni dans \wfgen pour déchiffrer et convertir les mots de passe dans le fichier web.config.

Serveur de la base de données

MS SQL Server

Microsoft SQL Server 2008/2012 ne sont plus supportés. Malgré que ces versions seront toujours compatible avec WorkflowGen, il n’y aura plus de support pour des problèmes de performance ou des bogues provenant de l’utilisation de SQL Server 2008/2012.

Pour les clients hébergeant actuellement WorkflowGen sur un serveur de base de données antérieur à MS SQL Server 2014, nous vous recommandons fortement de mettre à jour vers la dernière version de MS SQL Server pour obtenir les performances optimales.

Migration de la base de données WorkflowGen de MS SQL Server 2005/2008 vers les versions 2014 et ultérieures

Cette mise à jour de compatibilité de la base de données est obligatoire avant de migrer la base de données WorkflowGen de MS SQL Server 2005/2008 vers les versions 2014 et ultérieures. Elle n'est pas nécessaire si votre base de données WorkflowGen fonctionne déjà avec MS SQL Server 2012.

Lancez le script de mise à jour Update\Databases\MsSQLServer\Update_WFG-V7-0_SQL_Triggers_2012.sql dans SQL Server Management Studio.

Fin du support Oracle

La base de données Oracle n'est plus supportée à partir de la version 7.16.0 de WorkflowGen.

Modules Node.js

Les modules Node.js incluent l'API GraphQL, les « webhooks », SCIM et Auth. Pour des instructions sur la façon de les activer, voir la section Applications Web basées sur Node.js.

Mettre à jour la version de Node.js

Vous devez mettre à jour la version de Node.js à la version 18.20.4 LTS (voir https://nodejs.org/download/release/v18.20.4/).

Paramètres de gestion du téléchargement des fichiers GraphQL et webhooks entrants

À partir de la version 7.10.0 de WorkflowGen, si vous utilisez les webhooks entrants ou GraphQL pour télécharger des fichiers lors de la création d’une demande ou de la réalisation d’une action, vous devez régler les paramètres de configuration GraphqlFileInputAllowedFolders, HooksFileInputAllowedFolders, GraphqlMaxInputFileContentSize et HooksMaxInputFileContentSize avec les valeurs appropriées (voir la section Mise à jour pour les versions 7.9.1 et antérieures).

• GraphqlFileInputAllowedFolders et HooksFileInputAllowedFolders : Ces paramètres devraient contenir les chemins physiques des dossiers qui contiennent les fichiers utilisés dans les téléchargements.

• GraphqlMaxInputFileContentSize et HooksMaxInputFileContentSize : Ces paramètres devraient contenir la taille de fichier maximale (en kilo-octets) lors du téléchargement de fichiers en utilisant la méthode de contenu de fichier.

  ✏️ Note : Nous recommandons de limiter la taille du contenu de fichier à de petits fichiers inférieurs à 1 mégaoctet.

Dépendances JavaScript mises à jour

Dans WorkflowGen version 8, les dépendances suivantes ont été mises à jour :

• jQuery v1.7.2 ou 1.10.12 → 3.5.1

• jQuery UI v1.8.20 ou 1.10.3 → 1.12.1

• jQuery Colorbox v1.4.33 → 1.6.4

• jQuery Validation v1.11.1 → 1.19.3

Certains fichiers .js, .css et .png ont été déplacés vers les dossiers \wfgen\js\common et \wfgen\App_Themes\Default\common, respectivement. Si vous utilisez les versions précédentes des fichiers listés ci-dessus dans vos formulaires, vous devez réenregistrer les formulaires afin d'utiliser les chemins et fichiers corrects.

Configuration des formulaires Web personnalisés dans WorkflowGen versions 8 et ultérieures

Si vous utilisez des formulaires Web personnalisés configurés en .NET 2.0, vous pouvez continuer à les utiliser en .NET 2.0 ou les migrer en .NET 4.

Pour configurer les formulaires Web personnalisés en .NET 2.0

1. Utilisez WorkflowGen.My.dll en version 2.x.

2. Utilisez un pool d’applications en .NET 2.0.

3. Désactivez Sécurité des applications Web dans la section Sécurité sur l’onglet Général du Panneau de configuration.

4. Réglez ou mettez à jour les nœuds suivants dans le fichier web.config du formulaire Web :

   <configuration>
       <system.web>
           <pages validateRequest="false" enableSessionState="true" />
       </system.web>
   </configuration>

5. Si le mode d’authentification de votre formulaire Web est configuré avec l’authentification WorkflowGen de base, le nouveau mode de hachage des mots de passe (« One-way Hashing ») introduit dans la version 6.1 ne sera pas compatible avec votre formulaire web. Il existe deux solutions :

   • Utilisez le mode de gestion des mots de passe Version 5 à la place. Assurez-vous que vous utilisez les fichiers Advantys.My.dll et Advantys.Security.dll de la version 5.x dans le dossier \bin de votre formulaire Web.

     OU

   • Migrez votre formulaire Web en .NET 4. Assurez-vous que vous utilisez les fichiers Advantys.My.dll et Advantys.Security.dll de la version 8.x.x ou ultérieure dans le dossier \bin de votre formulaire Web. Pour des instructions sur la migration en .NET 4, voir la section suivante.

Pour migrer les formulaires Web personnalisés en .NET 4

1. Utilisez WorkflowGen.My.dll en version 8.x.x ou ultérieure.

2. Utilisez un pool d’applications en .NET 4.

3. Réglez ou mettez à jour les nœuds suivants dans le fichier web.config du formulaire Web :

   <configuration>
       <system.web>
           <httpRuntime requestValidationMode="2.0" targetFramework="4.8" />
           <pages validateRequest="false" enableSessionState="true" clientIDMode="AutoID" controlRenderingCompatibilityVersion="3.5" />  
       </system.web>
   </configuration>

4. Si le mode d’authentification de votre formulaire Web est configuré avec l’authentification WorkflowGen de base, assurez-vous que vous utilisez les fichiers Advantys.My.dll et Advantys.Security.dll en version 8.x.x ou ultérieure dans le dossier \bin du formulaire web.

• Les instructions ci-dessus s’appliquent uniquement à la configuration des formulaires Web afin de fonctionner correctement sans erreurs de configuration. Elles ne concernent pas des problèmes de migration ou de compatibilité potentiels qui pourraient survenir en raison de changements dans la dernière version de WorkflowGen.My. Vous devez pleinement tester à nouveau tous vos formulaires Web avant la production.

• Après une mise à jour ou une migration vers WorkflowGen versions 8 et ultérieures, les formulaires Web personnalisés qui utilisent une version 8 ou 9 de WorkflowGen.My.dll dans leurs dossiers \bin personnalisés nécessitent les fichiers de ressources WorkflowGenMy.*.resx dans leurs sous-dossiers App_GlobalResources.

Déploiement d’une application de workflow SDK de type assembly

Les assemblys WorkflowGen.My et Workflow Web Controls ne portent plus des noms forts (« strong names ») afin de permettre une dépendance de version non-spécifique lorsque les assemblys sont référencés par d’autres applications telles que les applications de workflow SDK de type assembly dans WorkflowGen.

Cela simplifie la procédure de déploiement d’une application de workflow SDK de type assembly personnalisée dans les versions 6.2.0 et ultérieures de WorkflowGen et permet la mise à jour de WorkflowGen à une version plus récente sans nécessiter la régénération de l’assembly d’une application qui référençait une version antérieure de WorkflowGen.My.

Lors du déploiement d’une application de workflow SDK de type assembly personnalisée dans WorkflowGen il faut prendre en considération l’emplacement de l’assembly, la référence à WorkflowGen.My et la référence aux bibliothèques de logiciels tiers.

Emplacement de l’assembly

Il y a deux méthodes pour déployer un fichier d’assembly dans WorkflowGen.

Méthode 1 : Référence par nom complet de l’assembly

Le fichier d’assembly doit être copié dans les trois dossiers \bin qui contiennent les fichiers exécutables de WorkflowGen : \wfgen\bin, \wfgen\ws\bin et DISQUE:\Program Files\Advantys\WorkflowGen\Services\bin.

Méthode 2 : Référence par chemin de l’assembly (chemin physique complet avec nom du fichier)

Le fichier d’assembly peut être copié dans un dossier personnalisé (par exemple DISQUE:\MesAppsWorkflow\Assembly.dll) pour ensuite utiliser ce chemin spécifique dans la définition de l’application de workflow.

Référence à WorkflowGen.My

WorkflowGen.My versions 3.1.0 et antérieures

Les versions 3.1.0 et antérieures de WorkflowGen.My portent des noms forts, donc votre assembly doit être généré par votre version de WorkflowGen cible et doit également utiliser cette version. Cela nécessite la recompilation de votre assembly à chaque fois que vous mettez à jour WorkflowGen à une version plus récente.

Vous pouvez utiliser l’une d’entre les trois solutions suivantes pour surmonter cette exigence :

1. Installez la version de WorkflowGen.My requise dans le Global Assembly Cache du système. Pour savoir comment faire, voir https://msdn.microsoft.com/fr-fr/library/dkkx7f79(v=vs.110).aspx.

   OU

2. Ajoutez un délégué pour gérer l’événement de résolution de l’assembly afin de charger la version de WorkflowGen.My courante. Pour savoir comment faire, voir l’article How to add an assembly resolve event delegate to overcome WorkflowGen.My dependency issue when deploying custom assembly SDK workflow application dans la base de connaissances de WorkflowGen.

   OU

3. Ajoutez un paramètre de configuration Web pour rediriger la version requise de WorkflowGen.My vers la version courante. Pour plus d’informations, voir https://msdn.microsoft.com/fr-fr/library/twy1dw1e(v=vs.110).aspx.

Si votre assembly est généré par WorkflowGen.My version 3.1.0 ou antérieure, il peut être utilisé dans les versions 6.2.0 et ultérieures de WorkflowGen si l’une des solutions ci-dessus a été implémentée.

WorkflowGen.My versions 3.2.0 et ultérieures

Depuis la version 3.2.0, WorkflowGen.My ne porte plus de nom fort afin de permettre une dépendance de version non-spécifique quand il est référencé par votre assembly. Vous pouvez tout simplement déployer votre fichier d’assembly dans les versions 6.2.0 et ultérieures de WorkflowGen en utilisant l’une des deux méthodes dans la section Emplacement de l’assembly ci-dessus.

Si votre assembly est généré par les versions 3.2.0 et ultérieures de WorkflowGen.My, il peut être utilisé dans les versions de WorkflowGen antérieures à la version 6.2.0 si vous avez implémenté soit la deuxième soit la troisième solution ci-dessus.

Référence aux bibliothèques de logiciels tiers

Si votre assembly utilise des bibliothèques de logiciels tiers, celles-ci doivent également être déployées dans les trois dossiers \bin qui contiennent les fichiers exécutables de WorkflowGen. Par ailleurs, les bibliothèques peuvent être installées dans le Global Assembly Cache du système si elles sont des assemblys avec nom fort.

Configuration pour la mise en conformité FIPS

WorkflowGen est compatible FIPS à partir de la version 7.10.0. Si vous voulez activer la conformité FIPS dans votre environnement Windows, il faut tout d'abord configurer le mode de gestion des mots de passe de la configuration et le mode de gestion des mots de passe des utilisateurs dans le module d'administration.

Mode de gestion des mots de passe de la configuration

Dans la section Sécurité sur l'onglet Général du panneau de configuration, réglez Mode de gestion des mots de passe sur le mode AES (FIPS Compliant) et saisissez une clé de chiffrement comportant 32 caractères. Lorsque vous cliquez sur Enregistrer, les mots de passe de l'application seront automatiquement convertis en mode de chiffrement symétrique.

Mode de gestion des mots de passe

Dans la section Authentification sur l'onglet Général du panneau de configuration, réglez Mode de gestion des mots de passe en mode One-way Hashing (SHA256 FIPS Compliant).

• Si vous utilisez l'authentification applicative en mode Version 5 (Legacy), les mots de passe des utilisateurs seront automatiquement convertis en mode One-way Hashing (SHA56 FIPS Compliant) la prochaine fois qu'ils se connectent à WorkflowGen.

• Si vous utilisez l'authentification applicative en mode One-way Hashing (SHA256) :

  1. Sélectionnez le mode d'authentification IIS.

  2. Sélectionnez le mode de gestion des mots de passe One-way Hashing (SHA256 FIPS Compliant), et cliquez sur Enregistrer.

  3. Ressaisissez tous les mots de passe des utilisateurs.

  4. Réinitialisez le mode d'authentification en mode applicatif.

Support des logiciels classiques

Navigateurs et systèmes d’exploitation

WorkflowGen ne supporte plus Internet Explorer, Windows XP, Windows 7, Windows 8 et Windows Server 2003 ou 2008.

Base de données

MS SQL Server 2005 n'est plus supporté depuis la version 6.2.0 de WorkflowGen, MS SQL Server 2008 n'est plus supporté depuis la version 7.10.0 de WorkflowGen, et MS SQL Server 2012 n'est plus supporté depuis la version 8.2.0 de WorkflowGen.

La base de données Oracle n'est plus supportée à partir de la version 7.16.0 de WorkflowGen.

Applications de workflow

Les applications suivantes sont obsolètes et ne sont plus fournies avec WorkflowGen depuis la version 6 :

• EFORMPDF

• DOCAPPROVAL

• DOCUPLOAD

• FDFTOXML

• PDFTODATABASE

Toutefois, si vous avez toujours des processus qui utilisent ces applications, vous pouvez les garder déclarées sur le site Web WorkflowGen comme dans la version 5.

Applications et licences de tierce partie

Les applications suivantes sont distribuées avec WorkflowGen (licences Apache 2.0, BSD, MIT et autres licences compatibles) :

• Ajax Cloud 9 Editor (voir https://github.com/ajaxorg/ace/blob/master/LICENSE)

• bluebird (voir https://github.com/petkaantonov/bluebird/blob/master/LICENSE)

• busboy (voir https://github.com/mscdex/busboy/blob/master/LICENSE)

• body-parser (voir https://github.com/expressjs/body-parser/blob/master/LICENSE)

• chai/chai-http/chai-fs/chai-things/chai-date-string (voir https://github.com/chaijs/chai/blob/master/LICENSE)

• change-case (voir https://github.com/blakeembrey/change-case/blob/master/LICENSE)

• cookie-parser (voir https://github.com/expressjs/cookie-parser/blob/master/LICENSE)

• cors (voir https://github.com/expressjs/cors/blob/master/LICENSE)

• dataloader (voir https://github.com/facebook/dataloader/blob/master/LICENSE)

• edge-js (voir https://github.com/agracio/edge-js/blob/master/LICENSE)

• eml-format (voir https://github.com/papnkukn/eml-format/blob/master/LICENSE)

• express (voir https://github.com/expressjs/express/blob/master/LICENSE)

• express-graphql (voir https://github.com/graphql/express-graphql/blob/master/LICENSE)

• file-uri-to-path (voir https://github.com/TooTallNate/file-uri-to-path/blob/master/LICENSE)

• file-url (voir https://github.com/sindresorhus/file-url/blob/master/license)

• format (voir https://sjs.mit-license.org)

• fs (voir https://github.com/synrc/fs/blob/master/LICENSE)

• got (voir https://github.com/sindresorhus/got/blob/master/license)

• graphiql (voir https://github.com/graphql/express-graphql/blob/master/LICENSE)

• graphql-js (voir https://github.com/graphql/graphql-js/blob/master/LICENSE)

• graphql-relay-js (voir https://github.com/graphql/graphql-relay-js/blob/master/LICENSE)

• graphql-tools (voir https://github.com/apollographql/graphql-tools/blob/master/LICENSE)

• iisnode (voir https://github.com/Azure/iisnode/blob/master/LICENSE.txt)

• json-server (voir https://github.com/typicode/json-server/blob/master/LICENSE)

• jsonwebtoken (voir https://github.com/auth0/node-jsonwebtoken/blob/master/LICENSE)

• jwks-rsa (voir https://github.com/auth0/node-jwks-rsa/blob/master/LICENSE)

• lodash (voir https://github.com/lodash/lodash/blob/master/LICENSE)

• mem (voir https://github.com/sindresorhus/mem/blob/master/license)

• mocha (voir https://github.com/mochajs/mocha/blob/master/LICENSE)

• mockery (voir https://github.com/mfncooper/mockery/blob/master/LICENSE)

• Node.js (voir https://github.com/nodejs/node/blob/master/LICENSE)

• nyc (voir https://github.com/istanbuljs/nyc/blob/master/LICENSE.txt)

• parse5 (voir https://github.com/inikulin/parse5/blob/master/LICENSE)

• proper-lockfile (voir https://github.com/moxystudio/node-proper-lockfile/blob/master/LICENSE)

• pug (Licence MIT)

• request (voir https://github.com/request/request/blob/master/LICENSE)

• request-promise-native (voir https://github.com/request/request-promise-native/blob/master/LICENSE)

• rimraf (voir https://github.com/isaacs/rimraf/blob/master/LICENSE)

• seriate (voir https://github.com/LeanKit-Labs/seriate/blob/master/LICENSE)

• sinon (voir https://github.com/sinonjs/sinon/blob/master/LICENSE)

• supertest (voir https://github.com/visionmedia/supertest/blob/master/LICENSE)

• uuid (voir https://github.com/kelektiv/node-uuid/blob/master/LICENSE.md)

• valid-url (voir https://github.com/ogt/valid-url/blob/master/LICENSE)

• xml-js (voir https://github.com/nashwaan/xml-js/blob/master/LICENSE)

• yargs (voir https://github.com/yargs/yargs/blob/master/LICENSE)