Projects
HubSessions API ‹identifiant_annexe›/xml

Le service ‹identifiant_annexe›/xml permet de récupérer les données d'une annexe.

Type de requête

Requête HTTP GET

Données en entrée

L'identifiant de l'annexe est inclus dans l'URL du service, qui n'accepte aucun paramètre.

Exemple de requête

Appeler le service pour l'annexe dont l'identifiant est 4321 se fait via l'URL suivante.

<siteUrl>/4321/xml

Données de retour

Comme expliqué dans l'introduction de cette API, la plupart du temps, le contenu binaire de l'annexe est encodé en Base64, puis potentiellement saucissonné en plusieurs morceaux. Cela étant dit, HubSessions peut également être configuré pour que le service retourne un chemin pointant vers le fichier sur le disque.

Mode binaire

Voici un exemple d'annexe en mode binaire.

<Annex type="object" id="355" iid="355" className="Annex">
 <!-- Main metadata -->
 <title>Logo de LibreOffice</title>
 <creator>info@emidesign.be</creator>
 <created type="DateTime">2023/04/03 10:26:54.243149 GMT+2</created>
 <modified type="DateTime">2023/04/03 10:26:54.243149 GMT+2</modified>
 <annexType>163:annex</annexType>
 <file type="file" mimeType="image/png" name="LibreOffice.png">
  <part type="base64" number="1">iVBORw0KGgoAAAANSUhEUgAAA...</part>
  <part type="base64" number="2">rsnY99YHNva8QBcCTUSEcYClG8RKJv2XU...</part>
 </file>
 <!-- Object history -->
 <record type="object" className="History">
  <data type="list" count="1">
   <e type="object" className="Trigger">
    <transition>_init_</transition>
    <login>info@emidesign.be</login>
    <state>created</state>
    <date type="DateTime">2022/11/16 10:18:20.061924 GMT+1</date>
    <comment/>
   </e>
  </data>
  <modified type="DateTime">2023/04/03 10:26:54.243149 GMT+2</modified>
 </record>
</Annex>

Les attributs id et iid du tag principal Annex représentent l’identifiant de base de données interne à HubSessions concernant cette annexe.

Le titre de l'annexe (tag title), obligatoire, est un descriptif court de l'annexe, qui peut différer du nom du fichier uploadé.

Comme pour tout objet Appy, on trouvera, au sein des métadonnées, le créateur du point (tag creator : il s’agit du login de la personne telle que connu par HubSessions), la date de création (tag created) et de dernière modification (tag modified) de l'annexe.

Une annexe est également caractérisée par un type logique (qui n'a rien à voir avec le format du fichier uploadé: PDF, LibreOffice, Word, etc). Le tag annexType identifie le type d'annexe lié. Son contenu est de la forme:

<identifiant_db_type_annexe>:<identifiant_logique_type_annexe>

Les types d'annexes existants sont des objets Appy à part entière, qui peuvent être récupérés par un appel au service ask/annexTypes.

L'identifiant DB (=base de données) du type d'annexe permet de récupérer les données du type, y inclus l'icône qui le représente. Pour ce faire, vous pouvez reconstituer l'URL du service ‹identifiant_type_annexe›/xml, permettant de consulter le type d'annexe, comme ceci:

<siteUrl>/<identifiant_db_type_annexe>/xml

L'identifiant logique correspond à l'attribut annexTypeId de la classe AnnexType et est plus lisible par un humain que l'identifiant de base de données, numérique.

Mode sur disque

Lorsqu'HubSessions est configuré en mode sur disque, le tag file ressemble à ceci.

<file type="file" mimeType="application/pdf" name="LibreOffice.pdf" location="chemin/vers/lo.pdf"/>

L'attribut location donne le chemin relatif de l'annexe sur le disque. Ce chemin peut être inclus:

  • dans le dossier contrôlé par la base de données d'HubSessions (dossier à l'intérieur duquel sont stockés tous les fichiers binaires référés dans les objets de la base de données);
  • dans un dossier miroir, si HubSessions est configuré de la sorte. En mode miroir, dès qu'une annexe est créée dans HubSessions, elle est stockée dans le dossier contrôlé par la DB et une copie en est automatiquement faite dans un dossier miroir. Ce dernier est souvent un disque distant accessible via un point de montage, également accessible au logiciel appelant l'API d'HubSessions. D'où l'intérêt de disposer du mode sur disque, qui évite de faire passer les fichiers binaires via l'interface HTTP.