You are here

README.txt in Web Service Clients 7.3

Clients module
==============

The Clients module aims to provide a simple way to manage connections to remote
sites, and the resources that they provide.

Connections and resources are exportable via the EntityAPI and thus can be added
to Features.

Requirements
============

Clients requires the following modules:

- Entity API

Connections and Resources
=========================

Clients module provides a simple UI for creating, editing, and testing
connections to remote sites.

There are two ways to use a connection:

- Connections can be called directly to make calls/requests to remote services.
- Resources can be defined on top of clients. These take care of handling the
  remote connection in a way that is transparent to the rest of Drupal. For
  example, a remote block resource would take care of declaring the various
  block hooks, and caching retrieved results. The remote block provided would
  function exactly like a normal, local block.

Connection substitution
=======================

It's possible to have the same connection machine name load different
connections depending on the site's environment. This is based on the value of
the 'environment_name' site variable. When loading a connection, the environment
name as defined by this variable is appended to the requested connection name,
and if this results in the name of another connection, that is loaded instead.

This allows a development site to connect to a development version of a service
without any changes in code.

For example:

// Just loads the foobar connection.
$connection = clients_connection_load('foobar');

variable_set('environment_name', 'dev');
// Loads the foobar_dev instead, if it exists. Otherwise, loads foobar.
$connection = clients_connection_load('foobar');


Using connections directly
==========================

The Clients connection object lets you call methods on remote sites very
simply, without having to deal with tokens, keys, and all that sort of
stuff.

Once a connection is defined in the admin UI, you can call a remote method on it
like this:

  try {
    // 'my_connection' is the machine name of the connection.
    $result = clients_connection_call('my_connection', 'method.name', $param1, $param2, $param_etc);
  }
  catch (Exception $e) {
    // Something went wrong; it's up to you to display an error.
    // This is the error message, if any:
    $message = $e->getMessage();
  }

So for example, to load a node from a remote Drupal site, do:

  try {
    $node = clients_connection_call('my_connection', 'node.get', $remote_nid);
    // Note that the $node will be an array.
  }
  catch (Exception $e) {
    drupal_set_message("Error loading a remote node.");
  }

If you need to make several calls, you can use the connection object yourself:

  $connection = clients_connection_load('my_connection');
  try {
    $result = $connection->callMethod('method.name', $param1, $param2, $param_etc);
  }
  catch (Exception $e) {
    drupal_set_message("Error calling method.name.");
  }

Debugging mode
==============

Each connections may have a debug mode flag set. Note that at this time not all
connection types support this (and may thus simply not provide any output).

Debug output may be sent to the following channels:

  - watchdog: The usual Drupal core watchdog. This may not be suitable for
      large data.
  - dpm: Devel module's dpm() function.
  - ddl: Devel Debug Log module's ddl() function.
  - dd: (Not used by default) Devel module's dd() function.

The channels used can be overridden by defining an array of the above names
as keys in the site variable 'clients_debug_channels'.

Extending the testing system
===========================

You can extend the connection testing system to provide tests that are specific
to your particular system.

- define connection test classes. See ClientsConnectionDrupalTestConnect for
  an example.
- to make your test class available, either:
  - implement hook_clients_connection_type_info_alter() to add your test class
    to all connections of a given type.
  - implement hook_client_connection_tests_alter() to add your test to a single
    connection.

Defining Connection types
=========================

To define your own connection type, you need:

- an implementation of hook_clients_connection_type_info().
- a class definition for your connection type. This should be named
  'clients_connection_YOUR_TYPE_ID' and implement the following methods:
  - connectionSettingsFormAlter(), which should add your configuration form
    elements to the FormAPI array for your connection type's edit form.
  - connectionSettingsForm_submit(), which should provide any processing of
    the form specific to your connection type.
  - callMethodArray(), which should call a remote method and return the result.

File

README.txt
View source
  1. Clients module
  2. ==============
  3. The Clients module aims to provide a simple way to manage connections to remote
  4. sites, and the resources that they provide.
  5. Connections and resources are exportable via the EntityAPI and thus can be added
  6. to Features.
  7. Requirements
  8. ============
  9. Clients requires the following modules:
  10. - Entity API
  11. Connections and Resources
  12. =========================
  13. Clients module provides a simple UI for creating, editing, and testing
  14. connections to remote sites.
  15. There are two ways to use a connection:
  16. - Connections can be called directly to make calls/requests to remote services.
  17. - Resources can be defined on top of clients. These take care of handling the
  18. remote connection in a way that is transparent to the rest of Drupal. For
  19. example, a remote block resource would take care of declaring the various
  20. block hooks, and caching retrieved results. The remote block provided would
  21. function exactly like a normal, local block.
  22. Connection substitution
  23. =======================
  24. It's possible to have the same connection machine name load different
  25. connections depending on the site's environment. This is based on the value of
  26. the 'environment_name' site variable. When loading a connection, the environment
  27. name as defined by this variable is appended to the requested connection name,
  28. and if this results in the name of another connection, that is loaded instead.
  29. This allows a development site to connect to a development version of a service
  30. without any changes in code.
  31. For example:
  32. // Just loads the foobar connection.
  33. $connection = clients_connection_load('foobar');
  34. variable_set('environment_name', 'dev');
  35. // Loads the foobar_dev instead, if it exists. Otherwise, loads foobar.
  36. $connection = clients_connection_load('foobar');
  37. Using connections directly
  38. ==========================
  39. The Clients connection object lets you call methods on remote sites very
  40. simply, without having to deal with tokens, keys, and all that sort of
  41. stuff.
  42. Once a connection is defined in the admin UI, you can call a remote method on it
  43. like this:
  44. try {
  45. // 'my_connection' is the machine name of the connection.
  46. $result = clients_connection_call('my_connection', 'method.name', $param1, $param2, $param_etc);
  47. }
  48. catch (Exception $e) {
  49. // Something went wrong; it's up to you to display an error.
  50. // This is the error message, if any:
  51. $message = $e->getMessage();
  52. }
  53. So for example, to load a node from a remote Drupal site, do:
  54. try {
  55. $node = clients_connection_call('my_connection', 'node.get', $remote_nid);
  56. // Note that the $node will be an array.
  57. }
  58. catch (Exception $e) {
  59. drupal_set_message("Error loading a remote node.");
  60. }
  61. If you need to make several calls, you can use the connection object yourself:
  62. $connection = clients_connection_load('my_connection');
  63. try {
  64. $result = $connection->callMethod('method.name', $param1, $param2, $param_etc);
  65. }
  66. catch (Exception $e) {
  67. drupal_set_message("Error calling method.name.");
  68. }
  69. Debugging mode
  70. ==============
  71. Each connections may have a debug mode flag set. Note that at this time not all
  72. connection types support this (and may thus simply not provide any output).
  73. Debug output may be sent to the following channels:
  74. - watchdog: The usual Drupal core watchdog. This may not be suitable for
  75. large data.
  76. - dpm: Devel module's dpm() function.
  77. - ddl: Devel Debug Log module's ddl() function.
  78. - dd: (Not used by default) Devel module's dd() function.
  79. The channels used can be overridden by defining an array of the above names
  80. as keys in the site variable 'clients_debug_channels'.
  81. Extending the testing system
  82. ===========================
  83. You can extend the connection testing system to provide tests that are specific
  84. to your particular system.
  85. - define connection test classes. See ClientsConnectionDrupalTestConnect for
  86. an example.
  87. - to make your test class available, either:
  88. - implement hook_clients_connection_type_info_alter() to add your test class
  89. to all connections of a given type.
  90. - implement hook_client_connection_tests_alter() to add your test to a single
  91. connection.
  92. Defining Connection types
  93. =========================
  94. To define your own connection type, you need:
  95. - an implementation of hook_clients_connection_type_info().
  96. - a class definition for your connection type. This should be named
  97. 'clients_connection_YOUR_TYPE_ID' and implement the following methods:
  98. - connectionSettingsFormAlter(), which should add your configuration form
  99. elements to the FormAPI array for your connection type's edit form.
  100. - connectionSettingsForm_submit(), which should provide any processing of
  101. the form specific to your connection type.
  102. - callMethodArray(), which should call a remote method and return the result.