31 July 2005

I'm so excited


I’m getting so excited!
I’m leaving for Redmond tomorrow for the Office 12 TAP kick off.
The best part about it is of course SharePoint 3.
All we’ve had thus far has been web casts.
This week, we actually get the bits to play with!  SWEET! 
Later
C

Google+image

29 July 2005

InfoPath treating fields as protected



While working on a InfoPath/SharePoint/BizTalk solution, I ran into a strange oddity.  The solution basically takes HL7 data feeds in BizTalk and then using the WSSLib adapter it writes the record to a Windows SharePoint Services based form library.  Users then interact with the data in the form library via the InfoPath form.  Simple right…
So while conducting my testing I found that some of the fields are protected.   In this case I was able to see both the WorkPhone field and the WorkPhoneExt field, but I was only able to update the WorkPhone field.  Now what is up with that???
OK, so obviously the schema definition of the fields in question must be different from the other surrounding fields that do work right.  Take a look at the schema and see if you can spot the problem…


xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003"xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="PAS_Record">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" name="EventCode" type="xs:string" />
        <xs:element minOccurs="0" name="MedicalRecordNum" type="xs:string" />
        <xs:element minOccurs="0" name="RegNum" type="xs:string" />
        <xs:element minOccurs="0" name="PreRegNumber" type="xs:string" />
        <xs:element minOccurs="0" name="LastName" type="xs:string" />
        <xs:element minOccurs="0" name="MaidenName" type="xs:string" />
        <xs:element minOccurs="0" name="FirstName" type="xs:string" />
        <xs:element minOccurs="0" name="MI" type="xs:string" />
        <xs:element minOccurs="0" name="SSN" type="xs:string" />
        <xs:element minOccurs="0" name="DOB" type="xs:string" />
        <xs:element minOccurs="0" name="Gender" type="xs:string" />
        <xs:element minOccurs="0" name="PrimaryLanguage" type="xs:string" />
        <xs:element minOccurs="0" name="Race" type="xs:string" />
        <xs:element minOccurs="0" name="MaritalStatus" type="xs:string" />
        <xs:element minOccurs="0" name="Address" type="xs:string" />
        <xs:element minOccurs="0" name="City" type="xs:string" />
        <xs:element minOccurs="0" name="State" type="xs:string" />
        <xs:element minOccurs="0" name="Zip" type="xs:string" />
        <xs:element minOccurs="0" maxOccurs="unbounded" name="Telephone">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" name="HomePhone" type="xs:string" />
              <xs:element minOccurs="0" name="HomePhoneExt" type="xs:string" />
              <xs:element minOccurs="0" name="WorkPhone" type="xs:string" />
              <xs:element minOccurs="0" name="WorkPhoneExt" type="xs:string" />
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</
xs:schema>

Well can you spot it?  Don’t feel bad if you weren’t able to identify the problem.  I didn’t see it either… because it wasn’t there!!!  Note these comparisons:
        <xs:element minOccurs="0" name="RegNum" type="xs:string" />


<<>>
        <xs:element minOccurs="0" name="PreRegNumber" type="xs:string" />

<<>>
type="xs:string" />
        <xs:element minOccurs="0" name="Race" type="xs:string" />
<<>>
        <xs:element minOccurs="0" name="PrimaryLanguage"

type="xs:string" />
<<>>
              <xs:element minOccurs="0" name="HomePhone" type="xs:string" />


<<>>
              <xs:element minOccurs="0" name="HomePhoneExt" type="xs:string" />

<<>>
              <xs:element minOccurs="0" name="WorkPhone" type="xs:string" />

<<>>
              <xs:element minOccurs="0" name="WorkPhoneExt" type="xs:string" />

<<>>

OK, since the form was derived from simply dragging the schema onto the canvas, maybe the fields got defined different somehow.  So I proceeded to check the properties of each of the InfoPath edit boxes for the fields in question as well as surrounding fields.  Here’s the properties comparison between RegNum and PreRegNumber displaying a snapshot of each pane first for RegNum then for PreRegNumber:

Data tab
 

Display tab
 

Size tab
 

Advanced tab

So did you notice any difference?  Well, neither did I.  OK, so we’ve eliminated schema differences… we’ve eliminated form property differences… what is going on here? 
So I posted to microsoft.public.infopath because surely there’s an InfoPath MVP genius out there who knows the answer right?  
No takers… Nothing… Nada… Zip… Zigalo… Didley Squat!
Mmm… guess I’m on my own on this one… so I started playing around a some more.  At home that night I was not connected to corporate VPN for BizTalk to generate the XML documents in the library, so I figured I’d just fill it out directly.  Same difference right?  Well it turns out when I edit the document directly from WSS, I don’t have the restrictions on my fields.   OK, now I’m doubly confused, but it does give me something to work with.  My first thought was that the direct edit is creating a new document while editing the BizTalk generated documents is editing an existing document.  I tested the theory by inserting all the same fields as the BizTalk document, saving it and then going back to edit it again…
Well, I was able to still edit my document.  So what then is the problem?  I saved both XML files to my local machine and then used my trusty tool for file comparison CompareIt! 3 by Grig Software to spot the difference.  Here’s the BizTalk generated XML document:

xml version="1.0" encoding="utf-8"?>
mso-infoPathSolution solutionVersion="1.0.0.1" productVersion="11.0.6357"PIVersion="1.0.0.0" href="http://home/sites/pas/PASInput/Forms/template.xsn"name="urn:schemas-microsoft-com:office:infopath:PASInput:" language="en-us" ?>
mso-application progid="InfoPath.Document"?>

<PAS_Record>
  <EventCode>A08</EventCode>
  <RegNum>1111111111</RegNum>
  <LastName>Doe</LastName>
  <MaidenName></MaidenName>
  <FirstName>John</FirstName>
  <MI></MI>
  <SSN>123456789</SSN>
  <DOB>19700101</DOB>
  <Gender>M</Gender>
  <Race>W</Race>
  <MaritalStatus>M</MaritalStatus>
  <Address>1 My Way</Address>
  <City>Indianapolis</City>
  <State>IN</State>
  <Zip>46254</Zip>
  <Telephone>
    <HomePhone>(317)555-5555</HomePhone>
    <WorkPhone></WorkPhone>
  </Telephone>
</
PAS_Record>

And here’s the WSS generated XML document:

xml version="1.0" encoding="utf-8"?>
mso-infoPathSolution solutionVersion="1.0.0.1" productVersion="11.0.6357"PIVersion="1.0.0.0" href="http://home/sites/pas/PASInput/Forms/template.xsn"name="urn:schemas-microsoft-com:office:infopath:PASInput:" language="en-us" ?>
mso-application progid="InfoPath.Document"?>
<PAS_Record>
  <EventCode>A08</EventCode>
  <RegNum>1111111111</RegNum>
  <PreRegNumber></PreRegNumber>
  <LastName>Doe</LastName>
  <MaidenName></MaidenName>
  <FirstName>John</FirstName>
  <MI></MI>
  <SSN>123456789</SSN>
  <DOB>19700101</DOB>
  <Gender>M</Gender>
  <PrimaryLanguage></PrimaryLanguage>
  <Race>W</Race>
  <MaritalStatus>M</MaritalStatus>
  <Address>1 My Way</Address>
  <City>Indianapolis</City>
  <State>IN</State>
  <Zip>46254</Zip>
  <Telephone>
    <HomePhone>(317)555-5555</HomePhone>
    <HomePhoneExt></HomePhoneExt>
    <WorkPhone></WorkPhone>
    <WorkPhoneExt></WorkPhoneExt>
  </Telephone>
</PAS_Record>

Can you spot the problem?  If not, take a look at this snapshot from CompareIt!.


As you can see, the WSS version actually included a node for each field while the BizTalk version did not…
The bottom line…
InfoPath will protect all fields in a form that maps to a schema for which the underlying data document does not have a representative node… weird but true!

Later
C

Google+image

Microsoft Authentication Library (MSAL) Overview

The Microsoft Authentication Library (MSAL) is a powerful library designed to simplify the authentication process for applications that conn...