RSS

Monthly Archives: 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
 
1 Comment

Posted by on July 31, 2005 in SharePoint

 

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&quot; xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

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

<<<works…>>>

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

<<<fails…>>>

type="xs:string" />

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

<<<works…>>>

        <xs:element minOccurs="0" name="PrimaryLanguage"

type="xs:string" />

<<<fails…>>>

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

<<<works…>>>

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

<<<fails…>>>

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

<<<works…>>>

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

<<<fails…>>>

 

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&quot; 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&quot; 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

 

 
3 Comments

Posted by on July 29, 2005 in Office

 

And the winner is…

OK, so I’ve been blogging for a while, but I’ve tried different blog engines and they always seem to come up short.  It’s not like I’m looking for spectacular features.  I figure a decent blog engine needs:
  1. RSS syndication.
  2. In line screen prints.
  3. Color coded, font differentiated code paste.
  4. Trackbacks.
  5. Comments.
  6. Lists.

That’s it.  I’m not asking for the world, but all the free on-line blog engines I tried (now granted I didn’t try them all) were coming up short on one thing or another.  Anyway, I thought about hosting my own blog engine on my web server.  It was a toss up between b2Evolution and DasBlog.  Then I began to notice all the posts for security patches that needed to be installed and I knew maintaining a blog engine would be a royal pain in the but!

Then I happened to read a regular article by one of my colleagues, Tim Landgrave, which contained a link to his blog.  It turned out he was using MSN Spaces.  I had looked at Spaces when it was in Beta and wasn’t too impressed at first glance.  I decided to take another look…

Sure enough, Spaces supports all my basic needs for a blog engine.  Given my limited time and full schedule, having to run my own blog engine just doesn’t make sense, so I decided to consolidate all my blogs here…

WELCOME!!!

Of course it will take me some time to get all my other blog entries from all over transferred here… if ever… oh well… just another day in paradise!

 

Later
C

 

 
1 Comment

Posted by on July 28, 2005 in Musings