Jump to content

Executer script d'un fichier local


Recommended Posts

Bonjour à tous,

Je rencontre actuellement un problème et j'ai du mal à le résoudre. Votre regard d'experts FileMaker pourra sans doute m'aider à y voir plus clair 😊

J'ai hérité de la maintenance et du suivi d'une ancienne application FileMaker, et voilà comment elle fonctionne :

Sur un FMS 16 sont hébergées plusieurs bases FileMaker, qui contiennent les données brutes. Les utilisateurs accèdent à ces données via un fichier FileMaker local, ce fichier est en fait copié sur chaque ordi (et il faut le copier à nouveau à chaque MàJ.)  Sur ce fichier, toutes les bases hébergées sur le FMS sont en fait des sources de données externes, ce qui permet d'afficher et manipuler les données. Ce modèle de conception à un nom, mais je ne m'en rappelle plus... 😅

J'ai récemment créé une nouvelle solution que j'ai hébergé sur ce FMS, et je dois développer une fonctionnalité d'export d'une fiche de cette nouvelle solution vers cette ancienne application. Je pensais m'en sortir assez facilement en exécutant le script de création d'une nouvelle fiche de l'ancienne application, en lui transmettant les données par variables, mais...

Le seul hic, c'est que ce script se trouve au sein de l'application locale. Alors, je peux tout à fait l’exécuter depuis mon ordinateur avec le menu "parcourir" de l'action de script Exécuter script, mais ça fonctionnera jusqu'à ce que je déplace ou renomme le fichier, et pour les utilisateurs c'est encore pire, puisque je ne sais pas où ils placent ce fichier. Donc du coup, il y aurait une solution pour pouvoir exécuter ce script depuis ma nouvelle solution ?

Merci d'avance pour votre aide !

Link to post
Share on other sites

Bonjour Jacques, merci pour votre réponse 😊

il y a 22 minutes, Jacques R. a dit :

Pourquoi le fichier "FileMaker Local" n'est-il pas unique et hébergé sur le serveur ?

C'était un choix fait par l'ancien développeur, que j'ai remplacé il y a peu. L'application à largement fêté ses 20 ans d'utilisation aujourd'hui...

Moi aussi, je préfère que toutes les solutions soient hébergés sur le FMS, c'est tellement plus simple (et logique, à mon sens). L'application à un fonctionnement assez complexe, je peine encore à en saisir les subtilités : elle fonctionne par années scolaires et les utilisateurs ont pris leurs petites habitudes avec ce fichier, comme par exemple de le dupliquer, afin d'avoir sur leur bureau un fichier 2018/2019 puis un autre 2019/2020.

En hébergeant ce fichier sur le FMS, mon problème serait résolu mais les utilisateurs perdront cette possibilité de duplication qui à l'air de leur plaire en fin de compte. Après, si on ne perd que ça (ça reste à déterminer), je me dis qu'on peut sûrement arriver au résultat similaire avec des liens snapshot... 🤔

Link to post
Share on other sites
Il y a 6 heures, Loraga a dit :

les utilisateurs ont pris leurs petites habitudes avec ce fichier, comme par exemple de le dupliquer, afin d'avoir sur leur bureau un fichier 2018/2019 puis un autre 2019/2020.

🤔

Utiliser des filtres à l'ouverture de la base, en captant les derniers filtres choisis par l'utilisateur à la fermeture de la base.. et on peux garder toutes les infos de toutes les années (scolaires ou civiles) dans une seule base. Et on ne change pas les "petites habitudes" des utilisateurs, et surtout on simplifie les manips en bannissant la consultation des fichiers d'archives n-1, n-2, . alors que tout peut rester dans la même base pendants des années (10 ans, 15 ans,..) sans soucis ni ralentissements si la bas est bien structurée. 

Link to post
Share on other sites

Merci Jacques pour votre aide 😊

Merci également pour vos conseils ; des solutions, je pense qu'il y en a plein pour ce cas précis, la vôtre à le mérite d'être simple à mettre en œuvre et efficace 😊

Il y a 10 heures, Jacques R. a dit :

(...) si la base est bien structurée. 

Je pense que c'est bien ça, le problème majeur. Le graphe des liens de cette application, c'est "Spaghetti Land", ce qui rend vraiment difficile la compréhension de la structure de la base. J'ai essayé de faire du tri, de le réordonner, mais si on ajoute à ça des noms de rubriques pas clairs du tout, des modèles/scripts qui contiennent un certain nombre de reliques datant de FileMaker 2 (l'app date de 1993 en fait, on est plutôt proche des 30 ans que des 20 ans), et sûrement encore bien d'autres surprises, je finis par me dire que je risque de passer plus de temps à tout remettre au propre qu'a recommencer une solution finalement.

Actuellement, l'application rame pas mal, les scripts sont lourds, donc recommencer avec une base propre me semble plus simple, mais ça ça reste à voir avec les utilisateurs finaux.

En attendant, je vais tenter l'hébergement de la solution sur FMS, si c'est pas trop galère, ce qui va me permettre de pouvoir accéder au script de création d'enregistrement via ma nouvelle solutio, ce qui répondrai donc à ma question initiale 😊

Bonne journée !

Link to post
Share on other sites
il y a une heure, Loraga a dit :

Actuellement, l'application rame pas mal, les scripts sont lourds, donc recommencer avec une base propre me semble plus simple, mais ça ça reste à voir avec les utilisateurs finaux.

Je déteste le slogan "changer le logiciel.." mais apparemment cela s'impose dans votre cas.

Repenser tranquillement l'ergonomie et les fonctionnalité attendues, préparer des scripts de traitements pour rationaliser les anciennes données (et pouvoir utiliser ces scripts le moment venu) et construire une nouvelle base partagée. Cela ne pourra que plaire aux utilisateurs finaux qui vont voir leur travail simplifié et fiabilisé. Beaucoup de travail à court terme mais que du bonheur par la suite...

Link to post
Share on other sites
  • 2 weeks later...
Le 16/05/2020 à 10:38, Loraga a dit :

l'application rame pas mal

Bonjour @Loraga, hello @Jacques R.

J'arrive tard dans cette discussion, mais je pense que vu l'ampleur du chantier potentiel et la durée d'utilisation de la solution, tout n'est pas encore fini…

Je voulais simplement pointer le fait qu'il existe quelques "points critiques habituels" entraînant des lenteurs. Je pense par exemple au souci des rubriques non indexées, dont un usage non strict entraîne des lenteurs qui peuvent être facilement résolues, même sur des systèmes anciens et tentaculaires. Ou encore des pratiques de script à l'ancienne qui peuvent assez facilement être révisées sur l'ensemble d'une solution…

Ca n'empêche pas une réflexion de fond, mais résoudre certains de ces points offre parfois du répit.

Bonne journée,

Jérémie

Link to post
Share on other sites

Bonjour Jérémie !

Merci pour votre réponse 🙂

Effectivement, ces fameux points critiques habituels sauvent un peu les meubles. A chaque fois que je dois améliorer/créer une nouvelle fonctionnalité, je prend  toujours le temps de mettre à jour les scripts. Je tombe souvent sur des actions de script comme Copier, Coller, ou encore sur des Définir rubrique qui servent de variable en fait, ce genre de choses quoi. L'application en est truffée, mais je comprend bien qu'à l'époque, les développeurs FileMaker n'avaient pas le choix quand les variables n'existaient pas encore.

Pour les rubriques non indexées, je n'ose jamais trop toucher aux options de rubriques, et plus globalement, à tout ce qui touche la base en elle même (notamment le graphe des liens), car je ne suis pas du tout à l'aise avec : les occurrences ont des noms pas tout à fait clair, et elles sont toutes reliées à la base principale, elle même reliée à 9 autres bases sur le FMS (d'où la comparaison avec le plat de spaghettis). Les modifications à ce niveau là ont des conséquences dramatiques si je fais des bêtises, et ma compréhension globale de la structure de la base n'est vraiment pas facilitée.

Le 15/05/2020 à 13:03, Loraga a dit :

J'ai récemment créé une nouvelle solution que j'ai hébergé sur ce FMS, et je dois développer une fonctionnalité d'export d'une fiche de cette nouvelle solution vers cette ancienne application. Je pensais m'en sortir assez facilement en exécutant le script de création d'une nouvelle fiche de l'ancienne application, en lui transmettant les données par variables, mais...

Le seul hic, c'est que ce script se trouve au sein de l'application locale.

Ah oui, et j'ai résolu ce souci assez simplement en fait. plutôt que de développer une fonctionnalité d'export depuis mon fichier sur le FMS vers l'app locale, j'ai plutôt développé une fonctionnalité d'import des fiches depuis l'application locale. C'était tout bête, il fallait prendre le problème à l'envers, mais je n'y avais pas pensé sur le moment 😅

Tout fonctionne bien, les utilisateurs sont ravis :D

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...