Overview for Developers

Wednesday, Oct 21, 2015

Developers often have limited time to get up to speed with the internal configuration or workings of CourseSales.com. They wish to spend time on integration not getting to know the whys and wherefores of how the training organisation is using the software. This will hopefully help designers and developers get and environment that they can work with during integration. This exerpt is addressed to developers, who we assume have been contracted/engaged to integrate CourseSales.com course listing or forms into a website.

If possible ask the training organisation contact to create the following, though perhaps this is all new for them and they would either like you or CourseSales.com to do this. If you use Selenium IDE we have scripts that you can use to create test configurations within your production site. We can also supply you with a test environment, which is found at [shortname].test.coursesales.com, we copy of the existing production database to the test environment after each major release. This effects all sites, and overwrite all test data.

Where should I do the development/integration?

You can either choose to use the production environment (that is, the standard site) or a test environment.

Environments, where to do your testing/development

Production (live) environment, this is the standard login eg https://ccl.coursesales.com, it is where customer data is updated and stored. Customers and staff interact daily with this site. It is our top priority for functioning smoothly.

Test environment, this is accessible by anybody, but not indexed by search engines etc, it sends no emails to anyone other than those specified by a configuration file so cannot be used to interact with customers. The test environment is the equivalent of another license - so effectively TWO licenses are paid during its use.

Note
If you create a complex configuration in test you must MANUALLY move that to production. Alternatively use our selenium scripts to automate the transfer of the configuration

Recommendations when integrating CourseSales.com

  • Use a test environment where possible (see above), this means minimizing test/trial emails to customers/staff needlessly.

  • Automate, where possible, configurations to easily transfer from one environment to another.

  • If using production (live) environment create a set of test data, by default we have a set of test data including: Locations, Venue, course masters, forms etc.

  • Control who receives emails/notifications by adding a set of test users with different emails and roles and add these to the course masters.

  • Put External reference numbers at the bottom of all emails sent out so you can refer to them in the future.

  • Keep in mind that the test environment has ACTUAL customer data (actually a duplicate at the time of transfer) - treat it with a much care as you do the production (live) environment.

Common issues when doing testing

Can’t see courses in public course listing. Check:

  • That the course date and course master are ‘public’ (if the date is public but the master is private the course dates will NOT show, if the Master is public and the course dates are private the course dates will NOT show).

  • That there is a user with the internal type ‘soap’, who has a password and username (you don’t need the username and password unless using the API)

  • That you are using the correct URL, ie ccl.test.coursesales.com/public/courses?h=1 only if the data is in the TEST environment.

  • Do you have scheduled courses (completed or canceled courses will not display on the public site)

Public vs Private courses

Integrating CourseSales.com usually means displaying public courses that the general public can purchase from a list of offered dates available. Training companies that deliver in-house (private) courses also need to take registrations however these are not usually offered to the public for registration. The other difference is that private courses don’t usually include payments at the point of registration (a private course usually has a single payment contact, so individuals don’t need to receive invoices etc). It is not practical to use private course dates as test courses during development because:

  • The document forms will not include the payment method

  • Invoices will not work and payment options, eg. paypal, will not be displayed

  • Private courses will not display on the public site

  • Private courses usually have a different process path, that does not include things like two-step registration or certain gather gathering activities (private courses usually require less information) nor human captcha fields.

A note for organisations with online courses

Online courses have effectively an unlimited number of course start dates, as each student could start a course at a different time. As CourseSales.com caters for face to face training online courses are still treated as a date delivered ‘course’ (as this is required for AVETMISS reporting). So you need to set up a course for each online course that, while it remains manageable, can take all registrations for a year. For this reason linking to the course listing is less likely to be useful, instead you might wish to link to the registration form, and make the course private (forms still work via the public site for all courses, even if the course date is private).

See Find a Course ID

Online payment methods - using sandbox/test options

By default CourseSales.com includes a sandbox paypal configuration. This will need to be adjusted before live use however it does a good job of providing a safe environment for testing how the payment method works. We can supply test signins for Mastercard and Visa payments. Other payment methods such as WorldPay also work, the test environment uses the following code to define the transactions as test:

<input type="hidden" name="testMode" value="100">

Plugin/integration with third party software

We encourage community supported integration for third party software applications like website content management systems, bulk email senders, accounting packages, learning management systems etc. Some plugins are supported by CourseSales.com, eg AVETMISS, Drupal & Moodle. We are willing to share the code for these plugins so you can see how these work, and use as a base for your own plugins. We do so with the understanding that the plugins will be made freely available to other users, with appropriate acknowledgement to CourseSales.com and any third party code we have used.

Contact us for specifics or to put you in touch with others who might also like to contribute in the development of the plugin.