|
To understand how to use Adobe Connect Web Services to
build a custom application, download the sample application from
www.adobe.com/go/learn_cnn_firstapp_en
.
The
sample application is written in Java and JSP using a model-view-controller architecture
and runs on any web application server with a J2EE servlet container. The
sample demonstrates how to implement Adobe Connect meeting functionality
in a Java custom application or portal, showing how to log in a
user, list a user’s meetings, and create, update, and delete meetings.
As you build and design your application, there are several points
about the Adobe Connect Web Services XML API you should keep in
mind:
-
Sequence of API calls
-
Calls
to the XML API often need to be made in a specific sequence. For
example, you need to get the
principal-id
of a
user and the
sco-id
of a meeting before you call
permissions-update
to
make the user a meeting presenter. Call sequences for various tasks
are described in the first chapters of this guide.
-
Different parameter names for the same value
-
A
value might have one parameter name in one call and a different
parameter name in another call. For example, the unique ID of a
SCO might be a
sco-id
when used with
sco-info
,
but an
acl-id
in
permissions-update
.
It’s the same value in both calls. The best way to learn this is
to use the API reference in this guide.
-
SCOs are not object-oriented
-
A
SCO is a shareable content object on the server (for a complete
definition, see
Find SCOs
). A SCO can be a meeting,
presentation, course, image, folder, or any object on the server.
SCOs are stored within folders in a navigation hierarchy. However,
there is no object-oriented structure for SCOs, and one type of
SCO is not a subclass of another type. Keep this in mind as you
design your application.
|
|
|
