Now it begins
We've created an application which can read and write Groove data.
Groove's web services APIs also expose a very wide range of other functionality. Let's outline some of the possibilities.
- Create a new workspace, blank, or from an archive or template (GSA file). (See GrooveSpaces.CreateFromGSAByRef, GrooveSpaces.CreateGrooveFileSharingSpace). A template consists of a set of tools, and can include data (files, checklists, and so on).
- Add new tools into an existing workspace (GrooveTools.Create).
- Read data from another system and write it into the new workspace. And vice versa. Files, forms records, discussions, calendar entries.
- Invite people to a workspace (GrooveMembers.Create); or create an "invitation file" which can be posted on a website or attached to an email (GrooveSpaces.CreateInvitationFile)
- Save a workspace as an archive (GrooveSpaces.ExportAsArchive)
We've concentrated on the detail of reading and writing data, but the surrounding activities really make this thing fly. We call an application implementing these a "controller".
My full demo is almost useful. It's a standalone application which scans a WSS list ("Incidents") looking for new records. When there's a new incident, my code creates a new Groove workspace, and pulls in data from the incident record and from other lists on the SharePoint site, into Groove Forms tools in the workspace. Then it creates an invitation file, and attaches the invitation to the incident record on SharePoint. If there were an assigned responder in the incident record, it could also send an invitation proactively to that user. (All of that takes only a few seconds).
The result of that simple skeleton demo app is that an incident team can rapidly be "swarmed" to handle a new occurrence, and then work with the appropriate team to handle the incident -- without being tied to the WSS site (which might be behind the firewall) -- and can continue working together even when communications is interrupted. After all, the Groove workspace contains all the relevant contextual data right away, with no user intervention, and members of the workspace don't need any network access to work with that data - it can be read and updated offline.
In a real system, you'd probably have the controller write data, or summary extracts, back from the workspace into the back-end whenever it changes. You'd also run the controller on a Groove Enterprise Data Bridge server, behind the firewall, 24/7.
Extending the reach of back-end systems, into the messy ugliness of real-world virtual team environments.
