10 bonnes pratiques pour DriveWorks Pro (partie 2/2)

Dans un article précédent, notre expert vous dévoilait 5 bonnes pratiques pour DriveWorks Pro. Ce nouvel article vient compléter la liste en vous suggérant 5 nouvelles bonnes pratiques pour optimiser votre utilisation de DriveWorks Pro.

En effet, 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

Ces bonnes pratiques sont 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 (au total) 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 ! Voici les 5 dernières bonnes pratiques ci-dessous (pour relire les 5 premières, cliquez ici).

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.

L’automatisation de conception en 7 points avec DriveWorks

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.

10 fonctionnalités relatives aux textes de DriveWorks Pro

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

DriveWorks Autopilot est-il indispensable à DriveWorks Live ?

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é !