Help Center > Foundation Help

S’applique à :

  • Winshuttle Foundation

Meilleures pratiques de développement de solution

5. Développer la solution

Guide des meilleurs pratiques de développement de solutions

  1. Créer une équipe de développement
  2. Démarrer le processus de reconnaissance
  3. Créer une validation de concept
  4. Collecter les besoins
  5. Développer la solution
  6. Support et maintenance de la solution

Une fois les besoins approuvés et figés, vous pouvez commencer le développement. Comme plusieurs développeurs peuvent participer à une solution, il est important d’utiliser un processus séquentiel pour le développement.

Dans cette page

  1. Créer des scripts. (Si vous effectuez l’intégration dans SAP).
    Si vous créez une solution qui s'intègre à SAP et qui utilise des scripts Winshuttle Transaction/Query, les scripts constituent la base du formulaire. Vous devez les créer et les tester avant de développer le workflow et le formulaire.
  2. Créer la vue de développeur .
    Créez une vue de développeur dans le formulaire pour l’utiliser comme vue de référence qui contient l’ensemble du contenu du formulaire, notamment toutes les règles et tous les calculs nécessaires à la solution.
  3. Créer le workflow.
    Développez le workflow après le formulaire, car les dépendances dans le formulaire pilotent le workflow.
  4. Créer les vues de formulaire.
    Une fois le formulaire terminé et le workflow testé, vous devez connaître le nombre de vues de formulaire à créer, et les participants de workflow (à savoir utilisateur et groupe) pour lesquels ils s’afficheront.
  5. Tester la solution.
    Testez la solution avec un groupe d'utilisateurs pour vérifier que tout fonctionne correctement dans le formulaire, les scripts et le workflow.

1. Créer des scripts

Si vous créez une solution qui s’intègre à SAP et qui utilise des scripts Winshuttle Transaction/Query, les scripts constituent le socle du formulaire.

Les scripts doivent être créés et testés avant de développer le workflow et le formulaire. Vous devez également tester les scripts scrupuleusement avant de les ajouter à la solution.

Pour chaque script créé, exécutez les tests suivants :

  1. Testez le script Winshuttle directement dans Winshuttle Transaction ou Query en utilisant Microsoft Excel.
  2. Enregistrez le mappage Excel pour le cas où des problèmes apparaîtraient plus tard dans le processus.
  3. Convertissez le mappage du type source du script Winshuttle en XML et testez dans Transaction or Query .
  4. Créez un formulaire très simple et un workflow avec chaque script Winshuttle. Exécutez le script directement dans le formulaire pour vérifier qu’il s’exécute correctement.

Ces tests permettent de vérifier que les fonctions utilisées dans Winshuttle Transaction ou Query fonctionneront dans un formulaire ou lors de l’exécution avec le type source XML.

En cas de problème avec un script lors des tests nécessitant un script supplémentaire ou une modification du script en cours, vous pouvez toujours recourir à un script supplémentaire ou modifier le script. Cependant, dans la mesure du possible, évitez de régénérer le formulaire pour maintenir tout correctement mappé.

2. Créer la vue de développeur

Après avoir créé et testé les scripts (si vous les utilisez), vous pouvez commencer à développer le formulaire.

Winshuttle recommande préalablement de créer une vue de développeur dans le formulaire devant faire office de vue de référence qui contient tout le contenu du formulaire, notamment toutes les règles et tous les calculs nécessaires à la solution. Ainsi, vous disposez d’une seule vue de formulaire comme référence, et cela facilite la création de vues de formulaire supplémentaires ultérieurement.

Une fois la vue de développeur terminée, testez le formulaire avec un petit groupe d’utilisateurs et vérifier que :

  1. Les scripts fonctionnent et sont mappés aux champs corrects (si vous utilisez des scripts Winshuttle).
  2. Les calculs, les règles ou toute autre logique applicative sans le formulaire fonctionnent correctement.
  3. La présentation ou le style du formulaire sont corrects.

Les tests initiaux doivent être exécutés avant de créer des vues de formulaire supplémentaires. Les problèmes découverts après la création de toutes les vues de formulaire sont plus longs à résoudre, car vous devez mettre à jour toutes ces vues. Si vous détectez un problème avant la création des vues supplémentaires, iI suffit de mettre à jour une seule vue.

Informations supplémentaires

Conseils et meilleures pratiques de conception de formulaire
Consultez d’autres conseils pour faciliter le développement du formulaire.

3. Créer le workflow

Après avoir créé et testé la vue de développeur, vous pouvez passer au développement de workflow. Parfois, le développement de workflow est exécuté par une personne autre que le développeur de formulaire, mais généralement le développement de formulaire et de workflow est réalisé par la même personne.

Développez le workflow après le formulaire, car les dépendances dans le formulaire pilotent le workflow. En outre, vous pouvez déterminer le nombre de vues qui seront nécessaires au formulaire et ce qu’affichera chaque vue. Par exemple, si vous disposez d’un workflow qui route en fonction de valeurs de champ dans le formulaire, vous ne pouvez pas les définir dans le workflow tant que les champs n’existent pas.

Une fois le workflow terminé, vous devez exécuter des tests de base avant de créer les vues de formulaire. Les tests dépendent considérablement de la manière dont le workflow est créé et de la manière dont vous routez le formulaire. Certains des tests généralement recommandés sont décrits ci-dessous.

Tests de workflow recommandés

  • Veillez à ce que les participants corrects soient attribués pendant le processus. Si vous utilisez un résolveur de participant, veillez à ce que la requête retourne ce qui est nécessaire pour attribuer les tâches.
  • Testez toutes les routes du workflow. Si le workflow est routé en fonction des données du formulaire, veillez à ce que ces valeurs de champs soient remplies.
  • Vérifiez que toutes les notifications sont envoyées et qu’elles sont reçues par les participants attribués.
  • Si vous utilisez des plug-ins dans le workflow, vérifiez qu’ils exécutent le ou les opérations correctes avec le ou les résultats attendus.
  • Testez les boucles. Assurez-vous que toutes les boucles sortent quand elles sont supposées le faire.

Lors de l’exécution de ces tests, tenez compte également de la manière de traiter les erreurs. S’il existe une possibilité d’erreur dans le workflow, vous disposez de propriétés Transition, telles que « IsAssignmentValid » ou « Otherwise », qui sont très efficaces pour éviter les erreurs de workflow.

Voir Propriétés des transitions Composer pour plus d’informations.

4. Créer les vues de formulaire

Les vues de formulaire entrent dans la dernière étape du processus de développement avec les tests de la solution. Une fois le formulaire terminé et le workflow testé, vous devez connaître précisément le nombre de vues de formulaire que vous devez créer et le ou les participants (utilisateur ou groupe) pour lesquels elles s’afficheront.

Winshuttle Composer dispose de vues de formulaire spéciales, prédéfinies et réservées (voir le tableau ci-dessous) qui peuvent être utilisées pour des scénarios donnés. Chaque vue doit avoir un nom unique, mais vous pouvez créer et nommer vos propres vues de formulaire comme vous l’entendez.

Winshuttle recommande au minimum de toujours utiliser la vue Auteur et la vue Processus terminé.

Voir Utilisation des vues Composer pour plus d’informations.

Vue de formulaire prédéfinies Winshuttle Designer/Composer

Vue Composer

Description

Vue Auteur

Cette vue s’affiche lorsque le formulaire est lancé pour la première fois par l’auteur.

Vue Resoumission

Cette vue s’affiche lorsque le formulaire est resoumis.

Vue État du processus

Cette vue s’affiche lorsqu’un utilisateur veut afficher le formulaire, mais n’a pas d’attribution en attente.

Vue Processus terminé

Cette vue s’affiche lorsque le processus est terminé.

5. Tester la solution

Une fois le développement terminé, vous pouvez tester la solution avec un groupe d’utilisateurs pour vérifier que tout fonctionne correctement dans le formulaire, les scripts et le workflow. Cela implique de créer des scénarios de test spécifiques à utiliser dans les tests.

Veillez à maintenir des canaux de communication ouverts avec les utilisateurs. Lorsque des problèmes apparaissent lors des tests, les développeurs de solution doivent continuer de collaborer avec les utilisateurs finaux pour les résoudre.

Notez que les tests et la validation d'une solution ne doivent généralement pas être utilisés par les utilisateurs pour demander une fonctionnalité ou des fonctions supplémentaires. Cependant, s’il est nécessaire d’ajouter des fonctions à ce stade, les tests doivent être étendus avant de transférer la solution vers l’environnement de production.

Une fois les tests de la solution terminés, planifiez la migration de la solution du serveur de développement, vers le serveur de production. Généralement, la migration d’une solution prend 1 jour.

Tester la solution après la migration

Lorsque la migration vers l’environnement de production aboutit, une personne doit le valider en vérifiant les dépendances. Éléments à vérifier après la migration :

  • Les scripts Winshuttle fonctionnent-ils toujours correctement ?
  • Les scripts Winshuttle s’exécutent-ils par rapport au système SAP correct ?
  • Le formulaire est-t-il routé correctement ?
  • Une logique de formulaire/workflow est-elle rompue ou manque-t-elle d'informations (par exemple, listes déroulantes) ?
  • Les notifications par e-mail sont elles envoyées ?
Informations supplémentaires