Workflow

Dec 17, 2009 at 3:02 PM

Hi Marc, great job on the latest release...

Do you happen to have any examples of using the SPServices.Workflow.StartWorkflow? I would like to kick off a workflow from a List View by way of a RenderPattern. To illustrate, a user opens a View and will see a link/button/icon that they can click on. Upon doing so a workflow for that item will be invoked to update fields, status etc. I think one of the Fantastic 40 templates does something similar in concept but uses a ton of custom XSL to do it. I believe it can be done nicely and neetly with the help of your library.

As always, thanks for your contributions.

Coordinator
Dec 17, 2009 at 8:44 PM
Edited Dec 21, 2009 at 12:10 AM

You should take a look at the SDK MSDN page for the Workflow.StartWorkflow Method for the particulars, but the function call will need to look something like this:

$().SPServices({
  operation: "StartWorkflow",
  item: "http://servername/Workflow%20Test%20Library/BLK_RGT.GIF",
  templateId: "{f449efd4-d5be-489b-9380-002fc66c2144}",
  workflowParameters: "",
  completefunc: function (xData, Status) {
    ...do stuff...
  }
});

M.

Dec 17, 2009 at 9:30 PM

awesome! thanks. I'll give it a whirl and let you know how it turns out.

Dec 22, 2009 at 3:54 AM

I've been working on this for a few days now. I don't believe it has anything to do with your library but I'll describe what is going on. I have a workflow that accepts one parameter (qPONum). The workflow is pretty simple, it updates an Invoice's PO Number. I tested with the StartWorkflow operation but moved to SoapUI when I couldn't debug it well enough. I continue to get an error regarding a null value.

This was taken from my workflow's XX.xoml.wfconfig.xml file

<Parameters><Parameter Name="qPONum" Type="System.String" /></Parameters>

 

This is my SOAP Envelope:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wor="http://schemas.microsoft.com/sharepoint/soap/workflow/">
   <soapenv:Header/>
   <soapenv:Body>
      <wor:StartWorkflow>
	<!--type: FileRef -->
         <wor:item>http://mytestbed.local/finance/treasury/dva/Invoices/9MR Invoice11-09-2009_10-06-39.pdf</wor:item>
         <!--type: guid-->
         <wor:templateId>{DB5A54A3-01B8-4080-8732-A575DD0C97CD}</wor:templateId>
         <!--Optional:-->
         <wor:workflowParameters>
            <qPONum>001234567</qPONum>
         </wor:workflowParameters>
      </wor:StartWorkflow>
   </soapenv:Body>
</soapenv:Envelope>

SOAP Response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode>
         <faultstring>Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.</faultstring>
         <detail>
            <errorstring xmlns="http://schemas.microsoft.com/sharepoint/soap/">Value cannot be null.</errorstring>
         </detail>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>
Coordinator
Dec 22, 2009 at 12:41 PM
Edited Dec 22, 2009 at 12:42 PM

Sometimes error messages can make you want to tear your hair out, eh?

I just checked the Workflow Web Service Protocol Specification, and the workflowParameters need to be specified as XML.  If you look in that document, there's one example (and I can't find any other):

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
  <StartWorkflow xmlns="http://schemas.microsoft.com/sharepoint/soap/workflow/">
   <item>http://server/Documents/Document.xml</item>
   <templateId>8637567d-fd4a-4bbc-a994-7854df1ebd7a</templateId>
   <workflowParameters>
    <my:myFields xml:lang="en-us" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD">
     <my:Reviewers>
      <my:Person>
       <my:DisplayName>User</my:DisplayName>
       <my:AccountId>DOMAIN\user</my:AccountId>
       <my:AccountType>User</my:AccountType>
      </my:Person>
     </my:Reviewers>
     <my:CC>
     </my:CC>
     <my:DueDate xsi:nil="true">
     </my:DueDate>
     <my:Description>
     </my:Description>
     <my:Title>
     </my:Title>
     <my:DefaultTaskType>0</my:DefaultTaskType>
     <my:CreateTasksInSerial>false</my:CreateTasksInSerial>
     <my:AllowDelegation>true</my:AllowDelegation>
     <my:AllowChangeRequests>true</my:AllowChangeRequests>
     <my:StopOnAnyReject xsi:nil="true">
     </my:StopOnAnyReject>
     <my:WantedTasks xsi:nil="true">
     </my:WantedTasks>
     <my:SetMetadataOnSuccess>false</my:SetMetadataOnSuccess>
     <my:MetadataSuccessField>
     </my:MetadataSuccessField>
     <my:MetadataSuccessValue>
     </my:MetadataSuccessValue>
     <my:ApproveWhenComplete>false</my:ApproveWhenComplete>
     <my:TimePerTaskVal xsi:nil="true">
     </my:TimePerTaskVal>
     <my:TimePerTaskType xsi:nil="true">
     </my:TimePerTaskType>
     <my:Voting>false</my:Voting>
     <my:MetadataTriggerField>
     </my:MetadataTriggerField>
     <my:MetadataTriggerValue>
     </my:MetadataTriggerValue>
     <my:InitLock>false</my:InitLock>
     <my:MetadataStop>false</my:MetadataStop>
     <my:ItemChangeStop>false</my:ItemChangeStop>
     <my:GroupTasks>false</my:GroupTasks>
    </my:myFields>
   </workflowParameters>
  </StartWorkflow>
 </soap:Body>
</soap:Envelope>

So my suggestion would be to add in the XML header with the namespacing and see if that works.  Also note that there are no squiggly brackets around the templateId, though I don't think that is causing the issue.  Once you have a working example, I'd really appreciate it if you could kick it back as an example for the documentation so that others can save some time!

M.

Dec 22, 2009 at 2:34 PM

I did see that example in my research. I also reviewed the web service protocol whitepaper that was published. It has a very similar example. The only part of it that didn't jive was that the example above is using the InfoPath XSD for the parameter definition. Additionally, I did finally get the example I put in above to partially work. It seemed I had the wrong templateId. I had opened my workflow's XXX.xoml.wfconfig.xml and grabbed the BaseId from it thinking that was the templateId. (I swear I read that you could do that to get the templateId easily.) None-the-less, I decoded the URL from the web UI to get it.

I could see the workflow against the item now but it kept erroring out. I kept having to manually go in and stop the workflow on the item. There was no additional error messages in the logs anywhere. The Event Logs only had a Warning for an Event 7397 and occassionally I would get an error "exception from hresult: 0x8102009b" which is typical if a workflow is running on an item and another is started. I so love the detailed error messages we get to decipher.

Any additional insight is helpful. I will continue to test. I am determined to get it working now for the knowledge as I have had to produce a different solution to my problem since I couldn't resolve it this way. I will keep updating the  post as I progress. To note, I could not get a workflow without parameters to start either. I hope to try it on a clean site/farm after the holidays.

Merry Christmas

Coordinator
Dec 22, 2009 at 2:41 PM
Edited Dec 23, 2009 at 12:36 AM

On my test site, the call to StartWorkflow I show above works (less the "... do stuff ..."), so I know that this is possible.  It sounds like you are taking all of the right routes to try to figure it out.  It also sounds like you are getting the workflow to start, but not run successfully?  Is it possible that there is a context issue in your workflow itself? (I'm grasping a little here.)

M.

Coordinator
Dec 23, 2009 at 12:40 AM

I was thinking about this some more, and that "exception from hresult: 0x8102009b" was nagging in my memory.  I tracked down a blog post that I had found when I was originally testing the function:
http://kindohm.com/archive/2007/06/26/com-exception-on-programmatic-wss-workflow-execution.aspx

"By accident, I discovered that the workflow was being started for a list item that already had the same workflow started - but had errored during its execution. SharePoint decides to keep the workflow in a "running" state until a user (or developer) explicitly chooses to terminate it."

When I was testing, I ran into this, too.  When I had fired the workflow but it hadn't run correctly, it got into a "stuck state", and I had to manually terminate it in order to fire up another instance.

I hope this helps.

M.