10 bonnes pratiques pour DriveWorks Pro

Le 19 décembre 2022

Pour progresser dans l’utilisation d’un logiciel, il y a 2 possibilités :

 

  • Apprendre par soi-même : de ses essais ou erreurs quand on s’en est rendu compte
  • Apprendre des autres : de leurs essais, erreurs, conseils ou bien sûr par une formation

Nous vous proposons 10 bonnes pratiques issues de notre expérience, et indirectement de celle de tous nos clients utilisant la solution DriveWorks depuis plus de 15 ans. Les outils DriveWorks suivent une philosophie très similaire aux produits Dassault Systèmes SOLIDWORKS. Ils sont donc extrêmement souples et laissent à l’utilisateur une très grande liberté.Comme souvent, lorsqu’on est libre, rien ne nous empêche de faire des choix qui peuvent être inadaptés et finalement avoir des inconvénients majeurs qui n’avaient pas été anticipés.

 

Ces 10 bonnes pratiques vous éviteront de perdre du temps en commettant à votre tour les erreurs que d’autres ont déjà expérimentées et solutionnées pour vous !

1. Structure de fichiers recommandée

 

S’il est possible d’organiser librement les fichiers qui composent un groupe DriveWorks, certains choix pourraient être préjudiciables.

 

Pour commencer, il y a 2 types de groupes : individuels (Individual) et partagés (Shared)

 

  • Un groupe individuel est prévu pour une utilisation par un seul utilisateur ou module à la fois.
  • Dès que des actions doivent s’exécuter simultanément ou que plusieurs utilisateurs ou modules doivent pouvoir utiliser les projets (configurateurs) d’un groupe, il est préférable d’utiliser un groupe partagé.
  • Il est évidemment possible de convertir un groupe individuel en un groupe partagé à tout moment.
  • Dans un groupe individuel, les données du groupe sont stockées dans un fichier unique au format « .drivegroup »
  • C’est l’utilisation d’un fichier unique qui limite l’utilisation par plusieurs modules ou utilisateurs.

 

Pour lever cette limitation, les groupes partagés stockent leurs informations dans une base de données sur un server Microsoft SQL.

 

 

 

 

En plus de ces données, d’autres fichiers sont nécessaires au fonctionnement des configurateurs.

 

Tous ces fichiers devront idéalement être stockés et organisés dans le dossier du groupe DriveWorks de la manière suivante :

 

 

Le respect de cette structure vous assurera de pouvoir utiliser l’ensemble des outils de gestions de données de DriveWorks (DriveWorks Data Management Tools).

 

Si vous décidez de modifier cette structure (exemple : sauver vos projets directement dans le dossier du groupe), certains de ces outils pourront ne pas fonctionner correctement.

 

Les fichiers de production (SOLIDWORKS, Word, Excel, etc.), qui seront générés par DriveWorks lors de l’utilisation des configurateurs, peuvent, bien entendu, être stockés où vous voulez, indépendamment de cette structure si nécessaire.

 

2. Le dossier Specifications

 

Lors de la création d’une nouvelle spécification, DriveWorks stocke systématiquement une copie du projet utilisé ainsi que les données saisies par l’utilisateur. Afin de pouvoir rééditer ou traiter cette spécification par la suite, ces données doivent pouvoir être retrouvées sans risques de perte ou de conflit.

 

C’est dans le dossier Specifications contenu dans le dossier d’un groupe DriveWorks que seront stockées ces données internes à DriveWorks.

 

Pour éviter toute perte ou conflit de données, chaque Spécification doit avoir un identifiant unique et doit stocker ces informations dans un sous dossier du dossier Specifications, nommé en utilisant cet identifiant.

 

Les Child Specifications sont également concernées par cette nécessité de référence unique. Même si elles ne peuvent pas être ouvertes sans leur projet parent, elles sont également nommées avec un identifiant unique. Elles ont la particularité de ne pas générer de fichiers de données car ces informations sont encapsulées dans les fichiers de leur spécification parente.

 

Par défaut, chaque groupe DriveWorks dispose d’un compteur (SpecificationID). Il est utilisé comme identifiant unique pour toute nouvelle spécification.

 

S’il est possible de personnaliser le nom (Specification Name) et l’emplacement (Specification Path) de ces fichiers internes à DriveWorks, il faut impérativement s’assurer de l’unicité du nom et de l’emplacement de ces données pour chaque spécification.

 

 

 

 

Il est donc souvent plus simple de ne pas modifier ces paramètres.

 

  • Pourquoi pourrait-on être tenté de modifier ces paramètres ? Et que risque-t-on ?

 

Dans un projet, tant que l’on n’aura pas personnalisé les règles par défaut, tous les fichiers que l’on prévoit de générer avec DriveWorks (pièces, assemblages, mises en plan, PDF, Word…) seront stockés en utilisant le nom unique de la spécification ainsi que l’emplacement des données internes de DriveWorks.

 

Lorsque l’on souhaite générer les fichiers SOLIDWORKS dans un dossier d’affaires sur le serveur de fichiers de l’entreprise, il est donc très tentant de modifier le dossier Specifications du groupe DriveWorks pour qu’il pointe vers ce dossier d’affaire. Ainsi, tous les fichiers générés par DriveWorks seront par défaut sauvés dans cet emplacement. Mais en procédant ainsi, les fichiers internes de DriveWorks le seront aussi.

 

La seule personnalisation de l’emplacement ne gênera qu’en cas de maintenance (per exemple pour supprimer les spécifications obsolètes).

Cependant, en plaçant les dossiers de spécifications dans un dossier d’affaire, la tentation est encore plus grande d’en profiter pour nommer ces dossiers en reprenant les standards en place dans l’entreprise. Et c’est ce nommage qui ne permet souvent pas l’unicité du nom de la spécification.

 

Parmi les cas courants, notons :

 

  • Un dossier par client. Plusieurs spécifications peuvent alors se retrouver dans le même dossier. Les fichiers internes de DriveWorks étant nommés par le nom du projet utilisé, la seconde spécification écrasera la précédente.
  • Un dossier par affaire, alors qu’une affaire peut nécessiter le lancement de plusieurs configurateurs et donc la création de plusieurs spécifications. Les fichiers internes de DriveWorks étant nommés par le nom du projet utilisé, la seconde spécification écrasera la précédente.
  • Le stockage des dossiers d’affaires dans un coffre SOLIDWORKS PDM. Les fichiers internes de DriveWorks ne sont pas prévus pour être stockés dans un coffre SOLIDWORKS PDM. Si cela est techniquement possible, ce n’est pas recommandé en raison des opérations manuelles nécessaires pour que cela fonctionne (voir la section relative aux fichiers Group et Project sur la page relative à SOLIDWORKS PDM dans la documentation de DriveWorks).

 

En cas de conflit ou perte de ces fichiers internes pour une spécification donnée, ses transitions et opérations deviendront alors indisponibles et la spécification ne sera plus éditable. Il ne faut donc pas procéder de cette façon !

 

A la place, nous vous conseillons de modifier les règles qui pilotent le nom et l’emplacement des fichiers à générer sans altérer les paramètres de ce dossier Specifications interne à DriveWorks.

 

 

 

3. Les numéros de colonne des tables

 

S’il est évident qu’il faut nommer correctement une table, on oublie souvent qu’il faut en nommer correctement les colonnes. En effet, si dans DriveWorks on précise une colonne par son numéro d’index dans toutes les fonctions référençant une table, ce n’est pas pour autant une bonne habitude.

 

La relecture des règles utilisant des numéros de colonnes est complexe :

Qui se rappelle le rôle de la 42ème colonne d’une table 6 mois après ?

De plus, il existe un risque d’erreurs important en cas de réorganisation de la table.
En référençant une colonne par son numéro d’index dans les règles, on court le risque de générer de très nombreuses erreurs dans tout le projet en changeant l’ordre des colonnes d’une table.

 

Une fonction spécifique existe dans DriveWorks pour éviter ces inconvénients :

 

  • La fonction TableGetColumnIndexByName()

 

– Elle permet de retrouver l’index de la colonne d’une table par son nom.
– Elle peut être utilisée directement dans les fonctions à la place de l’index de la colonne souhaitée.

 

Cependant, nous vous conseillons une approche plus systématique :

 

  • Nommez toutes les colonnes des tables dans DriveWorks
  • Après chaque création de table, créez une catégorie de Variables portant le nom de table (en ajoutant « Table » en préfixe du nom de la catégorie pour clarifier son rôle). Il est également conseillé de regrouper toutes les catégories de ce type dans une catégorie générique « Tables ».
  • Créer une règle pour chaque colonne en utilisant la fonction TableGetColumnIndexByName()

 

Ces règles seront toutes identiques à l’exception du nom de la table et de celui de la colonne.
Il serait donc assez simple de les générer dans Excel à partir d’une liste des nom de colonnes.
Astuce : il est possible de copier une ou plusieurs variables de DriveWorks vers une table Excel (et vis-versa ? )

 

Si ces opérations peuvent paraître longues à créer par rapport à l’utilisation directe des numéros d’index, ce temps est largement regagné dans la globalité de la vie d’un configurateur.

 

A chaque relecture d’une règle, il n’y aura plus de confusions ou de temps perdu à retrouver le rôle d’une colonne par son numéro. De plus, puisqu’il permet la réorganisation d’une table sans aucun risque, il participera à rendre vos projets DriveWorks plus robustes.

 

  • Remarque :

 

En plus de ne pas nommer les colonnes, il ne faut pas placer de valeurs directement à partir de la première ligne d’une table. En effet, la majorité des fonctions relatives aux tables ne liront pas cette ligne puisqu’elle est supposée contenir… les noms de colonnes.

 

4. Ne jamais réordonner les colonnes d’une table de calcul

 

Les tables de calculs fonctionnent d’une façon similaire à une feuille de calcul Excel.

 

 

 

 

Dans la règle de calcul d’une cellule, il est ainsi possible d’utiliser les valeurs des autres cellules de la table en les référençant de manière relative. C’est-à-dire en indiquant la direction et le nombre de cellules séparant la cellule actuelle de celle contenant la valeur voulue.

 

Exemple de syntaxe d’une référence relative :

 

  • Pour aller chercher la valeur dans la cellule juste à gauche on tapera [1L] (L pour Left).
  • Les autres directions seraient « codées » : R=Right, U=Up et D=Down
  • Et pour aller chercher la valeur dans la cellule située 3 colonnes plus loin à Droite et 2 cellules plus haut on taperait [3R,2U]

 

Si cela est très pratique pour créer les règles nécessitant ce type de références, cela peut également se révéler problématique si on envisage de modifier l’ordre des colonnes après l’écriture des règles.

 

Par exemple, dans une table de trois colonnes : A, B, C et D

 

 

 

 

  • Remarque : La règle de la colonne D s’applique à toute la colonne

Si on réorganise la table pour avoir l’ordre suivant : C, A, B et D

 

Les valeurs de la colonne D sont alors très différentes

 

 

 

 

Cela représente un risque d’erreur si on n’est pas conscient de l’existence de cette règle et du danger potentiel de réordonner les colonnes d’une table de calcul.

 

5. Référencer une table de calcul dans l’une de ses cellules

 

Dans les tables de calculs, il est possible de référencer une cellule de 2 façons :

 

  • De manière relative : comme nous l’avons évoqué dans le conseil précédent.
  • Directement : par le nom de la colonne et le numéro de la ligne

Il y a cependant une différence majeure par rapport à une table Excel qu’il faut connaître !

Une cellule de la table de calcul ne peut pas référencer la table en elle-même en dehors des deux types de références citées plus haut.

 

  • Cela exclut donc toutes les fonctions de tables existant dans DriveWorks (vlookup, dwvlookup, listall, etc…).
  • Une cellule ou une colonne d’une table de calcul ne peut pas exécuter de fonctions sur cette même table.

 

Cela s’explique simplement.

 

  • La table de calcul n’existe pas tant que tous les calculs (cellules ou colonnes) ne sont pas terminés.
  • Il n’est donc pas possible de demander le contenu de la table pendant qu’elle se calcule.
  • Il s’agirait d’une référence cyclique (boucle infinie).

 

Dans ce cas, il faut simplement utiliser une seconde table de calcul pour interroger la première contenant les données souhaitées.

 

Il faut cependant garder en tête la complexité de calcul que ces tables peuvent représenter. Si elles contiennent beaucoup de cellules avec des règles complexes, ces tables peuvent assez vite demander beaucoup de ressources. Il convient donc de bien réfléchir à la structure des données pour ne pas multiplier ces règles complexes inutilement (ex : requêtes SQL, imports de fichiers…).

 

 

6. Eviter D’utiliser Des Valeurs “Constantes” Directement Dans Vos Calculs

 

Pour calculer la longueur d’une pièce dans un assemblage, il est tentant d’utiliser, par exemple, la longueur hors tout saisie par l’utilisateur et les jeux fonctionnels directement dans la même règle.

 

« Que se passera-t-il le jour où il faudra modifier ce jeu fonctionnel ? Combien de règles utilisent ce jeu fonctionnel dans tout votre projet ? »

 

Il est également tentant, pour insérer une image dans l’interface, d’aller la chercher dans l’explorateur Windows pour ajouter le chemin à la règle pilotant cette image.

 

« Que se passera-t-il si le dossier est déplacé ? Combien d’images dans combien de pages de l’interface doivent être modifiées individuellement pour retrouver toutes les images d’origine ? »

 

Exemple de règle, voici un cas inspiré du manuel de formation de DriveWorks Pro :

 

Mettez-vous en situation : 6 mois après avoir créé cette règle, vous arrivez devant cette règle, sans avoir le schéma…

 

« A quoi correspondent les chiffres dans la formule ? Et comment savoir dans quelles règles intervenir (en plus de celle-ci) le jour où certaines de ces valeurs changeront ? »

 

  • Pour cette raison, il convient d’éviter le plus possible d’utiliser des valeurs brutes (numérique, texte, liste, chemin sur le réseau…) dans une règle DriveWorks.
    Il est préférable de les ajouter dans une variable puis d’utiliser la variable dans le calcul.
  • Il est aussi possible de modifier une règle où des valeurs brutes ont déjà été ajoutées en utilisant la commande “Extract rule” pour extraire ces valeurs dans des variables dédiées (cette fonction est également capable de rechercher/remplacer cette valeur dans toutes les règles d’un projet).

 

 

 

  • Cette méthode présente un autre avantage, celui de faciliter la compréhension des règles. Il n’y a plus de valeurs isolées au milieu d’un calcul, mais une variable (au nom idéalement explicite) éventuellement complétée d’une description et d’une documentation illustrée.

 

 

7. Uniformiser Le Nommage Des Objets De Driveworks

 

Que vous travailliez seul(e) ou en équipe sur des projets de configurateurs DriveWorks, il est important d’uniformiser le nommage des objets créés dans vos configurateurs.

 

Lors de l’ajout d’un objet dans DriveWorks, un nom est systématiquement demandé.

 

  • Ce nom doit être unique pour chaque type/famille d’entités. Ces noms vous permettront de référencer ces entités dans les règles que vous créerez dans vos configurateurs.
  • S’il est relativement facile de se rappeler le nom d’un objet que nous venons de créer, il n’en est pas de même lorsqu’il faut retrouver une variable ou une table 6 mois après.

 

Pour cette raison, en plus de documenter vos projets de configurateurs pour pouvoir facilement les modifier plusieurs mois/années après leur création, il est important de bien réfléchir au nommage des entités et de toujours appliquer la même logique (surtout s’il y a plusieurs utilisateurs).

 

Voici une liste non exhaustive de conseils sur le nommage des entités DriveWorks :

 

  • Form Design :
  • Ne jamais laisser le nom par défaut proposé par DriveWorks

 

Il est facile de retrouver une CheckBox parmi d’autre types de contrôles. Son type sera toujours affiché dans l’arbre des formulaires (il est possible de filtrer cet arbre par types).

 

En revanche, il sera beaucoup plus pratique de choisir un nom qui permettra rapidement de retrouver cette entité lorsque vous devrez la référencer dans une règle.

 

Exemple de filtre sur l’interface du projet du manuel de formation DriveWorks Pro :

 

 

  • Pour une étiquette (Label), ne pas forcément utiliser comme nom le texte que vous voulez afficher à l’écran

 

Par défaut, DriveWorks reprend le nom de l’entité pour l’utiliser dans le texte à afficher. Cependant, ce texte que l’on prévoit d’afficher présente souvent des inconvénients pour assurer un nommage clair, concis et unique d’une entité.

 

N’hésitez pas à choisir un nom qui vous facilitera la tâche en tant que concepteur du configurateur. Ensuite, vous pourrez personnaliser le texte à afficher à l’utilisateur pour que le rôle de cette entité soit clair.

 

  • Pensez bien à l’utilisation des suffixes numériques

 

Lorsque l’on copie/colle une entité nommée avec un suffixe numérique dans un même projet, DriveWorks incrémente automatiquement ce suffixe (sauf pour les noms trop courts = moins de 5 caractères, suffixe compris).

 

En préparant correctement la première entité (en utilisant notamment les fonctions MyName() et ExtractNumber() ), il devient possible de créer rapidement des dizaines d’entités sans avoir à retoucher les règles. Après la copie, chaque règle changera son comportement en “s’adaptant” au suffixe porté par le nom de l’entité.

 

Ce système de nommage peut aussi permettre la communication automatique avec les tables de calculs de DriveWorks (Control Input et Control Output).

 

Exemple de projet de Nuancier RAL réalisé avec ce principe :

 

Ici toutes les vignettes ont été créées par copier-coller. Elles utilisent donc toutes les mêmes règles. C’est uniquement grâce au suffixe de la vignette que chaque règle ira chercher la bonne valeur dans les tables de la base de données.

 

 

  • Constantes :

 

Utilisées par les Child Specification controls : assurez-vous de nommer de manière claire les constantes ayant pour but d’être pilotées par un projet parent. N’hésitez pas à les copier depuis un projet terminé similaire pour éviter toute erreur dans des nouveaux projets (le copier-coller de constantes entre projets est possible).

 

C’est également le cas pour une utilisation par

 

  • Le module Integration de DriveWorks Pro Live
  • Les APIs du thème Integration de DriveWorks Pro Live
  • Les connecteurs de DriveWorks Pro Autopilot
  • Des Specification Host Controls

 

Utilisées par des macros : n’hésitez pas à rappeler le nom de la macro dans laquelle elle est référencée (dans son nom ou sa description)

 

  • Variables :

 

– Comme pour les entités de Form Design, l’utilisation de suffixes numériques peut permettre de créer/gérer des règles en masse si elle est bien pensée. Ces variables utiliseront généralement aussi les fonctions MyName() et ExtractNumber().
– Utilisez les catégories pour classer les variables.
Il est possible de créer autant de niveaux de sous-catégorie que nécessaire.
Il est même possible d’illustrer une catégorie en lui associant une image (schéma de principe…).
– Les variables peuvent avoir tous types d’entités comme résultat (nombre, texte, liste, table, booléen).
N’hésitez pas à indiquer dans le nom d’une variable le type d’entité qu’elle calcule. Ce sera plus simple de retrouver cette entité par la suite. Cela permettra également d’éviter d’utiliser une variable pour une autre dans une règle.

 

  • Tables :

 

– Nommer toutes les colonnes des tables afin de pourvoir les référencer par leur nom à la place de leur index grâce à la fonction TableGetColumnIndexByName()
– Il n’est pas possible d’utiliser un suffixe numérique dans le nom de colonne d’une table de calcul.
En effet, la référence « Valeur12 » d’une colonne nommée « Valeur » indique la valeur à la 12ème ligne de cette colonne. Il est donc logique ne pas pouvoir également ajouter un suffixe numérique au nom de la table (c’est en revanche possible au milieu du nom).

 

  • Drive3D :

 

– L’adresse d’un nœud dans un document Drive3D est référencé par un chemin similaire à une arborescence d’un disque dans Windows.
Comme pour les entités de Form Design, l’utilisation de suffixes numériques peut permettre de créer/gérer des règles en masse si elle est bien pensée. Ces variables utiliseront généralement aussi les fonctions MyName() et ExtractNumber().
Cela est facilité par l’option « View as combined » de la barre de commande. Elle regroupera toutes les propriétés de même nom des entités actuellement sélectionnées. Cela permet d’ajouter une règle sur l’ensemble des propriétés de toutes les entités actuellement cochées.
Pour éviter toute erreur, si une propriété affiche “…” comme résultat, alors que plusieurs entités sont sélectionnées avec l’option “View as combined”, c’est qu’au moins l’une des règles est différente.

 

  • Specification Macros :

 

 

  • Renommez les tâches après les avoir insérées dans une macro pour indiquer clairement leur rôle.
  • Choisissez le nom d’une macro avec soin. En cas de renommage, DriveWorks ne peut pas retrouver toutes les règles qui référencent une macro. De nombreuses commandes ou actions deviendraient alors inopérantes avant correction.
  • Utilisez des catégories pour regrouper vos macros pour faciliter leurs rééditions ultérieures.

 

Plus généralement et en complément du nommage des entités : utilisez les descriptions “en plus du nommage” pour préciser le rôle et le fonctionnement de certaines règles.

 

 

8. Comment bien affecter une tâche à autopilot ?

 

Lors de l’utilisation d’un configurateur, la spécification peut passer par plusieurs états (ou étapes). Ces états sont décrits par un synoptique appelé Specification Flow.

 

 

L’état actif lors de l’utilisation du configurateur par les utilisateurs est l’état Actif (Running). C’est dans cet état que le configurateur est ouvert et que l’interface utilisateur conçue dans DriveWorks Pro Administrator est affichée.

 

Cet état est accessible depuis toutes les interfaces permettant de lancer une spécification : depuis le Specification Explorer des applications DriveWorks ou depuis un navigateur internet connecté à un serveur DriveWorks Pro Live.

 

DriveWorks Pro Autopilot est le module chargé de centraliser les actions de génération ou les tâches dont on veut soulager les autres modules. Il est généralement chargé exclusivement de la génération des fichiers SOLIDWORKS, Word ou Excel (qui ne peuvent pas être générés par DriveWorks Pro Live directement).

 

Pour qu’un document arrive dans les files de traitements pour génération par Autopilot, il faut exécuter les tâches « Release Document » ou « Release Model ».

 

Cependant, suivant quelle application exécute ces tâches et quand la tâche est exécutée, le résultat peut varier.

 

  • Depuis l’interface de l’utilisateur final

 

Si la tâche est exécutée pendant que l’interface utilisateur est affichée (par une Specification Macro), c’est l’application depuis laquelle la Specification a été lancée qui se chargera de la traiter.

 

Cela peut avoir des conséquences sur les performances perçues par l’utilisateur. En effet, pendant le traitement par un serveur DriveWorks Pro Live, l’interface utilisateur peut être indisponible (“Loading” affiché).

 

Ce traitement peut même être impossible dans le cas d’un DriveWorks Pro Live hébergé sur un serveur Microsoft IIS. En effet, dans ce cas, les applications Word et Excel ne sont pas accessibles par un service. Ces deux types de documents ne peuvent donc pas être générés/lus/modifiés de cette manière.

 

Ce n’est donc pas de cette façon qu’il faut procéder pour que la génération de documents soit traitée par DriveWorks Pro Autopilot.

 

  • Traitement par DriveWorks Pro Autopilot

 

Ces tâches de génération peuvent aussi être exécutées plus tard dans le Specification flow (pour Autopilot):

 

  • Dans un état Automatic

 

 

Ces état permettent de confier des actions à tout DriveWorks Pro Autopilot configuré pour traiter la file de traitement des Specifications (aussi chargée des documents).
Lors de la définition d’un état, il est possible de définir des tâches qui seront systématiquement exécutées à l’arrivée ou la sortie de cet état (il est possible d’ajouter des conditions à leur exécution).

 

  • Pendant une transition en sortie d’un état Automatic
    – Une transition permet de passer d’un état à un autre.
    – Des tâches peuvent être exécutées pendant cette transition.
    – Une transition déclenchera systématiquement les tâches en sortie de son état d’origine et à l’arrivée dans son état de destination.
    – Toutes les tâches déclenchées par une transition seront gérées par l’application l’ayant initiée
    – Pour que des actions soient exécutées par DriveWorks Pro Autopilot, elle doivent être en sortie de l’état Automatic.
    – Elle peuvent donc être soit dans le Leave State de l’état Automatique, soit dans la transition sortante, soit dans le Enter state de l’état de destination de la transition sortante.

 

Afin de confier la génération de documents à une machine DriveWorks Pro Autopilot, il faut donc que les tâches “Release Document” ou “Release Model” soient idéalement exécutées depuis le Specification Flow en sortie d’un état Automatic.

 

9. Ne Pas Utiliser De “Lecteur Réseau” Avec Driveworks Live Et Iis

 

 

DriveWorks Pro Live peut fonctionner de 2 façons : en tant qu’application ou hébergé par un serveur Microsoft IIS.

 

Le fonctionnement en tant qu’application peut être suffisant pour des tests, ou dans les cas où il y a peu d’utilisateurs, ou encore qu’on ne souhaite pas une haute disponibilité et de bonnes performances.

 

Il est donc extrêmement courant d’utiliser l’hébergement par un serveur Microsoft IIS pour les configurateurs en production. Microsoft IIS fonctionne sous la forme d’un service Windows.
Un service sous Windows a la particularité de démarrer indépendamment des sessions utilisateurs.
De ce fait, un service n’a pas accès aux applications ou éléments de Windows qui démarrent avec une session utilisateur Windows.

 

Cela a plusieurs conséquences sur DriveWorks Pro Live lorsqu’il est hébergé de cette façon :

 

  • Il faut choisir judicieusement le compte utilisateur déclaré pour démarrer le service Microsoft IIS pour qu’il dispose des droits d’accès à la fois aux ressources locales (fichiers du thème Web utilisé, polices de caractères…) mais aussi aux ressources sur le réseau (dossier du configurateurs, fichiers à afficher ou référencés…).
  • Il faut prévoir l’exécution de certaines tâches de générations sur un Autopilot car Live ne pourra parfois pas s’en charger.
  • Il ne faut pas avoir utilisé de lecteur réseau pour référencer les fichiers utilisés par les configurateurs DriveWorks.

 

Ce dernier point peut paraître surprenant car nous avons l’habitude d’utiliser ces lecteurs qui sont souvent “montés” automatiquement à l’ouverture de nos sessions Windows en entreprise.

 

Le problème vient justement du fait que ces lecteurs existent uniquement pendant une session utilisateur. Un service ne peut donc pas simplement accéder à ces disques réseaux.

 

C’est pour cette raison qu’il ne faut pas utiliser ces chemins dans les projets DriveWorks lorsqu’une utilisation future de DriveWorks Pro Live avec Microsoft IIS est envisagée.

 

Il suffit, à la place, d’utiliser le chemin complet réseau permettant d’accéder aux fichiers souhaités (en passant par la machine les hébergeant dans le voisinage réseau).
Ces chemins complets sont aussi appelés chemins UNC (Uniform Naming convention ou Universal Naming Convention)

 

10. Documentez

 

« Comme il est bon de garder le meilleur pour la fin, voici probablement le conseil le plus important de tous. C’est malheureusement celui qui est le plus souvent sous-estimé. Car s’il prend du temps à mettre en place, il peut aussi vous éviter d’en perdre énormément ! »

 

Il est capital de documenter vos projets de configurateurs pour pouvoir facilement les modifier plusieurs mois/années après leur création par vous et encore plus par un autre collaborateur. Le document de description de chaque projet est probablement le plus important à rédiger.

 

Ce document devrait par exemple idéalement détailler :

 

  • Les principaux mécanismes du configurateur
  • La liste des modèles et documents capturés en détaillant :
    – Le nom des éléments pilotés dans l’application d’origine ainsi que dans DriveWorks (dimensions, propriétés, etc…)
    – L’emplacement sur le réseau (par un chemin UNC ?)
    – La logique de nommage des fichiers que DriveWorks générera à partir de ce modèle (Master)

 

  • Le rôle de chaque sous-projet (ainsi que ses entrées et sorties)
  • Les entités impliquées pour ce mécanisme (constantes, variables, tables…)
  • Les mots-clés à rechercher pour retrouver ces entités dans le configurateur
  • Les éventuels avertissements en cas de modification/déplacement
  • Les workflows prévus pour chaque profil d’utilisateur
  • Le fonctionnement des macros (encore plus si des macros en appellent d’autres)

 

Une fois en production, il est conseillé également de conserver un historique détaillé des modifications réalisées sur le configurateur et de leur raison/origine. Les outils permettant un tel suivi sont très variables suivant vos habitudes ou suivant si vous travaillez seul ou en équipe.

 

Par expérience, voici quelques supports fréquemment utilisés et assez efficaces :

 

  • Tout simplement, un document Word par projet
  • Un bloc note de type OneNote ou équivalent
  • Des outils comme Trello ou Bubblz pour faciliter la gestion des projets en cours de “développement” ou de modification. Ces outils sont encore plus intéressants si vous travaillez en équipe.

 

« Voyez donc la documentation comme un investissement comparable à une assurance : il est techniquement possible d’habiter un logement sans assurance pendant des années sans gêne particulière. Mais le jour ou un problème survient… Mieux vaut être assuré ! »

 

Les solutions faites pour vous

DriveWorks

Créer des variantes de produits standards simplement

Réduisez vos délais de conception avec un configurateur CAO créant les variantes de vos produits standards en quelques minutes.

Découvrir

Visiativ CPQ

Configurer, tarifer et éditer des devis rapidement et sans erreur

Simplifiez et accélérez vos processus de vente et de fabrication de vos produits complexes.

Découvrir
SOLIDWORKS

SOLIDWORKS CAO 3D

Optimiser ses conceptions avec une solution intuitive

Bénéficiez d'une solution de conception et de fabrication intuitive, puissante et novatrice pour transformer vos idées en produits innovants.

Découvrir

Inscrivez-vous à nos Newsletters