Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

External services description

From MoodleDocs

Jerome's proposal

  • Database table should only contain data that can be manage by administrator
  • All the web services description should be in a array into each external.php file
  • a cron job browse all external file, check the description and update the database (if functions/services disappeared or are created)

external_functions table

List of external functions. Created automatically by parsing of external files.


Field Type Default Description
id int(10) auto-incrementing
name varchar(150) Name of function - Appears on the admin page
enabled int(1) function enabled, function might be disabled for security reasons - The only field editable by administrator !
phpfile varchar(255) location where function defined - Needed for identifying

external_services table

Service is defined as a group of functions.


Field Type Default Description
id int(10) auto-incrementing
name varchar(150) Name of service (gradeexport_xml_export, mod_chat_export) - appears on the admin page
enabled int(1) service enabled, for security reasons some services may be disabled - The only editable field by the admin
custom int(1) 0 Custom local service, created manually by admin or some other way (CAN BE updated automatically during the cron job => function not existing get removed). This field is useful if we want to implement an admin page where the admin selects some functions from a list of all external functions. Note: we probably need a button to desactivate all services in once.

external_services_functions table

Specifies functions used by services.

Field Type Default Description
id int(10) auto-incrementing
externalserviceid int(10) foreign key, reference external_services.id
externalfunctionid int(10) foreign key, reference external_functions.id


Avalaible method for discovery

This paragraph exists only to define the way we'll descrive the web services. There are three possible ways to describe web services:

  1. a PHP array : this array will contains all params + return value. In this array we also need to make a difference between array and object. PHP Associative array has to be defined as object.

For the purpose to be compatible with many languages we should see array as list and Associative array as object. It makes me think that we should probably only deal with object, not associative array.
This "array" solution has been implemented till revision 1.10 of user/external.php (CVS Head). This solution is the fastest in term of performance and should be the easier to use in order to create the servers. The way to define array/object has not been really well fixed!

  1. Zend reflexion + phpdoc new annotation: in this solution we use new "Moodle phpdoc annotation" in order to describe the web services. Have a look to the last revision 1.17. This solution avoid all redundancy, however it's harder to implemente, lass faster, and more difficult to maintain
  2. a XML file : a XML should contains all web service description. This solution is probably the more human readable (if xml is well designed).


Another point to come to, all external function should return always the same type of object (no new or missing attribut). PHP Array should be considered as list.

PHP array description

$this->descriptions['function_name'] = array( 'params' => array('params_name'=> PARAM_STRING),

                                      'optionalparams' => array( ),
                                      'return' => array('list:param_1' => 
                                                           array('attribut_1' => PARAM_INT, 
                                                                 'attribut_2' => PARAM_STRING, 
                                                                 'attribut_3' => PARAM_INT)));

Explanation:

  • base is:

$this->descriptions['function_name'] = array( 'params' => array(),

                                                           'optionalparams' => array( ),
                                                           'return' => array());

  • when a param/return is a list so it should be called 'list:param_name'
  • when a param/return is not a list so it's either a primary type (e.g. PARAM_STRING), either a object (e.g. array)
  • params and optionalparams have to follow the exact order of the function
  • PARAM_RAW has to be replaced by the correct type (cannot be array)

Way to fill the database tables

Fill the external_functions, external_services and external_services_functions tables from a XML file like xmldb install.

Return values are filtered by the servers

External function should be able to return whatever they want. Each server should be looking at the web services description and return the expected values.