Before attempting to integrate imip-agent with other system components, it can be useful to check whether the different programs function as expected by themselves. Should errors or faults occur, these would need to be remedied first before attempting to get the software working with the mail and Web system components.
How the Software Works
To see how the software operates, you can run one of the agent programs provided in the distribution. For example:
./imip_resource.py -S xxx/store -P xxx/static -p xxx/prefs -d \ < tests/templates/event-request.txt
This uses one of the test files, sending it to the agent program for resource entities, producing output resembling the following:
Outgoing parts for email@example.com... From nobody Wed Oct 28 00:24:41 2015 MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/calendar; charset="utf-8"; method="REPLY" From: firstname.lastname@example.org To: email@example.com Subject: Calendar system message QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVQTFkNClZFUlNJT046Mi4wDQpCRUdJTjpWRlJFRUJV U1kNCk9SR0FOSVpFUjptYWlsdG86cGF1bC5ib2RkaWVAZXhhbXBsZS5jb20NCkFUVEVOREVFO1NF TlQtQlk9Im1haWx0bzpjYWxlbmRhckBleGFtcGxlLmNvbSI6bWFpbHRvOnJlc291cmNlLXJvb20t Y29uZnJvb20NCiBAZXhhbXBsZS5jb20NClVJRDpmYjFAZXhhbXBsZS5jb20NCkVORDpWRlJFRUJV U1kNCkVORDpWQ0FMRU5EQVINCg==
The rather opaque encoding can be inspected using the tools/showmail.py program, and thus the result of the script can be seen by piping the output through that program as follows:
./imip_resource.py -S xxx/store/ -P xxx/static/ -p xxx/prefs/ -d \ < tests/templates/event-request.txt \ | tools/showmail.py
The result should resemble the following:
Outgoing parts for firstname.lastname@example.org... MIME-Version: 1.0 Content-Type: text/calendar; charset="utf-8"; method="REPLY" From: email@example.com To: firstname.lastname@example.org Subject: Calendar system message BEGIN:VCALENDAR METHOD:REPLY VERSION:2.0 BEGIN:VEVENT DTSTAMP:20151027T232738Z UID:email@example.com ATTENDEE;PARTSTAT=ACCEPTED;SENT-BY="mailto:firstname.lastname@example.org":mailto:reso email@example.com SUMMARY:Meeting at 4pm ORGANIZER:mailto:firstname.lastname@example.org DTSTART;TZID=Europe/Oslo:20141126T160000 DTEND;TZID=Europe/Oslo:20141126T170000 END:VEVENT END:VCALENDAR
What has happened here is the presentation of a request to the resource program in the form of an e-mail message containing an iCalendar event employing a scheduling method. The program interprets the request, consults its own records, makes a decision about scheduling the event, and indicates the kind of response it would like to send back to the requester.
The Test Suite
A script called test_all.sh is provided that runs a test suite (found in the tests directory within the source code distribution), initialising new and separate data store instances for each test, running programs that are presented with message content, and testing for the desired effects of running those programs with such content.
The test suite by default (or by indicating file as the data store type), records test information in subdirectories of /tmp.
The test suite records postgresql tests in a specially-created database called imip_agent_test that the system user running the tests must be allowed to create and drop. This may require the granting of administrative rights within PostgreSQL for the system user concerned.
Individual tests may also be run directly from the topmost level of the source code distribution. For example:
Should everything be functioning correctly, Success should be reported repeatedly as opposed to Failed. If the latter occurs, the output of the tests should be inspected: a number of files whose names end with .tmp will have been saved in the current directory, and these will contain the output from various commands from the last test script invocation; the err.tmp will contain tracebacks indicating serious error conditions, should any have occurred.
Testing in the Deployment Environment
Although the above testing may indicate that the software is functional, it does not demonstrate that the software has been successfully integrated into the deployment environment. One elementary test involves sending mail to an address that should be configured to handle incoming calendar messages.
A basic script is provided that replicates a subset of the functionality in the traditional mail command for sending messages. It is invoked by specifying the sender and recipients of a message and by passing the message itself to the script's standard input. For example:
tools/sendmail.py email@example.com firstname.lastname@example.org \ < tests/templates/event-request.txt
Here, the sender (email@example.com) and recipient (firstname.lastname@example.org) must match the identities specified within the supplied file (tests/templates/event-request.txt), and for a specific deployment environment these identities will need to be changed. The following lines from the supplied file would be involved:
From: email@example.com To: firstname.lastname@example.org ORGANIZER:mailto:email@example.com ATTENDEE;ROLE=CHAIR:mailto:firstname.lastname@example.org ATTENDEE;RSVP=TRUE:mailto:email@example.com
It makes most sense to choose a recipient acting as a resource so that an automated response may be generated with the sender receiving this response. However, other kinds of recipients may also be tested in this way.
The result of this invocation will become known via the following sources of information:
- The sender's mailbox (if the recipient sends an automated response)
- The sender's data store
- The recipient's mailbox (if the recipient is configured to store mail)
- The recipient's data store
- Mail system logs (particularly in case of errors)
See the mail integration guide for more information about configuring and troubleshooting mail systems.