> For the complete documentation index, see [llms.txt](https://documentation.efalia.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.efalia.com/documentations/efalia-process/administration/administration-fonctionnelle/designer-html.md).

# Designer HTML

Le **Designer HTML** d'Efalia Process est l'outil de création des formulaires, des connecteurs, des règles de gestion avancées et des tableaux de bord. Il s'appuie sur le modèle de processus créé dans la [Modélisation](/documentations/efalia-process/administration/administration-fonctionnelle/modelisation-designer.md) pour générer automatiquement les interfaces utilisateur et les comportements applicatifs.

***

## Conception des Formulaires

Les formulaires sont les interfaces de **saisie et de consultation** des données métier dans Efalia Process. Chaque document peut avoir plusieurs formulaires selon le contexte (lecture, écriture, archivage).

### Créer un Formulaire

{% tabs %}
{% tab title="Depuis les propriétés d" %}
{% stepper %}
{% step %}

#### Sélectionner le document

Dans le graphe de processus, sélectionnez le **Document** pour lequel vous souhaitez créer un formulaire.
{% endstep %}

{% step %}

#### Accéder aux propriétés

Dans le panneau de droite, cliquez sur le bouton **Formulaire** puis sur **Nouveau**.
{% endstep %}

{% step %}

#### Configurer le formulaire

Renseignez le nom, le libellé et définissez si ce formulaire est le formulaire **par défaut** (lecture, écriture, archivage).
{% endstep %}
{% endstepper %}
{% endtab %}

{% tab title="Depuis le panneau Projets" %}
{% stepper %}
{% step %}

#### Accéder à la section Formulaires

Dans le panneau de gauche, localisez la section **Formulaires** de votre projet.
{% endstep %}

{% step %}

#### Créer un nouveau formulaire

Cliquez sur l'icône **+** à côté de "Formulaires".
{% endstep %}

{% step %}

#### Associer le formulaire au document

Une fois créé, associez le formulaire au document concerné depuis les propriétés du document.
{% endstep %}
{% endstepper %}
{% endtab %}
{% endtabs %}

### Composants de Formulaire

Faites glisser les composants depuis le panneau vers le canvas du formulaire :

{% tabs %}
{% tab title="Saisie de données" %}

| Composant            | Type de données    | Usage                                   |
| -------------------- | ------------------ | --------------------------------------- |
| **Ligne unique**     | Texte court        | Nom, référence, code                    |
| **Multi-ligne**      | Texte long         | Description, commentaire                |
| **Bouton radio**     | Sélection unique   | Statut, catégorie (valeurs prédéfinies) |
| **Liste**            | Sélection multiple | Tags, mots-clés                         |
| **Liste à cocher**   | Choix multiple     | Options, fonctionnalités                |
| **Liste déroulante** | Sélection unique   | Domaine de valeur                       |
| **Calendrier**       | Date / Heure       | Échéance, date de livraison             |
| **URL**              | Lien externe       | Référence web, document en ligne        |
| {% endtab %}         |                    |                                         |

{% tab title="Contenu riche" %}

| Composant           | Type de données                | Usage                          |
| ------------------- | ------------------------------ | ------------------------------ |
| **Pièce jointe**    | Fichier                        | Facture, contrat, justificatif |
| **Table simple**    | Champs alignés horizontalement | Données structurées fixes      |
| **Table dynamique** | Lignes variables               | Lignes de commande, articles   |
| **Vue embarquée**   | Référence vers une vue         | Documents liés, sous-dossiers  |
| {% endtab %}        |                                |                                |

{% tab title="Organisation" %}

| Composant     | Usage                                         |
| ------------- | --------------------------------------------- |
| **Section**   | Regroupe des champs dans une zone rétractable |
| {% endtab %}  |                                               |
| {% endtabs %} |                                               |

📸 **CAPTURE : admin-fonct-designer-html-01-creation-formulaire.png**

> Interface du Designer HTML avec un formulaire en cours de construction, composants dans le panneau gauche et canvas de conception à droite

### Propriétés d'un Composant

Chaque composant de formulaire dispose de **6 catégories de propriétés** configurables :

| Catégorie              | Contenu                                                     |
| ---------------------- | ----------------------------------------------------------- |
| **Général**            | Libellé, nom interne, obligatoire, taille                   |
| **Paramètres**         | Comportement spécifique (lecture seule, valeur par défaut…) |
| **Scripts**            | Code STalk ou JavaScript exécuté au chargement/modification |
| **Connecteurs**        | Alimentation depuis des sources de données externes         |
| **Description / Aide** | Texte d'aide affiché à l'utilisateur                        |
| **Information**        | Métadonnées (créé le, modifié le…)                          |

### Règles de Visibilité des Formulaires

Efalia Process sélectionne automatiquement le formulaire approprié selon **4 critères** :

| Critère                   | Exemple                                                |
| ------------------------- | ------------------------------------------------------ |
| **Rôle de l'utilisateur** | Le valideur voit un formulaire différent du demandeur  |
| **État du document**      | Formulaire lecture seule si document en état "Clôturé" |
| **Type d'opération**      | Formulaire de création vs formulaire de modification   |
| **Niveau d'accès**        | Lecture (`read`) ou Écriture (`write`)                 |

{% hint style="info" %}
💡 Si plusieurs formulaires correspondent aux critères, Efalia Process affiche une liste de choix à l'utilisateur.
{% endhint %}

***

## Connecteurs

Les connecteurs permettent d'alimenter des champs de formulaire depuis des **sources de données externes** (bases de données, services, applications tierces).

### Types de Connecteurs

{% tabs %}
{% tab title="Connecteur SQL" %}
**Alimentation depuis une base de données**

Exécute une requête SQL et injecte les résultats dans les champs du formulaire.

**Paramètres :**

* **Source de données** : DataSource déclarée dans la configuration serveur
* **Requête SQL** : Requête SELECT avec paramètres de liaison
* **Mapping** : Association colonne SQL → champ formulaire

**Exemple d'usage :** Charger automatiquement les informations d'un fournisseur quand son code est saisi.
{% endtab %}

{% tab title="Connecteur Java" %}
**Alimentation via une classe Java personnalisée**

Appelle une classe Java déployée sur le serveur pour récupérer ou calculer des données.

**Paramètres :**

* **Classe Java** : Nom complet de la classe (ex : `com.efalia.connectors.MyConnector`)
* **Paramètres** : Variables passées à la classe
* **Mapping** : Association résultat → champ formulaire

**Exemple d'usage :** Appeler un web service externe, calculer un tarif, vérifier une disponibilité.
{% endtab %}
{% endtabs %}

{% hint style="warning" %}
⚠️ Les DataSources utilisées par les connecteurs SQL doivent être préalablement déclarées dans la configuration du serveur (`catalina.properties`). Contactez votre administrateur technique.
{% endhint %}

***

## Modélisation Avancée des Opérations

### Opérations Séquentielles

Une **opération séquentielle** est prise en charge par un seul rôle à la fois. Elle fait avancer le document d'un état à l'autre.

**Comportements configurables :**

* Création d'un nouveau document
* Modification d'un état existant
* Exécution conditionnelle selon l'état du document
* Annulation possible par l'utilisateur (avec trace historique)

### Opérations Parallèles

Les **opérations parallèles** permettent à plusieurs rôles d'intervenir **simultanément**, sans ordre prédéfini. Le document n'avance vers l'état suivant que lorsque **tous** les rôles ont effectué leurs opérations.

📸 **CAPTURE : admin-fonct-designer-html-02-operations-paralleles.png**

> Exemple de bloc d'opérations parallèles avec 3 rôles travaillant simultanément

### Opérations Automatiques

Une **opération automatique** est exécutée par un **Agent** (tâche planifiée serveur) sans intervention humaine.

{% hint style="warning" %}
⚠️ **Règle importante** : Une opération affectée à un agent automatique ne peut avoir qu'**un seul état de sortie**. Elle ne peut pas présenter de choix à l'utilisateur.
{% endhint %}

### Règles de Transition (Liens de Sortie)

Les liens de sortie d'une opération peuvent inclure des **règles de condition** qui déterminent automatiquement le prochain état :

| Mode                  | Comportement                                                                          |
| --------------------- | ------------------------------------------------------------------------------------- |
| **Automatique**       | Le système évalue les règles dans l'ordre et sélectionne la première qui est vraie    |
| **Choix utilisateur** | L'utilisateur sélectionne manuellement l'état de sortie parmi les options disponibles |
| **Sans règle**        | Sélectionné par défaut si aucune règle n'est vérifiée                                 |

### Gestion des Délais

Les **liens de délai** (flèches vertes en tirets) permettent de définir des échéances sur les opérations :

* **Délai d'alerte** : Avertissement avant l'expiration
* **Changement d'état automatique** : Le document change d'état automatiquement si le délai est dépassé

***

## Fonctionnalités Avancées de Modélisation

### Dérivation de Documents

Une opération peut créer un **document dérivé** (sous-dossier) qui suit son propre cycle de vie indépendant.

**Cas d'usage :** Une commande principale génère automatiquement plusieurs bons de livraison.

Les champs peuvent être **hérités automatiquement** du document parent vers le document dérivé.

### Synchronisation entre Documents

Des **règles de synchronisation** permettent à une opération d'attendre qu'un document dérivé atteigne un état spécifique avant de s'exécuter.

**Cas d'usage :** La facturation ne peut démarrer que lorsque tous les bons de livraison sont en état "Livré".

### Regroupement / Dégroupement

Coordonne plusieurs documents indépendants en les **regroupant** sous un workflow unifié pour une validation groupée.

### Annulation d'Opération

Une opération peut être configurée comme **annulable**, permettant à l'utilisateur de revenir à l'état précédent. L'historique des annulations est conservé.

### États Universels

Une opération peut être rendue accessible depuis **n'importe quel état** du document (ex : une opération "Archiver" accessible à tout moment).

***

## Règles du Dictionnaire

Les **règles du dictionnaire** définissent des contraintes de validation sur les données du document (obligatoire, format, valeur min/max, etc.).

📸 **CAPTURE : admin-fonct-designer-html-03-regles-dictionnaire.png**

> Interface de création d'une règle du dictionnaire avec conditions et actions

Elles s'appliquent indépendamment des formulaires et sont évaluées lors de la sauvegarde du document.

***

## Déploiement d'un Processus

### Vérifications Automatiques Avant Déploiement

Avant de déployer, Efalia Process effectue une série de **contrôles de cohérence** :

{% tabs %}
{% tab title="Cycle de vie" %}

* Tous les états des documents doivent être **atteignables**
* Aucune opération **isolée** (sans lien entrant ou sortant)
* Chaque procédure doit être **attachée** à au moins un processus
  {% endtab %}

{% tab title="Champs et Domaines" %}

* Tous les champs doivent avoir un **type SQL défini**
* Les domaines booléens doivent avoir **exactement 2 valeurs**
  {% endtab %}

{% tab title="Vues et Sections" %}

* Une vue doit avoir **au moins une colonne**
* Une section ne peut pas être **vide** (doit contenir au moins un champ ou une table)
  {% endtab %}

{% tab title="Opérations" %}

* Le nom d'une opération est **unique** dans la liste des opérations d'un rôle
* Les opérations d'agent automatique n'ont qu'**un seul état de sortie**
  {% endtab %}
  {% endtabs %}

### Déployer

{% stepper %}
{% step %}

#### Lancer la vérification

**Outils > Vérifier** — Corrigez toutes les erreurs avant de continuer.
{% endstep %}

{% step %}

#### Déployer le processus

Cliquez sur **Déployer** dans la barre d'outils (ou **Outils > Générer**).

Efalia Process génère l'application de workflow à partir de la modélisation. La licence **Workey Engine** est requise.

📸 **CAPTURE : admin-fonct-designer-html-04-deploiement.png**

> Bouton Déployer dans la barre d'outils du Designer et confirmation de succès
> {% endstep %}

{% step %}

#### Vérifier en production

Accédez à l'application (`/workey`) pour confirmer que le processus est disponible.

**Résultat :** Le déploiement est pris en compte **immédiatement**, sans redémarrage serveur.
{% endstep %}
{% endstepper %}

### Maintenance du Projet

La fonction **Maintenance** (`Outils > Maintenance`) nettoie le projet et corrige automatiquement les incohérences mineures susceptibles de bloquer le déploiement.

{% hint style="info" %}
💡 Utilisez la Maintenance régulièrement sur les projets complexes pour éviter l'accumulation de références orphelines.
{% endhint %}

***

## Migration depuis Flash Designer

Si vous avez des projets modélisés avec l'ancien Designer Flash, Efalia Process propose une **procédure de migration** vers le Designer HTML.

{% hint style="warning" %}
⚠️ La migration de projets Flash vers HTML nécessite une étape de vérification et d'adaptation des formulaires. Consultez votre référent technique ou le support Efalia avant d'entreprendre une migration.
{% endhint %}

***

## Bonnes Pratiques

{% hint style="success" %}
**✅ À faire :**

* Créer un formulaire **dédié à l'archivage** pour chaque type de document
* Tester chaque formulaire dans les différents contextes (rôle, état, opération)
* Utiliser les **sections** pour structurer les formulaires complexes
* Documenter les règles de connecteur dans la description des composants
* Vérifier le déploiement sur un **environnement de recette** avant la production
  {% endhint %}

{% hint style="danger" %}
**❌ À éviter :**

* Créer des formulaires sans formulaire d'archivage associé (données perdues à l'archivage)
* Utiliser des connecteurs SQL pointant vers des tables sans index (problèmes de performance)
* Déployer directement en production sans test préalable
* Laisser des sections vides dans un formulaire (bloque le déploiement)
  {% endhint %}

***

## Questions Fréquentes

<details>

<summary>Comment créer un formulaire différent selon le rôle de l'utilisateur ?</summary>

Créez plusieurs formulaires pour le même document, puis configurez les règles de visibilité dans les propriétés de chaque formulaire. Dans la section "Général" du formulaire, vous pouvez spécifier pour quel(s) rôle(s) ce formulaire doit être affiché.

Si plusieurs formulaires correspondent aux critères, Efalia Process propose un choix à l'utilisateur.

</details>

<details>

<summary>Un connecteur SQL peut-il mettre à jour des données (INSERT/UPDATE) ?</summary>

Les connecteurs peuvent être de type **lecture** (pour alimenter des champs) ou **écriture** (pour synchroniser des données vers une base externe). Les connecteurs en écriture s'exécutent lors de la sauvegarde du document.

Attention : ces connecteurs n'utilisent pas les mécanismes transactionnels d'Efalia Process — en cas d'erreur, la transaction Efalia Process peut être annulée mais pas les opérations SQL déjà exécutées.

</details>

<details>

<summary>Peut-on réutiliser un formulaire dans plusieurs processus d'un même projet ?</summary>

Oui. Les formulaires définis dans un projet sont disponibles pour tous les documents du projet. Il est cependant recommandé de nommer les formulaires clairement pour éviter les confusions lors de leur association aux documents.

</details>

<details>

<summary>Que se passe-t-il si un déploiement échoue en production ?</summary>

En cas d'échec de déploiement, Efalia Process effectue un **rollback automatique** vers la version précédente du processus. L'ancienne version reste opérationnelle et les documents en cours ne sont pas affectés. L'erreur est enregistrée dans les logs du serveur.

</details>

<details>

<summary>Comment tester un formulaire sans le déployer en production ?</summary>

Le Designer HTML propose un **mode aperçu** pour tester l'affichage des formulaires. Ce mode simule l'affichage sans déployer le processus.

Pour des tests fonctionnels complets (workflow, connecteurs), déployez sur un **environnement de recette** dédié.

</details>

<details>

<summary>Les tables dynamiques ont-elles une limite de lignes ?</summary>

Il n'y a pas de limite technique configurée par défaut, mais les performances peuvent se dégrader avec un très grand nombre de lignes (> 500). Pour les cas de grands volumes, envisagez une solution de pagination ou une vue dédiée plutôt qu'une table dynamique dans le formulaire.

</details>

<details>

<summary>Comment gérer les champs calculés dans un formulaire ?</summary>

Utilisez la catégorie **Scripts** des propriétés d'un champ pour exécuter du code STalk ou JavaScript lors du chargement ou de la modification d'autres champs. Ce mécanisme permet de calculer automatiquement des valeurs (totaux, dates calculées, concaténations…).

Consultez l'article [Langages de Processus](/documentations/efalia-process/administration/administration-fonctionnelle/langages-process.md) pour la documentation STalk et WKYJS.

</details>

<details>

<summary>Est-il possible d'embarquer une vue de documents liés dans un formulaire ?</summary>

Oui, utilisez le composant **Vue embarquée**. Il référence une vue définie dans un graphe de procédure et l'affiche directement dans le formulaire, permettant de voir et naviguer dans les documents liés sans quitter le formulaire principal.

</details>

***

**Le Designer HTML vous permet de couvrir l'ensemble des besoins de modélisation et de configuration.** Pour personnaliser l'interface utilisateur du Panorama, consultez l'article sur le Paramétrage du Front Office.

Pour aller plus loin :

* [Paramétrage du Front Office](/documentations/efalia-process/administration/administration-fonctionnelle/parametrage-front-office.md)
* [Langages de Processus (STalk, WKYJS)](/documentations/efalia-process/administration/administration-fonctionnelle/langages-process.md)
* [Tableaux de Bord et Vues](/documentations/efalia-process/administration/administration-fonctionnelle/tableaux-bord-vues.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://documentation.efalia.com/documentations/efalia-process/administration/administration-fonctionnelle/designer-html.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
