I met with some of the senior developers at work yesterday. They were happy to see what I had done up until this point, which was:
Code a DB controller app:
- Connect to a DB, at first through a SqlConnection object but potentially allowing a future expansion (ie. WebServices)
- Find the appropriate tables in the database for the scheduler (which was interesting due to quite a few tables in the system database)
- Connect scheduler tasks with several other database tables in the system to gather related info which is important (like the Job location for example)
- Grab the schema for the resulting view and send it to the add-in, allowing for the user to select which fields they wanted
- Delivered information as per the schema the user requested
This provided a data access layer for the add-in, allowing for the controller app to decide how it wants to get the information.
The add-in simply:
- Asks for tasks for a specific user
- Formats them into AppointmentItems
- Populates the AppointmentItems fields with information related to the desired schema, and a primary key to prevent duplicates
- Provides an interface to view the schema and choose appropriate fields
- Adds a right click context menu to allow specific actions and links back to the Nimbus system specifically for Outlook appointments gathered from the scheduler
The meeting was originally for me to inform them of the software restrictions and thus what version we could support; as well as asking about the data access layer the system already had. What ended up happening was a discussion the benefits and drawbacks to my potential implementation, which lead us down a path of wondering about working with an exchange server directly. This has limitations on only working with an Exchange server obviously, but has benefits of being applicable to any interface (ie. the appointments would show in any version of Outlook, including web interfaces which have a very different add-in architecture).
Much to my excitement I was given the task to research an implementation such as this. The research I have done to this stage has found most of the documentation for coding against Exchange server relates to coding against its publicly accessible email interfaces rather than working with its internal functioning (ie. directly with user mailboxes being hosted by the server). It will be a much more difficult challenge to get something that will work with every configuration, but the research I have done so far has hinted at the possibility of it being done albeit with some very specific configurations and prerequisites which may be achievable programmatically.
My goal for the next few days is to get a virtualized test server ready and to code some possible solutions I have found from my research. I will test each solution and see what works and what doesn’t, particularly in the context of differing configurations – it needs to be as universally applicable as possible.
Developer Reflection 