Introduction #
This article will show how to use the new functionality provided in version 4.3 of the Microsoft Exchange Connector Tool to retrieve attachments contained in a calendar item. Exchange 2013 and 2016 will be contrasted and calendar items in both local and public folders will be used.
Prerequisites #
To be able to follow this article and design similar tasks requires:
- A general familiarity with TaskCentre and the Microsoft Exchange Connector Tool;
- One or more Exchange connections;
- One or more calendar items with attachments on which to perform the operations; and
- The ExchangeCalendarId for these calendar items.
ExchangeCalendarId #
The only mandatory field for performing a Get operation on a Calendar Item is the ‘ExchangeCalendarId’ which contains the unique identifier for the calendar item. This may be obtained in two main ways:
- In the response to ‘Create’; ‘Find’; or ‘Find Occurrences’ operations.
- In a notification from a subscribed Exchange event.
Example 1 – Exchange 2013 Local Folder #
In this example an Exchange 2013 mailbox has a calendar item located in ‘Backup\Alternative Calendar’ for which the attachments will be retrieved. This is seen in Outlook 2013 as:
…and when opened contains:
Note that in the calendar item everything appears within the body. The spreadsheets; Word document; zip file; and image are all inline along with the text. There is no distinction between the attachments that Exchange actually regards as ‘inline’ and those that are discrete (sometimes called ‘regular’) attachments. Also be aware that two attachments have identical names (‘Example Spreadsheet.xlsx’) which is not possible within a file system.
In the Get operation, the following fields were populated using variables:
| SupplementaryReference | Any value | This field is used to pass a value through the operation to appear in the response and can be any value required. |
|---|---|---|
| ExchangeCalendarId | AAMkAGRhNjJiN2… | The full ID retrieved earlier. This field is mandatory. |
| SavedAttachmentFolder | C:\Saved Attachments | This is where the Tool will create the unique folder for this calendar item in which to save attachments that Exchange doesn’t regard as inline. If the folder doesn’t exist, the Tool will attempt to create it. |
| SavedInlineAttachmentFolder | C:\Saved Attachments | This is where the Tool will create the unique folder for this calendar item in which to save attachments that Exchange regards as inline. If the folder doesn’t exist, the Tool will attempt to create it. |
| NameFormat | MD5 | This field determines the naming convention to be used when creating the unique folder for this calendar item. If it is left empty, or ‘ExchangeCalendarId’ is provided, then a representation of the Exchange unique Id will be used. If ‘MD5’ is provided then the shorter – but still unique – MD5 folder name will be used. |
Queueing a task containing this step results in a folder being created containing five attachments:
The duplicates have both been saved by appending a ‘(1)’ to the name of the second spreadsheet. The inline image has been given the name ‘ATT07366’ by Exchange, but is actually a JPEG and can be viewed by adding the ‘.jpg’ file extension.
Removing the mapping for either ‘SavedInlineAttachmentFolder’ or ‘SavedAttachmentFolder’ – or giving them paths to different folders – shows that the full set of attachments can only be retrieved by using both nodes, as the difference between ‘regular’ attachments and ‘inline’ attachments cannot be otherwise distinguished.
In the response to the Get, the folder name used is returned in the SavedName field and ‘regular’ attachment Name and Size values are also given:
The response does not detail ‘inline’ attachments – they are not regarded by Exchange as being discrete objects.
Combining the ability to save attachments with the detail provided in the response allows for a business process to associate the contents of the (attachments) folder with the original calendar item.
Example 2 – Exchange 2016 Public Folder #
Here Exchange 2016 has a calendar item in the public folder located at ‘Public Folder Root\Public Calendar’ (as seen in Outlook 2016):
…and when opened contains:
Notice how ‘regular’ attachments are no longer stored within the body of the calendar item as they were in Exchange/Outlook 2013.
For the Get, the ‘NameFormat’ field was left unmapped and different locations for each type of attachment were given (‘C:\Saved Attachments\Regular’ and ‘C:\Saved Attachments\Inline’). As a result of queuing a task containing this step, the following output was generated:
As can be seen above, the ‘regular’ attachments are in their own folder which uses the longer – default – folder name based on the ExchangeCalendarId. Similarly, the ‘inline’ attachment is in its own folder. In this case, Exchange has provided two versions of the same image – once as a PNG and once as a JPEG – the PNG is the original version and the JPEG a copy resized to the same dimensions as found in the calendar item.
Conclusion #
It has been demonstrated that there are differences in the handling of calendar attachments between the Exchange versions and the underlying business process may need adjusting to cater for these. In contrast, the location of the calendar item itself is irrelevant once the ExchangeCalendarId has been retrieved.
