Tuesday, May 17, 2011

InfoPath 2010\Infopath is not working for sharepoint designer workflow.

Hello All,

I got some really good news, in my opinion. I’ve found a pretty easy way to keep the original aspx page in the loop while still upgrading your workflow. You’re going to have to set the content type of the form each time though but so far has worked very well in my testing.

I’ll start with the basic workflow I created and what I’ve been doing for the last day or so.

1. In 2007 create a workflow that has 9 lookup columns in a collect feedback from user action.
2. Have the workflow start when a new item is created.
3. Publish the workflow and make sure it completes.
4. If all is good backup the 2007 database in SQL.
5. Restore the database to a new database.
a. I’m on the latest build of 2007 and 2010 (April CU)
6. Now, what is supposed to happen, if you don’t touch the SPD 2007 workflows, is you should be able to use your 2007 workflows without any issues. You should be able to keep using your aspx page and life should be good.
a. This is not what happens. I’m not sure if this is because of a regression or if it’s never worked. I want to say I recall testing this during beta and at RTM and it works.
b. What happens is if you try to complete a task you’ll get the following error in ULS and in the browser:

05/11/2011 18:28:37.53 w3wp.exe (0x13F4) 0x0F24 SharePoint Foundation Runtime tkau
Unexpected System.Runtime.InteropServices.COMException: Cannot complete this action. Please try again.
at Microsoft.SharePoint.Library.SPRequestInternalClass.GetListItemDataWithCallback2(IListItemSqlClient pSqlClient, String bstrUrl, String bstrListName, String bstrViewName, String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags, ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback, ISPDataCallback pPagingPrevCallback, ISPDataCallback pFilterLinkCallback, ISPDataCallback pSchemaCallback, ISPDataCallback pRowCountCallback, Boolean& pbMaximalView)
at Microsoft.SharePoint.Library.SPRequest.GetListItemDataWithCallback2(IListItemSqlClient pSqlClient, String bstrUrl, String bstrListName, String bstrViewName, String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags, ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback, ISPDataCallback pPagingPrevCallback, ISPDataCallback pFilterLinkCallback, ISPDataCallback pSchemaCallback, ISPDataCallback pRowCountCallback, Boolean& pbMaximalView)

c. I tried to open the aspx page to see if the DataFormWebPart was broken or what was going on but it would never allow me to return any of the fields. Very odd stuff. On the task list I could not get an SPListItemCollection or anything.
d. So, I captured a dmp file and took a look inside of it and it gave me a better callstack.
e. I found that we’re trying to make the following CAML query happen but keep getting an error:
f. 2
g. Very simple query that should return an collection of items or since we’re providing an ID value a single item.
h. I confirmed this fails with web services using U2U caml query builder for SharePoint.
7. With that knowledge under my belt I went in and modified each of the site columns that are part of this workflow. I should say, the site columns that the collect feedback action created.
8. All I did is click on each column as if I were going to modify them and just clicked ok.
9. The SchemaXml changes as follows:



to:



We add this to each lookup column:

Required="FALSE" EnforceUniqueValues="FALSE" Group="Custom Columns" UnlimitedLengthInDocumentLibrary="FALSE" Version="1"

10. This seems to fix the issue. There seems to be some sort of issue with the upgrade where we don’t upgrade these columns correctly.
11. Now, I can complete my task list items like I thought I was supposed to. I’m not 100 sure if this is limited to lookup columns.
12. Next, I could finally move onto the part where I figured out the workaround. I’ll have that be a separate section below this write-up.

To summarize, with the steps above you should be able to keep all your columns and workflows as is and they should just keep working.


This section is my workaround explanation for keeping the aspx page in play after upgrading the workflow.

1. Now, we’re ready to upgrade your workflow. When you open the workflow in SPD 2010 and click publish you’ll get a warning that indicates we’re going to be upgrading your workflow to an XSN based forms. You have to acknowledge it and then you can click publish or add actions to your workflow..
2. If you do so and have some of the unsupported columns, in this given scenario: lookups, calculated, extended and page breaker, the InfoPath xsn generation will indicate an error. That’s fine, we don’t care about this xsn based form. Let SPD try to auto generate this form.
3. Once click Lists and Libraries.
4. Click Tasks, usually the default task list for SPD 2007 workflows.
5. Find your content type, in the content type slab, that was created by the collect data form user action.
6. Take note of the forms urls for display and edit.
a. They should be something like this: _layouts/WrkTaskIP.aspx
b. Change the edit form to the path of your aspx page. It won’t be visible if you click the workflows in the site objects but should be visible via the All files site object.
c. In my example I had to change the edit form to /Workflows/myWorkflow/customEditForm.aspx.
7. Save the content type at that list level.
8. Now, you should be able to complete your tasks using the aspx page and the original form. The xsn file is just ignored.
a. If you have custom email notification like you have then just make sure to keep pointing those to the aspx page.
9. The only downside is that if you update this workflow you’ll need to remember to change the content type on that task list to use your aspx page.

1 comment:

Anonymous said...

the form urls for the content type is not working on upgrading. It always opens the custom task edit form..