Now that we have succeeded in creating, updating and deleting calendar items and mastered Exchange Impersonation, it’s time to turn our attention to having Exchange notify us about what it is doing. Part 4 of this series is going to provide a detailed code walk-through of some code that leverages the Subscription API.
The example includes two code examples – one for Java programmers and one for OpenEdge programmers. The OpenEdge version writes updates through the OpenClient via the OpenEdge AppServer to an OpenEdge database.
In part 2 of this series, we are going to spend some time looking at the CalendarItem API, how it works and what it takes to create, get and delete an appointment. Before we start, you should make sure you have your environment set up per the explanation in part 1. If you have done that, you can download the example code for both the Java portion and the OpenEdge portion so you can follow along as we walk through this code together.
Part 2 of this series of articles is dedicated to giving you an overview of the process of connecting to Exchange and doing some basic Calendar item work. Through the sample code, you will learn how to:
– Connect to the Exchange Web Service from Java;
– Create calendar items on the Exchange Server;
– Get calendar items from the Exchange Server;
– Delete calendar items from the Exchange Server; and
– Connect to the Java service from OpenEdge to perform the same operations.
The Java functionality will be exposed as a Web Service so that other platforms can also leverage, which is how we will get at it from OpenEdge. The OpenEdge code leverages the new GUI for .NET and object-oriented extensions, so you may find the example interesting if you have not done this before. [...]
Someone e-mailed me off-line and pointed out that I post UML diagrams on my blog fairly regularly. He wanted to know what tool I use for this. In the process, his e-mail reminded me that I had written a post back in March of 2009, where I said that an upcoming post would talk about this. Promises, promises!
Actually, now is a really good time to have this conversation because with the work I am doing on the Exchange Web Service code, I have just finished revamping my internal infrastructure to support the equipment and software I need to do the job. So this is going to be a two-part article. In this part, I’ll tell you about the software development components that I use. In the next part, I’ll tell you about the infrastructure components. The problem is that you need to understand some of the details of why, so I’m going to start with a little background.
It’s been a really busy week since I posted my first post on Exchange Web Services. I have learned a lot in that short period of time that I want to share with you. Whether you are an OpenEdge, Java or .NET developer, I think this post is going to have some information for all of you.
In my first post, I told you about the background story – I need to enable an OpenEdge CRM application to create, modify and delete calendar and task items in Microsoft Exchange. I also need Exchange to let me know any time a calendar or task item is changed so that I can update the OpenEdge database accordingly. Simple use cases.
When I left off last week, my next step was to get Exchange subscriptions working, and, boy, what a trip that has been.
A couple of months back, a gentleman who has now become a friend and business partner, came to me and asked me if there was any way to get at all the calendar items in his sales organization’s calendars with the intention of integrating it with his Progress OpenEdge CRM system. Jim is using Exchange 2007 for his e-mail and calendaring solutions.
I was aware that Microsoft had released a new API for Exchange in Exchange 2007 called Exchange Web Services (EWS), and so I said that I needed to do a little research on the API, but I was pretty sure that it was possible. Sure enough, MSDN has some documentation of the API and Microsoft is touting it as the replacement for all APIs that communicate with Exchange. Web Services – how hard can it be?
In a previous post, I said I would post an example that demonstrates the use of the OpenEdge Dynamic OpenClient. Well here is the Java version of it. This post is an extensive discussion of the example and how it is structured. Enjoy.
In one of the more recent versions of OpenClient, the API that the OpenClient uses is documented so that it is now possible to dynamically construct the proxy calls at run-time. The overarching benefit in this lies in the ability to now define the temp-table definitions on the fly. The Java/.NET code can now define the temp-table dynamically at run-time so that if a change is made to the definition, the client can deal with the change with no impact on the OpenClient source code.