Introduction to Adobe Connect Web Services Architecture

Understand the architecture of Connect Web Services and get to know how the APIs work.

Adobe® Connect™ Web Services is the web service layer over the Adobe Connect Server suite of applications.

Web services allow you to build portals or web applications that integrate Adobe Connect functionality and reporting information with third-party systems such as portals, customer relationship management systems, and enterprise resource planning systems.

Adobe Connect Web Services provides meeting, training, and events functionality to your applications through its XML API.
Adobe Connect Web Services provides meeting, training, and events functionality to your applications through its XML API.

As an example, you might have a central user management system, such as an LDAP directory, Microsoft Active Directory, or another third-party system, that is an integral part of your business processes.

Using web services, you can write an application that synchronizes users between your system and Adobe Connect. The application can use the J2EE platform or another technology of your choice to pull a list of users from the directory, compare it against a list of Adobe Connect users, and then perform requested updates within the Adobe Connect user repository, such as adding or deleting users or groups.

Data flow

The data flows between client applications and Adobe Connect are shown in the following diagram. Custom applications that you write use paths 1 to 2 and A to B. Adobe Connect applications (such as Adobe Connect Meeting, Adobe Connect Training, or Adobe Connect Events) can use any of the data flow paths.

The data flow between Adobe Connect and client applications.
The data flow between Adobe Connect and client applications.

The data flow can be encrypted with SSL or unencrypted.

Unencrypted

If the data flow is unencrypted, connections are made over HTTP and Adobe Real Time Messaging Protocol (RTMP) and follow the paths described in the following table.

Diagram number

Description

1

The client web browser requests an Adobe Connect meeting or content URL over port HTTP:80 (connection paths may vary).

2

The web server responds with content transfer or provides the client browser with information to enter Adobe Connect.

3

Adobe Connect application for desktop requests a connection to Adobe Media Server over RTMP:1935 and HTTP:80.

4

Adobe Media Server responds, and a persistent connection is opened to stream meeting traffic to the browser.

3a (alternate)

In some cases, Adobe Connect application for desktop requests a connection to the Adobe Media Server, but can only obtain a tunneled connection over RTMPT:80.

4a (alternate)

Adobe Media Server responds, and a tunneled connection is opened to stream meeting traffic to the browser.

Encrypted

If the data flow is encrypted, connections are made securely over HTTPS and RTMPS (Real Time Messaging Protocol over SSL), as follows.

Diagram number

Description

A

The client web browser requests a secure meeting or content URL over an encrypted connection on HTTPS:443 (connection paths may vary).

B

The web/application server responds with an encrypted content transfer or provides the client with information to make an encrypted connection to Adobe Connect.

C

Adobe Connect application for desktop requests an encrypted connection to Adobe Media Server over RTMPS:443.

D

Adobe Media Server responds, and a persistent connection is opened to stream meeting traffic to the browser.

Custom applications

Adobe Connect Web Services provides an XML API, so your application must be able to communicate with Adobe Connect using XML over HTTP or XML over HTTPS. Your application calls the API by building a request URL and passing it one or more parameters, either as name/value pairs or as an XML document. Web Services returns an XML response, from which you can extract values.

Custom applications retrieve metadata from the Adobe Connect database. Metadata includes meeting or course names and times, meeting room URLs, content URLs, and report information.

The data flow for a custom application retrieving metadata from the database is from a client web browser, to the client web application server, to the XML API, the Adobe Connect web application server, and the SQL database—and then back again.

The data flow between a custom application and Adobe Connect works like this:

  1. A user accesses your custom application from a web browser.

  2. The application calls the XML API over HTTP:80 or HTTPS:443.

  3. The Adobe Connect web application server authorizes the application and its users, retrieves metadata from the SQL database, and returns the metadata.

  4. On the client side, your web or application server, XML parser, and software libraries handle the response and return it to your application.

  5. The user continues to work in your custom application, and clicks a meeting or content URL. At this point, the user accesses a Adobe Connect application to enter a meeting room, and the typical data flow between a Adobe Connect application and the server begins.

Adobe Connect applications

Adobe Connect applications call the server using the same Web Services XML API that you use from a custom application.

In general, content is transported over HTTP port 80 or HTTPS port 443. Content includes slides, HTTP pages, SWF files, and files transferred through the FileShare pod. These are default port numbers that you can configure (see Migrating, Installing, and Configuring Adobe Connect Server for details).

Streamed, real-time communications from Adobe Media Server are transported over RTMP port 1935. Streamed communications include audio, video (webcam and FLV), file share, and chat. Meeting state is also maintained over RTMP port 1935.

Components of Adobe Connect

Adobe Connect is architected with two server components, and each server uses a SQL database.

The web application server

The web application server is the brains of Adobe Connect. It contains and executes all of the business logic needed to deliver content to users. It handles access control, security, quotas, and licensing, as well as management functions such as clustering, failover, and replication.

The web application server also handles Adobe Connect Central, the application through which you view and manage your organization’s content and users—when you are not using a custom application or integrated third-party system. The metadata describing content and users can be stored in either single or multiple replicated SQL databases. The web application server is stateless, which means that scaling is near linear.

Adobe Media Server

Adobe Media Server streams audio, video, and rich media content using RTMP. When a meeting is recorded and played back, audio and video are synchronized, or content is converted and packaged for real-time screen sharing, Adobe Media Server does the job.

Adobe Media Server also plays a vital role in reducing server load by caching frequently accessed web pages, streams, and shared data.

The SQL database

Adobe Connect uses the Microsoft SQL Server database for persistent storage of transactional and application metadata, including users, groups, content, and reporting information. The XML API retrieves metadata stored in the database. The database can be implemented with either the Microsoft SQL Server Desktop Engine (MSDE) or the full version of Microsoft SQL Server 2005.

Making your first API call

Adobe Connect Web Services uses a servlet framework to handle XML API requests. In the data flow diagram, the servlet framework is represented by the API component. The API servlet receives XML requests from clients and returns XML responses from the web application server and the database.

A request to the XML API is formatted as an HTTP request URL that the API servlet handles. A request URL has an action name and parameters in name/value pairs, like this:

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

If you have access to a Adobe Connect account in which you can test API calls, you can experiment. In fact, Adobe recommends testing API calls in the browser while you learn the API and write applications.

Before you begin, it’s useful to install a tool that allows you to view HTTP request and response headers in your browser.

Call common-info in a browser

  1. (Optional) Enable a tool for viewing HTTP headers in your browser.

  2. Open a browser and navigate to your Adobe Connect login page.

  3. Without logging in, delete the part of the URL after the domain name and add a call to common-info:

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

    The response from common-info gives you information about your session with the server, especially the cookie that identifies your session:

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

    When you log a user in from an application, you need to send the cookie value back to the server to identify the user’s session (see Log in from an application).

Call principal-list in a browser

Once you have the BREEZESESSION cookie value from common-info, the browser adds it to the request header on your next request.

  1. In a web browser, log in to Adobe Connect. Change the browser URL to call principal-list:

     https://example.com/api/xml?action=principal-list
  2. Check the request header. This time it sends the BREEZESESSION cookie value back to the server:

     GET /api/xml?action=principal-list HTTP/1.1 
     Accept: */* 
     Accept-Language: en-us 
     Accept-Encoding: gzip, deflate 
     User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) 
     Host: example.com 
     Connection: Keep-Alive 
     Cookie: BREEZESESSION=breezbryf9ur23mbokzs8
  3. Check the response, which lists all principals on the server, each in its own principal element.

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

Add filters and sorts

Many actions in the API allow you to add a filter to return only certain response elements or a sort to display response elements in a certain order.

A filter is a special parameter that starts with the keyword filter, followed by an optional modifier, then a field name and a value. These are all examples of filters:

  • filter-name=jazz doe (which matches results with the exact name jazz doe)

  • filter-like-name=jazz (which matches any results that contain jazz in the name)

  • filter-out-type=user (which returns any results that do not have a type of user)

These are just a few filter types, and you can find more in filter-definition. Check an action in the reference (at Action reference) to see whether its response can be filtered. In general, if an action allows filters, you can use them on any response element or attribute.

A sort is another special parameter that starts with the keyword sort (or sort1 or sort2), followed by a field name and then one of the keywords asc or desc, for example:

  • sort-name=asc (to sort in ascending order by name)

  • sort-group-id=desc (to sort in descending order by group-id)

These are just a few sort examples. You can test sorts in the browser or see sort-definition for more.

Make a call with a filter and sort

  1. Call principal-list again, displaying only groups and sorting them alphabetically by name:

     https://example.com/api/xml?action=principal-list&filter-type=group 
         &sort-name=asc
  2. To tighten the response, choose a group from the list and filter on its name:

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

    This time, only one group is returned:

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

Where to go from here

At this point, you can continue to test calls in the browser and observe how they work. It’s the best and easiest way to learn the XML API. When you need more information, turn to any of these sources:

  • The API reference in Action reference.

  • Login and requests for information on how to log users in from applications.

  • Basics to learn the three basic concepts underlying the API.

  • Meetings if you want to create and manage meetings from an application.

  • Training if you are building a training application.

 Adobe

Get help faster and easier

New user?