Table of Contents
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
- Make sure your environment meets the requirements.
- Make sure you meet the framework D2L requirements.
- 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
- Edit the configuration file
- Start testing. You will need to access the stage1.php file to begin.
- 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
