Microsoft Exchange Connector Tool – Retrieving attachments in calendar items

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:

  1. A general familiarity with TaskCentre and the Microsoft Exchange Connector Tool;
  2. One or more Exchange connections;
  3. One or more calendar items with attachments on which to perform the operations; and
  4. 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:

SupplementaryReferenceAny valueThis field is used to pass a value through the operation to appear in
the response and can be any value required.
ExchangeCalendarIdAAMkAGRhNjJiN2…The full ID retrieved earlier.
This field is mandatory.
SavedAttachmentFolderC:\Saved AttachmentsThis 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.
SavedInlineAttachmentFolderC:\Saved AttachmentsThis 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.
NameFormatMD5This 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.

Microsoft Exchange Integration Brochure

Microsoft Exchange Integration Brochure

Learn how integrating Microsoft Exchange with business applications increases the visibility of key information and enhances employee productivity.

Download Brochure