Accessing a WCF Service from a Custom Timer Job

At work, we have a job that has to run every 5 minutes and that check to see if a permission list has been change in our SharePoint environment. If an item in the list changed, the job has to update the Access Control Log (ACL) on a Shared drive on a remote server.

 

image_5.png

To achieve this with SharePoint, we had to develop a SharePoint Custom Job. The logic was to be such that the timer job would be responsible for checking to see if a change happened, and in case there has been a change, call an external WCF Service that would then handle the ACl attribution on the external folder. The big problem is that timer jobs run inside the OWSTimer.exe process, so defining the external WCF contract in the web.config is not going to cut it. After much struggle with this, the solution was found to be easier than thought. The OWSTimer service uses a file located at

 

[14 Hive]/Bin/Owstimer.exe.config

 

This file acts as an app.config file for the timer service. All you need to do for your custom Timer Jobs to have access to your external WCF service, is to define the contract’s info in there. Don’t forget to restart the SharePoint timer service after you’ve made the modification!

My First Thoughts on the NAPA Cloud Apps IDE

Last July 17th, Microsoft unveiled the preview version of the upcoming Office 2013 suite, including the server bits. One of the major changes, in my opinion, is the introduction of these new “Office Apps”. This concept opens the door to infinite possibilities for developers since they can now develop their own generic “pluggable” components and sell them directly on the Office App Store. Office Apps can target either the client applications like Word or Excel, or can target the Web like it is the case for the SharePoint Apps. These apps require developers to learn javascript and jQuery since they are required to run client side. Off course you can always develop a lightweight front-end component that would require minimal JavaScript code, and place the major part of the logic on the server side, but for real world scenarios, this would require you to register for a Windows Azure account, or to have your own on premises server.

 

With the Office 2013 preview announcement, Microsoft also made available an “obscure” online IDE component codenamed NAPA. This tool allows developers to create, deploy and test Office Apps from their browsers. In order to use this online IDE, you are required to register for an Office 365 vNext account. To find your way to its interface, you either need to create a new SharePoint site based on the Developer’s site template, and then add the NAPA apps to it, or you can simply navigate to https://www.napacloudapp.com/ . Please note that the later link requires you to be signed into your Office 365 vNext account first.

 

Now, I am one of the few lucky people to be using Visual Studio 2012 RTM. The release includes a downloadable version of the VS 2012 SharePoint 2013 developers tools that allows you to create new applications directly from within the Visual Studio IDE, which let’s face it, just feels moreā€¦natural.

 

Over the next couple of weeks I’ll try to write several articles on Office Apps development for SharePoint. I’ve taken the decision to mainly focus my new development on these types of Apps, and believe me, the future for these is extremely bright.