Application Client

Fuzible est fourni avec une application "Service" ainsi qu'une application "Client" qui permettent à tout un chacun de lancer des Jobs à distance.

L'application "Client" est un outil simplifié à l'extrême qui peut être distribué à n'importe qui (dans votre société, par exemple) pour permettre d'avoir la main sur le lancement de certains Jobs.

Quelques cas d'usage :

  • Quelqu'un veut extraire des données occasionnellement
  • Quelqu'un a besoin d'intégrer régulièrement des fichiers dans une base de données, mais le jour d'intégration et le nom du fichier varient...
  • Quelqu'un veut envoyer chaque semaine un reporting à d'autres personnes.

Plus globalement, n'importe quelle tâche pour laquelle votre valeur en tant que développeur (à part cliquer sur un bouton) est faible

Le service de fond fonctionne sur un système de "pile", qui dépile les Jobs dans l'ordre au fil de l'eau pour éviter l'engorgement.

Vous pouvez définir le nombre de Jobs qui peuvent être lancés en simultané, et une priorité pour chacun d'entre eux. Le système de pile prend en charge l'heure de lancement souhaitée, ainsi que la priorité.

Le service de fond est aussi responsable du lancement des Jobs orchestrés, qui sont également mis en pile pour éviter les collisions, et les débordements de puissance et les engorgements.

Tout a été pensé pour éviter une saturation disque, RAM, CPU, réseau

1. Mettre un Job disponible pour l'application "Client"

L'onglet de configuration générale.
Il vous suffit de cocher la case, et le Job sera alors visible par l'application "Client".

Le service de fond et l'application "Client" utilisent une base de données pour fonctionner. Par défaut, c'est la BDD interne de Fuzible (SQLite) qui est utilisée, mais vous pouvez utiliser n'importe quel type de BDD. La seule chose dont vous devez vous préoccuper, c'est que le poste sur lequel est installée l'application "Client" peut accéder à cette base de données.

2. L'application "Client"

2.1. Paramètres de base

L'application "Client" est pensée pour être la plus simple possible.
Les Jobs disponibles. Chacun d'entre eux nécessite un mot de passe pour être invoqué/exécuté.

Pour des raisons de sécurité, n'importe qui possédant l'application peut voir tous les Jobs, mais ceux-ci étant protégés par mot de passe, vous évitez qu'un utilisateur lance le Job d'un autre.

Les utilisateurs peuvent choisir d'invoquer immédiatement le lancement du Job ou de le décaler. Par exemple, si vous voulez que le Job soit lancé dans la nuit, et que vous ne voulez pas vous réveiller pour cliquer sur le bouton !

Les utilisateurs peuvent également changer les paramètres dynamiques du Job : c'est très pratique si par exemple, dans le cas d'un Job d'intégration d'un fichier dans une BDD, le nom de fichier est changeant et connu du seul utilisateur concerné : le nom de fichier peut être paramétré dynamiquement dans la requête (voir ici).

2.2. Invoquer l'exécution d'un Job

L'utilisateur doit juste cliquer sur un bouton !

Un contrôle de d'abus a été intégré et permet d'éviter qu'un utilisateur déclenche en boucle plusieurs fois le même Job. Le délai entre 2 exécutions est configurable.

2.3. Contrôler le Statut

Un Job a été invoqué (mis en pile) mais il n'a pas encore été pris en charge par l'application Service.
L'utilisateur peut contrôler le statut en temps réel. Ce Job est terminé.
fr_FRFrench