Disclaimer: This is a rather technical article on how exactly support for Attachments work in CRMfO.
The following images visualizes the flow of the program whenever an activity (or other document) is created with an attachment (the colored parts are the parts running syncronously):
As is evident CRMfO relies heavily on asyncronous calls for this process as the user would otherwise suffer unacceptable hangs if they had to wait for uploads to finish. The two timers (on the client and the server) run constantly waiting to pick up files to either upload or download from the selected storage account, and the communication between the client and the server itself also runs asynchronously in order to avoid constant lockups and hangups in the client from bad connections or congestion.
This ensures optimum performance at all times, but it also causes a few idiosyncracies and things to be aware of:
- There can be a (not insignificant) delay between an activity being created with attachment(s) and those attachments being available on the server. Particularly for large size attachments and/or low bandwidth connections.
- It's possible for the client to be closed before background upload is done. This will also terminate the timer running in the background. However, it will pick back up on next startup of the CRMfO client and should complete the upload then.
- If an upload should fail 100 times the client will give up and place the file in "%appdata%\Boyum IT\CRM for Outlook\Attachments\Uncommitted" from whence it can be collected and if needed manually copied to the server's attachments folder
- It's possible for the upload from the client to work - but the download from the server/upload to SAP to fail. Perhaps due to network errors on the server, missing support for SSL/TLS or missing write permissions tot he attachments folder for the user running CRMfO Server component service. In that case the file will remain in the storage account selected for use with attachments and can be copied manually to the attachments folder if needed. The server should keep trying to get those files as well.
In all of those cases the end-user will not see an error since those errors occured "off-thread" in asyncronous calls - potentially long after the initial creation of the activity - and the creation of the activity itself happened flawlessly. These errors are primarily diagnosed through the existence of 0kb dummy files among the attachments or through the Eventlogs of the client and server component.