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.
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 firstname.lastname@example.org... 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: email@example.com To: firstname.lastname@example.org 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 email@example.com... MIME-Version: 1.0 Content-Type: text/calendar; charset="utf-8"; method="REPLY" From: firstname.lastname@example.org To: email@example.com Subject: Calendar system message BEGIN:VCALENDAR METHOD:REPLY VERSION:2.0 BEGIN:VEVENT DTSTAMP:20151027T232738Z UID:firstname.lastname@example.org ATTENDEE;PARTSTAT=ACCEPTED;SENT-BY="mailto:email@example.com":mailto:reso firstname.lastname@example.org SUMMARY:Meeting at 4pm ORGANIZER:mailto:email@example.com 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.
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.
To run all tests against a different data store, such as a database store instead of the file store, the STORE_TYPE environment variable can be specified as in the following example:
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.
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 firstname.lastname@example.org email@example.com \ < tests/templates/event-request.txt
Here, the sender (firstname.lastname@example.org) and recipient (email@example.com) 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: firstname.lastname@example.org To: email@example.com ORGANIZER:mailto:firstname.lastname@example.org ATTENDEE;ROLE=CHAIR:mailto:email@example.com ATTENDEE;RSVP=TRUE:mailto:firstname.lastname@example.org
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:
See the mail integration guide for more information about configuring and troubleshooting mail systems.