Aperçu Cisco Webex Meetings des mises à jour API (API 41)

Pour plus d’informations sur l’API XML 39 et l’API XML 11, consultez le Présentation des mises à jour de l’API XML de Cisco Webex Meetings (API XML 39 et versions antérieures).

Pour plus d’informations sur l’API 40 XML, consultez le document Présentation des mises à jour de l’API XML Cisco Webex Meetings (API 40 et versions ultérieures).

Pour les mises à jour pour l’API XML 11 SP9 et version précédente, allez à Cisco DevNet.

Mises à jour de l’API XML 41.12.0

Cliquez ici pour télécharger le schéma XML API 41.12.0.

XMLAPI bloquera la programmation Webex Events (Classique) et la modification en fonction de l'élément de configuration du site d'EnableClassicEvent qui est faux

API et changements de schémas impactés

Dans la page de configuration de l’administration du site, si la case Activer l’événement classique est erronée, ce site ne Webex Events plus en charge les réunions (classiques).

Si la case Activer l’événement classique est erronée, vous appelez ces API pour Webex Events réunion (classique) :

CreateEvent, SetEvent, GetEvent, GetSessionInfo, LstsummaryEvent, LstrecordedEvent, LstsummaryProgram, UploadEventImage

L'API répondra à la nouvelle exception 010106 L'événement classique a été désactivé.

Changements de schémas

Aucun changement de schéma.

Exemple de demande et de réponse API

Demande et réponse de l'API CreateEvent

Demande de Créer un événement

XXXXXXXX


XMLAPI EC Testing


17/07/2021 01:29:15
15

Réponse de Créer un événement

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>FAILURE</serv:result>
<serv:reason>L'Événement classique a été désactivé.</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>

CréerEvent3.1.3 Affecter les API :

• Configurer l'événement GetEvent

• Obtenir les détails de lassion

• Événement LstsummaryEvent

• ÉvénementLstenregistré

• Dernier résumé du programme

• Charger l’image de l’événement

XMLAPI LstMeetingType sera responsable du nouvel élément du subProductCodePrefix

API impactées

Mettez à jour l'élément de réponse API LstMeetingType de productionCodePrefix : PRO, AUO et autres qui sont des préfixes de type réunion Webex.

Après cette nouvelle amélioration, l'API répondra à un nouvel élément de subProdctCodePrefix:PRO1, PRO2, etc. qui peut être personnalisé de type meet prefix.

Modifications du schéma sur l’API : TypeRéunionLst

Il répondra au nouvel élément : PréfixeCodeProdct

Exemple de demande et de réponse API

Demande et réponse de l'API LstMeetingType

Demande de LstMeetingType

13810

Réponse de LstMeetingType

<serv:bodyContent xsi:type="mtgtype:lstMeetingTypeResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mtgtype:matchingRecords>
<serv:total>1</serv:total>
<serv:returned>1</serv:returned>
<serv:startFrom>1</serv:startFrom>
</mtgtype:matchingRecords>

<mtgtype:productCodePrefix>PRO</mtgtype:productCodePrefix>
<mtgtype:subProductCodePrefix>PRO3</mtgtype:subProductCodePrefix> //Nouvel élément pour type de réunion personnalisé
<mtgtype:active>ACTIVATED</mtgtype:active>
<mtgtype:name>Cus_Chat_Closed</mtgtype:name>
<mtgtype:displayName>Cus_Chat_Closed</mtgtype:displayName>

Mises à jour de l’API XML 41.11.0

Cliquez ici pour télécharger le schéma XML API 41.11.0.

Prise en charge XML API faire suivre la compatibilité dans l’API de gestion des utilisateurs pour les sites gérés par Control Hub

API et changements de schémas impactés

Si votre application d’intégration utilise actuellement des API de gestion des utilisateurs XMLAPI Webex : CreateUser, SetUser, DelUser et GetUser pour provisionner ou gérer les utilisateurs, après que votre site Webex classique ait été converti en site géré par Control Hub, ces API continueront à fonctionner pour la compatibilité directe. Il y a quelques changements de comportement comme indiqué ci-dessous :

• Lors de l’utilisation de créerUtilisez - si le statut de l’utilisateur dans Control Hub n’est pas « actif » alors le statut de l’utilisateur sur le site ne sera pas actif. Si le statut de l’utilisateur dans Control Hub est actif , alors le statut de l’utilisateur sur le site est également actif, référence : Statut des utilisateurs nouveaux et convertis dans Control Hub.

• L’élément du mot de passe des API Créer un utilisateur et Configurer un utilisateur sera ignoré, nous commençons à envoyer un courrier électronique d’activation aux nouveaux utilisateurs, les utilisateurs peuvent cliquer sur le lien dans le courrier électronique pour saisir un nouveau compte actif et saisir un nouveau mot de passe.

• L'élément actif de l' API CreateUser sera ignoré, le nouvel utilisateur (non vérifié) ne peut pas être activé via ce paramètre en utilisant l'API SetUser.

• La valeur de l’élément webExId dans le corpsContent des API Créerutiliseur doit être identique à l’adresse électronique. Si webExId est différent du courrier électronique, nous traiterons le webExId comme le courrier électronique lors de son stockage dans WebDB et la valeur sera ignorée.

• La valeur de l'élément webExId dans le bodyContent des APIs SetUser doit être l'identité utilisateur de l'adresse électronique, vous pouvez la modifier en utilisant <email> dans bodyContent.

• L’API Configurer l’utilisateur prendra en charge la modification de l’adresse électronique de l’utilisateur existant : c’est un succès si le compte d’opération dans SécuritéContexte est l’administrateur complet du site de Control Hub. Sinon, l’API signale une erreur avec le nouveau code d’erreur et le nouveau message ci-dessous :

  • 030120 Le compte doit être un administrateur de site complet pour changer d'adresse électronique.

• L’élément nouveauWebExId dans le corpsContent de l’API SetUser sera ignoré.

• L’API Configurer l’utilisateur tente de changer en une adresse électronique qui est déjà en cours d’utilisation, l’API place sous le nouveau code d’erreur et le message d’erreur :

  • 030118 L’adresse électronique est déjà utilisée dans les sites gérés par Control Hub.

• L’API DelUser désactive l’utilisateur du côté de la réunion Webex et la licence de réunion correspondante est supprimée du site Webex. Cet utilisateur désactivé peut être réactivé en utilisant l’API : SetUser (ACTIVATED) tant que l'utilisateur est vérifié auparavant.

• Les API Créerutilneur et Configurer l’utilisseur envoient un nouveau code d’erreur et un message d’erreur comme démontré ci-dessous :

  • 030117, cet utilisateur existe en dehors de votre organisation, il doit donc être réclamé, pour se déplacer dans votre organisation via le processus de réclamation de l’utilisateur. Pour les étapes à suivre pour revendiquer l’utilisateur dans votre organisation, voir Demander aux utilisateurs de prendre part à votre organisation (Convertir les utilisateurs). Vous devez vérifier le domaine à quel l’utilisateur appartient avant de réclamer l’utilisateur.

  • 030119 Le jeton d’accès CI doit inclure le périmètre webexsquare : admin lors de l’approvisionnement de l’utilisateur.

Changements de schémas

Aucun changement de schéma sur ces API : CreateUser, SetUser, DelUser et GetUser.

Exemple de demande et de réponse API

Demande et réponse de l'API CreateUser

Demande d'API :
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:serv="http://www.webex.com/schemas/2002/06/service"
xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service http://www.webex.com/schemas/2002/06/service/service.xsd">

<securityContext>
<siteName>{siteName}</siteName>
<webExID>{site Admin account}</webExID>
<email>{compte Admin du site}</email>
<sessionTicket>xxxx</sessionTicket> ou ou
ou , lors de l'utilisation de CI « accessToken », il doit inclure la portée webexsquare:admin lors du provisionnement de l'utilisateur
</securityContext>




<corps>
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/></head><bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
<webExId>Jack@qa.webex.com</webExId> --- il doit s'agir de l'identité de l'utilisateur de l'adresse électronique
<email>Jack@qa.webex.com</email>
<firstName>Jack</firstName>
<lastName>Smith</lastName>
<password>...</password>
<privilège>
<host>true</host>
</privilège>
<active>ACTIVATED</active> ---ce paramètre ne peut pas activer l'utilisateur directement jusqu'à ce que l'utilisateur s'active lui-même via un courrier électronique d'activation.
</bodyContent>
</corps>


Exemple de réponse API :
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:use="http://www.webex.com/schemas/2002/06/service/user">
<serv:en-tête>
<serv:réponse>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="use:createUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<use:userId>23778617</use:userId>
</serv:bodyContent>

Affecter les API :

• Createuser

• Setuser

• DelUser (Utiliseur)

L’API XML prend en charge la compatibilité de ascendant d’authentification des utilisateurs existants après la conversion du site classique Webex en site géré par Control Hub

API impactées

Une fois le site Webex classique converti en site géré par Control Hub, la valeur de l’élément dans doit être identique à l’adresse électronique, détails ci-dessous :

• Pour les utilisateurs existants créés dans le site Classique de Webex, nous prenons en charge à la fois les anciens services webExID (Par exemple : Jack) et le nouvel ID WebEx (le contenu est le même que la messagerie électronique, exemple : Jack@xx.com) pour se connecter, cette compatibilité ascendante de l’authentification est pour toutes les API XML.

• Pour les nouveaux utilisateurs créés dans les sites gérés par Control Hub, la valeur de l’élément webExID doit être identique à l’adresse électronique pour la connexion.

{siteName}
{userName} --- les utilisateurs existants ont été créés sur le site classique webEx, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
xxxx ou ou ou

Affecter les API :

Toutes les API XML.

Après la conversion du site Webex classique en un site géré par Control Hub, la valeur de l’élément <bodyContent> doit être identique à l’adresse électronique, détails ci-dessous :

• Pour les utilisateurs existants créés sur le site Webex classique, nous prenons en charge les deux anciens webExId(par ex. : Jack) et le nouveau webExId (le contenu est le même que la messagerie électronique, par exemple : Jack@xx.com) dans corpsContent.

• Pour les nouveaux utilisateurs créés dans les sites gérés par Control Hub, la valeur de l’élément webExId doit être identique à celle de l’adresse électronique dans bodyContent.

xxxx --- les utilisateurs existants ont été créés dans le site webEx classique, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com

Affecter les API : GetUser, SetUser et DelUser.

Changements de schémas

Aucun changement de schéma sur les API.

Exemple de demande et de réponse API

Demande et réponse API GetUser

Requête API :
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:serv="http://www.webex.com/schemas/2002/06/service"
xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service http://www.webex.com/schemas/2002/06/service/service.xsd">


<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- les utilisateurs existants ont été créés dans le site classique webEx, cela peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
xxxx ou ou ou




xxxx --- les utilisateurs existants ont été créés sur le site classique webEx, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com




Exemple de réponse de l'API :
...comme avant

Amélioration de l’API du rapport d’affichage de l’enregistrement à prendre en charge dans Webex Meetings, Webex Events (Nouveau) et Webex Events (Classique)

API impactées

API actuelle : lstrecordaccessHistory et lstrecordaccessDetailHistory ne prennent en charge que le rapport d'historique consulté sur les enregistrements Webex Trainings. La nouvelle amélioration prend en charge l Webex Meetings, Webex Events (nouveau) et l’affichage Webex Events d’enregistrement (classique) accès à l’historique rapport également.

Changements de schémas

Nous ons en charge ci-dessous le nouveau schéma dans l’API lstrecordaccessHistory dans le corps de la requête de l’API :

MeetingCenter
TrainingCenter
EventCenter

Détails

L’API : lstrecordaccessHistory permet de restituer l’historique des accès aux enregistrements pour Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.

• S'il n'y a aucun serviceType spécifié dans la demande de l'API, l'API de lstrecordaccessHistory renvoie uniquement l'historique des vues d'enregistrement de Webex Trainings.

• Lorsque le serviceType est MeetingCenter, l'API de lstrecordaccessHistory renvoie à la fois l'historique des vues d'enregistrement Webex Meetings et Webex Events (nouvelle).

• Lorsque le serviceType est EventCenter, l'API de lstrecordaccessHistory renvoie l'historique d'accès à l'enregistrement Webex Events (classique).

L’API : lstrecordaccessDetailHistory peut renvoyer les détails par recordID de Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.

Exemple de demande et de réponse API

lstrecordaccessHistory Demande et réponse de l'API

<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>

<corps>

<viewTimeScope>
<viewTimeStart>20/09/2021 00:00:00</viewTimeStart>
<viewTimeEnd>28/09/2021 23:59:59</viewTimeEnd>
</viewTimeScope>
<listControl>
<startFrom>1</startFrom>
<maximumNum>100</maximumNum>
</listControl>

<orderBy>RECORDID</orderBy>
<orderAD>ASC</orderAD>
</commander>

<serviceType>Centre de réunions</serviceType>
<serviceType>Centre de formation</serviceType>
<serviceType>EventCenter</serviceType>





<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:history="http://www.webex.com/schemas/2002/06/service/history">
<serv:en-tête>
<serv:réponse>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="history:lstrecordaccessHistoryResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>Test LstrecordaccessHistory TC-20210924 1324-1</history:recordName>
<history:creationTime>24/09/2021 13:28:13</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>2</history:downloaded>
<history:seen>1</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>TestErollment_001-20210610 1905-1</history:recordName>
<history:creationTime>10/06/2021 19:10:15</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:seen>3</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>Tester la lecture instantanée 2-20210705 0709-1</history:recordName>
<history:creationTime>07/05/2021 07:15:06</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:seen>1</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>EC2.0_232423-20210922 0447-1</history:recordName>
<history:creationTime>22/09/2021 04:53:05</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:seen>1</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>Test LstrecordaccessHistory EC2.0-20210924 1315-1</history:recordName>
<history:creationTime>24/09/2021 13:19:00</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:seen>1</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>Test LstrecordaccessHistory MC-20210924 1319-1</history:recordName>
<history:creationTime>24/09/2021 13:25:12</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:seen>1</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test EC classic-20210924 1331-1</history:recordName>
<history:creationTime>24/09/2021 13:37:28</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:seen>1</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:matchingRecords>
<serv:total>8</serv:total>
<serv:returned>7</serv:returned>
<serv:startFrom>1</serv:startFrom>
</history:matchingRecords>
</serv:bodyContent>

lstrecordaccessDetailHistory Demande et réponse de l'API

<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:serv="http://www.webex.com/schemas/2002/06/service">

<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>

<corps>
<bodyContent xsi:type=
"java:com.webex.service.binding.history.LstrecordaccessDetailHistory">
<recondID>1XXXXXX7</recondID>
<timeZoneID>20</timeZoneID>

</corps>


<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:history="http://www.webex.com/schemas/2002/06/service/history">
<serv:en-tête>
<serv:réponse>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="history:lstrecordaccessDetailHistoryResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<history:recordDetail>
<history:viewID>1XXXXXX7</history:viewID>
<history:participantName>Axxxg</history:participantName>
<history:participantEmail>Axxxg@qa.webex.com</history:participantEmail>
<history:accessTime>24/09/2021 13:27:26</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>false</history:downloaded>
<history:seen>true</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordDetail>
<history:recordDetail>
<history:viewID>1XXXXXX7</history:viewID>
<history:participantName>Axxxg</history:participantName>
<history:participantEmail>Axxxg@qa.webex.com</history:participantEmail>
<history:accessTime>24/09/2021 13:27:39</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>true</history:downloaded>
<history:seen>false</history:seen>
<history:timeZoneID>20</history:timeZoneID>
</history:recordDetail>
<history:matchingRecords>
<serv:total>2</serv:total>
<serv:returned>2</serv:returned>
<serv:startFrom>1</serv:startFrom>
</history:matchingRecords>
</serv:bodyContent>

Affecter les API :

• lstrecordaccessHistorique

• lstrecordaccessDetailHistory

Corrigez le trou de la longueur maximum de la description Webex Events (Classique) entre XMLAPI et la page Webex.

API impactées

L’API XML : L'élément de description de CreateEvent et de SetEvent permet d'entrer un maximum de 10 000 caractères. Si l'entrée est supérieure à la taille, le nouveau code d'erreur et le nouveau message s'afficheront :

060068 description de saisie illégale. Cette description ne peut pas dépasser 1 000 caractères.

Changements de schémas

Aucun changement de schéma.

Exemple de demande et de réponse API

Demande et réponse de l'API CreateEvent

#Exemple de demande d'API :
...

<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent"
xmlns:att="http://www.webex.com/schemas/2002/06/service/event" xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service/event http://www.webex.com/schemas/2002/06/service/event/event.xsd">
<accessControl>
<sessionPassword>111111</sessionPassword>
<listing>PRIVATE</listing>
</accessControl>
<metaData>
<sessionName>test EC</sessionName>
<description>.......</description>
</metaData>
...


------------------------------------
#Exemple de réponse de l'API lorsque la description dépasse 10 000 caractères :

<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">


<serv:result>FAILURE</serv:result>
Description de saisie illégale. La description ne peut pas dépasser 10 000 caractères
PRIMARY
060068

Affecter les API :

• Créer un événement

• Configurer l’événement

API XML : GetUser renvoie un nouvel élément de compte gratuit

API impactées

GetUser renvoie un nouvel élément qui identifiefreeAccount le compte utilisateur est FreeAccount ou non.

Changements de schémas

Obtenir l’exemple de réponse De l’utilneur

GetUser response:
AW
false

3
false

Affecter les API :

Obtenir l’utilateur

Mises à jour de l’API XML 41.9.0

Cliquez ici pour télécharger le schéma de l’API XML 41.9.0.

Décommission XML API 10.0.0 pour tous les sites T31

Webex envisage de mettre fin à la prise en charge de l’API XML ver 10.0.0 pour tous les sites T31.

Nous désémissionons le code XML API 10.0.0 de toutes les productions dans la mise à jour 41.9.0.

Mises à jour de l’API XML 41.8.0

Cliquez ici pour télécharger le schéma XML API 41.8.0.

Décommission XML API 10.0.0 pour tous les sites T31

Webex envisage de mettre fin à la prise en charge de l’API XML ver 10.0.0 pour tous les sites T31.

Webex a trouvé certains clients clients accédant à l’URL de l’API XML de façon incorrecte comme : https://{siteName}.webex.com/WBXService/xml10.0.0/XMLService, la bonne façon d’accéder à l’URL de l’API XML en tant que : https://{siteName}.webex.com/WBXService/XMLService.

Veuillez changer votre code d’accès API XML en utilisant le bon moyen pour éviter tout impact avant que nous ne évitions la prise en charge de L’API XML version 10.0.0.

Mises à jour de l’API XML 41.7.0

Cliquez ici pour télécharger le schéma XML API 41.7.0.

La suppression et la modification des enregistrements mobiles doivent être contrôlées par l’option d’administration du site : Autoriser les organisateurs à réattribuer, modifier, désactiver et supprimer des enregistrements

API et changements de schémas impactés

Obtenir le site : retournera de nouveaux éléments nommant enableNBRMCModify et separateNoRecordingEdit sous les outils.

Exemple de réponse

ObtenirRéponseSite :

Obtenir le site

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:ns1="http://www.webex.com/schemas/2002/06/service/site" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:en-tête>
<serv:réponse>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="ns1:getSiteResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<ns1:outils>
...
<ns1:enableNBRMCModify>false</ns1:enableNBRMCModify>
<ns1:separateNoRecordingEdit>true</ns1:separateNoRecordingEdit>
...
</ns1:tools>
</serv:bodyContent>

Mises à jour de l’API XML 41.6.3

Cliquez ici pour télécharger le schéma XML API 41.6.3.

GetSite Response nouvel élément de supportLargeEvent

API et changements de schémas impactés

Obtenir le site : renvoie de nouveaux éléments nommant supportLargeEvent sous siteCommonOptions pour indiquer à l'appelant si le site prend en charge Large Event (Webex Event (nouveau)) ou non.

Changement de schéma

Exemple de réponse

ObtenirRéponseSite :

Obtenir le site

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:ns1="http://www.webex.com/schemas/2002/06/service/site" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:en-tête>
<serv:réponse>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="ns1:getSiteResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<ns1:siteCommonOptions>
...
<ns1:enablePreMeetingLobby>false</ns1:enablePreMeetingLobby>
<ns1:supportLargeEvent>true</ns1:supportLargeEvent>
</ns1:siteCommonOptions>
</serv:bodyContent>

Mises à jour de l’API XML 41.6.0

Cliquez ici pour télécharger le schéma XML API 41.6.0.

La prise en charge de XMLAPI Webex Events 2.0 en approvisionnement

API impactées

GetUser : retourne un nouvel élément nommant largeEventCapacity qui indique la capacité du nouvel Event 2.0 (EC 2.0) sous ce compte utilisateur. Par exemple, si le compte utilisateur a une licence CI_EC3K, la valeur de largeEventCapacity est de 3000.

Changements de schémas

Exemple de réponse

Obtenir la réponse de l’utilneur :

L’heure de création de l’enregistrement XMLAPI LstRecording applique l’heure de démarrage de l’enregistrement

API impactées

LstEnregistrement : La réponse LstRecordingCreateTime est l'heure à laquelle l'utilisateur appuie réellement sur le bouton Enregistrer.

Détails

Dans le passé, l'API XML utilisait l'horodatage de la création de l'enregistrement dans la base de données comme heure de création dans la réponse LstRecording . C’est maintenant l’heure à partir de l’utilisateur qui démarre pour effectuer l’enregistrement. Cette modification s’applique à tous les enregistrements des services. Il n’y a aucun changement de schéma.

Mises à jour de l’API XML 41.5.0

Cliquez ici pour télécharger le schéma XML API 41.5.0.

XMLAPI a la possibilité de démarrer des réunions Webex programmées à partir de RTCP en tant qu’organisateur

API impactées

• Créer un utilisateur : génère le hostPIN que la salle de réunion personnelle (PMR) de l'utilisateur soit activée ou non lorsque le rôle de l'utilisateur est l'organisateur ou les administrateurs de site complets ou en lecture seule ou de gestion des utilisateurs.

• DéfinirUtilisateur : configure hostPIN en utilisant phones.hostPIN lorsque personalMeetingRoom.hostPIN n'est pas dans la requête XML (condition préalable : la bascule de fonctionnalité AllowStartScheduledMtgFromPhone est activée).

• GetUser : renvoie phones.hostPIN , que la salle de réunion personnelle (PMR) de l'utilisateur soit activée ou non. (condition préalable : la bascule de fonctionnalité AllowStartScheduledMtgFromPhoneest activée).

Changements de schémas

ObtenirRéponseUtilisateur :

DéfinirUtilisateur :

Exemple de réponse

ObtenirRéponseUtilisateur :

DéfinirUtilisateur :

Réponse XMLAPI GetSite : deux nouveaux éléments pour le client mobile

API impactées

• Obtenir le site : GetSite va maintenant répondre à deux nouveaux éléments pour prendre en charge la logique du client mobile pour afficher ou non l'onglet enregistrement.

  • enableRecordingAccess : vrai ou faux, les super administrateurs Webex peuvent activer ou désactiver l'accès à l'enregistrement à l'aide du bouton à bascule (EnableRecordingAccess).

  • storageEmptyStatus : vrai ou faux, si les deux sites ne prennent pas en charge la fonction NBR et ont attribué l'espace de stockage NBR à zéro, alors la réponse du statut est vrai, sinon est faux.

Changements de schémas

Exemple de demande pour GetSite

Exemple de réponse pour Getsite

Le sujet du courrier électronique qui a des caractères non ASCII sera encodé avec RFC2047. En cas de sujet de courrier électronique ASCII pur, il n’y a pas d’encodage

Il n’y a aucune conséquence sur une demande API, la charge utile des réponses, mais elle modifie le comportement du code électronique du sujet. Lorsque le sujet de l’adresse électronique qui a des caractères non ASCII sera encodé avec RFC2047. Il n’y a aucun encodage en cas de sujet de courrier électronique ASCII pur.

Changements de schémas

Il n’y a aucun changement de schéma.

Mises à jour de l’API XML 41.4.0

Cliquez ici pour télécharger le schéma XML API 41.4.0.

Créer un événement programmé Webex Events les paramètres par défaut au niveau du site lors de la tonalité d’entrée et de sortie

XMLAPI s’aligne avec la nouvelle logique actuelle pour contrôler les tonalités d’entrée et de sortie. Toutes les tonalités Webex Events été contrôlées par un paramètre différent dans l’administration du site. Dans GetSite , XMLAPI renvoie une entrée de champ supplémentaireExitToneEC pour indiquer la valeur. À l’origine, lorsque l’administrateur du site configurerait une tonalité par défaut, créer l’événement ne exploitait pas ce paramètre en appliquant la valeur par défaut XMLAPI.

API impactées

L’API XML : GetSite renvoie un nouvel élément entryExitToneEC pour indiquer la valeur.

L’API XML : La logique métier back-end CreateEvent, SetEvent, GetEvent lit la valeur de entryExitToneEC.

Changements de schémas

API XML : Obtenir un exemple de réponse sur le site :

<ns1 : valeurs par défaut>
<ns1:emailReminders>true</ns1:emailReminders>
<ns1:entryExitTone>ANNOUNCENAME</ns1:entryExitTone>
<ns1:entryExitToneEC>NOTONE</ns1:entryExitToneEC>
<ns1:voip>true</ns1:voip>
<ns1:téléconférence>
<ns1:telephonySupport>AUCUN</ns1:telephonySupport>
</ns1:téléconférence>
<ns1:joinTeleconfNotPress1>true</ns1:joinTeleconfNotPress1>
<ns1:updateTSPAccount>false</ns1:updateTSPAccount>
</ns1:defaults>

Affecter les API :

• Obtenir le site

• Créer un événement

• Configurer l’événement

• Obtenir un événement

XMLAPI renvoie uniquement les informations détaillées sur les événements de grande taille (Webex Event 2.0)

1. Si la réunion Webex est un grand événement ou une diffusion Web, GetSessionInfo renvoie certaines informations détaillées incluant le mot de passe de la réunion, le mot de passe numérique de la réunion, le mot de passe du panéliste et le mot de passe numérique du panéliste (aucun schéma ne doit être modifié).

2. XMLAPI ne prend pas en charge la création et la modification des fonctionnalités d’événements de grande taille ou d’émission Web, donc Créerréeting et Configurer la réunion renvoyent une nouvelle exception (110064, le type d’événement et de session webcast ne sont pas pris en charge.) pour les événements de grande taille ou les cas de webcast.

API de l’impact

Mises à jour de l’API XML 41.3.0

Cliquez ici pour télécharger le schéma XML API 41.3.0.

Les nouveaux changements de l’API XML Webex Events fonction 2.0

API impactées

Les DEUX API : GetSessionInfo et GetMeeting éléments de retour enableEvent et enableWebniar également.

Changements de schémas

GetSessionInfo renvoie les éléments enableEvent et enableWebniar pour EC 2.0.

GetMeeting renvoie les éléments enableEvent et enableWebniar pour EC 2.0.

Modèle de réponse :

Réponse de GetSessionInfo :

PUBLIC
false
true
false
false
false
false
true

Réponse de GetMeeting :

false
true
true
true
false
false
true

Les nouveaux changements XMLAPI supportent la fonctionnalité de lobby d’avant réunion

API impactées

L’API XML : GetSite, LstSummarySession, GetSessionInfo et GetMeeting répondront au nouvel élément enablePreMeetingLobby pour le lobby de pré-réunion.

Changements de schémas

L’API XML : GetSite renvoie l'élément enablePreMeetingLobby pour le lobby de pré-réunion.

L’API XML : LstSummarySession renvoie l'élément enablePreMeetingLobby pour le lobby de pré-réunion.

L’API XML : GetSessionInfo renvoie l'élément enablePreMeetingLobby pour le lobby de pré-réunion.

L’API XML : GetMeeting renvoie l'élément enablePreMeetingLobby pour le lobby de pré-réunion.

Modèle de réponse :

Réponse de GetSite :

false
false
false
true
true
true
true
false
true
true

Réponse de LstSummarySession :

false
true
0
false
false
false
true

Réponse de GetSessionInfo :

PUBLIC
false
true
false
false
false
false
true

Réponse de GetMeeting :

false
true
true
true
false
false
true

L'API XML GetSite response Information change behavior disclose

API impactées

L’API XML : GetSite uniquement les éléments de réponse ci-dessous pour le compte administrateur, qui comprennent les rôles : SiteAdmin, RO_SiteAdmin et UserAdmin.

...
...
...
...
...
...
...
...

Comportement modifié

Autoriser uniquement le rôle d'administrateur a des données de licence de réponse de GetSite. L’organisateur ou l’invité ne recevra pas ces données de licence dans la réponse Obtenir le site.

Voici l’API : Exemple de réponse de GetSite pour siteadmin ou siteadmin prêt uniquement ou administrateur de gestion des utilisateurs :

Mises à jour de l’API XML 41.2.0

Cliquez ici pour télécharger le schéma XML API 41.2.0.

XMLAPI doit prendre en charge SRC hybride VOIP si le site prend en charge la téléphonie Webex

API impactées

• GetSite renvoie un nouvel élément IsWebexTelephony dans la réponse.

• CreateUser et SetUser peuvent mettre à jour l'élément cmrHybridVoip si IsWebexTelephony est vrai avec d'autres conditions. IsTSPUsingTelephonyAPI n'est plus conséquente.

Changements de schémas

API XML : La réponse GetSite renvoie un élément supplémentaire IsWebexTelephony

La réponse GetSite inclut ce nouvel élément :

true
false
Numéro de conférence personnelle
Code d'accès invité
Code d'accès organisateur
ID invité

.....

LstSummarySession prend en charge EC2.0

Les API XML doivent être impactées

LstSummarySession renverra deux nouveaux éléments pour prendre en charge EC 2.0

Changements de schémas

API XML : SessionRésumé : Ajouter les éléments <enableEvent> et <enableWebniar>

Réponse de l’API XML : DernierSummarySession

Réponse pour EC 2.0

true

0
false
true
true

XMLAPI prend en charge pour renvoyer l’option de l’assistant vocal Webex de l’utilisateur du site pour l’intégration MCT

APIs affectées

GetUser renvoie un nouvel élément webexAssistantEnabled (vrai ou faux) dans la réponse.

Changements de schémas

getUserResponse :

Exemple de réponse