Using Windows Workflow Foundation to SMS-Enable MOSS

For the past couple of weeks, I have been doing an in-depth look at various mobile communication technologies (SMS, EMS, MMS, etc.) for the purposes of incorporating these technologies into our existing strategies. While the scenarios vary, most of the use-cases driving us to SMS et al. revolve around information delivery in areas where Internet connectivity is problematic, yet cell phones abound. It sounds counter-intuitive maybe, but in many regions (like Africa for example), it’s far easier to put up a cell tower than it is to lay cable of any kind. Thus, mobile technology can be found in many places where land lines and Internet access cannot.

Being the agenda-pusher that I am, I can’t pass up an opportunity to integrate this technology study with work I have already done and am doing. Since my biggest interest right now is in the Composite Applications space, I wanted to use one of the demos in this study to prove out (to some degree) the composition argument I have been making both in this blog and internally. Thus, I created a demo scenario for this study that sends a 1-way, application-originated SMS Text Message through an SMS Gateway (Clickatell in this case) to a mobile subscriber when a particular field on a list in MOSS is changed. Now, this scenario isn’t rocket science, nor is it earth-shattering. What it is, however, is me taking my own medicine. If I’m going to preach the Composite Applications gospel, I’d better try it on for size myself. Here’s how I implemented the scenario:


I started by creating a stand-alone custom activity in Windows Workflow Foundation. The code, with some key details removed, is included below. Note: In order use this yourself, you’ll need access to an SMS Gateway (like Clickatell, which is used here) and access to their HTTP API, if they have one. Not the only way to send a text message, I know, but SS7 Gateways can provide guaranteed message delivery to the subscriber.

Like I said, nothing earth-shattering. However (and I won’t go into the details of WF here as there are plenty of good resources that do that) the end-result is a stand-alone Workflow Foundation Activity which encapsulates the business logic for distributing an SMS Text Message via our Gateway provider and which can be hosted in any application that provides the WF runtime. This Activity can easily be dropped into a container Sequential or State-Machine Workflow project (as I did when testing this activity on my machine), or it can be deployed to MOSS as a stand-alone activity which can be included in a Workflow built using SharePoint Designer. Two scenarios with different composers, both using the same asset. That’s the vision of Composite Applications. (As an aside, with the recent Oslo announcement, I imagine that we’re not far from a day where that same activity could be also be reused in BizTalk and Microsoft CRM, among others).

So what do those scenarios look like? For the developer adding a custom activity to a WF Workflow, it’s a simple matter of dragging the activity from the Toolbox to the designer, then binding to the DependencyProperties (Number and Message in this case) and creating an event-handler to receive the event raised by the activity (in this case, sendSMSActivity_MessageSent).

For an individual slinging SharePoint Designer, the experience is different, but also quite powerful. However, The first step I must take as an activity developer is to deploy said activity to the MOSS server. This requires deploying the Activity assembly to the GAC on the MOSS server, adding said assembly as a safe control in the web.config file, and adding the Activity to the WSS.actions file (or a new .actions file in the same directory, which is probably a better idea), which SharePoint designer uses to load up the list of available workflow actions. All of this can be done via a feature in SharePoint (I know that the first two can and I think that the last can, so feel free to comment if I am incorrect). Here is the code for the WSS.ACTIONS file (Added in the <Actions> section):

Page 1 of 2 | Next page