InfoPath Dev

Hello,

I'm trying out DBXL 2.3 and so far it's working as advertised when it comes to getting data into SQL from IPFS.  My problem is that the subsequent push of the XML to a Sharepoint library is giving the XML a filename of "<DBXL DocID#>.xml", which is somewhat unfriendly.  There is no setting that I could find in the DAT that allows me to setup the DocID (which is fine as I understand that it is essentially a primary key for DBXL).  Is there a way to have DBXL use a filename that is a value in the XML itself.  That would essentially solve my problem.

 Thanks in advance,

- Ra

Hi, Ra:

Currently, we do not have this functionality. This came up recently with another DBXL customer, so we are definitely going to be considering it as a feature for upcoming releases.

You can promote columns from your form that might help work around this by providing your users with other information from the form in the default view to help them know which form to select. One customer I work with has his library view organized to display the title of the form first (from a promoted property) then the name (linked to item menu) second.

Thank you for your response.  Unfortunately, the filename in question needs to be hyperlinkable by Sharepoint BDC actions (so that I can click on a BDC action and it takes me to the IPFS for that particular XML).  In addition, IP promoted fields do not show up in Sharepoint Designer's workflow designer as fields that I can look up or compare values with.  Do you have any suggestions?

 Thanks again,

- Ra

Ra Jeffrey:

In addition, IP promoted fields do not show up in Sharepoint Designer's workflow designer as fields that I can look up or compare values with

Ra, can you clarify this?  Any IP fields that you promote are then visible to SPD via the library itself.  However, those fields can only be modified by SPD if you select the check box to allow for editing in SharePoint.  I don't think that applies here, but I thought I'd mention it just in case.

Where is the checkbox you are talking about located (SPD, IP, or Sharepoint)?  I could not find it in IP.

To clarify, in IP I promate a field.  The field value is visible as a column in the Sharepoint library, but I can't edit or delete it (I can still do lookups on it from another library though).  I open SPD and start creating a workflow for that forms library.  I go to try and look for the promoted field so that I can include it in a workflow action (i.e. column X = promoted field value), but I can't because the promoted field name doesn't appear on the list.

It's in IP, but not in the Tools > Form Options > Property Promotion tab.  You do it as part of the publishing process when you get to the part of the wizard where you choose columns.  that's where you define your promoted properties, assign them to new or existing columns, choose an action (if repeating), and choose whether it can be editable.  I don't know if you go through the publishing wizard using DBXL, so maybe that's the problem?  You need to go through there to make these fields usable.

When using DBXL I'm publishing to it's web service.  I do not get the edit checkbox option when publishing to a web service.  I even tried saving the XSN to publish to directly to the sharepoint library (thus getting the editable checkbox), THEN importing that template into DBXL using DAT.  The promoted fields still were uneditable.

Yeah, then the Qdabra folks will have to address that.  You can definitely do it through the publish to SharePoint as you saw, but when publishing to a web service, I don't know how you'd do it.  I think that the DBXL process would have to do that when it publishes itself to the library.

Hi, Ra:

I have a test library that is linked to a DBXL doctype with a SharePoint Mapping. My promoted properties from my form are accessible in SharePoint Designer when I create a workflow action. For example, I have a promoted field called 'Job Name' and in a work flow action I can access that field for setting a condition or adding it to an action (like putting the value in the body of an email, for example).

Do your form's promoted properties display correctly in DAT under the SharePoint Mapping tab for your doctype?

Hilary, I think he can reference the fields in SPD, but not for actions that deal with changing data in those fields.  For instance, if you try to do "update list item" or "set field in current item," those fields won't show up.  They will show up, however, for reading the data (or at least they should).  I could be wrong, but I would 100% expect the fields to show up for read purposes if they show up in the library as columns (which he said they did).

Ah, okay, I misunderstood. I don't believe that currently the DBXL / SharePoint integration will allow demoted properties. I'll check with the rest of the team.

Currently, DBXL doesn't support property demotion from SharePoint for SharePoint mapped forms.

That is totally OK, because I couldn't tell you the difference between a demoted property and a demented propeller.  My primary concern is finding a way to name the XML based on a value in the form itself.  DBXL currently can't do it, which is unfortunate as it does everything else smashingly well.   

Hello everyone,

So, after a couple days of trying, I conjured a workaround using an SPD workflow ... only to run into another DBXL set back (which I will tell you about in a second). 

Basically, I created a workflow in SPD for the document library that the Qdabra DAT pointed to.  To get the promoted fields to actually show in SPD, a column with the exact name of the field you are promoting has to exist in the library.  This will cause there to be 2 columns with the same name in the library (one is the promoted IP form field, the other is the Sharepoint column).  A little weird but no worries, as you have full control of the Sharepoint column and can hide it from view.  The neat thing is that through DBXL/Sharepoint hocus-pocus, the value of the IP promoted field will map into both columns.  The Sharepoint version of the column IS visible in SPD, so I used that to create a dynamic string that became the new filename for the XML (remember to use .xml at the end).  I told the workflow to store the dynamic string in a variable, then as a second action to set "Name (for use in forms)" equal to that variable.  I ran the workflow manually and it worked like a dream.  The xml file gets renamed to something more useful than an integer.  YAY!

BUT ... when I set the workflow to run automatically as new item is created in the library, nothing happens.  New XML's from DBXL don't seem to register as "new" to the library, so the workflow isn't kicking on to rename them.  I went onto this website and found a document called "How to create a SharePoint workflow that will work with DBXL and IPFS", and stepped through it.  Unfortunately, it does not work.  The approval workflow either does not run while "Start this workflow when a new item is created" is checked off in the approval worklow setup.  However, manually starting the workflow still works OK.

So I still have the original problem of renaming the XML files DBXL pushes to the Sharepoint libraries.  Workflow solutions to that problem can't work because the XML's that DBXL pushes don't seem to register as "newly created" to the workflows.  Anyone got anything?  I mean I'm really desperate here.

Hi, Ra:

I've forwarded this to some other members of our team who are more familiar than I am with the document you mention, so we'll have someone else posting soon on that.

I'm still perplexed as to why you are having to create columns in your SharePoint library for your promoted properties to be available in SharePoint Designer. When I open a library that I have a DBXL based form shredding to, I can see my promoted properties... at least in some actions. I've been assuming that those are the actions where I am reading only, and not setting a value, which makes sense.

In fact, I just tried your suggestion (which I like very much, by the way) and created a workflow on the same library I've used for testing to do the same thing.... and when I saved a new form where I opened the template from SharePoint, my workflow ran as I'd anticipated. I tried again, opening the template from DAT and saving... and again, the workflow ran. I'm wondering if you might have some kind of configuration issue? Do you have any errors in any of your event logs? Particularly the Qdabra log, but you might also want to check for SharePoint errors....