We have Exchange integration into our CRM (diaries and email); we have done this through CRL functions in our SQL 2008 server which handle all the authentication and communication with Exchange 2007 web services. The CLR then presents the functions to developers in SQL Server as regular functions and stored procedures which makes coding wit them simple. We are handling our synching through SSIS to sync the data up.
Unfortunately i cant just install exchange 2003 onto our network Our sales team are in the middle of negotiating a sale that will require me to back migrate the code to work on Exchange 2003. When i am looking to back-port the interface what are the main functional differences between the exchange 2003 and exchange 2007 web services?
What are any potential pitfalls i might face ?
Thanks :)
There are no EWS for Exchange 2003.
EWS were introduced in Exchange 2007.
Exchange Web Services - What You Didn't Know – Exchange Team Blog … (2009-03-25)
Related
My current project uses the EWS proxy API. I'd like to bring the code we utilize in EWS up to date and was thinking about importing the full EWS API. But I'm kind of wondering if Graph is a possible/better choice. We only have an on site exchange server, no hybrid or Office 365 stuff. We use EWS to grab emails from a specific folder and process them into a database. If Graph can handle on site only server tasks as good as or better than EWS would it be better to use Graph?
The Microsoft Graph does not support on-premises versions of Exchange. There is planned work to support hybrid scenarios, but if you are not connected to Azure AD/Office 365 you won't be able to use it when it is supported. You will have to continue to use EWS API.
I purchased an ITHit .NET SERVER licence in May 2008, for an ASP.net application, c#, that works fine when on the client side is MS Office 2003.
The documents are stored in a MS Sql Server database and I use a custom IHttpHandler to process the documents.
Since the organisation started to increase, new licences of MS Office (2007/2010/2013) were purchased and instaled on client side.
Although I followed the instruction stated on the page: http://www.webdavsystem.com/server/documentation/ms_office_read_only/, couldn`t make it work with MS Office 2007 and further (still opens documents as read-only).
In order to provide for my client, would it work by aquiring a new licence/upgrade the existing one, or is it possible to fix this issue with the existing licenced version of ITHit WebDAV Server Engine for .NET?
Please keep in mind that I need a solution that still have to deal with a mixed environment of MS Office, meaning there still will be used instances of 2003, 2007, 2010 and 2013, and even 2016, for the next 3 years.
We have client - server application, where client is built in Delphi XE4 and server uses SQL Server 2012 Express edition. Can my delphi application (using WMI for server events) receive data change notifications from Express edition?
The documentation says that Express edition supports service broker as "Client Only".
Is it possible to achieve the above functionality using Express edition with out the help of any other sql server edition in between.
Yes, you can. Query Notifications and SQLDependency are fully functional in Express editions. Working with Query Notifications explains how to use Query Notifications directly from OleDB (via SSPROP_QP_NOTIFICATION_TIMEOUT, SSPROP_QP_NOTIFICATION_MSGTEXT and SSPROP_QP_NOTIFICATION_OPTIONS) and from ODBC (via SQL_SOPT_SS_QUERYNOTIFICATION_TIMEOUT, SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT and SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS). I don't know if Delphi exposes Query Notifications at higher level or you would have to code against low level ODBC or OLEDB. The really usable options are exposed via managed driver in C# et all, via SQLDependency class.
I see in the link MartynA posted the XE8 supports Query Notifications. It should work with Express.
The 'client only' restriction for Express refers strictly to Service Broker remote communications (exchanging messages between SQL Server instances), a capability not needed for Query Notifications.
You cannot use this feature with only Express edition.
You need at least Standard Edition to get the SQL Server Service Broker backend up and running. Once you have one Standard editon instance other Express edition instances can participate.
I have figured out that TFS 2010 has the following web service endpoint
http://tfsservername:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx
Are there ones to get a feed of check-ins, work items and other TFS items?
Update: yes! Visual Studio Online introduced a new REST API, and on-premises installations of TFS 2013 have access to this new API.
In versions of TFS prior to TFS 2013:
tl;dr: Not in any way you're going to want to consume.
Team Foundation Server does expose SOAP web services that the clients use to talk to it. However, it's not something that is publicly documented, it's not supported by Microsoft (meaning they can, and will, change version to version) and, quite frankly, it's remarkably unlikely that the effort required will be worth the result.
Although the web services are well designed, some of the web services require a significant amount of client state. This is particularly true of the work item tracking web services. The clients basically contain an entire "rules engine" for processing and verifying changes to any fields. The client must, basically, be able to understand the process template and process all these state changes before submitting an updated work item back to the server. The server will also run the rules and verify that the client made only legal changes.
The rules engine is not exposed publicly. You would have to reverse engineer it.
This also makes some underlying assumptions like your web services stack can successfully speak NTLM2 and Kerberos properly (most can't, outside of the .NET web services stack, although some an support NTLM version 1 to some degree, which will only give you the illusion that you should be authenticating.)
It's therefore strongly suggested that you just use one of Microsoft's APIs for accessing TFS, either the .NET or the Java SDK.
(I actually worked for a third-party company that successfully wrote a Java front-end to TFS by talking to the web services. It was a fair challenge for us -- especially the work item implementation -- and this was the full-time job for several of us. I wouldn't recommend it as a side project.)
Just like Edward mentioned, the TFS web services aren't meant for public consumption.
On the other hand, you might want to give the "OData Service for Team Foundation Server" a try.
It offers a really nice REST-like interface - thus callable simply by issuing HTTP requests, just like you were willing to do with the web services.
To learn more, check this blog post: http://blogs.msdn.com/b/briankel/archive/2011/10/26/odata-service-for-team-foundation-server-2010-v1.aspx
Our intranet (apache/php) is currently talking to our Exchange 2003 server via webdav. Our company was looking at upgrading from Exchange 2007 a while back, we even had the test server up and running and there was some effort made to port our webdav functionality to use the new EWS. The project was shelved for a while, but we are now looking at upgrading to 2010. Are there any big differences between the two EWSs? (I haven't been able to track down any articles about 2007 2010 EWS code migration.)
Answering to close this up. No modifications to EWS code were needed when migrating between servers.