1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
= Testing =
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 [[../MailIntegration|mail]] and [[../WebServerIntegration|Web]]
system components.
<<TableOfContents(2,2)>>
== 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 paul.boddie@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: calendar@example.com
To: paul.boddie@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 paul.boddie@example.com...
MIME-Version: 1.0
Content-Type: text/calendar; charset="utf-8"; method="REPLY"
From: calendar@example.com
To: paul.boddie@example.com
Subject: Calendar system message
BEGIN:VCALENDAR
METHOD:REPLY
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20151027T232738Z
UID:event1@example.com
ATTENDEE;PARTSTAT=ACCEPTED;SENT-BY="mailto:calendar@example.com":mailto:reso
urce-room-confroom@example.com
SUMMARY:Meeting at 4pm
ORGANIZER:mailto:paul.boddie@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.
== 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.
{{{
./test_all.sh
}}}
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
[[../DatabaseStore|database store]] instead of the [[../FileStore|file store]],
the `STORE_TYPE` environment variable can be specified as in the following
example:
{{{
STORE_TYPE=postgresql ./test_all.sh
}}}
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:
{{{
tests/test_resource_invitation.sh
}}}
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 paul.boddie@example.com resource-room-confroom@example.com \
< tests/templates/event-request.txt
}}}
Here, the sender (`paul.boddie@example.com`) and recipient
(`resource-room-confroom@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: paul.boddie@example.com
To: resource-room-confroom@example.com
ORGANIZER:mailto:paul.boddie@example.com
ATTENDEE;ROLE=CHAIR:mailto:paul.boddie@example.com
ATTENDEE;RSVP=TRUE:mailto:resource-room-confroom@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 [[../MailIntegration|mail integration guide]] for more information
about configuring and troubleshooting mail systems.
|
