InfoPath Dev

Start with a working Infopath to sharepoint form. It has say 5 published fields. These fields are available to workflows for editing etc.

Edit the template to change the submit to sharepoint to be submit to DBXL. Republish template to SharePoint & add to the DAT tool.

Via Dat create mappings to SQL and to SharePoint.

Result at this point is all the published fields are visible but locked! This means that fields as if they were published as read only which sometimes that's what you want but sometimes you NEED fields to be editable so that workflows can edit the fields as needed. Currently all fields will be locked making any edit workflows not work at all, you can't even edit these fields via the edit properties form option manually.

attempted solution: Unplublish each field from then republish each field and update the form to SharePoint and Dat. This worked sometimes for 1 field at a time!!!

 Then as I was unpublishing 1 field at a time, republishing, saving to SharePoint and to DBXL I noticed that say the 1 field I finally got to show up again correctly as an editable field is now NOT and the one I was working to get as a published editable field is not also! This is total random madness.

I also noticed that my metadata in the SharePoint List has each field that was "attempted" to be published duplicated!

Hi there, sorry you are having issues with SharePoint.

What version of DBXL did you purchase and what support plan?  Someone from our support team would be happy to help you out if you could let us know your name & phone number and when you purchased DBXL.  We don't have any record of a "homeslacks" in our licensing DB.

Regards

Hi Gil,

You shouldn't have to republish your XSN to SharePoint. Adding the template to DAT and clicking Save should automatically republish to SharePoint. You need to let DAT do this so that the PI and href in the solution are correctly referring to the DBXL instance which is the core store for your data (that's because the Web Service is the gatekeeper and must be the official reference for XSN and XML data).

You cannot edit the fields directly via Workflow since the data doesn't get mapped back to the XML contents in DBXL. This is why I suggested using Forms-based workflow in an earlier e-mail to change assignment, status, etc. It's not a limitation of DBXL but rather an issue with where workflow stores the data. Since SharePoint Workflow requires storing assignment, status, etc. in columns in SharePoint, there is no way to update the XML in DBXL. Even if we provided some kind of SharePoint event handler, it a) wouldn't know the reverse mapping to update the XML correctly, and b) could be problematic if the data being stored doesn't validate. SharePoint doesn't validate workflow data to InfoPath fields, so you have this latter problem with InfoPath and SharePoint already (regardless of DBXL).

Recommendations:

• Use SharePoint workflows with custom columns that don't exist in the XML (aren't promoted properties)
• Use Forms-based workflow with promoted properties

We have a workflow course that we give which goes into more detail to describe the differences. Bottom line: SharePoint workflows don't integrate with data stored in other places (for example, SQL), so you have to either keep the data separate or use Forms-based workflow. Forms-based workflow is a better alternative than SharePoint since you get more fine grained permissions and you can customize them without writing code.

Hope this helps.

I now better understand the relationship with the XSN/DAT and SharePoint and it makes sense. Regarding the use of Forms-Based workflows I've never seen how they are created, what they can do etc. I've read for example from front to back an Office Infopath 2007 Dev book and it never mentioned forms based workflows. Would you kindly let me know what tools are used to create them? Probably infopath itself? Maybe there's a web site somewhere with a basic tutorial on creating one which would be enough to get me to see the tools involved?

 Thanks again.

Forms based workflow would be using rules and conditional formatting within InfoPath to manage the workflow.  You can also use custom code in InfoPath as well to do the same thing but in general many workflow needs can be handled via simple rules & conditional formatting.

For a very simple workflow imagine a form with 3 "statuses": draft, submitted, approved.  You would add a field to the form schema call "status".  A user creates a new form and saves it, it is in draft mode (using rules to set the value of the status field).  Then the user has a button to submit to their manager, this changes the status to submitted and the form is assigned to the manager.  Then the manager opens the form and they have a button to approve the form, again when they do that the form status is changed via rules to approved.

This is a very simple example but gives the you the idea of one way to implement in form workflow.  With conditional formatting you can show/hide sections based upon status or make sections/fields read only based upon status etc. 

Hope that helps

Ted

Ahhhhh....I got you now, I know what you mean. I'm going to see about using as much of that style of rules and formatting as I can.

 Thank you kindly.

:)