Did you try to consume data from webs.asmx into InfoPath Forms?
I did, and found problems, as InfoPath was not able to generate the full schema (or SharePoint did not generate the expected WSDL).
Although there are some limitations in the Web Services InfoPath support http://msdn.microsoft.com/en-us/library/bb852081.aspx
I manage to change imported schema in order to get subwebs from a site. So feel free to get the attached file if you found the same problem.
The problem with SP web services is that they like to use raw untyped XML (<xs:any/>) in both requests and replies, something that neither InfoPath nor many other tools (such as SSIS) like.
We just ended up writing our own Web services to wrap all SharePoint ones, with proper WSDL.
Yes. You can check this behaviour in the above Url.
The main goal here is not deploying new components and leverage the existing WebServices.
Creating a "WebService Proxy" for InfoPath may introduce complexity as the limitations need to be managed at Server level.
On the other hand creating WebService proxy in order to minimize attack surface, is really a good idea.
Web Service Requirements and Limitations
To work correctly with InfoPath, a Web service must provide the following features:
The Web service response must conform to the same schema at run time as it did at design time.
When you import XML Schema Definition (XSD) schema definitions that are defined in the WSDL contract, you must import all XSD schema definitions.
InfoPath has the following limitations when connecting to Web services:
Handling of certain schema constructs:
Abstract complex types. Although InfoPath does support creating a form template from a schema that contains abstract complex types (which it represents as choice groups), it does not support these types in Web services.
xsi:nil. InfoPath does not respect xsi:nil in Web service schemas, and it does not set the xsi:nil value for elements submitted to a Web service.
Required xsd:any elements. If the Web service schema contains a required xsd:any element, InfoPath performs a sample query and infers the schema from what is returned by the Web service. At run time, InfoPath depends on the Web service response conforming to the same schema as the one InfoPath inferred at design time. If a form designer wants to specify something more complex than what InfoPath infers, the Web service designer must modify the WSDL file to specify the exact schema for the response required by the desired form design.
InfoPath does not support multiple namespaces in some SQL Server 2005 Web service responses. For example, if an xsd:any schema element has a different namespace, InfoPath fails to design against it.
InfoPath cannot consume a Web service that has a space in the namespace name. For example, this occurs in Siebel Web services when one of your business objects has a space in the name. If your business object is named "Customer Expense", all Web services based on this object will have spaces in the namespace name. To work around this limitation, always create Siebel business objects with no spaces in the name, such as "Customer_Expense". For arbitrary Web services, you should consider the space to be a prohibited character.
InfoPath Web service support depends on the Microsoft SOAP Toolkit 3.0 and is bound by the limitations of that technology.
thanks for this post and attachment. Can you explain to me how to implement the attached files? I am trying to get the number of subwebs from a site and have had no luck with the web services..
Hi can you explain how to attach these to the infopath form.