From The Field

I wanted to share a tidbit I encountered when working with a client. We were attempting to troubleshoot a V10 Action – specifically, a Create Item action that was working for the person who built it.  Other users that tried to run the Action received an error in the Action Form stating “Object reference not set to an instance of an object”. This error also occurred if the same users tried to access/edit the Action via the Actions Wizard.

Figuring this had to be a permissions issue, we checked the following:

• · Did the user have access to the Actions Library?  Yes, they did.
• · Did the user have access to the individual Action in said library? Yes, they did.
• · Did the user have Add rights on the list the Action was configured to run against?  It shouldn’t be necessary but we looked anyway and they did have rights.
• · The Action itself and the CorasWorks Central View it was attached to were stored in another site collection, so we made doubly-sure they had Read rights there as well.  They did.
• · The list/Action form contained a CorasWorks Toolset Workplace Lookup (WPL); perhaps the user’s didn’t have Read rights on the WPL Provider, but they did.

At this point, I was a little bit stumped and not sure where else the user’s would need permissions.  To be sure, we bumped them up to Site Owners on both the site collection they were working in as well as the site collection where the Central Views and Actions were stored – even that didn’t work.

Then it hit me.

They were using a Global Link to configure the Action; specifically, a Global Link to point to the specific list the Action should create the new item within.  The Global Links are stored in a list that is automatically created when enabling Central Configuration via Central Administration.  Our customer wanted the Central Configuration site to be a secured site for him and other CorasWorks-trained Administrators only.  His general users did not have Read rights to the Central Configuration site; as such, they weren’t able to read the Global Links list found within.

In the end it was a perfectly reasonable, and soon to be common, configuration – it just wasn’t part of my usual permissions check when something didn’t work.  So, lesson learned: if you see that error when trying to run an Action but the user has sufficient rights (in our case, Admin rights) on everything you think to check, don’t forget to look at the Global Links themselves and if the user has access to those!

The possibilities for creating solutions with the Data Integration Toolset are almost limitless.  With this in mind, one idea for creativity is tracking file downloads from SharePoint with some simple settings of the External Data Provider.   

Let’s set up our scenario: A software company, SuperSoft stores and manages their software releases in SharePoint libraries and they give their customers access to these downloads based on their level of purchase.  What SuperSoft currently doesn’t support internally is the tracking of who is actually downloading the software.  EDP to the rescue! 

To solve SuperSoft’s problem, we’ll first have them setup a Custom List in SharePoint where we’ll store the visitor’s information, we’ll create 3 columns: User, DownloadDate and FileDownloaded.  DownloadDate will be a DateTime field with the default value being the current date and time.  We’ll adjust our default view for our library to just show these three columns.

 Next, we have SuperSoft create a couple of document libraries for storing our EDP files.  We have them first create a Connections library that we’ll use to hold our EDP connection file and we have the create a Providers library that we’ll hold our EDP.  Once these are created we’ll create our connection file and we’ll be using the EDP to connect to the SharePoint Lists web service.

 Setting up our connection file is the key to getting the data that we are looking for.  We create a new XML file and we we’ll configure it with the required data provider connection information for using a Web Service.  In this connection file we will set it up to accept a parameter, in this case we’ll call it %sw%, which will be the actual URL to the file being downloaded and the connection file will also utilize the built-in CorasWorks parameter, CWUserID, which returns us the currently logged in user. 

 In order to setup our connection file, we need to have the Soap envelope and action information from the web service.  The easiest way to do this when working with a .NET based web service, is to browse to the web service using Internet Explorer and get our information.  To find the Lists web service, we type in our current site information and append _vti_bin/Lists.asmx to it… so our URL might look like: http://sp.mysite.com/software/_vti_bin/Lists.asmx, when we browse to this page it will return a list of public methods, we’ll find the one we need, the “UpdateListItems” method and copy the SOAP envelope and Action information.  Once we have the SOAP envelope information in place, then we need to make a small adjustment so that it will correctly call the UpdateListItems method.  More information on this can be found here: http://msdn.microsoft.com/en-us/library/lists.lists.updatelistitems.aspx

 The end result is that our connection file will look like:

<?xml version="1.0" encoding="utf-8" ?>

<Data>

    <Name>InsertVisitorInfo</Name>

    <Default>true</Default>

    <ConnectionType>Web Service</ConnectionType>

    <RedirectTo>%sw%</RedirectTo>

    <Request>%SiteURL%/_vti_bin/Lists.asmx</Request>

    <SOAP>

        <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

            <soap:Body>

                <UpdateListItems xmlns="http://schemas.microsoft.com/sharepoint/soap/">

                    <listName>VisitorInfo</listName>

                    <updates>

                        <Batch OnError="Return">

                            <Method ID="1" Cmd="New">

                                <Field Name="User">%CWUserID%</Field>

                                <Field Name="FileDownloaded">%sw%</Field>

                            </Method>

                        </Batch>

                    </updates>

                </UpdateListItems>

            </soap:Body>

        </soap:Envelope>

    </SOAP>

    <SOAPAction>http://schemas.microsoft.com/sharepoint/soap/UpdateListItems</SOAPAction>

    <UseCurrentUserCredentials>2</UseCurrentUserCredentials>

    <OutputType>text/xml</OutputType>

    <Values>

        <sw />

    </Values>

</Data>

Notice that we use our %sw% parameter in a couple spots in the connection file, first you’ll see it in the <RedirectTo> node, this tells the EDP to redirect it’s web request to the supplied value, in this case it will be the path of the file to be downloaded.  We also use the %sw% parameter to store that URL in our FileDownloaded column in the VisitorInfo custom list we created.

 The hard part has now been created and configured, the next task we need to complete is to create a new Web Part Page (Site Actions > Create) and we’ll name ours VisitorsDP.aspx, we’ll use “Full Page, Vertical” and we’ll save it to our Provider library we created.  Our new web part page will be opened in edit mode, so we’ll click on “Add a Web Part” and select our External Data Provider.  Now we need to setup the EDP, so we click on “Edit” and select “Modify Shared Web Part” and we need to set two properties.  First, under the “Source XML” group, we’ll set our “Source XML File Location” property to point to the connection file we created above:

 <%SiteURL%>/Connections/VisitorSource.xml

 Note: The %SiteURL% parameter is another built-in CorasWorks parameter that will return back the path of the current site that we are in.

 The second property we need to set is under the “Output Properties” group and that is to check the “Output To XML” property.  Once we have these set, we click “OK” and refresh our page… the page should return us information about our call to the web service with some error information that would look something like:

<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>

        <UpdateListItemsResponse xmlns="http://schemas.microsoft.com/sharepoint/soap/">

            <UpdateListItemsResult>

                <Results>

                    <Result ID="1,New">

                      <ErrorCode>0x00000000</ErrorCode>

                      <ID />

                      <z:row ows_ContentTypeId="0x010002C6DFE43EC9F549B89508FE53C52E4C" ows_User="CW\kdager" ows_DownloadDate="2009-04-07 15:30:06" ows_ID="2" ows_ContentType="Item" ows_Modified="2009-04-07 15:30:06" ows_Created="2009-04-07 15:30:06" ows_Author="90;#Kevin Dager" ows_Editor="90;#Kevin Dager" ows_owshiddenversion="1" ows_WorkflowVersion="1" ows__UIVersion="512" ows__UIVersionString="1.0" ows_Attachments="0" ows__ModerationStatus="0" ows_SelectTitle="2" ows_Order="200.000000000000" ows_GUID="{10485444-B8F2-49F8-81C2-52366E3DD1FB}" ows_FileRef="2;#dager/ws/Lists/VisitorInfo/2_.000" ows_FileDirRef="2;#dager/ws/Lists/VisitorInfo" ows_Last_x0020_Modified="2;#2009-04-07 15:30:06" ows_Created_x0020_Date="2;#2009-04-07 15:30:06" ows_FSObjType="2;#0" ows_PermMask="0x7fffffffffffffff" ows_FileLeafRef="2;#2_.000" ows_UniqueId="2;#{FE9CEC14-FC47-44C1-808B-A404EC29707D}" ows_ProgId="2;#" ows_ScopeId="2;#{D6B4CB69-82DC-4807-A211-E241DB00ADD6}" ows__EditMenuTableStart="2_.000" ows__EditMenuTableEnd="2" ows_LinkFilenameNoMenu="2_.000" ows_LinkFilename="2_.000" ows_ServerUrl="/dager/ws/Lists/VisitorInfo/2_.000" ows_EncodedAbsUrl="http://devrapps.corasworks.net/dager/ws/Lists/VisitorInfo/2_.000" ows_BaseName="2_" ows_MetaInfo="2;#" ows__Level="1" ows__IsCurrentVersion="1" xmlns:z="#RowsetSchema" />

                      </Result>

                  </Results>

              </UpdateListItemsResult>

          </UpdateListItemsResponse>

      </soap:Body>

  </soap:Envelope>

 The reason this returns in this fashion is because we setup our EDP to expect a value being passed in, remember our %sw% parameter we configured?

 Everything is now setup for our tracking purposes.  What SuperSoft will do from this point, is on their main software download page, instead of setting the file download URL to the actual file itself, they would set their link to first call the EDP and pass in the URL of the file to download:

http://www.supersoft.com/software/providers/VisitorDP.aspx?sw=http://www.supersoft.com/software/download/superproduct.zip

 As soon as the end user clicks on the link to download the software, the EDP logs the needed info, calls the redirect which will immediately begin the download process, seemless to the end user.  When we check our VisitorInfo list, we’ll see we have user info tracked!

Happy Coding!

Posted by Steve P. Evangelista on 6-Mar-09

The latest release of the Data Integration Toolset provides expanded field validation within the Business Data Form Adapter.

Below you will find the configuration for setting up field validation.  In the configuration below, TestField is being compared to TestField2.  In order to pass the validation rule, TestField must equal TestField2.  If they are not equal, a validation message will appear and the form will not submit.

<Control type="TextBox">

    <ControlName>TestField</ControlName>

    <ControlSize>150</ControlSize>

    <DefaultText>2</DefaultText>

    <ValidationRules>

        <Validation type="fieldcompare">

            <Child>TestField2</Child>

            <Value>equal</Value>

            <ConvertValueTo>number</ConvertValueTo>

        </Validation>

    </ValidationRules>

</Control>

<Control type="TextBox">

    <ControlName>TestField2</ControlName>

    <ControlSize>150</ControlSize>

    <DefaultText>1</DefaultText>

</Control>

In the <ValidationRules> node, you will find the <Validation> node which indicates that a fieldcompare rule is being established.  You have a number of comparison options listed in the table below.

The Child node indicates which field the current control is being compared to.  And the Value node indicates what type of compare will occur.

The ConvertValueTo indicates how the fields should be treated when being compared.  The table below lists the valid field conversion options.

This expanded validation capability has certainly added a lot of value for doing form validation using the Business Data Form Adapter.  If more complex validation needs to take place, you can always write javascript to do other kinds of validation on fields.  For an example on how to implement this technique, please check out this blog post that discusses Date Validation.

Rodney Fickas

Professional Services

Posted by Rodney Fickas on 6-Mar-09

Posted by Steve P. Evangelista on 2-Mar-09

A scenario came up when saving a masked date control in the Business Data Form adapter back to SharePoint through Web Services, if a value was not specified the masking characters will be sent into the SharePoint web service. The SharePoint Web Services expect the date to be in a format of yyyy-MM-dd, however in the case of the date control, without the date control being a required field, the date would be passed into the Web Services in an invalid format (similar to ‘____-__-__’) and cause an error because it is not a valid date.

With the CorasWorks controls, the ability to alter the control’s properties is available by using the function GetClientIDValues(a, b); Where a is the title of the Business Data Form Adapter web part and b is the name of the CorasWorks control. So using this function the javascript: document.getElementById(GetClientIDValues(a, b)) you can gain access to all the control’s properties.

So now in our BDF source, we can create a javascript function to validate the date control to make sure that if the date isn’t required, that we format the value being passed to allow the save to be successful. To make this work, we must specify the CheckValue() method in the “Extra Methods” property of the BDF. This entry would look like: var Page_IsValid = CheckValue(); This instructs the BDF to call the CheckValue() function when we submit the form.

function CheckValue()

{

    if (document.getElementById(GetClientIDValues(a, b)).value == "____-__-__")

    {

        document.getElementById(GetClientIDValues(a, b)).value = "";

        Page_IsValid = true;

        return true;

    }

}

Posted by Steve P. Evangelista on 17-Feb-09

I recently posted about how many times in Toolset implementations there is a requirement to pop-up a window. Often times these pop-ups come from a grid display so you can display a Business Data Form Adapter for editing information. And at other times to display a new form for creating new items.

In my last post (you can find it here), I outlined how to use a third-party CSS pop-up window. There are a number of script files needed to make that work and managing those script file references can become cumbersome.

Since that blog was posted, CorasWorks released version 1.3 of the Toolset. In this release, there are many new capabilities. And I’m sure we will be blogging about them in the near future.

But as it pertains to this pop-up requirement, we are now able to handle very nice looking pop-ups using the updated Page Utility web part.

The implementation is straightforward and I walk you through the steps below.

1) Add a Page Utility web part to the page where you would like to have a pop-up

2) You will want to hide this web part

3) Configure the Windows Setup property under Page Loader Setup Properties (I’ve shown a simple configuration below but there are many different configuration options.)

<popup>

<window>

<ID>Admin</ID>

<Width>1024</Width>

<Height>300</Height>

<VisibleOnPageLoad>false</VisibleOnPageLoad>

<VisibleStatusBar>false</VisibleStatusBar>

<Modal>true</Modal>

<Title>Add New Account</Title>

<Skin>WebBlue</Skin>

<MinimizeZoneID>holdminimizehere</MinimizeZoneID>

<KeepInScreenBounds>true</KeepInScreenBounds>

</window>

</popup>

4) Note what you put in the ID node it will be needed when invoking the window from your display

In the screenshot below, we have a Content Editor Web Part (CEWP) that is providing a way for the user to open a new window for adding new accounts. The HTML for that CEWP is provided below.

5) Drop a CEWP on your page and include the following HTML

<table height="25" cellpadding="2" width="100%" class="ms-toolbar" border="0">
<tr>
<td class="ms-toolbar">
<a style="text-decoration: none" href="#" onclick="CWChangeWindowLocationAdmin(
'AccountAdmin.aspx');">
<img align="absmiddle" border="0" alt="Add New Account" src="/_layouts/images/newitem.gif"
style="border-width:0px;" width="16" height="16"/>
</a>
<a href="#" onclick="CWChangeWindowLocationAdmin('AccountAdmin.aspx');">Add New Account</a>
</td>
</tr>
</table>

Notice the “onclick” script for the icon and the Add New Account text link. The CWChangeWindowLocation script is built-in script that will open a new window. By appending your ID (Admin) from the Window Setup property, it references the right setup for which window to open. The AccountAdmin.aspx will be loaded in the pop-up.

The result when the user clicks on the link in the CEWP is this very professional looking pop-up. No managing of scripts is necessary.

Rodney Fickas

Professional Services