The other day, someone on twitter made fun of the name I chose for my demo library, pocketSOAP. That’s ok, and I am actually glad that the name matches the intent. As I have already said, pocketSOAP is just a toy to experiment with SharePoint Web Services.

Something else that sounds funny: people sometimes ask me which services are supported by pocketSOAP (see for example the twitter link above), and my answer is… I don’t know. At the end of the first pocketSOAP article, I listed a number of existing libraries that abstract SOAP services. All those libraries follow the same technique and hardcode the service call. pocketSOAP and its parent library SPELL are radically different: instead of having the information hardcoded, they go and fetch it on SharePoint. That explains why the libraries are so lightweight. By the way SPELL is the smartest of the two, and when it learns a new service it memorizes it for next time.

In the past few weeks, I had the opportunity to do more testing based on users’ requests. I confirmed that my libraries worked fine for the following calls:

• Lists.asmx:
  • GetListItems: retrieves items from SharePoint lists
• WebPartPages.asmx:
  • GetWebPartProperties2: collects the list of Web Parts present on the page and their properties
  • SaveWebPart2: saves changes made to the properties of a Web Part (e.g. its title)
• Workflow.asmx:
  • GetTemplatesForItem: collects the list of workflows for a given list
  • StartWorkflow: allows to trigger a workflow

The code for WebPartPages and Workflow is more intricate than what I posted in my previous pocketSOAP articles, so I am not sharing it here. If you have registered to the SPELL interest list, you’ll receive two entry level demos with the August newsletter:

• a Web Part Page Quick Editor (features the WebPartPages service)
• a button that triggers workflows (features the Workflow service)

So far so good, all the services I have tested have responded just fine. Now waiting for the next challenge!