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 d’API XML 11 SP9 et des versions antérieures, rendez-vous sur Cisco DevNet.

Mises à jour XML API 41.12.0

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

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

Modifications des API et du schéma concernées

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

Si la case à cocher Activer classicEvent est fausse, vous appelez ces API pour faire fonctionner la réunion Webex Events (classique) :

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

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

Modifications du schéma

Aucun changement de schéma.

Exemple de requête et de réponse API

Créer un événement Demande et réponse de l’API

Demande de CreateEvent

<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
<accessControl>
<sessionPassword>XXXXXXXX</sessionPassword>
</accessControl>
<metaData>
<sessionName>Test XMLAPI EC</sessionName>
</metaData>
<schedule>
<startDate>17/07/2021 01:29:15</startDate>
<openTime>15</openTime>
</schedule>
</bodyContent>

Réponse de CreateEvent

<?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>ÉCHEC</serv:result>
<serv:reason>L'événement classique a été désactivé.</serv:reason>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
<serv:exceptionID>010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>

CreateEvent3.1.3 Affecter les API :

• SetEvent GetEvent

• GetSessionInfo

• LstsummaryEvent

• LstrecordedEvent

• LstsummaryProgram

• UploadEventImage

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

API concernées

Mettre à jour l'API LstMeetingType élément de réponse 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 peuvent être personnalisés préfixe du type de rencontre.

Changements de schéma sur l’API : LstMeetingType

Il répondra à un nouvel élément : subProdctCodePrefix

Exemple de requête et de réponse API

LstMeetingType Demande et réponse API

Demande du LstMeetingType

<bodyContent xsi:type="java:com.webex.service.binding.meetingtype.LstMeetingType">
<meetingTypeID>13810</meetingTypeID>
</bodyContent>

Réponse de LstMeetingType

<serv:body>
<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:meetingType>
<mtgtype:productCodePrefix>PRO</mtgtype:productCodePrefix>
<mtgtype:subProductCodePrefix>PRO3</mtgtype:subProductCodePrefix> //Nouvel élément pour le type de réunion personnalisé
<mtgtype:active>ACTIVÉ</mtgtype:active>
<mtgtype:name>Cus_Chat_Fermé</mtgtype:name>
<mtgtype:displayName>Cus_Chat_Fermé</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.

L’API XML prend en charge la compatibilité de transfert dans l’API de gestion des utilisateurs pour les sites gérés par Control Hub

Modifications des API et du schéma concernées

Si votre application d'intégration utilise actuellement les API de gestion des utilisateurs Webex XMLAPI : 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é de transfert. Il y a quelques changements de comportement comme indiqué ci-dessous :

• Lors de l’utilisation de createUser- si le statut de l’utilisateur dans le 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 mot de passe des API CreateUser et SetUser sera ignoré, nous commençons à envoyer un courrier électronique d'activation aux nouveaux utilisateurs, les utilisateurs peuvent cliquer sur le lien contenu dans le courrier électronique pour activer un nouveau compte et saisir un nouveau mot de passe.

• Le actifélémentdel’API CreateUser sera ignoré, le nouvel utilisateur (non vérifié) ne peut pas être activé via ce paramètre en utilisant l’API DéfinirUtilisateur.

• La valeur de identifiant webExId élément du bodyContent des APIs CreateUser doit être identique à la messagerie électronique. Si identifiant webExId est différent de e-mail, nous traiterons le identifiant webExId identique au courrier électronique lors du stockage dans WebDB et la valeur sera ignorée.

• La valeur de identifiant webExId élément du bodyContent des APIs SetUser doit être l’identité utilisateur de l’adresse email, vous pouvez la modifier en utilisant <e-mail> dans bodyContent.

• L'API SetUser prendra en charge la modification de l'adresse électronique de l'utilisateur existant : elle réussit si le compte d’exploitation dans SecurityContext est l’administrateur complet du site Control Hub. Sinon, l'API signale une erreur avec un nouveau code d'erreur et un nouveau message ci-dessous :

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

• L'élément newWebExId dans le bodyContent de l'API SetUser sera ignoré.

• L'API SetUser tente de passer à un courrier électronique déjà en cours d'utilisation, l'API passe au-dessous du nouveau code d'erreur et du nouveau message d'erreur :

  • 030118 Le courrier électronique est déjà utilisé 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 (<active>ACTIVATED</active>) tant que l'utilisateur est vérifié auparavant.

• Les API CreateUser et SetUser émettent un nouveau code d'erreur et un nouveau message d'erreur comme illustré 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 Revendiquer des utilisateurs dans votre organisation (Convertir des utilisateurs). Vous devrez vérifier le domaine auquel appartient l’utilisateur avant de le revendiquer.

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

La compatibilité avant est prise en charge uniquement pour une période limitée. Nous vous informerons à l’avance avant que cette compatibilité ne soit supprimée.

Modifications du schéma

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

Exemple de requête 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/servicehttp://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{compte Admin du site}</webExID>
<email>{compte Admin du site}</email>
<sessionTicket>xxxx</sessionTicket> ou <password> ou <webExAccessToken>
ou <accessToken>, lors de l'utilisation de CI « accessToken », il doit inclure la portée webexsquare:admin lors du provisionnement de l'utilisateur
</accessToken></webExAccessToken></password></securityContext>
</header>



<body>
<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>Cric</firstName>
<lastName>Smith</lastName>
<password>...</password>
<privilege>
<host>vrai</host>
</privilege>
<active>ACTIVÉ</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>
</body>


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:header>
<serv:response>
<serv:result>SUCCÈS</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>
</serv:body>
</serv:message>

Affecter les API :

• Créer un utilisateur

• Définir l’utilisateur

• SupprUtilisateur

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

API concernées

Une fois le site Webex classique converti en site géré par Control Hub, la valeur de l’élément <webExID> dans <securityContext> doit être identique à celle de l’e-mail, détails ci-dessous :

• Pour les utilisateurs existants créés sur le site Webex classique, nous prenons en charge les deux anciens webExID (Par exemple : Jack) et le nouveau webExID (le contenu est identique au courrier électronique, exemple : Jack@xx.com) pour se connecter, cette authentification rétrocompatibilité est pour toutes les API XML.

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

<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- 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
<sessionTicket>xxxx</sessionTicket> ou <password> ou <webExAccessToken> ou <accessToken>
</accessToken></webExAccessToken></password></securityContext>
</header>

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’<webExID> élément <bodyContent> doit être identique à celle de l’e-mail, détails ci-dessous :

• Pour les utilisateurs existants créés sur le site Webex classique, nous prenons en charge les deux anciens identifiant webExId(ex : Jack) et neuf webExId(le contenu est identique au courrier électronique, par exemple : Jack@xx.com) dans bodyContent.

• Pour les nouveaux utilisateurs créés dans les sites gérés par Control Hub, la valeur de identifiant webExId L’élément doit être identique à l’e-mail dans bodyContent.

<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- utilisateurs existants ont été créés sur le site webEx classique, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
</bodyContent>

Affecter les API :GetUser, SetUser et DelUser.

Modifications du schéma

Aucun changement de schéma sur les API.

Exemple de requête et de réponse API

Demande et réponse API GetUser

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/servicehttp://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- les utilisateurs existants ont été créés sur le site classique webEx, cela peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
<sessionTicket>xxxx</sessionTicket> ou <password> ou <webExAccessToken> ou <accessToken>
</accessToken></webExAccessToken></password></securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- les utilisateurs existants ont été créés sur le site webEx classique, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
</bodyContent>
</body>


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

Amélioration de l’API de rapport de l’historique des affichages des enregistrements pour prendre en charge dans Webex Meetings, Webex Events (Nouveau) et Webex Events (Classique)

API concernées

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

Modifications du schéma

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

<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</serviceType>
</serviceTypes>

Détails

L’API : lstrecordaccessHistory est en mesure de restituer l’historique des accès à l’affichage des enregistrements pour Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.

• S’il n’y a pas Type de service spécifié dans la requête de l'API, l'API de lstrecordaccessHistory renvoie uniquement l’historique des accès à l’affichage des enregistrements de Webex Trainings.

• Lorsque le serviceType est MeetingCenter, l'API de lstrecordaccessHistory renvoie à la fois l’historique des accès aux vues des enregistrements Webex Meetings et Webex Events (nouveau).

• Lorsque le Type de service est EventCenter, l'API de lstrecordaccessHistory retourne l’historique des accès à l’affichage de l’enregistrement Webex Events (classique).

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

Exemple de requête 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">
<header>
<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.history.LstrecordaccessHistory">
<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>
<order>
<orderBy>RECORDID</orderBy>
<orderAD>ASC</orderAD>
</order>
<serviceTypes>
<serviceType>Centre de réunions</serviceType>
<serviceType>Centre de formation</serviceType>
<serviceType>Centre d'événements</serviceType>
</serviceTypes>
</bodyContent>
</body>
</serv:message>

<?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:header>
<serv:response>
<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>LstrecordaccessHistory test 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:viewed>1</history:viewed>
<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>06/10/2021 19:10:15</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>3</history:viewed>
<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>Le 07/05/2021 07:15:06</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>1</history:viewed>
<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:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test 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:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test 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:viewed>1</history:viewed>
<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:viewed>1</history:viewed>
<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>
</serv:body>
</serv:message>

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">
<header>
<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>
</header>
<body>
<bodyContent xsi:type="">
"java:com.webex.service.binding.history.LstrecordaccessDetailHistory">
<recondID>1XXXXXX7</recondID>
<timeZoneID>20</timeZoneID>

</body>


<?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:header>
<serv:response>
<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>faux</history:registered>
<history:downloaded>faux</history:downloaded>
<history:viewed>vrai</history:viewed>
<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>faux</history:registered>
<history:downloaded>vrai</history:downloaded>
<history:viewed>faux</history:viewed>
<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>
</serv:body>
</serv:message>

Affecter les API :

• lstrecordaccessHistory

• lstrecordaccessDetailHistory

Corrigez l’écart de la longueur maximale autorisée de la description de Webex Events (classique) entre XMLAPI et la page Webex.

API concernées

L' API XML : Élément CreateEvent et SetEvent de description autorisera les entrées de maximum 10 000 caractères, si la saisie est trop importante, elle entraînera le nouveau code d'erreur et le nouveau message :

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

Modifications du schéma

Aucun changement de schéma.

Exemple de requête et de réponse API

Demande et réponse de l'API CreateEvent

#Exemple de demande d'API :
...
<body>
<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/eventhttp://www.webex.com/schemas/2002/06/service/event/event.xsd">
<accessControl>
<sessionPassword>111111</sessionPassword>
<listing>PRIVÉ</listing>
</accessControl>
<metaData>
<sessionName>Test CE</sessionName>
<description>.......Supposons que vous remplissiez 10000 caractères dans la description.......</description>
</metaData>
...


------------------------------------
#Exemple de réponse API lorsque la description dépasse 10000 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:header>
<serv:response>
<serv:result>ÉCHEC</serv:result>
<serv:reason>Description de saisie illégale. La description ne peut pas dépasser 10000 caractères</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>060068</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>

Affecter les API :

• CreateEvent

• SetEvent

API XML : GetUser retourne un nouvel élément de freeAccount

API concernées

GetUser retourne un nouvel élément qui identifie freeAccount le compte utilisateur est FreeAccount ou pas.

Modifications du schéma

Exemple de réponse GetUser

Réponse de GetUser :
<use:initials>AW</use:initials>
<use:isUploaded>false</use:isUploaded>

<use:largeEventCapacity>3</use:largeEventCapacity>
<use:freeAccount>false</use:freeAccount>

Affecter les API :

GetUser

Mises à jour de l'API XML 41.9.0

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

Désactiver l'API XML 10.0.0 pour tous les sites T31

Webex prévoit de mettre fin à la prise en charge de l’API XML version 10.0.0 pour tous les sites T31.

Nous mettons hors service 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ésactiver l'API XML 10.0.0 pour tous les sites T31

Webex prévoit de mettre fin à la prise en charge de l’API XML version 10.0.0 pour tous les sites T31.

Webex a trouvé des clients accédant à l’URL de l’API XML en utilisant une manière 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 API XML d'accès au code en utilisant la bonne manière pour éviter tout impact avant que nous ne mettions fin à 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 de l'enregistrement mobile doivent être contrôlées par l'option d'administration du site : Autoriser les coorganisateurs à réattribuer, modifier, désactiver et supprimer les enregistrements

Modifications des API et du schéma concernées

GetSite: renverra de nouveaux éléments nommant enableNBRMCModify et separateNoRecordingEdit sous les outils.

Exemple de réponse

GetSiteResponse:

GetSite

<?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:header>
<serv:response>
<serv:result>SUCCÈS</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:tools>
...
<ns1:enableNBRMCModify>false</ns1:enableNBRMCModify>
<ns1:separateNoRecordingEdit>true</ns1:separateNoRecordingEdit>
...
</ns1:tools>
</serv:bodyContent>
</serv:body>
</serv:message>

Mises à jour de l'API XML 41.6.3

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

GetSite Réponse nouvel élément de supportLargeEvent

Modifications des API et du schéma concernées

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

Changement de schéma

Exemple de réponse

GetSiteResponse:

GetSite

<?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:header>
<serv:response>
<serv:result>SUCCÈS</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>
</serv:body>
</serv:message>

Mises à jour de l'API XML 41.6.0

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

XMLAPI prend en charge Webex Events 2.0 dans le provisionnement

API concernées

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

Modifications du schéma

Exemple de réponse

ObtenirRéponseUtilisateur :

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

API concernées

LstRecording: LstRecording réponse CreateTime comme l'heure à laquelle l'utilisateur appuie réellement sur le bouton d'enregistrement.

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 LstRecording réponse. C'est maintenant l'heure à laquelle l'utilisateur commence réellement à enregistrer. Ce changement s’applique à tous les enregistrements de service. Il n’y a pas de changement de schéma.

Mises à jour XML API 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 programmées Webex à partir du RTCP en tant qu’organisateur

API concernées

• CreateUser: génère 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.

• SetUser: ensembles hostPIN utilisation phones.hostPIN lorsque personalMeetingRoom.hostPIN n'est pas dans la requête XML (pré-condition : bascule de fonctionnalité AllowStartScheduledMtgFromPhoneest activé).

• GetUser: retours phones.hostPIN que la salle de réunion personnelle (PMR) de l’utilisateur soit activée ou non. (condition préalable : bascule de fonctionnalité AllowStartScheduledMtgFromPhone est activé).

Modifications du schéma

GetUserResponse:

SetUser:

Exemple de réponse

GetUserResponse:

SetUser:

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

API concernées

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

  • enableRecordingAccess: vrai ou faux, les super administrateurs Webex peuvent activer ou désactiver l’accès à l’enregistrement à l’aide de la fonction bascule( EnableRecordingAccesses).

  • 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.

Modifications du schéma

Demande d’échantillon pour GetSite

Exemple de réponse pour Getsite

L’objet du courrier électronique contenant des caractères non ASCII sera encodé avec RFC2047. Dans le cas d’un objet de courrier électronique à caractère ASCII pur, il n’y a pas d’encodage

Il n’y a aucun impact sur les demandes d’API, la charge utile des réponses, mais cela modifie le comportement d’encodage de l’objet du courrier électronique. Lorsque l'objet du courrier électronique contenant des caractères non ASCII sera encodé avec RFC2047. Dans le cas d’un objet de courrier électronique purement ASCII, il n’y a pas d’encodage.

Modifications du schéma

Il n'y a pas de changements 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.

Webex Events peut tirer parti de la tonalité par défaut au niveau du site à l’entrée et à la sortie

XMLAPI s’aligne sur la nouvelle logique actuelle de contrôle de la tonalité d’entrée et de sortie. Toutes les tonalités pour Webex Events ont été contrôlées par un paramètre différent dans l’administration du site. Dans GetSite, XMLAPI renvoie un champ supplémentaire entryExitToneEC pour indiquer la valeur. À l'origine, lorsque l'administrateur du site définit une tonalité par défaut, la création d'événement n'exploite pas ce paramètre en appliquant la valeur par défaut XMLAPI.

API concerné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.

Modifications du schéma

API XML : Exemple de réponse GetSite :

<ns1:defaults>
<ns1:emailReminders>true</ns1:emailReminders>
<ns1:entryExitTone>ANNOUNCENAME</ns1:entryExitTone>
<ns1:entryExitToneEC>NOTONE</ns1:entryExitToneEC>
<ns1:voip>true</ns1:voip>
<ns1:teleconference>
<ns1:telephonySupport>NONE</ns1:telephonySupport>
</ns1:teleconference>
<ns1:joinTeleconfNotPress1>true</ns1:joinTeleconfNotPress1>
<ns1:updateTSPAccount>false</ns1:updateTSPAccount>
</ns1:defaults>

Affecter les API :

• Obtenir le site

• CréerEvénement

• SetEvent

• ObtenirÉvénement

XMLAPI renvoie simplement les informations détaillées de l'événement de grande envergure (Webex Event 2.0)

1. Si la réunion Webex est le grand événement ou le webcast, GetSessionInfo renvoie certaines informations détaillées, y compris le mot de passe de la réunion, le mot de passe numérique de la réunion, le mot de passe du co-animateur et le mot de passe numérique du co-animateur (Aucun schéma ne doit être modifié).

2. XMLAPI ne prend pas en charge la création et la modification d'une fonctionnalité d'événement ou de webcast de grande envergure, donc CreateMeeting et SetMeeting renvoyer une nouvelle exception (110064, L’événement et le type de session webcast ne sont pas pris en charge.) pour le cas d’événement de grande envergure ou de webcast.

API d’impact

Mises à jour XML API 41.3.0

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

Les nouvelles modifications de l’API XML prennent en charge la fonctionnalité Webex Events 2.0

API concernées

Les deux API : Éléments de retour GetSessionInfo et GetMeeting enableEvent et enableWebniar aussi.

La prise en charge XMLAPI renvoie au-dessus de deux éléments pour EC 2.0. La version actuelle de l'API XML ne prend pas en charge la programmation et la configuration de la réunion EC2.0.

Modifications du schéma

GetSessionInfo éléments de retour enableEvent et enableWebniar pour EC 2.0.

GetMeeting éléments de retour enableEvent et enableWebniar pour EC 2.0.

Échantillon de réponse :

GetSessionInfo réponse :

<ep:accessControl>
<ep:listStatus>PUBLIC</ep:listStatus>
<ep:registration>false</ep:registration>
<ep:passwordReq>true</ep:passwordReq>
<ep:isEnforceAudioPassword>false</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>false</ep:isEnforceAudioLogin>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:accessControl>

GetMeeting réponse :

<meet:supportPKI>false</meet:supportPKI>
<meet:HQvideo>true</meet:HQvideo>
<meet:HDvideo>true</meet:HDvideo>
<meet:viewVideoThumbs>true</meet:viewVideoThumbs>
<meet:enableEvent>false</meet:enableEvent>
<meet:enableWebniar>false</meet:enableWebniar>
<meet:enablePreMeetingLobby>true</meet:enablePreMeetingLobby>

Les nouvelles modifications XMLAPI prennent en charge la fonctionnalité de lobby de pré-réunion

API concernées

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

Modifications du schéma

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

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

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

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

Échantillon de réponse :

GetSite réponse :

<ns1:siteCommonOptions>
<ns1:SupportCustomDialRestriction>false</ns1:SupportCustomDialRestriction>
<ns1:SupportTelePresence>false</ns1:SupportTelePresence>
<ns1:SupportTelePresencePlus>false</ns1:SupportTelePresencePlus>
<ns1:EnableCloudTelepresence>true</ns1:EnableCloudTelepresence>
<ns1:EnableCMRForAllUsers>true</ns1:EnableCMRForAllUsers>
<ns1:enablePersonalMeetingRoom>true</ns1:enablePersonalMeetingRoom>
<ns1:SupportAlternateHost>true</ns1:SupportAlternateHost>
<ns1:SupportXMLAPIReturnScheduledPMR>false</ns1:SupportXMLAPIReturnScheduledPMR>
<ns1:SupportAnyoneHostMeetings>true</ns1:SupportAnyoneHostMeetings>
<ns1:enablePreMeetingLobby>true</ns1:enablePreMeetingLobby>
</ns1:siteCommonOptions>

LstSummarySession réponse :

<ep:isException>false</ep:isException>
<ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>
<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>false</ep:isScheduledPMR>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>

GetSessionInfo réponse :

<ep:accessControl>
<ep:listStatus>PUBLIC</ep:listStatus>
<ep:registration>false</ep:registration>
<ep:passwordReq>true</ep:passwordReq>
<ep:isEnforceAudioPassword>false</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>false</ep:isEnforceAudioLogin>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:accessControl>

GetMeeting réponse :

<meet:supportPKI>false</meet:supportPKI>
<meet:HQvideo>true</meet:HQvideo>
<meet:HDvideo>true</meet:HDvideo>
<meet:viewVideoThumbs>true</meet:viewVideoThumbs>
<meet:enableEvent>false</meet:enableEvent>
<meet:enableWebniar>false</meet:enableWebniar>
<meet:enablePreMeetingLobby>true</meet:enablePreMeetingLobby>

L'API XML GetSite réponse Information changement de comportement divulgué

API concernées

L' API XML : GetSite seule réponse ci-dessous les éléments pour le compte administrateur, qui incluent les rôles : SiteAdmin, RO_SiteAdmin et UserAdmin.

<ns1:activeUserCount>...</ns1:activeUserCount>
<ns1:EEActiveUserCount>...</ns1:EEActiveUserCount>
<ns1:activeCETHost>...</ns1:activeCETHost>
<ns1:auoActiveUserCount>...</ns1:auoActiveUserCount>
<ns1:MCActiveUserCount>...</ns1:MCActiveUserCount>
<ns1:ECActiveUserCount>...</ns1:ECActiveUserCount>
<ns1:TCActiveUserCount>...</ns1:TCActiveUserCount>
<ns1:SCActiveUserCount>...</ns1:SCActiveUserCount>

Comportement modifié

Autoriser uniquement le rôle d’administrateur à avoir des données de licence de réponse de GetSite. L’organisateur ou l’invité ne recevra pas ces données de licence dans GetSite réponse.

Voici les API : GetSite's exemple de réponse pour siteadmin ou prêt uniquement siteadmin ou admin 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 « CMR Hybrid VOIP » si le site prend en charge la téléphonie Webex

API concernées

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

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

Modifications du schéma

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

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

<ns1:telephonyConfig>

<ns1:isWebexTelephony>true</ns1:isWebexTelephony>
<ns1:isTSPUsingTelephonyAPI>false</ns1:isTSPUsingTelephonyAPI>
<ns1:serviceName>N° conférence personnelle</ns1:serviceName>
<ns1:participantAccessCodeLabel>Code d'accès invité</ns1:participantAccessCodeLabel>
<ns1:subscriberAccessCodeLabel>Code d'accès organisateur</ns1:subscriberAccessCodeLabel>
<ns1:attendeeIDLabel>ID invité</ns1:attendeeIDLabel>

.....

</ns1:telephonyConfig>

LstSummarySession prend en charge EC2.0

Les API XML seront impactées

LstSummarySession retournera deux nouveaux éléments pour soutenir EC 2.0

Modifications du schéma

API XML : LstSummarySession: Ajouter le < enableEvent> et < enableWebniar> éléments

Réponse de l'API XML : LstSummarySession

Réponse pour EC 2.0

<ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>

<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>false</ep:isScheduledPMR>
<ep:enableEvent>true</ep:enableEvent>
<ep:enableWebniar>true</ep:enableWebniar>

XMLAPI prend en charge le retour de l'utilisateur du site Webex-voice-assistant option d'intégration TCM

APIs affectées

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

Modifications du schéma

getUserResponse:

Exemple de réponse