InfoPath Repeating Table Lookup control on SharePoint List

Scenario: I have Repeating table control in my InfoPath form which look like this

and I am biding this Repeating table to a repeating group “Test” with four fields

1. 1) Title
2. 2)Name
3. 3)Amount
4. 4)Date

I have a test list:

 

I create a data connection to this library in my InfoPath form. I then bind my Title dropdown to the Title column in the list.  What I want to happen is when user selects the a value in title he other fields in the form get auto-populated based on current Title selection, as shown below:

To achieve this, I have created a data connection “Test” and I have dropdown in the Title column and I am binding it to Title field from the data connection:

Then I added the rule on DropDown box select, that will set the Name column of the repeating table with Name1 field on the data connection filter by title@combobox=title@test-data-connection:

XPath of the rule is: xdXDocument:GetDOM("Test")/dfs:myFields/dfs:dataFields/dfs:Test/@Name1[../@Title = xdXDocument:get-DOM()/my:myFields/my:Test/my:Title]

Issue: I published the form hoping that this will work fine, and found this:

The issue I am facing is that if I select "A1" first, it returns the correct value of “John”, but if I add a new row to the table, and choose, say "A5", that too comes back as “John”. What’s more weird is that if I select "A5" as first row, then any subsequent rows work fine. It looks like first row returns back all the data from the list up to the value selected. If you choose "A1", you only get first row from the list, but if you choose "A5" you will get all the rows up to this item.

Solution: After googling for this behavior I found that XPth “current()” function should fix this problem. I modified the XPath on the rule as:

XPath for the rule looks like this:

xdXDocument:GetDOM("Test")/dfs:myFields/dfs:dataFields/dfs:Test/@Name1[../@Title = current()/../my:Title]

and that’s it, I am able to see the result I was hoping for.

InfoPath: Displaying SharePoint Group List Using “GetGroupCollectionFromUser” method

 

In this post I will show a method to display Group membership of a user without writing any code behind in InfoPath form. This method will take advantage of the usergroup.asmx web service. We will try to get data from “GetGroupCollectionFromUser”.

Creating a Secondary Data Connection to UserGroup.asmx web service

1) Create a new Data Connection from “Tools” menu:

 

2) Create “Receive Data” connection:

3) Select Web Service as source of data:

4) Give service address (it should be http://youserver/_vit_bin/usergroup.asmx):

you can check in the browser first:

5) Select GetGroupCollectionFromUser web method:

6) Give a real username otherwise this will not allow you create the connection:

You can leave next step blank as we will specify the input parameter from a input field: 

7) We will not store a copy of data for this example but you can chose to do that:

8) I will give this connection a friendly name and will not try to automatically get data on opening form as I will specify the input parameter once form is loaded:

 

Saving Form as Source File

Once you have followed the above steps, you can choose data source in the tab view and see the fields available to you in this connection:

As you can see above return fields in the connection do not reflect the fields that are returned by the web service. To correct these fields we will have to modify the schema file. To modify the schema first same the form as “Source Files”:

Once you have done that you can browse to the folder and see the following files in uncompressed form:

  

File of our interest is GetGroups1.xsd.

 

Correcting the xsd for the Return Fields

In the code below you will see that GetGroupCollectionFromUser method return fields are not same the fields specified by the method in MSDN site: http://msdn.microsoft.com/en-us/library/ms772552.aspx.

<s:element name="GetGroupCollectionFromUser">

        <s:complexType>

            <s:sequence>

                <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string"></s:element>

            </s:sequence>

        </s:complexType>

    </s:element>

    <s:element name="GetGroupCollectionFromUserResponse">

        <s:complexType>

            <s:sequence>

                <s:element minOccurs="0" maxOccurs="1" name="GetGroupCollectionFromUserResult">

                    <s:complexType mixed="true">

                        <s:sequence>

                            <s:any></s:any>

                        </s:sequence>

                    </s:complexType>

                </s:element>

            </s:sequence>

        </s:complexType>

    </s:element>

According to the article we should have the schema which reflect following fields:

Return Value

<GetGroupCollectionFromUser xmlns=
   "http://schemas.microsoft.com/sharepoint/soap/directory/">
   <Groups>
      <Group ID="3" Name="Group1" Description="Description" OwnerID="1" 
         OwnerIsUser="False" />
      <Group ID="15" Name="Group2" Description="Description" 
         OwnerID="12" OwnerIsUser="True" />
      <Group ID="16" Name="Group3" Description="Description" 
         OwnerID="7" OwnerIsUser="False" />
   </Groups>
</GetGroupCollectionFromUser>

In order to correct the fields we will modify the GetGroups1.xsd file as following:

 

1) Add new “ComplexType” definition to the GetGroups1.xsd:

Just below this line:

<s:import namespace="http://www.w3.org/2001/XMLSchema"></s:import>

 

Add this section:

<s:complexType name="GetGroupCollectionFromUserType">

   <s:sequence>

     <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string"/>

     <s:element minOccurs="0" maxOccurs="1" name="Groups">

       <s:complexType>

         <s:sequence>

           <s:element maxOccurs="unbounded" name="Group" >

             <s:complexType>

               <s:attribute name="ID" type="s:unsignedShort"></s:attribute>

               <s:attribute name="Name" type="s:string"></s:attribute>

               <s:attribute name="Description" type="s:string"></s:attribute>

               <s:attribute name="OwnerID" type="s:unsignedByte"></s:attribute>

               <s:attribute name="OwnerIsUser" type="s:string"></s:attribute>

             </s:complexType>

           </s:element>

         </s:sequence>

       </s:complexType>

     </s:element>

   </s:sequence>

 </s:complexType>

 

2) Replace:

<s:element name="GetGroupCollectionFromUser">

        <s:complexType>

            <s:sequence>

                <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string"></s:element>

            </s:sequence>

        </s:complexType>

    </s:element>

with:

<!--<s:element name="GetGroupCollectionFromUser">

      <s:complexType>

          <s:sequence>

              <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string"></s:element>

          </s:sequence>

      </s:complexType>

  </s:element>-->

<s:element name="GetGroupCollectionFromUser" type="tns:GetGroupCollectionFromUserType" />

After Saving the changes

Once you save the GetGroups1.xsd file right click Manifest.xsf file and chose design. Now is you choose data source you will able to see the new fields:

I drag-dropped the “Group” repeating group as “repeating table” and a text-field to input the username.

Note: You have to provide fully qualified name domain name (domain\username) in order to get the group data.

Requirements Engineering for Software Project and Project Failures

Requirement gathering is the basic activity to ask stack holders in a project “What the need/value of the system”? It is very important to also know how the current state of things are and how this system will address those concerns/challenges.

Pitfalls in Requirement Engineering

Wrong Requirements: If we fail to gather correct requirements we will end up producing system that is not desired or a system with missing feature that other competing products will have.

Missing Requirements: Not talking/recognizing to all the stack holder may result in missing requirements. Usually a system will multiple type of stack holders like management, end user, administrators. If you do not address them you might end up delivering a system with missing feature like (Reports, usability or configuration management plan, deployment paths).

Changing Requirements: Not foreseeing the need of requirement changes. Requirements changes, it is an inevitable fact in software project. Most project team do not have plan to incorporate the changing requirements. This is eventually lead to failed project/product.

 

Consequences of Failing in Requirements Engineering

Failed products with unwanted functionality.

Projects late in delivery. Projects run over-time and over-budget.

Systems with missing functionalities.

System with poor quality.

Incorrect technology or tools.

 

Requirement Engineering Categories

Market Requirements/Externals Requirements: Should provide by the client or the marketing analysis team. What product should do. Owners should be involved.

Product Requirements/Features Set: These requirements drives the future functionality and enhancements addressing marketing requirements.

Component Requirements: These are the low level requirements that are addressing how the system will the addressing the features that are requested by product requirements.

Functional/Non-Functional Requirements: Functional requirements are the explicit requirements that clients expects from the system. Non-functional requirements are the implicit or quality attributes of a system like usability, maintenance, scalability of a system.

 

Requirement Engineering Activities

Requirements Elicitation: Requirement Elicitation is the process of exactly stating what users want from the system. This process should provide a way for closure to all system requirements. Elicitation failures can show up as late as user acceptance testing. Before this step can starts it is very important to remove internal conflicts between the users.  

In 1994, the Federal Aviation Administration (FAA) canceled its 10-year 
effort to modernize the nation's air control system. $1.3 billion was 
written off. Requirements elicitation phase was incomplete.This is one of 
the most expensive development failure due to a requirements failure.

Challenges in requirements elicitation:

• Lack of User Inputs.



• Lack of development team involvement.



• Failure to remove “Yes, but..” reaction of the user when they first see the system. Team should try to get “This is cool” reaction from the end users.



• Recognizing the scope of elicitation (when to stop elicitation activity).

 

Requirements Analysis:

This one of the more studies area of requirement engineering. You can find more detailed description of it in wikipedia.  One of the largest failed system reported is NHS, more information can be found here. Another great article can be found on IEEE Spectrum portal.

 

Requirements Specification: A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. Modeling languages like UML can help a lot in this process, but the end goal of this activity is to communicate “what” or “how” things needs to be done to all the stack holders. Read more here.

Requirements Verification: Verification provide “traceability” of the activity with the business value. This activity helps you align every activity of the project with the real business need. Remember that a good requirement is the one that can be measured/tested against a business need. Verification  is an ongoing process. Here is a good resource for requirement verification.

Requirements Management:  The purpose of requirements management is to assure the organization meets the expectations of its customers and internal or external stakeholders.

 

Always remember:

• Refractor processes. Through wasteful practices.



• Perfection us attend not when there is nothing to add but when there is nothing to take away.



• Add talent not skills.



• Software specifications: describes how problems will be solved. Written by software architects.



• Success is should be measured in business values.



• Great software can fail when they do not provide ROI to organization.



• It takes 25 min to regain train of thought. On an average distractions costs 30% of the day.



• Don't measure software teams against wrong parameters. Measuring number of hours is BIG mistake. Hours measure "more" Or "faster" not "critical" work. Also suffers from degraded quality as a side affect.



• Projects depend on teamwork.



• Do not try to write perfect system/code. Do not run after complete knowledge.



• Promote communication among team members.



• Always keep Your eye on the END.

 

Utilities and Resources;

http://www.processimpact.com/goodies.shtml#reqs

 

Failed Projects and analysis:

http://spectrum.ieee.org/blog/computing/it/riskfactor/tennessees-erp-project-mess http://spectrum.ieee.org/blog/computing/it/riskfactor/good_it_news_bad_it_news_at_de http://spectrum.ieee.org/blog/computing/it/riskfactor/philadelphias_serial_it_blunde http://spectrum.ieee.org/print/1455 http://it-project-failures.blogspot.com/