InfoPath Dev

Hi,

I'm trying to send a request to a web service (written in C#) from an Infopath form. The web service method I'm trying to access doesn't take simple parameters (string, int, ...) but a complex object containing various fields, an array of strings and an array of integers.

Visual Studio suggests the SOAP request for that method should look like this :

<?xml version="1.0" encoding="utf-8"?>
<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>
    <insererContenu xmlns="http://tempuri.org/">
      <c>
        <id_contenu>int</id_contenu>
        <titre>string</titre>
        <chemin>string</chemin>
        <internet>int</internet>
        <restreint>int</restreint>
        <id_rubrique>int</id_rubrique>
        <mots_cles>
          <anyType />
          <anyType />
        </mots_cles>
        <acces_restreint>
          <anyType />
          <anyType />
        </acces_restreint>
      </c>
    </insererContenu>
  </soap:Body>
</soap:Envelope>

And the data contained in my Infopath form looks like this :

<?xml version="1.0" encoding="UTF-8"?>
<?mso-infoPathSolution solutionVersion="1.0.0.77" 
productVersion="11.0.6357" PIVersion="1.0.0.0" 
href="file:///D:\Dev\InfoPath\cms_test\...PublierContenu.xsn" 
name="urn:schemas-microsoft-com:office:infopath:PublierContenu:-myXSD-2005-08-25T08-37-41" ?>
<?mso-application progid="InfoPath.Document"?>

<my:InsererContenu 
xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2005-08-25T08-37-41"
 xmlns:xd="http://schemas.microsoft.com/office/infopath/2003" 
xml:lang="fr">
	<my:c>
		<my:id_contenu xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></my:id_contenu>
		<my:titre>test</my:titre>
		<my:chemin>test</my:chemin>
		<my:internet>0</my:internet>
		<my:restreint>0</my:restreint>
		<my:id_rubrique>2</my:id_rubrique>
		<my:mots_cles></my:mots_cles>
		<my:acces_restreint></my:acces_restreint>
	</my:c>
</my:InsererContenu>

As you can see, the SOAP request required by the web service method and the InfoPath form data have basically the same structure.

When I submit the form, InfoPath indicates that the operation succeeded, but the web service method is unable to access the elements contained in the object passed as a parameter : they are all null !

I tried to change the parameter settings in the InfoPath data source wizard (send whole form, send data as string, field or group...) but the result remained the same.

1) Is there a way I can capture the SOAP request sent to the web service, so that I can really see if it has the right structure ?

2) Do you see an obvious reason why the web service method wouldn't accept that SOAP request ?

Any comment/solution welcome

Thanks in advance

Hi Maximilian,

It's possible that your webservice don't like the prefix of namespace "my:" and that make an error ! I have the same probleme as you before but now I send it with the code It's more easy

I have some probleme to do one of my send in a webservice because infopath put an attribute xml:lang="fr" (for dictionnary I suppose) in the root markup of my xml! And the schema can't validate it in the Webservice


You can send this with code! but don't forget to make a WEB reference in your project

For example:

using AG_Feststellungsurkunde.ch.powernet.zefix;

...
...


ch.powernet.zefix.WordML NewTrans = new WordML();

//appel du WS	
string Transformed = NewTrans.OpenWord(thisXDocument.DOM.selectSingleNode("/ns1:Case/@ns1:Termin").text, ....);

And with this you can catch the return of the webservice if he has one!

Sorry I don't know how to see what infopath send when he send a soap request! But if your webservice is in debug mode "Il peux peut-être" catch the infopath send!

++

Thierry

Every moment hesitated is a moment gone for life!!! Think about it

Hello
There is one way to solve this issue. Instead of taking a submit connection to this function. Take a recieve data connection to it. Now you have the DOM of this web service connection available as a secondary DOM. On the button that you click to submit the data to the web service, add rules to set the various values in the secondary DOM from the main DOM and call Query on this data connection. The fields where you set the data will be in the queryFields part of the DOM. Any output that the web service returns will be in the dfs:dataFields node

This will call the web service function and the data will be submitted to it.

Virgul is most probably right -> the reason why the web service is failing is because you have the my: prefix in your main which is not present in you Web service.

Let us know if you still have issues.

Shanthi
InfoPath Dev India

Hi Shanthi

Thanks for your answer, I'll try that too.

At the moment, I'm attempting to do a code-based call to the web service like virgul suggested :

 try{
//Get a reference to the SendXMLNode secondary data source
IXMLDOMDocument2 objSendXMLNode = 
(IXMLDOMDocument2)(thisXDocument.GetDOM("Envoi"));
objSendXMLNode.setProperty( "SelectionNamespaces",			"xmlns:s1=\"http://joelallxp.microsoft.com/schema\" " +
"xmlns:s0=\"http://tempuri.org/\" " +		"xmlns:dfs=\"http://schemas.microsoft.com/office/infopath/2003/dataFormSolution\"" );

//Remove any data from the SendXMLNode secondary data source
IXMLDOMNode objData = objSendXMLNode.selectSingleNode(
				"/dfs:myFields/dfs:queryFields/s0:SendXMLNode/s0:Envoi");

//Clone the XDocument (or the element with the repeating children)
IXMLDOMNode objClonedDocument = 
thisXDocument.DOM.selectSingleNode("/tns:insererContenu").cloneNode(true);
objData.appendChild( objClonedDocument );

//Call the "Query" method of the secondary data source to send the data
				thisXDocument.DataObjects["Envoi"].Query();
}
catch(Exception ex)
{
	//eventObj.ReturnStatus = false;
}

With this code, the InfoPath form is successfully sent but again, the web service method can't fetch the contents of the submitted data.
Note that this was basically JScript code that I adapted into C#, so there may be mistakes.

In addition, several remarks come to my mind :

- The my: prefix problem might not be the point, since I've tried to contact another method of the web service taking a simple string as a parameter, and it worked perfectly.

- I was afraid to see how poorly documented the Infopath / web service interface is on the net, especially in terms of C# code.
I know that Infopath is not so widespread, but that product is now several years old, so there should be experience feedback now, not to mention official stuff from Microsoft...

- Infopath is supposed to "fully integrate with Web Services" and "provide a rich client experience for Web Services XML data". So why do you have to find such workarounds as the one Shanthi suggested to make (rather simple) things work ?
I think there's a problem there.

Anyway, I'll try that solution and let you know if it works...

Hi,

try to go on the webpage of your webservice in debug mode enter your xml (instead of make your webservice in infopath formcode make a save of your xml(for do this put thisxdocument in xmldocument and make a save on your harddisk and after see what have inner)) in the query field of the webservice's webpage and send! see what happens in your webservice because it's possible that your webservice don't work correctly

I know Microsoft has make a program and don't make nothing to help developer! Shame on Microsoft! The only help that you can have is here! because on microsoft.public.infopath there are only question no answer(sorry for the MSFT who is on this forum and do is best but there are too much questions for answer to all)!

For this reason I wan't one more time thanks all the guys from autonomysytems to help us!

++

Thierry

Every moment hesitated is a moment gone for life!!! Think about it

Unfortunately, I can't test the web service by entering XML in the Visual Studio interface, because "the test form is available only for methods whose parameters are primitive types or array of primitive types".

I've noticed another strange thing about my web service data source in InfoPath. When I look into the manifest.xsf file, the web service is described as follows :

<xsf:webServiceAdapter
wsdlUrl="http://localhost/cms_test/backend/webservice_cms/Service1.asmx?WSDL"
queryAllowed="no" submitAllowed="yes" name="Envoi">
<xsf:operation name="insererContenu"
soapAction="http://tempuri.org/insererContenu"
serviceUrl="http://localhost/cms_test/backend/webservice_cms/Service1.asmx">
<xsf:input source="Submit19.xml">
<xsf:partFragment
match="/dfs:myFields/dfs:dataFields/tns:insererContenu/tns:c"
replaceWith="/my:PublierContenu"></xsf:partFragment>
</xsf:input>
</xsf:operation>
</xsf:webServiceAdapter>

So the xml data sent to the method seems to be stored in Submit19.xml.
However, when I look into that file, there's no data, just an empty structure :

<dfs:myFields xmlns:dfs="http://schemas.microsoft.com/office/infopath/2003/dataFormSolution" xmlns:tns="http://tempuri.org/">
<dfs:dataFields><tns:insererContenu><tns:c><tns:id_contenu></tns:id_contenu><tns:titre></tns:titre><tns:chemin></tns:chemin>
<tns:internet></tns:internet><tns:restreint></tns:restreint><tns:id_rubrique></tns:id_rubrique><tns:mots_cles><tns:anyType></tns:anyType></tns:mots_cles>
<tns:acces_restreint><tns:anyType></tns:anyType></tns:acces_restreint></tns:c></tns:insererContenu></dfs:dataFields></dfs:myFields>

Is that file supposed to contain the last data sent to the web service, or just a general structure ?

Hi,

Yes It's probably what is send to the webservice so two option:

You change your webservice or you make an XSLT for have the correct xml to send in your webservice! If you want some example for your XSLT ask!

++

Thierry

Every moment hesitated is a moment gone for life!!! Think about it

Shanthi, I've tried your method of calling a receive data connection. Here's the OnSubmit code I use :

IXMLDOMDocument2 objSendXMLNode = (IXMLDOMDocument2)(thisXDocument.GetDOM("insererContenu"));
				objSendXMLNode.setProperty( "SelectionNamespaces",
				"xmlns:s1=\"http://joelallxp.microsoft.com/schema\" " +
				"xmlns:s0=\"http://tempuri.org/\" " +

				"xmlns:dfs=\"http://schemas.microsoft.com/office/infopath/2003/dataFormSolution\"" );

				 objSendXMLNode.selectSingleNode("/dfs:myFields/dfs:queryFields/tns:insererContenu/tns:c/tns:titre").text = thisXDocument.DOM.selectSingleNode("/my:my:insererContenu/my:signatureGroup/my:titre").text;
				 objSendXMLNode.selectSingleNode("/dfs:myFields/dfs:queryFields/tns:insererContenu/tns:c/tns:chemin").text = thisXDocument.DOM.selectSingleNode("/my:my:insererContenu/my:signatureGroup/my:chemin").text;
				 objSendXMLNode.selectSingleNode("/dfs:myFields/dfs:queryFields/tns:insererContenu/tns:c/tns:internet").text = thisXDocument.DOM.selectSingleNode("/my:my:insererContenu/my:signatureGroup/my:internet").text;
				 objSendXMLNode.selectSingleNode("/dfs:myFields/dfs:queryFields/tns:insererContenu/tns:c/tns:id_rubrique").text = thisXDocument.DOM.selectSingleNode("/my:my:insererContenu/my:signatureGroup/my:id_rubrique").text;
				 objSendXMLNode.selectSingleNode("/dfs:myFields/dfs:queryFields/tns:insererContenu/tns:c/tns:restreint").text = thisXDocument.DOM.selectSingleNode("/my:my:insererContenu/my:signatureGroup/my:restreint").text;
				 thisXDocument.DataObjects["insererContenu"].Query();

However I get this error when submitting :

"InfoPath cannot send form data because the form template doesn't support them"

What's wrong with my code ?

Just my input, but I have not tried to build complex objects in a web service and then expect a client, like InfoPath, to use that complex object in a web method call. From a design point of view, that may not be the best approach. You would be coupling the web service and the InfoPath form. Suggest using pure XML to pass data to and from the InfoPath form and the web service. From a portability aspect that would be optimum because if the web service and the InfoPath form would not be dependant on .NET. Have you tried consuming XML in your web service and then using XmlSerializer in .NET to populate a complex object from the XML set into the web service? Just a thought…

Hi,

I'm quite new to .NET so I don't really know how to deal with raw XML data in a C# Web Service. All I can do is code my WebService class and the methods, and .NET does the rest...

Plus, what's the point of having such complex technologies as InfoPath and VS .NET if you can't take advantage of the integrated possibilities they provide ?
I mean I would be bothered if I had to code all those low-level operations myself. Don't tell me Microsoft didn't know programmers would want to submit more than a simple integer or string to a Web Service...

Call me lazy, but I would find it much easier (and normal after all) to do things the "conventional" way.


Thanks anyway, if I have no other choice I'll consider your advice ;)

Well, this really is not a Microsoft issue. When I referred to the word above "Portability" that means the code is not technology or platform dependant. This is why a lot of people do down the Java path. I do not to go off a tangent, but this is why InfoPath is SO powerful. XML is an independent standard that is not Microsoft defined. For instance lets say I create a web service in .NET, that web service can be called my a Microsoft .NET application or even a Java application running on a desperate machine not within an current enterprise of a company. So, if you are writing .NET complex objects into the web service method signature you could run into issues when other applications try to call the web service (suggest you do some research into Remoting as well and review the trade offs of a web service and remoting in .NET). If I were to use pure XML with a XSD there are no integration issues. Right now, I am writing an InfoPath form that makes web service calls to populate combos and lists directly from SQL Server, a Mainframe system and still allow for future requirements to access a SAP. Wow!!! I now have a completely integrated front end that is pulling data from all of these data sources and the InfoPath form is completely decoupled from the data sources because it calls a web service that passes back raw XML. Plus I can now re-use the web services in other technologies across this enterprise which may not be using .NET applications. As well, I am not an expert on SOAP but again it is a non Microsoft based technology that is an industry standard. This is not some Microsoft propaganda. Suggest you looking into the Gang of Four design patterns. Something like the Fascade pattern relates directly to what I am talking about.

Great article on 5 five things that a web service should not do.

http://www.theserverside.net/articles/showarticle.tss?id=Top5WSMistakes

I know this is an InfoPath forum but the first mistake is directly tied to this thread...

Great article!

Patrick Halstead [InfoPath MVP]
InfoPathDev

Vt, don't get me wrong. I'm not calling you a MS propagandist at all.

But the point is, I tried to set up a non-DotNet web service for my InfoPath form to communicate with.
I created the wsdl myself, respecting the xsd standards and everything (the web service was in PHP, but who cares).

It worked perfectly with a classical web service client but there's no way I could make it function in conjunction with Infopath because InfoPath *didn't accept* the wsdl definition.
That's why I thought an automatically generated DotNet web service could do the trick (though I was quite reluctant about it at first).

So I'm just saying that if InfoPath is not able to correctly interface with a slightly complex .NET web service, Microsoft have to stop their marketing b*****t about that product ("fully integrates with Web Services", "provides a rich client experience for Web Services XML data" and blah blah blah)...

Now if I have to change my web service parameters so that it takes a string instead of a complex type, I'll do it but it won't be very clean or self-descriptive.

Wow...did not know you were have problems getting InfoPath working with a web service that is not in .NET. Will have to give that a try sometime soon...had assumed there would be no issues there.