Projects
Projects
Advanced search...
Active
Inactive
rEve API privée create/activity

Description

Le service create/activity permet d'ajouter une activité dans rEve. Une activité se crée au nom d'un partenaire. Seul un utilisateur disposant du rôle de partenaire (Partner) peut créer une activité. Étant donné qu'un utilisateur de ce type peut être lié à plusieurs partenaires, la requête devra préciser au nom de quel partenaire l'activité doit être créée.

Type de requête

Requête HTTP POST

Données en entrée

La charge utile de la requête HTTP POST de création d'une activité a une structure telle qu'illustrée ci-dessous.

<?xml version="1.0" encoding="UTF-8" ?>
<Activity type="object">
 <partnerId>40213</partnerId>
 <title type="dict">
  <entry type="object">
   <k>fr</k>
   <v>Excursion</v>
  </entry>
  <entry type="object">
   <k>nl</k>
   <v>Excursie</v>
  </entry>
 </title>
 <summary type="dict">
  <entry type="object">
   <k>fr</k>
   <v>Explication un peu plus détaillée</v>
  </entry>
  <entry type="object">
   <k>nl</k>
   <v>Een iets gedetailleerdere uitleg</v>
  </entry>
 </summary>
 <description type="dict">
  <entry type="object">
   <k>fr</k>
   <v><![CDATA[
      <p>Excursion</p>
      <p>Avec <em>détail</em> et <strong>formatage</strong>.</p>
      ]]>
   </v>
  </entry>
  <entry type="object">
   <k>nl</k>
   <v><![CDATA[
      <p>Excursie</p>
      <p>Met <em>details</em> en <strong>opmaak</strong>.</p>
      ]]>
   </v>
  </entry>
 </description>
 <variety>standard</variety>
 <capacity>10</capacity>
 <periodType>schooltime</periodType>
 <domain>ocs</domain>
 <price type="float">10.1</price>
 <tags type="list" count="1">
  <e>1166</e>
 </tags>
 <targets type="list" count="2">
  <e>1177</e>
  <e>1178</e>
 </targets>
 <innerPeriods type="list" count="2">
  <e type="object">
   <startDate type="DateTime">2026/07/01 10:00:00 GMT+2</startDate>
   <endDate type="DateTime">2026/07/01 11:30:00 GMT+2</endDate>
   <publishDate type="DateTime">2026/06/01 09:00:00 GMT+2</publishDate>
   <publishDatePrivileged/>
   <unregisterDate/>
   <unpublishDate type="DateTime">2026/06/30 23:00:00 GMT+2</unpublishDate>
  </e>
  <e type="object">
   <startDate type="DateTime">2026/08/01 10:00:00 GMT+2</startDate>
   <endDate type="DateTime">2026/08/01 11:30:00 GMT+2</endDate>
   <publishDate type="DateTime">2026/06/01 09:00:00 GMT+2</publishDate>
   <publishDatePrivileged/>
   <unregisterDate/>
   <unpublishDate type="DateTime">2026/06/30 23:00:00 GMT+2</unpublishDate>
  </e>
 </innerPeriods>
 ...
</Activity>

Mention du partenaire

Comme expliqué plus haut, une activité est proposée au nom d'un partenaire. L'identifiant technique du partenaire en question doit être fourni dans le tag partnerId.

Champs de texte

Une activité est tout d'abord décrite par 3 champs de texte:

  • un titre (tag title),
  • un résumé (tag summary),
  • une description (tag description).

Ces champs peuvent soit être monolingues, soit multilingues.

L'exemple illustre une configuration au sein de laquelle les champs sont bilingues, français (fr) et néerlandais (nl).

Alors qu'un champ unilingue se représenterait simplement comme ceci:

<title>Excursion</title>

, un champ multilingue contient un sous-tag entry par langue. Chaque tag entry se décompose d'un sous-tag k (pour key), qui donne le code ISO (2 lettres) de la langue en minuscules, et d'un tag v (pour value) qui donne la valeur textuelle pour cette langue.

Au-delà de cet aspect mono- ou multilingue, il existe des différences additionnelles entre les 3 tags title, summary et description.

  • Le tag title ne peut pas contenir de passage à la ligne (caractère \n).
  • Le tag summary peut en contenir.
  • Alors que les tags title et summary contiennent du texte brut, le tag description contient une description détaillée de l'activité au format XHTML. La valeur de chaque sous-tag contenant le contenu XHTML doit être entouré d'une mention CDATA, comme illustré.

Variété

La variété de l'activité représente une catégorisation dont l'explication et les valeurs possibles sont décrites ici. La valeur la plus fréquente est standard.

Capacité

La capacité d'une activité (tag capacity) se réfère au nombre de places disponibles. Il s'agit d'un champ obligatoire. Si votre activité ne définit pas une capacité précise, encodez ici un nombre suffisamment grand pour permettre d'inscrire suffisamment de personnes.

Type d'activité

Second schéma de catégorisation, le type de l'activité se définit via le tag periodType. Le nommage de ce dernier peut surprendre, les raisons sont historiques (il devrait s'appeler activityType). Les différents types d'activité sont décrits ici. Le type schooltime, illustré dans l'exemple, représente une activité à inscription automatique qui se déroule à l'école, en période scolaire: une excursion, une classe verte, la visite d'un musée ou encore une petite baignade à la piscine.

Domaine

Le site rEve que vous attaquez peut être divisé en domaines. Chaque domaine représente une entité distincte sous la houlette de laquelle un jeu d'activités, proposés par divers partenaires, est organisé. Si les domaines sont activés sur le site, il est obligatoire de fournir, dans le tag domain, l'identifiant technique de ce domaine. Cet identifiant doit vous avoir été llivré par un administrateur du site.

Prix

Le tag price, obligatoire, doit reprendre le prix tel que demandé par le partenaire. Il doit s'agir d'une valeur réelle. Indiquez 0 dans le cas d'une activité gratuite. Dans le cas d'une inscription de type schooltime (activité à inscriptions automatiques), il s'agit du prix que chaque élève doit payer.

Publics-cibles

Chaque activité est destinée à un ou plusieurs publics-cibles: enfants, adultes, famille, etc. Les publics-cibles définis sur un site rEve peuvent être récupérés via un appel au service get/activityTargets. Le tag targets doit définir au moins un de ces publics-cibles, en spécifant son identifiant technique (iid, exposé par le service get/activityTargets), comme illustré dans l'exemple ci-dessus.

Tags

Chaque activité doit être marquée par un ou plusieurs tags, sorte de schéma de catégorisation multiple d'activités, dont la sémantique précise est de la responsabilité des gestionnaires du site rEve. Les tags définis sur un site rEve peuvent être récupérés via un appel au service get/activityTags. Le tag tags doit définir au moins un de ces tags, en spécifiant son identifiant technique (iid, exposé par le service get/activityTags), comme illustré dans l'exemple ci-dessus.

⚠️ Pour une activité avec paiements externalisés, c'est-à-dire dont les factures et leur paiement sont délégués à un logiciel tiers, une contrainte s'applique: l'activité ne peut être liée qu'à un seul tag définissant un code externe. Renseignez-vous auprès des administrateurs du site rEve pour savoir si les activités que vous devez créer sont à paiement externalisé ou non.

Périodes

Une activité se déroule à une ou plusieurs périodes. Chaque période représente un intervalle de temps, ayant une date et heure de début et une date et heure de fin. Cet intervalle peut représenter une heure trente (une séance de cinéma par exemple) ou une semaine (un stage pour enfants durant l'été).

Il existe deux types fondamentaux de périodes.

  • Les périodes externes sont des périodes standardisées qui sont créées de manière globale au sein de rEve, ou, quand les domaines sont activés, domaine par domaine le cas échéant. Ce type de période convient bien pour représenter des périodes de vacances (exemples: Été semaine 3, Congé d'hiver semaine 2) ou, à l'inverse, une période scolaire (de juin à septembre). Une activité planifiée sur une ou plusieurs périodes externes doit mentionner cette ou ces périodes, via le tag periods, dont la structure est assez similaire à celle des tags targets ou tags présentés ci-dessus. L'état actuel de l'API ne permet pas encore de créer une activité à périodes externes.
  • À l'inverse, les périodes internes sont des périodes qui sont propres à une activité et qui doivent être définies en son sein, via le tag innerPeriods, tel qu'illustré sur l'exemple en début de page. Comme déjà expliqué, chacune de ces périodes peut représenter un intervalle de temps variable, allant d'une heure à une semaine, voire plus. Chaque période interne définit les champs suivants:
    • une date et heure de début (sous-tag startDate) [obligatoire];
    • une date et heure de fin (sous-tag endDate) [obligatoire];
    • une date d'ouverture des réservations pour l'activité, à cette période précise (sous-tag publishDate) [obligatoire];
    • une date alternative d'ouverture des réservations, pour les citoyens de la zone privilégiée (tag publishDatePrivileged) [optionnel];
    • une échéance de désinscription de cette activité, à cette période, par le citoyen (tag unregisterDate) [optionnel];
    • une date de clôture des réservations, pour cette activité à cette période (tag unpublishDate) [obligatoire].

Voici quelques considérations complémentaires concernant les périodes internes.

  • Veillez à bien renseigner l'heure et le fuseau horaire dans chacune des dates, selon le format illustré dans l'exemple.
  • En ce qui concerne les activités à inscriptions automatiques (voir ci-dessous), les dates d'ouverture et de clôture des réservations (sous-tags publishDate et unpublishDate) sont obligatoires mais n'ont pas de sens, puisque les citoyens ne s'inscrivent pas eux-mêmes à ces activités. Il faut donc renseigner ici des dates fictives, en respectant les règles ci-dessous, afin d'être certain que le service ne génère pas d'erreur:
    • définissez la date d'ouverture des réservations avant la date de début de la période;
    • définissez la date de clôture des réservations un jour avant la date de début de la période (et en tous cas après la date d'ouverture des réservations).

Champs spécifiques aux activités pour enfants

L'exemple ci-dessus présente le jeu de champs de base, qui s'applique à la plupart des activités gérables par rEve.

La présente section détaille les champs spécifiques aux activités pour enfants. Les types d'activités correspondant à des activités pour enfants sont listés ici.

Les tags décrits dans cette section sont à ajouter directement sous le tag principal Activity.

Niveau scolaire

Certaines activités pour enfants sont accessibles uniquement à ceux d'un ou plusieurs niveaux scolaires déterminés.

⚠️ Toute activité pour enfant ne restreint pas nécessairement son accès sur base du niveau scolaire. Certaines restreignent, par exemple, l'accès aux enfants sur base d'une tranche d'âge.

Si votre activité n'est accessible qu'aux enfants d'un ou plusieurs niveaux scolaires, définissez un tag schoolLevels comme illustré ci-dessous.

<schoolLevels type="list" count="4">
 <e>p3</e>
 <e>p4</e>
 <e>p5</e>
 <e>p6</e>
</schoolLevels>

Ce tag définit l'activité comme étant accessible aux éleves de la troisième jusqu'à la sixième primaire. Les valeurs possibles pour ce tag sont définies ici.

Activités à inscriptions automatiques

Une activité à inscriptions automatiques est une activité pour laquelle les inscriptions sont réalisées, par une école pour une ou plusieurs de ses classes, de manière groupée, en dehors de rEve. Ensuite, au sein de rEve, des inscriptions individuelles sont créées pour chaque élève concerné.

S'il s'agit d'une inscription à activités automatiques, le tag booléen autoreg doit être défini.

<autoreg type="bool">True</autoreg>

De plus, la liste des identifiants des classes participantes doit être renseignée. Il doit s'agir d'une ou plusieurs classes appartenant à l'école à laquelle le partenaire mentionné dans le tag partnerId est relié.

<rooms type="list" count="2">
 <e>1234</e>
 <e>5678</e>
</rooms>

Dans l'exemple ci-dessus, les classes 1234 et 5678 seront inscrites à l'activité. Notez que le ou les niveaux scolaires de ces classes doivent correspondre à celui ou ceux mentionné·s dans le tag schoolLevels décrit ci-dessus.

Le service get/rooms vous permet de récupérer de l'information (dont les identifiants requis ici) au sujet des classes d'une école liée à un partenaire donné.

Enfin, les tags suivants, optionnels, peuvent être ajoutés à la requête. S'ils ne le sont pas, ils recevront la valeur par défaut False.

<presenceIsDefault type="bool">False</presenceIsDefault>

Si le tag presenceIsDefault est défini à True et qu'aucune présence n'a été encodée sur cette activité au moment de générer une facture mensuelle, alors tous les élèves de la ou des classe·s sélectionnée·s seront considérés comme ayant participé à l'activité.

<incomplete type="bool">False</incomplete>

Si le tag incomplete a la valeur True, l'information encodée au sujet de cette activité est considérée comme incomplète ou imprécise. Ce faisant, vous bloquez temporairement toute génération mensuelle de factures, le temps que l'information soit complétée ou corrigée. Par exemple, si cette activité représente une activité externe pour laquelle son organisateur doit émettre une facture à l'école, il se peut qu'on ne connaisse le prix exact par enfant qu'au moment où cette facture sera émise, ce qui peut se produire plusieurs jours, semaines voire mois après que l'activité ait eu lieu.

Données de retour

Le service create/activity se conforme au format de retour standardisé tel que décrit ici (à consulter notamment pour connaître la signification des différents codes de retour possibles). Au sein du sous-tag data, l'identifiant technique de l'activité créée dans rEve, en cas de succès, est présent, comme illustré ci-dessous. Il est important pour l'appelant de conserver cet identifiant, qui permettra, par exemple, de réaliser sur rEve des appels subséquents afin, par exemple, de s'enquérir du statut de l'activité ou de consulter des informations complétées par la suite via son interface web.

<?xml version="1.0" encoding="utf-8" ?>
<Response type="object" className="Response">
 <code type="int">0</code>
 <text>WS create/activity :: Activity 1234 successfully created.</text>
 <data type="object" className="Object">
  <id type="int">1234</id>
 </data>
</Response>

Nanti de l'identifiant technique de l'activité, vous pouvez ensuite appeler le service {activityId}/xml afin de récupérer les informations sur l'activité en question; informations susceptibles d'évoluer au sein du logiciel.

⇠⇢