Présentation de l’architecture des services Web Adobe Connect

Comprendre l’architecture des services Web Connect et découvrir le fonctionnement des API.

Les services Web Adobe® Connect™ constituent la couche de services Web au-dessus de la suite d’applications Adobe Connect Server.

Les services Web vous permettent de créer des portails ou des applications web qui intègrent les fonctionnalités et les informations des rapports Adobe Connect à des systèmes tiers tels que des portails, des systèmes de gestion de la relation client et des systèmes de planification des ressources d’entreprise.

Les services Web Adobe Connect fournissent des fonctionnalités de réunion, de formation et d’événements à vos applications par le biais de son API XML.
Les services Web Adobe Connect fournissent des fonctionnalités de réunion, de formation et d’événements à vos applications par le biais de son API XML.

Par exemple, vous pouvez utiliser un système central de gestion des utilisateurs, par exemple un annuaire LDAP, Microsoft Active Directory ou un autre système tiers, qui fait partie intégrante de vos processus d’entreprise.

Les services Web vous permettent d’écrire une application qui synchronise les utilisateurs entre votre système et Adobe Connect. L’application peut utiliser la plate-forme J2EE ou une autre technologie de votre choix pour extraire une liste d’utilisateurs de l’annuaire, la comparer à une liste d’utilisateurs Adobe Connect, puis effectuer les mises à jour demandées dans le référentiel d’utilisateurs Adobe Connect, comme l’ajout ou la suppression d’utilisateurs ou de groupes.

Flux de données

Les flux de données entre les applications clientes et Adobe Connect sont présentés dans le diagramme suivant. Les applications personnalisées que vous écrivez utilisent les chemins 1 à 2 et A à B. Les applications Adobe Connect (par exemple Adobe Connect Meeting, Adobe Connect Training ou Adobe Connect Events) peuvent utiliser n’importe lequel des chemins de flux de données.

Le flux de données entre Adobe Connect et les applications clientes.
Le flux de données entre Adobe Connect et les applications clientes.

Le flux de données peut être chiffré avec SSL ou non chiffré.

Non chiffré

Si le flux de données n’est pas chiffré, les connexions passent par HTTP et Adobe Real Time Messaging Protocol (RTMP), et empruntent les chemins décrits dans le tableau suivant.

Numéro de diagramme

Description

1

Le navigateur Web du client demande une réunion Adobe Connect ou l’URL d’un contenu sur le port HTTP:80 (les chemins de connexion peuvent varier).

2

Le serveur Web répond et transfert le contenu ou fournit au navigateur du client les informations nécessaires pour accéder à Adobe Connect.

3

L’application de bureau Adobe Connect demande une connexion à Adobe Medium Server sur RTMP:1935 et HTTP:80.

4

Adobe Media Server répond, et une connexion permanente est ouverte pour transmettre en streaming le trafic de la réunion vers le navigateur.

3a (variante)

Dans certains cas, l’application de bureau Adobe Connect demande une connexion à Adobe Media Server, mais ne peut obtenir qu'une connexion par tunnel par RTMPT:80.

4a (variante)

Adobe Media Server répond, et une connexion par tunnel est ouverte pour transmettre en streaming le trafic de la réunion vers le navigateur.

Chiffré

Si le flux de données est chiffré, les connexions passent de manière sécurisée par HTTPS et RTMPS (Real Time Messaging Protocol over SSL), comme suit.

Numéro de diagramme

Description

A

Le navigateur Web du client demande une réunion ou l’URL d’un contenu de manière sécurisée via une connexion chiffrée par HTTPS:443 (les chemins de connexion peuvent varier).

B

Le serveur Web/d’application répond par un transfert de contenu chiffré, ou fournit au client les informations nécessaires pour établir une connexion chiffrée avec Adobe Connect.

C

L’application de bureau Adobe Connect demande une connexion chiffrée à Adobe Medium Server par RTMP:1935.

D

Adobe Media Server répond, et une connexion permanente est ouverte pour transmettre en streaming le trafic de la réunion vers le navigateur.

Applications personnalisées

Les services Web Adobe Connect fournissent une API XML. Votre application doit donc pouvoir communiquer avec Adobe Connect en utilisant XML par HTTP ou XML par HTTPS. Votre application appelle l’API en construisant une URL de demande et en lui transmettant un ou plusieurs paramètres, soit sous forme de paires nom/valeur, soit sous forme d’un document XML. Les services Web renvoient une réponse XML, dont vous pouvez extraire les valeurs.

Les applications personnalisées récupèrent les métadonnées de la base de données Adobe Connect. Ces métadonnées incluent les noms et heures des réunions ou des cours, les URL des salles de réunion, les URL du contenu et les informations sur les rapports.

Le flux de données d’une application personnalisée qui récupère les métadonnées de la base de données va du navigateur Web du client au serveur d’applications Web du client, en passant par l’API XML, le serveur d’applications Web Adobe Connect et la base de données SQL, et vice-versa.

Le flux de données entre une application personnalisée et Adobe Connect fonctionne comme suit :

  1. Un utilisateur accède à votre application personnalisée depuis un navigateur Web.

  2. L’application appelle l’API XML par HTTP:80 ou HTTPS:443.

  3. Le serveur d’applications Web Adobe Connect autorise l’application et ses utilisateurs, extrait les métadonnées de la base de données SQL, puis renvoie les métadonnées.

  4. Côté client, votre serveur Web ou d’application, votre analyseur XML et vos bibliothèques logicielles traitent la réponse, puis la renvoient à votre application.

  5. L’utilisateur continue à travailler dans votre application personnalisée et clique sur l’URL d’une réunion ou d’un contenu. À ce stade, l’utilisateur accède à une application Adobe Connect pour rejoindre une salle de réunion, et le flux de données classique entre une application Adobe Connect et le serveur commence.

Applications Adobe Connect

Les applications Adobe Connect appellent le serveur à l’aide de la même API XML de services Web que celle que vous utilisez à partir d’une application personnalisée.

En général, le contenu est transporté par le port HTTP 80 ou le port HTTPS 443. Le contenu inclut les diapositives, pages HTTP, fichiers SWF et fichiers transférés via le module FileShare. Il s’agit des numéros de port par défaut que vous pouvez configurer (voir Migration, installation et configuration d’Adobe Connect Server pour plus de détails).

Les communications diffusées en continu et en temps réel provenant d'Adobe Media Server sont transmises par le port RTMP 1935. Les communications diffusées en continu incluent l’audio, la vidéo (webcam et FLV), le partage de fichiers, et le chat. L’état de la réunion est également géré par le port RTMP 1935.

Composants d’Adobe Connect

Adobe Connect est conçu avec deux composants serveur, et chaque serveur utilise une base de données SQL.

Le serveur d’application Web

Le serveur d’applications Web est l’élément central d’Adobe Connect. Il contient et exécute toute la logique nécessaire pour fournir du contenu aux utilisateurs. Il gère le contrôle d’accès, la sécurité, les quotas et les licences, ainsi que les fonctions de gestion comme la mise en cluster, le basculement et la réplication.

Le serveur d’applications Web gère également Adobe Connect Central, l’application par laquelle vous visualisez et gérez le contenu et les utilisateurs de votre entreprise, lorsque vous n'utilisez pas une application personnalisée ni un système tiers intégré. Les métadonnées décrivant le contenu et les utilisateurs peuvent être stockées dans une ou plusieurs bases de données SQL répliquées. Le serveur d’applications Web est sans état, ce qui signifie que la mise à l’échelle est presque linéaire.

Adobe Media Server

Adobe Media Server diffuse des contenus audio, vidéo et multimédia à l’aide du protocole RTMP. Lorsqu’il s’agit d’enregistrer et de diffuser une réunion, de synchroniser l’audio et la vidéo ou de convertir et d’empaqueter du contenu pour le partage d’écran en temps réel, Adobe Media Server s’occupe de tout.

Adobe Media Server joue également un rôle central dans la réduction de la charge du serveur en mettant en cache les pages Web fréquemment visitées, les flux continus et les données partagées.

La base de données SQL

Adobe Connect utilise la base de données Microsoft SQL Server pour le stockage permanent des métadonnées transactionnelles et d’application, y compris les informations sur les utilisateurs, les groupes, le contenu et les rapports. L’API XML récupère les métadonnées stockées dans la base de données. La base de données peut être implémentée soit avec Microsoft SQL Server Desktop Engine (MSDE), soit avec la version complète de Microsoft SQL Server 2005.

Effectuer votre premier appel d’API

Les services Web Adobe Connect utilisent un cadre servlet pour traiter les demandes de l’API XML. Dans le diagramme de flux de données, le cadre servlet est représenté par le composant API. Le servlet API reçoit les demandes XML des clients et renvoie les réponses XML du serveur d’applications Web et de la base de données.

Une demande adressée à l’API XML est formatée comme une URL de demande HTTP que le servlet API traite. Une URL de demande comporte un nom d’action et des paramètres dans des paires nom/valeur, comme ceci :

 https://example.com/api/xml?action=sco-info&sco-id=2006334909

Si vous avez accès à un compte Adobe Connect dans lequel vous pouvez tester les appels API, vous pouvez tester ces appels. En fait, Adobe recommande de tester les appels API dans le navigateur pendant que vous apprenez l’API et écrivez des applications.

Avant de commencer, il est utile d’installer un outil vous permettant de visualiser les en-têtes de demande et de réponse HTTP dans votre navigateur.

Appel à common-info dans un navigateur

  1. (Facultatif) Activez un outil pour afficher les en-têtes HTTP dans votre navigateur.

  2. Ouvrez un navigateur et accédez à votre page de connexion Adobe Connect.

  3. Sans vous connecter, supprimez la partie de l’URL après le nom de domaine, puis ajoutez un appel à common-info :

     https://example.com/api/xml?action=common-info

    La réponse de common-info vous fournit des informations sur votre session avec le serveur, en particulier le cookie qui identifie votre session :

     <?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?> <results> <status code=&quot;ok&quot; /> <common locale=&quot;en&quot; time-zone-id=&quot;85&quot;> <cookie>breezbryf9ur23mbokzs8</cookie> <date>2008-03-13T01:21:13.190+00:00</date> <host>https://example.com</host> <local-host>abc123def789</local-host> <url>/api/xml?action=common-info</url> <version>connect_700_r641</version> <user-agent> Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) </user-agent> </common> </results>

    Lorsque vous connectez un utilisateur à partir d’une application, vous devez renvoyer la valeur du cookie au serveur pour identifier la session de l’utilisateur (voir Se connecter à partir d’une application).

Appel à principal-list dans un navigateur

Une fois que vous recevez la valeur de cookie BREEZESESSION de common-info, le navigateur l’ajoute à l’en-tête de la demande lors de votre prochaine demande.

  1. Dans un navigateur Web, connectez-vous à Adobe Connect. Modifiez l’URL du navigateur pour appeler principal-list :

     https://example.com/api/xml?action=principal-list
  2. Vérifiez l'en-tête de la demande. Cette fois-ci, il renvoie la valeur de cookie BREEZESESSION au serveur :

     GET /api/xml?action=principal-list HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: example.com Connection: Keep-Alive Cookie: BREEZESESSION=breezbryf9ur23mbokzs8
  3. Vérifiez la réponse, qui répertorie tous les principaux sur le serveur, chacun dans son propre élément principal.

     <?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?> <results> <status code=&quot;ok&quot; /> <principal-list> <principal principal-id=&quot;624526&quot; account-id=&quot;624520&quot; type=&quot;user&quot; has-children=&quot;false&quot; is-primary=&quot;false&quot; is-hidden=&quot;false&quot;> <name>joe harrison</name> <login>jharrison@example.com</login> <email>jharrison@example.com</email> </principal> <principal principal-id=&quot;624550&quot; account-id=&quot;624520&quot; type=&quot;user&quot; has-children=&quot;false&quot; is-primary=&quot;false&quot; is-hidden=&quot;false&quot;> <name>bob jones</name> <login>bjones@example.com</login> <email>bjones@example.com</email> </principal> ... </principal-list> </results>

Ajout de filtres et de tris

De nombreuses actions de l’API vous permettent d’ajouter un filtre pour ne renvoyer que certains éléments de réponse, ou un tri pour afficher les éléments de réponse dans un certain ordre.

Un filtre est un paramètre spécial qui commence par le mot-clé filter, suivi d’un modificateur facultatif, puis d’un nom de champ et d’une valeur. Voici tous les exemples de filtres :

  • filter-name=jazz doe (qui correspond aux résultats avec le nom exact jazz doe)

  • filter-like-name=jazz (qui correspond à tous les résultats dont le nom contient jazzin)

  • filter-out-type=user (qui renvoie tous les résultats dont le type n’est pas user)

Il ne s’agit que de quelques types de filtre, et vous en trouverez d’autres dans filter-definition. Vérifiez une action dans la référence (dans Référence de l’action) pour voir si sa réponse peut être filtrée. En général, si une action autorise les filtres, vous pouvez les utiliser sur n’importe quel élément ou attribut de la réponse.

Un tri est un autre paramètre spécial qui commence par le mot-clé sort (ou sort1 ou sort2), suivi d’un nom de champ, puis d’un des mots-clés asc ou desc, par exemple :

  • sort-name=asc (pour trier dans l’ordre croissant par name)

  • sort-group-id=desc (pour trier dans l’ordre décroissant par group-id)

Ce ne sont que quelques exemples. Vous pouvez tester les tris dans le navigateur ou consulter sort-definition pour plus d’informations.

Passer un appel avec un filtre et un tri

  1. Appelez à nouveau principal-list, en affichant uniquement les groupes et en les triant par ordre alphabétique selon leur nom :

     https://example.com/api/xml?action=principal-list&filter-type=group &sort-name=asc
  2. Pour renforcer la réponse, choisissez un groupe dans la liste, puis filtrez selon son nom :

     https://example.com/api/xml?action=principal-list&filter-name=developers

    Cette fois, un seul groupe est renvoyé :

     <?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?> <results> <status code=&quot;ok&quot; /> <principal-list> <principal principal-id=&quot;2007105030&quot; account-id=&quot;624520&quot; type=&quot;group&quot; has-children=&quot;true&quot; is-primary=&quot;false&quot; is-hidden=&quot;false&quot;> <name>developers</name> <login>developers</login> </principal> </principal-list> </results>

Où aller maintenant ?

À ce stade, vous pouvez continuer à tester les appels dans le navigateur et à observer leur fonctionnement. Il s’agit du meilleur moyen, et le plus simple, d’apprendre l’API XML. Pour plus d’informations, consultez l’une des sources suivantes :

  • Référence de l’API dans Référence de l’action.

  • Login and requests (Connexion et demandes) pour obtenir des informations sur la façon de connecter des utilisateurs à partir d’applications.

  • Basics (Concepts de base) pour apprendre les trois concepts de base qui sous-tendent l’API

  • Meetings (Réunions) si vous souhaitez créer et gérer des réunions à partir d’une application.

  • Training (Formation) si vous créez une application de formation.

 Adobe

Recevez de l’aide plus rapidement et plus facilement

Nouvel utilisateur ?