Littéralis¶

Avant-propos¶

Côté sécurisation, chaque commune utilise un couple login/mot de passe différent.
Coté Publik, il faut créer autant d'instance de connecteurs que de communes concernées, et dans le workflow, faire en sorte d’appeler l'instance de connecteur appropriée.

Installation¶

1. Configurer le ou les connecteurs.
2. Importer le workflow.
3. Créer le formulaire.

Connecteur¶

Informations à demander au client :

• Identifiant et mot de passe d’authentification basique
• le cas échéant, certificat TLS client (a priori pas utilisé)
• le cas échéant, le fichier « autorités de confiance » (a priori pas utilisé)
• le cas échéant, le proxy HTTP et HTTPS
• URL de l’API (https://staging.api.sogelink.fr/litteralis/ pour la recette)

Chaque client du fournisseur doit également avoir un identifiant et un nom unique pour pouvoir les différencier. Cela permet de discriminer plusieurs collectivités qui utiliseraient le même fournisseur. Les champs titre et identifiant servent à cela.

Dans le paramétrage, laisser coché « Vérification des certificats » sauf si vous savez ce que vous faites.

Endpoints¶

Injection dans Littéralis :

• /demandes-recues : permet l’injection d’une demande
• /upload : permet d’injecter un fichier dans une demande dans Littéralis
• /annexe : permet d’injecter un fichier d’annexe dans une demande dans Littéralis (plan de situation, pièces complémentaires etc fournies par de demandeur)

Suivi :

• /demandes-recues-reponses : statut de la demande dans Littéralis
• /demandes-recues-arrete : récupération de l’acte (fichier)

Workflow¶

Donnée de traitement « identifiant demande littéralis » pour stocker l’id_demande retournée par l’appel à /demandes-recues

Injection de la demande dans Littéralis (/demandes-recues)¶

• AdditionalInformation/… : en plus de dateDebut, dateFin et typeDemande, selon le type de demande créé et selon le paramétrage fait sur l’instance du client, certains champs supplémentaires sont nécessaires (cf documentation p5 et suivantes).
• AdditionalInformation/typeDemande (à valider lors d’un prochain déploiement) :
  • si TypeModele = DA, typeDemande = « Temporaire de travaux »
  • si TypeModele = DPS, typeDemande = « Stationnement pour travaux »
  • si TypeModele = DPV, typeDemande = « Permission de voirie avec travaux »
• dateEnvoi : date et heure de réception de la demande dans Publik (pour le format, cf workflow modèle).
• fournisseur : désigne la plateforme de GRC (mettre : ENTROUVERT).
• localisation : il s’agit de l’adresse pour la demande (une adresse est également rattachée au demandeur ; ici il s’agit du lieu concerné par les travaux/stationnements/...)
• geom : coordonnées pour la demande au format geojson ; pour geom/type, mettre « Point ».
• idDemande : ne sert à rien a priori ; mettre form_number ou form_number_raw
• TypeModele : « DA » (Demande d’arrêté), « DPS » (Demande de Permis de stationnement) ou « DPV » (Demande de Permission de Voirie )

Retourne « idDemande » et « status » (avec la valeur « A_TRAITER »).

Injection de fichier (/upload)¶

Optionnel ; un PDF récapitulant la demande.

• file : objet fichier (de manière générale, {{ form_var_fichier }} )
• id_demande : l’id récupéré lors de l’injection de la demande

Injection de l’annexe (/annexes)¶

Optionnel ; documents annexes à la demande (transmis par l’usager).

Note : le workflow modèle n’intègre pas cet appel.

• file : objet fichier (de manière générale, {{ form_var_fichier }} )
• id_demande : l’id récupéré lors de l’injection de la demande

Récupération du statut (/demandes-recues-reponses)¶

id_demande à passer en paramètre d’url.

Les codes suivants sont possibles :

• A_TRAITER
• REFUSEE (dans ce cas un motif accompagne le statut)
• TRAITEE

Récupération de l’acte (/demandes-recues-arrete)¶

Bien que ce endpoint soit exposé, il n'est pas fonctionnel. Cela peut faire l'objet d'un développement complémentaire.

Formulaire¶

Littéralis a besoin de coordonnées géographiques (champs obligatoires à l’injection). Il faut donc prévoir une carte ou résoudre les coordonnées par l’adresse.