Introduction

This script allows you to test your installation of the D2L Web Services. You would use this for testing or debugging individual SOAP calls.

Author: Thomas Hawkins (thawkins@mun.ca)
Version: 1.0.0
Released: Dec. 22, 2010
License: http://creativecommons.org/licenses/by-nc-sa/3.0/

License Information

This code is made available by the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license. You can learn more about it here: http://creativecommons.org/licenses/by-nc-sa/3.0/

In addition to the license restrictions, I would appreciate if any improvements to this script flowed back to me so that they can be distributed to the rest of the community.

Download

Here is a .zip file containing the scripts.

d2l-php-ws-test.zip 12.1kb

Installation

  1. Make sure your environment meets the requirements.
  2. Make sure you meet the framework D2L requirements.
  3. Download and copy the files to a web accessible location
    • README.txt
    • API/auth.php
    • API/config.php
    • tests/stage1.php
    • tests/stage2.php
    • tests/stage3.php
    • tests/stage4.php
    • tests/styles/default.css
    • tests/message.php
    • wsdl/
      • This is an empty folder. I highly recommend you download all of your WSDL/xsd files, and place them in this folder. This should greatly increase speed when accessing the system. These files can be found in your D2L installation: {DRIVE}:\Desire2Learn\instances\{INSTANCE NAME}\D2LWS\Schemas
  4. Start testing. You will need to access the stage1.php file to begin.
  5. If you run into trouble, check the troubleshooting section.

PHP Requirements

  • PHP 5 or greater (Not sure exactly which version would be the minimum. My test server is running 5.2.9)
  • PHP native SOAP extension (Compile with –enable-soap)

D2L Requirements

The testing framework, and the API in general, are designed with the assumption that you will use a single account for your web services transactions. You must have an account in D2L with the permissions required to do what you want. For testing and debugging, I suggest an administrator account with an obscure username and password combo.

The full API does basic token management for you, if you use the global username/password approach noted above. However, if you want users to authenticate with their own information, you can create the tokens yourself, pass them into the functions, and then ensure that users only have their D2L level of access to the API. This is discussed in more detail on the full API page.

Configuration File Explained

The configuration file defines a series of constants that are used in the testing script, and the D2L PHP API. This allows you to set up a series of profiles that cane be used on production, testing, development, etc servers. You can maintain one configuration file with multiple configurations. You can then tweak the profile variable to the configuration you want in each situation.

The Server Profile Settings are the remote settings for the application. The Location Profile Settings refer to the WSDLs stored locally.

In both switch blocks you can define additional profiles. Shipped with the code are two profiles: prod and dev.

An explanation of the settings follows:

Variable Description Required Notes
D2LWS_USER The username of the user in D2L that will be preforming the web services calls. This is required for the testing script. This user should have the required permissions to make the calls that you need, otherwise they will fail. Yes
D2LWS_PASSWORD This is the password for the above account. Yes
WSDL_AUTH This is the remote location of the WSDL for authentication. This is included in all D2L installations. You probably only need to enter your installations root URL in this path (but you may need to update the whole thing). The root url would be something like http://www.yoursite.com. I can't remember why I didn't download this file with the other WSDLs when I set this up originally, but I imagine I had a good reason. Yes Base Install
ENDPOINT_AUTH Where web service calls go that are to the Authentication Services. You should only need to update the root URL. Yes Base Install
ENDPOINT_GRADE
ENDPOINT_USER
ENDPOINT_ORG
Where web service calls go that are to the Grade Management\User Management\Org Management Services. You should only need to update the root URL. Yes Web Services
SECURITYTOKEN This is a token you set in the DOME. All calls are required to have this token. Yes Web Services
INSTALLCODE This is a code that is set by D2L when they install your web services. Yes Web Services
ENDPOINT_GUID This is the endpoint of the GUID service that is needed if you have a single signon installation. I did a bit of work with this in the API, but it was not fully developed. No SSO
WSDL_GUID This is the WSDL for the GUID service, which is required for the single signon. No SSO
WSDL_GRADE
WSDL_USER
WSDL_ORG
These variables point to the Grade Management\User Management\Org Management Services WSDL files that are stored on the local system. You should only need to update the root URL. Yes Web Services
DEVKEY Your D2L Developer Key Yes

Variables that you shouldn't change without good reason:

Variable Description Required
WSDL_NS_USER The Namespace for the requests for the User Management Service. Yes
WSDL_NS_ORG The Namespace for the requests for the Org Management Service. Yes
WSDL_NS_GRADE The Namespace for the requests for the Grades Management Service. Yes
D2LWS_URI_COMMON A common Namespace used across all requests. Yes

Testing Examples

Troubleshooting

d2l/webservicestesting.txt · Last modified: 2010/12/22 16:01 by cornmaster
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0