Publishflow Block : MNET Services: Difference between revisions
(r) |
|||
Line 5: | Line 5: | ||
Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth. | Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth. | ||
==Service : | ==Service : publishflow== | ||
===Description=== | ===Description=== | ||
This service is used to | This service is used to hold all RPC related functions for publishflow operations. | ||
===Functions=== | ===Functions=== | ||
delivery_get_sessions() : get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node. | delivery_get_sessions() : get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node. | ||
==Service : coursedelivery_admin== | ==Service : coursedelivery_admin== |
Revision as of 21:29, 28 September 2012
Publishflow implements a set of MNET services in order to perform proper across MNET operations.
Here comes the list of MNET XML-RPC functions that are provided by the blocks XML-RPC API.
Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth.
Service : publishflow
Description
This service is used to hold all RPC related functions for publishflow operations.
Functions
delivery_get_sessions() : get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node.
Service : coursedelivery_admin
This service is used to register course delivery commands.
Functions
delivery_deliver(): get a course backup from a remote platform. If data transfer is done using local file system, will only give information about the physical location of a course archive.
delivery_deploy(): deploys a course archive where called. This function has to be called remotely from the archive originator that will drive the deployement process (i.e. the deployment IS NOT initiated from the platform you want the course coming in, but where it goes out).
delivery_publish(): similar to the deployment function, but there are some particularities when dealing between a Course Factory and a Course Catalog Moodle instances.
publishflow_updateplatforms(): This function is called by other hosts in a MNET to explore the network and determine which instances are in the MNET neighborhood.
Other Unregistered XML-RPC Calls
The following functions entries are XML-RPC functions that were setup for external control of the deployement. They are not registered into MNET services.
Function name: publishflow_rpc_deploy
purpose: Asking from an external system to deploy a course somwhere in the network.
parameters:
- callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
- idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
- courseidentifier: The value that identifies the course backup, regarding what was choosen as idfield.
- wherewwwroot: the HTTP root identifying the MNET host where to deploy.
- parmsoverride: a structure that can override any value of the Moodle "course" record thus deployed instance can have its name, shortname or starting date changed. OPTIONAL.
- json_response: if true, the response is JSONed for convenience with remote XML-RPC implementation.
Function name: publishflow_rpc_close_course
Purpose: Asks a remote node to close a course (regarding the course life-cycle handling by the publishflow block)
Parameters:
- callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
- idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
- courseidentifier : the value that identifies the course to be closed, regarding what was choosen as idfield.
- wherewwwroot: the HTTP root identifying the node where the course needs to be closed
- mode: The closing mode (see publishflow Course life-Cycle in Training Nodes)
- json_response: (see above).
Alternate form of the external RPC calls
Some external applications (ERPs) do not provide support for shooting RPC calls with separate parameters (OfBiz). the two functions above are also available in a wrapped alternate form :
publishflow_rpc_deploy_wrapped($wrap) publishflow_rpc_close_course_wrapped($wrap)
the wrap is an associative array grouping all required parameters in to a single parameter data bundle. these functions are given as 'adaptors' for that special situations.