Hier finden Sie alle wichtigen Informationen, die Sie über die Cisco Webex Meetings-API benötigen, wie etwa Schemaänderungen und andere Ankündigungen.
Weitere Informationen zu XML API 39 und XML API 11 finden Sie unter Cisco Webex Meetings XML API Updates Overview (XML API 39 und früher).
Weitere Informationen zu XML API 40 finden Sie in Cisco Webex Meetings Übersicht über XML API Updates (XML API 40 und höher).
Aktualisierungen für XML API 11 SP9 und früher finden Sie unter Cisco DevNet.
AKTUALISIERUNGEN VON API 41.12.0
XML API 41.12.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.12.0-Schemaherunterzuladen.
XMLAPI blockiert den Webex Events (Classic) und die Bearbeitung entsprechend der Site-Konfigurationsaufgabe von EnableClassicEvent
das ist falsch
Auswirkungen auf APIs und Schemaänderungen
Wenn auf der Konfigurationsseite der Site-Administration das Kontrollkästchen Klassisches Event aktivieren falsch ist, unterstützt diese Site keine Webex Events (klassische) Meetings mehr.
Wenn das Kontrollkästchen Enable classicEvent (klassisches Event aktivieren) falsch ist, rufen Sie diese APIs auf, um Webex Events (classic) Meeting zu betreiben:
CreateEvent
, SetEvent
, GetEvent
, GetSessionInfo
, LstsummaryEvent
, LstrecordedEvent
, LstsummaryProgram
, UploadEventImage
Die API antworte auf neue 010106 Das klassische Eventwurdedeaktiviert.
Schemaänderungen
Keine Schemaänderungen.
API-Anfrage- und Antwortbeispiel
CreateEvent API-Anfrage und -Antwort
Anfrage für CreateEvent
<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
<accessControl>
<sessionPassword>XXXXXXXX</sessionPassword>
</accessControl>
<metaData>
<sessionName>XMLAPI EC Testing</sessionName>
</metaData>
<schedule>
<startDate>07/17/2021 01:29:15</startDate>
<openTime>15</openTime>
</schedule>
</bodyContent>
</body>
</serv:message>
Antwort von 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>FAILURE</serv:result>
<serv:reason>The classic Event has been disabled.</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>
CreateEvent3.1.3 Auswirkungen auf APIs:
SetEvent GetEvent
GetSessionInfo
LstsummaryEvent
LstrecordedEvent
LstsummaryProgram
UploadEventImage
XMLAPI LstMeetingType
antworte auf neues Element subProductCodePrefix
Auswirkungen auf APIs
Aktuell die API LstMeetingType
Antwortelement productionCodePrefix
: PRO, AUO und andere, die webex vordefiniertes Meet-Type-Präfix sind.
Nach dieser neuen Verbesserung reagiert die API auf neue Elemente subProdctCodePrefix
:P ro1, PRO2 usw., die angepasst werden können Meet-Type-Präfix.
Schemaänderungen auf API: LstMeetingType
Es wird auf ein neues Element reagieren: subProdctCodePrefix
API-Anfrage- und Antwortbeispiel
LstMeetingType
API-Anfrage und Antwort
Anforderung von LstMeetingType
<bodyContent xsi:type="java:com.webex.service.binding.meetingtype.LstMeetingType">
<meetingTypeID>13810</meetingTypeID>
</bodyContent>
</body>
</serv:message>
Antwort von 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> //New element for customized meeting
type
<mtgtype:active>ACTIVATED</mtgtype:active>
<mtgtype:name>Cus_Chat_Closed</mtgtype:name>
<mtgtype:displayName>Cus_Chat_Closed</mtgtype:displayName>
AKTUALISIERUNGEN VON API 41.11.0
XML API 41.11.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.11.0-Schemaherunterzuladen.
XML API-Unterstützung – Vorwärtskompatibilität in der Benutzerverwaltungs-API für von Control Hub verwaltete Sites
Auswirkungen auf APIs und Schemaänderungen
Wenn Ihre Integrationsanwendung derzeit Benutzerverwaltungs-APIs für Webex XMLAPI verwendet: CreateUser
, SetUser
, DelUser
, und GetUser
zum Bereitstellen oder Verwalten von Benutzern funktionieren diese APIs weiterhin für die Vorwärtskompatibilität, nachdem Ihre klassische Webex-Site in Control Hub konvertiert wurde. Es gibt einige Verhaltensänderungen wie unten beschrieben:
Wenn createUser verwendet wird – Wenn der Benutzerstatus im Control Hub nicht "aktiv" ist, ist der Benutzerstatus auf der Sitenicht aktiv. Wenn der Benutzerstatus in Control Hub aktiv ist, ist der Benutzerstatus auf der Site ebenfalls aktiv. Referenz: Benutzerstatus von neuen und konvertierten Benutzern in Control Hub.
Das Passwortelement von CreateUser und SetUser APIs wird ignoriert. Wir senden eine Aktivierungs-E-Mail an neue Benutzer. Benutzer können auf den Link in der E-Mail zum aktiven neuen Konto klicken und ein neues Passwort eingeben.
Das aktive Element der CreateUser API wird ignoriert, neuer Benutzer (nicht verifiziert) kann nicht über diesen Parameter mit API SetUser aktiviertwerden.
Der Wert des Elements webExId in bodyContent von CreateUser APIs muss mit dem Von E-Mail identisch sein. Wenn sich die webExId von der E-Mail-Adresse ab unterscheiden sollte, werden die webExId und die E-Mail-Adresse beim Speichern in der WebDB behandelt. Der Wert wird ignoriert.
Der Wert von webExId-Element in bodyContent vonSetUser APIsmuss die Benutzeridentität der E-Mail-Adresse sein. Sie können es mithilfe von E-Mail-> in bodyContent ändern.
Die SetUser-API unterstützt das Ändern der E-Mail-Adresse vorhandener Benutzer: es war erfolgreich, wenn das Operation-Konto in SecurityContext Control Hub Voll-Site-Administrator ist. Andernfalls meldet der API-Fehler mit einem neuen Fehlercode und der folgenden Meldung:
030120 Das Konto muss ein Site-Volladministrator sein, um E-Mails zu ändern.
Das Element newWebExId in bodyContent von SetUser API wird ignoriert.
Die SetUser-API versucht, zu einer E-Mail zu wechseln, die bereits verwendet wird. Die API hebt unter dem neuen Fehlercode und der Fehlermeldung:
030118-Mail wird bereits in von Control Hub verwalteten Sites verwendet.
Die DelUser-API deaktiviert den Benutzer auf der Webex Meeting-Seite und die entsprechende Meeting-Lizenz wird aus der Webex-Site. Dieser deaktivierte Benutzer kann über API reaktiviert werden: SetUser (<active>ACTIVATED )</active>solange der Benutzer zuvor verifiziert ist.
Die CreateUser- und SetUser-APIs löst einen neuen Fehlercode und eine Fehlermeldung aus, wie unten dargestellt:
030117 ist dieser Benutzer außerhalb Ihrer Organisation vorhanden und muss daher beansprucht werden, um über den Benutzerprozess zum Beanspruchen in Ihre Organisationzu wechseln. Weitere Informationen zum Beanspruchen des Benutzers für Ihre Organisation finden Sie unter Beanspruchen von Benutzern an Ihre Organisation (Benutzer konvertieren). Sie müssen die Domäne verifizieren, zu der der Benutzer gehört, bevor Sie den Benutzer beanspruchen.
030119 Das CI-Zugriffstoken muss den Umfang webexsquare beinhalten: Admin bei der Bereitstellung des Benutzers.
Nur für einen begrenzten Zeitraum wird Die Kompatibilität mit der Forward-Anwendung unterstützt. Wir werden Ihnen eine erweiterte Mitteilung geben, bevor diese Kompatibilität entfernt wird. |
Schemaänderungen
Keine Schemaänderungen auf diesen APIs: CreateUser
, SetUser
, DelUser
, und GetUser
definiert.
API-Anfrage- und Antwortbeispiel
CreateUser API-Anfrage und Antwort
API request:
<?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">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{site Admin account}</webExID>
<email>{site Admin account}</email>
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken>
or <accessToken>, when using CI "accessToken", it must include scope webexsquare:admin when provisioning
user
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
<webExId>Jack@qa.webex.com</webExId> --- it should is user identity of email address
<email>Jack@qa.webex.com</email>
<firstName>Jack</firstName>
<lastName>Smith</lastName>
<password>....</password>
<privilege>
<host>true</host>
</privilege>
<active>ACTIVATED</active> ---this parameter can't active the user directly until the user self activate itself via activation
email.
</bodyContent>
</body>
</serv:message>
API response example:
<?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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>
APIs beeinflussen:
Createuser
Setuser
EntfUser
XML API unterstützt die Kompatibilität vorhandener Benutzerauthentifizierungs-Forward-Kompatibilität, nachdem die klassische Webex-Site in eine von Control Hub verwaltete Site konvertiert wurde
Auswirkungen auf APIs
Nachdem die klassische Webex-Site in eine von Control Hub verwaltete Site konvertiert wurde, muss der Wert des Elements in mit dem E-Mail-Konto identisch sein. Details <webExID> <securityContext> unten:
Für bestehende Benutzer, die in der klassischen Webex-Site erstellt wurden, unterstützen wir sowohl die alte webExID (Zum Beispiel: Jack) und die neue webExID (der Inhalt ist gleich wie die E-Mail. Beispiel: Jack@xx.com) anmelden müssen, gilt diese Authentifizierung für alle XML-APIs.
Für neue Benutzer, die in von Control Hub verwalteten Sites erstellt wurden, muss der Wert des WebExID-Elements mit dem E-Mail-Wert für die Anmeldung identisch sein.
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com;
new user must use jack@xx.com
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken> or <accessToken>
</securityContext>
</header>
APIs beeinflussen:
Alle XML-APIs.
Nachdem die klassische Webex-Site in eine Control Hub-verwaltete Site konvertiert wurde, muss der Wert von element bodyContent > mit E-Mail identisch sein. Details <webExID> unten:
Für bestehende Benutzer, die in der klassischen Webex-Site erstellt wurden, unterstützen wir beide alten webExId(z. B.: Jack) und die neue webExId (der Inhalt ist gleich wie die E-Mail- Adresse. Beispiel: Jack@xx.com) in bodyContentan.
Für neue Benutzer, die in von Control Hub verwalteten Sites erstellt wurden, muss der Wert des webExId-Elements mit dem Wert "E-Mail" in identisch sein.
bodyContent
definiert.
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user
must use jack@xx.com
</bodyContent>
APIs beeinflussen:GetUser
, SetUser
, und DelUser
definiert.
Schemaänderungen
Keine Schemaänderungen auf beliebigen APIs.
API-Anfrage- und Antwortbeispiel
GetUser API-Anfrage und Antwort
API request:
<?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">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com;
new user must use jack@xx.com
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken> or <accessToken>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user
must use jack@xx.com
</bodyContent>
</body>
</serv:message>
API response example:
...same as before
Verbesserung der Berichts-API für die Aufzeichnungsansicht zur Unterstützung Webex Meetings, Webex Events (Neu) und Webex Events (Classic)
Auswirkungen auf APIs
Aktuelle API: lstrecordaccessHistory
und lstrecordaccessDetailHistory
Unterstützt nur Aufzeichnungsansicht von Webex Trainings, Zugriff auf Verlaufsbericht. Die neue Verbesserung unterstützt Webex Meetings, Webex Events (neu) und Webex Events (klassische) Aufzeichnungsansicht auch den Zugriff auf den Verlaufsbericht.
Schemaänderungen
Wir unterstützen unten ein neues Schema in API lstrecordaccessHistory im API-Anforderungskörper:
<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</serviceType>
</serviceTypes>
Details
Die API: lstrecordaccessHistory
ist in der Lage, den aufzeichnenden Verlauf der Aufzeichnungsansicht für Webex Meetings, Webex Events (neu), Webex Events (classic) und Webex Trainings zurückspart.
Wenn in der API-Anforderung kein serviceType angegeben ist, wird die API von
lstrecordaccessHistory
gibt nur den zugriff auf die Aufzeichnungsansicht von Webex Trainings zurück.Wenn der serviceType MeetingCenter ist, wird die API von
lstrecordaccessHistory
gibt sowohl den Webex Meetings- als Webex Events (neuen) Verlauf der Aufzeichnungsansicht zurück.Wenn der serviceType EventCenter ist, wird die API von
lstrecordaccessHistory
gibt Webex Events (klassische) Aufzeichnungsansicht zurück, auf die zugegriffen wurde.
Die API: lstrecordaccessDetailHistory
kann Details zurückgeben durch recordID
von Webex Meetings, Webex Events (neu), Webex Events (classic) und Webex Trainings.
API-Anfrage- und Antwortbeispiel
lstrecordaccessHistory
API-Anfrage und -Antwort
<?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>9/20/2021 00:00:00</viewTimeStart>
<viewTimeEnd>9/28/2021 23:59:59</viewTimeEnd>
</viewTimeScope>
<listControl>
<startFrom>1</startFrom>
<maximumNum>100</maximumNum>
</listControl>
<order>
<orderBy>RECORDID</orderBy>
<orderAD>ASC</orderAD>
</order>
<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>09/24/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>Test instant playback 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: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>09/22/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>09/24/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>09/24/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>09/24/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
API-Anfrage und -Antwort
<?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>
</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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>09/24/2021 13:27:26</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>false</history:downloaded>
<history:viewed>true</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>09/24/2021 13:27:39</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>true</history:downloaded>
<history:viewed>false</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>
APIs beeinflussen:
lstrecordaccessHistory
lstrecordaccessDetailHistory
Behebung der Lücke bei maximal zulässigen Webex Events Beschreibungslänge zwischen XMLAPI und Webex Page.
Auswirkungen auf APIs
Die XML-API: Das Beschreibungselement von CreateEvent und SetEvent ermöglicht maximal 1.0000 Zeichen-Eingaben. Wenn die Eingabe größer ist, führt dies zu einem neuen Fehlercode und einer neuen Nachricht:
060068 Ungültige Eingabebeschreibung. Diese Beschreibung darf nicht mehr als 10.000 Zeichen umfassen.
Schemaänderungen
Keine Schemaänderung.
API-Anfrage- und Antwortbeispiel
CreateEvent API-Anfrage und -Antwort
#API request example:
...
<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/event
http://www.webex.com/schemas/2002/06/service/event/event.xsd">
<accessControl>
<sessionPassword>111111</sessionPassword>
<listing>PRIVATE</listing>
</accessControl>
<metaData>
<sessionName>EC test</sessionName>
<description>.......Suppose you filling in 10000 characters in description.......</description>
</metaData>
...
------------------------------------
#API response example when the description exceeds 10000 characters:
<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>Illegal input description. The description can't exceed 10000 characters</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>060068</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>
APIs beeinflussen:
CreateEvent
SetEvent
XML-API: GetUser gibt neues Element von freeAccount zurück
Auswirkungen auf APIs
GetUser
gibt ein neues Element zurück, das freeAccount
die Benutzerkonto ist FreeAccount
oder nicht.
Schemaänderungen
Beispiel für GetUser-Antwort
GetUser response:
<use:initials>AW</use:initials>
<use:isUploaded>false</use:isUploaded>
</use:avatar>
<use:largeEventCapacity>3</use:largeEventCapacity>
<use:freeAccount>false</use:freeAccount>
</serv:bodyContent>
</serv:body>
</serv:message>
APIs beeinflussen:
GetUser
AKTUALISIERUNGEN VON API 41.10.0
Es gibt keine Schemaänderungen am XML API 41.10.0-Schema. |
AKTUALISIERUNGEN VON API 41.9.0
XML API 41.9.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.9.0-Schema herunterzuladen.
Deaktivierung der XML-API 10.0.0 für alle T31-Sites
Webex plant die Unterstützung der XML-API 10.0.0 für alle T31-Sites.
In der Aktualisierung von 41.9.0 wird der XML API 10.0.0-Code aller Produktionen aktualisiert.
AKTUALISIERUNGEN VON API 41.8.0
XML API 41.8.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.8.0-Schemaherunterzuladen.
Deaktivierung der XML-API 10.0.0 für alle T31-Sites
Webex plant die Unterstützung der XML-API 10.0.0 für alle T31-Sites.
Webex hat festgestellt, dass einige Kunden, die auf den URL der XML-API zugreifen, auf falsche Weise zugreifen: https://{siteName}.webex.com/WBXService/xml10.0.0/XMLService sie für den richtigen Zugriff auf die XML API-URL wie: https://{siteName}.webex.com/WBXService/XMLService.
Bitte wechseln Sie den Codezugriff auf DIE XML-API auf einen richtigen Weg, um Auswirkungen vor dem Ende des Lebenszyklus der XML API-Version 10.0.0 zu vermeiden.
AKTUALISIERUNGEN VON API 41.7.0
XML API 41.7.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.7.0-Schemaherunterzuladen.
Das Löschen und Bearbeiten von Aufzeichnungen über Mobilgeräte sollte durch die Site-Administration-Option gesteuert werden: Gastgebern neu zuweisen, bearbeiten, deaktivieren und löschen von Aufzeichnungen
Auswirkungen auf APIs und Schemaänderungen
GetSite
: gibt die Namen neuer Elemente zurück enableNBRMCModify
, und separateNoRecordingEdit
unter Tools.
Beispiel für Antwort
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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>
AKTUALISIERUNGEN VON API 41.6.3
XML API 41.6.3 Aktualisierungen
Klicken Sie hier, um das XML API 41.6.3-Schemaherunterzuladen.
GetSite
Antwort neues Element supportLargeEvent
Auswirkungen auf APIs und Schemaänderungen
Websiteerhalten: gibt die Benennung neuer Elemente zurück supportLargeEvent
unter siteCommonOptions
um den Anrufer darüber zu informieren, ob die Site ein großes Event (Webex Event (neu)) unterstützt oder nicht.
Schemaänderung
Beispiel für Antwort
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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>
Aktualisierungen von API 41.6.0
XML API 41.6.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.6.0-Schemaherunterzuladen.
XMLAPI-Webex Events 2.0 bei der Bereitstellung
Auswirkungen auf APIs
GetUser
: gibt die Benennung neuer Elemente zurück largeEventCapacity
in diesem Fall wird die Kapazität des neuen Events 2.0 (EC 2.0) Benutzerkonto. Beispiel: Wenn der Benutzerkonto eine CI_EC3K-Lizenz hat, wird der Wert von largeEventCapacity
ist 3000.
Schemaänderungen
Beispiel für Antwort
GetUserResponse:
XMLAPI LstRecordings CreateTime wendet die Anfangszeit der Aufzeichnung an
Auswirkungen auf APIs
LstRecording
: LstRecording
Antwort CreateTime
als Uhrzeit, zu der der Benutzer die Aufzeichnungsschaltfläche tatsächlich drückt.
Details
In der Vergangenheit hat die XML-API Uhrzeitstempel verwendet, als die Aufzeichnung zur Erstellungszeit in der Datenbank erstellt wurde. LstRecording
Antwort. Es ist nun die Zeit, an der der Benutzer tatsächlich beginnt, die Aufzeichnung zu machen. Diese Änderung gilt für alle Serviceaufzeichnungen. Es gibt keine Schemaänderung.
AKTUALISIERUNGEN VON API 41.5.0
XML API 41.5.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.5.0-Schemaherunterzuladen.
XMLAPI kann mit Webex angesetzten Meetings von PSTN Gastgeber aus starten
Auswirkungen auf APIs
CreateUser
: generierthostPIN
unabhängig davon, PMR Benutzerrolle aktiviert ist oder nicht, wenn die Benutzerrolle Gastgeber oder vollständig bzw. schreibgeschützt ist oder Site-Administratoren für die Benutzerverwaltung sind.SetUser
: legt fest:hostPIN
Mitphones.hostPIN
WennpersonalMeetingRoom.hostPIN
ist nicht in xml-Anforderung (Vorbedingung: FunktionsumschalterAllowStartScheduledMtgFromPhone
ist aktiviert).GetUser
: gibt zurückphones.hostPIN
unabhängig davon, PMR Benutzer-Option aktiviert ist oder nicht. (Vorbedingung: FunktionsumschalterAllowStartScheduledMtgFromPhone
ist aktiviert).
Schemaänderungen
GetUserResponse
:
SetUser
:
Beispiel für Antwort
GetUserResponse
:
SetUser
:
XMLAPI GetSite
Antwort zwei neue Elemente für mobilen Client
Auswirkungen auf APIs
GetSite
:GetSite
Antwort auf zwei neue Elemente zur Unterstützung des mobilen Clients hat die Logik, die Registerkarte "Aufzeichnung" anzuzeigen oder nicht anzuzeigen.enableRecordingAccess
: true oder false, Webex Superadministratoren können den Aufzeichnungszugriff durch umschalten aktivieren oder deaktivieren(EnableRecordingAccesses
).storageEmptyStatus
: true oder false, wenn beide Seiten die NBR-Funktion nicht unterstützen und dem NBR-Speicherplatz als Null zugewiesen haben, dann ist die Statusantwort wahr, andernfalls ist falsch.
Schemaänderungen
Beispielanforderung für GetSite
Beispielantwort für Getsite
E-Mail-Betreff mit Nicht-ASCII-Zeichen wird mit RFC2047 codiert. Bei einem E-Mail-Betreff mit reinen ASCII-Zeichen ist keine Codierung verfügbar
Auswirkungen auf APIsEs gibt keine Auswirkungen auf API-Anforderungen und Nutzdatendaten, aber sie ändert das Codierungsverhalten des E-Mail-Betreffs. Wenn der Betreff der E-Mail, der Nicht-ASCII-Zeichen enthält, mit RFC2047 codiert wird. Bei einem E-Mail-Betreff mit reinen ASCII-Zeichen ist keine Codierung verfügbar.
Schemaänderungen
Es gibt keine Schemaänderungen.
AKTUALISIERUNGEN VON API 41.4.0
XML API 41.4.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.4.0-Schemaherunterzuladen.
Event angesetztes Event Webex Events kann Standard auf Site-Ebene beim Ton bei Beitritt und Verlassen nutzen
XMLAPI entspricht der aktuellen neuen Logik zur Steuerung des Tons bei Beitritt und Verlassen. Alle Töne für Webex Events wurden in der Site-Administration durch eine andere Einstellung gesteuert. In GetSite
gibt XMLAPI ein zusätzliches Feld zurück entryExitToneEC
um den Wert anzugeben. Ursprünglich, wenn der Site-Administrator einen Standard auf den Ton eingestellt hat, kann Event diese Einstellung nicht durch Anwendung der XMLAPI-Standardeinstellung nutzen.
Auswirkungen auf APIs
Die XML-API: GetSite gibt ein neues Element zurück entryExitToneEC
um den Wert anzugeben.
Die XML-API: Business-Logik bei CreateEvent, SetEvent, GetEvent back liest den Wert von entryExitToneEC
definiert.
Schemaänderungen
XML-API: Beispiel für Website-Antwort:
<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>
APIs beeinflussen:
GetSite
Createevent
Event festlegen
Getevent
XMLAPI gibt nur die Detailinformationen zum großen Event (Webex Event 2.0) zurück.
Wenn der Webex Meeting das große Event oder Webcast ist,
GetSessionInfo
gibt einige Detaillierte Informationen wie Meeting-Passwort, numerisches Meeting-Passwort, Diskussionsist-Passwort und numerisches Diskussionsist-Passwort zurück (kein Schema wird geändert).XMLAPI unterstützt das Erstellen und Bearbeiten großer Event- oder Webcast-Funktionen nicht.
CreateMeeting
undSetMeeting
Zurückgeben einer neuen Ausnahme (110064, das Event und das Webcast Sitzungstyp werden nicht unterstützt.) für große Events oder Webcast-Fälle.
Auswirkungen auf APIs
API-Name |
Beschreibung |
Bemerkung |
---|---|---|
|
Wenn der Webex Meeting das große Event oder Webcast ist, |
Schema wird nicht geändert. |
|
Wenn der Benutzer versucht, |
Verhalten wird geändert. |
AKTUALISIERUNGEN VON API 41.3.0
XML API 41.3.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.3.0-Schemaherunterzuladen.
Die neuen Änderungen an der XML-API unterstützen Webex Events 2.0-Funktion
Auswirkungen auf APIs
Beide APIs: GetSessionInfo und GetMeeting-RückgabeelementeenableEvent
und enableWebniar
Zu.
Elementname |
Beschreibung |
---|---|
Event aktivieren |
Unterstützt EC 2.0 in einem Webex-Meeting |
AktivierenWebniar |
Unterstützt Webinar in einem Webex-Meeting |
Die XMLAPI-Unterstützung gibt bei EC 2.0 zwei Elemente wieder. Die aktuelle XML API-Version unterstützt das Ansetzung und Festlegen eines EC2.0-Treffens nicht. |
Schemaänderungen
GetSessionInfo
Elemente zurücksenk enableEvent
und enableWebniar
für EC 2.0.
GetMeeting
Elemente zurücksenk enableEvent
und enableWebniar
für EC 2.0.
Antwort-Beispiel:
GetSessionInfo
Antwort:
<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
Antwort:
<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>
</meet:enableOptions>
Die neuen Änderungen an XMLAPI unterstützen die Lobby-Funktion vor dem Meeting
Auswirkungen auf APIs
Die XML-API: GetSite
, LstSummarySession
, GetSessionInfo
, und GetMeeting
antworte auf das neue Element enablePreMeetingLobby
für Lobby vor dem Meeting.
Schemaänderungen
Die XML-API: GetSite
Rückgabeelement enablePreMeetingLobby
für Lobby vor dem Meeting.
Die XML-API: LstSummarySession
Rückgabeelement enablePreMeetingLobby
für Lobby vor dem Meeting.
Die XML-API: GetSessionInfo
Rückgabeelement enablePreMeetingLobby
für Lobby vor dem Meeting.
Die XML-API: GetMeeting
Rückgabeelement enablePreMeetingLobby
für Lobby vor dem Meeting.
Antwort-Beispiel:
GetSite
Antwort:
<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
Antwort:
<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>
</ep:session>
GetSessionInfo
Antwort:
<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
Antwort:
<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>
</meet:enableOptions>
Die XML-API GetSite
Änderung des Reaktionsverhaltens von Informationen offen legen
Auswirkungen auf APIs
Die XML-API: GetSite
Nur Antwort unten Elemente für Administratorkonto, die Rollen umfassen: SiteAdmin
, RO_SiteAdmin
, und UserAdmin
definiert.
<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>
Verhalten geändert
Nur Zulassen, dass Admin-Rolle Antwortlizenzdaten von hat GetSite
definiert. Der Gastgeber oder Teilnehmer bekommt diese Lizenzdaten nicht in GetSite
Antwort.
Unten sind API: GetSite's
Antwortbeispiel für siteadmin
oder nur bereit siteadmin
oder Administrator der Benutzerverwaltung:
AKTUALISIERUNGEN VON API 41.2.0
XML API 41.2.0 Aktualisierungen
Klicken Sie hier, um das XML API 41.2.0-Schemaherunterzuladen.
XMLAPI sollte "VoIP CMR Hybrid unterstützen, wenn die Site Webex-Telefonie unterstützt
Auswirkungen auf APIs
GetSite
gibt ein neues Element zurückIsWebexTelephony
in der Antwort.CreateUser
undSetUser
kann diecmrHybridVoip
Element, wennIsWebexTelephony
gilt zusammen mit anderen Bedingungen.IsTSPUsingTelephonyAPI
ist keine Folge mehr.
Schemaänderungen
XML-API: GetSite
Antwort gibt ein zusätzliches Element zurück IsWebexTelephony
GetSite
Antwort schließen Sie dieses neue Element ein:
<ns1:telephonyConfig>
<ns1:isWebexTelephony>true</ns1:isWebexTelephony>
<ns1:isTSPUsingTelephonyAPI>false</ns1:isTSPUsingTelephonyAPI>
<ns1:serviceName>Personal Conference No.</ns1:serviceName>
<ns1:participantAccessCodeLabel>Attendee access code</ns1:participantAccessCodeLabel>
<ns1:subscriberAccessCodeLabel>Host access code</ns1:subscriberAccessCodeLabel>
<ns1:attendeeIDLabel>Attendee ID</ns1:attendeeIDLabel>
.....
</ns1:telephonyConfig>
LstSummarySession
unterstützt EC2.0
XML-APIs sind von der
LstSummarySession
gibt neue zwei Elemente zurück, um EC 2.0 zu unterstützen
Elementname |
Beschreibung |
---|---|
Event aktivieren |
Unterstützt EC 2.0 in einem Webex-Meeting |
AktivierenWebniar |
Unterstützt Webinar in einem Webex-Meeting |
Schemaänderungen
XML-API: LstSummarySession
: Hängen Sie die < enableEvent
> und enableWebniar
> Elemente
Antwort der XML-API: LstSummarySession
Antwort für 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>
</ep:session>
XMLAPI unterstützt die Rückgabe von Site-Benutzer Webex-voice-assistant
Option für MCT-Integration
Betroffene API
GetUser
gibt ein neues Element zurück webexAssistantEnabled
(wahr oder falsch) in der Antwort.
Schemaänderungen
getUserResponse
:
Beispiel für Antwort
AKTUALISIERUNGEN VON API 41.1.0
Es gibt keine Schemaänderungen am XML API 41.1-Schema. |